Управление виртуальной машиной iEx.ec

Мы продолжаем нашу серию статей, посвященных распределенному облаку iEx.ec основанному на технологии Блокчейн. В этой статье представлено управление виртуальной машиной iExec.

Вступление

Как описано в предыдущей статье, iExec относится к известной парадигме глобальных вычислительных платформ, которые реализуют трехуровневую архитектуру, где набор централизованных сервисов создается и доступен через интернет-соединение.

Эта серия статей стремится быть максимально краткой и поучительной, вводя парадигмы шаг за шагом. До сих пор мы вводили технологию в терминах, с которыми можно быть знакомым при обсуждении глобальных вычислений: децентрализованные сервисы, режим pull и одноранговые (P2P) коммуникации.
Но наша технология идет дальше, предлагая то, что мы называем «совместное использование провайдера». В этой статье представлена парадигма так называемого «совместного использования провайдера», а также ее первый вариант использования: управление виртуальными машинами.

Архитектура

Архитектура, показанная в предыдущих статьях, еще не ввела все советы и рекомендации для облегчения понимания нашей платформы. На следующем рисунке мы углубимся в детали, введя службы и протоколы совместного доступа провайдера. Можно, конечно, получить то, что уже было представлено в предыдущих статьях, где были показаны службы iEx.ec, такие как планировщик, репозиторий данных, клиент и работник. С другой стороны, можно, конечно, заметить значок «поставщика обмена» на предоставленной ресурсной стороне — «рабочий». Это не нарушает глобальных правил вычислений, но вводит функцию, в которой предоставленные ресурсы могут предлагать больше, чем только «CPU» и «RAM». При совместном использовании этого поставщика любой ресурс может предложить некоторые электронные активы, которыми он владеет на своей стороне.

Традиционно глобальные планировщики вычислений используют алгоритмы «matchmaking», в которых децентрализованные характеристики ресурсов, такие как CPU, RAM, OS и т.д., используются для определения того, что отправлять и где. Например, задание, относящееся к приложению с двоичным файлом Linux, может быть отправлено только на ресурс, работающий под управлением операционной системы Linux.

С помощью парадигмы обмена нашими поставщиками мы предлагаем сделать больше. Распределенный ресурс может представлять любой цифровой актив (приложение, библиотеку, данные, графический процессор) и планировщик может использовать эту информацию для расчета matchmaking. В этой статье основное внимание уделяется обмену приложениями поставщика, который позволяет управлять виртуальными машинами по множеству децентрализованных ресурсов.

Безопасность

Эта новая парадигма — совместное использование продукта — не нарушает безопасность, как это было введено в предыдущих статьях, таким образом:

• обмен провайдерами должен быть зарегистрирован в службах iEx.ec
• авторизации и права доступа применяются к раздаче провайдера (смотреть статью «Безопасность iExec »).

Рабочий поток

Совместное использование поставщика разрешает новый рабочий процесс, слегка, но не полностью отличающийся от представленного в предыдущей статье. Различия выделены жирным шрифтом и подчеркнуты:

• Службы XWHEP позволяют администратору управлять зарегистрированными приложениями.
• Клиент готовит данные, необходимые для успешного вычисления заданий. Эти данные могут храниться в инфраструктуре iEx.ec или в любом репозитории, как только данные могут быть описаны с помощью URI и доступны через сеть. Ограничений по размеру данных нет, но данные, превышающие несколько сотен мегабайт, могут загружаться или загружаться очень долго. Благодаря совместному использованию провайдера, метаданные данных могут не определять контент и указывать, что эти данные должны предлагаться децентрализованными ресурсами, владеющими контентом данных.
• Авторизованный клиент регистрирует приложение в инфраструктуре iEx.ec . Благодаря совместному использованию провайдера метаданные приложения могут не определять ни двоичные, ни библиотечные данные, а также указывать, что это приложение должно предлагаться децентрализованными ресурсами, которыми владеет приложение.
• Клиент готовит задания (единицы работы), содержащие ссылку зарегистрированного приложения, необязательные параметры, дополнительные ссылки на дополнительные файлы.
• Наконец, клиент отправляет подготовленные задания в планировщик.
• Независимо друг от друга рабочие контактируют с планировщиком, чтобы получить рабочие места, подходящие для их архитектуры и в конечном итоге, их распределяют.
• В ответ планировщик отправляет подходящее описание работы работнику.
• Для каждого файла, на который ссылается задание, которого нет в локальном кэше рабочего, рабочий извлекает файл из репозитория данных или внешнего репозитория данных. Работнику не нужно загружать и устанавливать любые данные, библиотеку или приложение, которое оно разделяет.
• Как только работа заканчивается на стороне рабочего, работник связывается с сборщиком результатов, чтобы отправить результаты.

Случай использования

Совместное использование приложений поставщиком является нашим первым вариантом использования. Это позволяет управлять виртуальными машинами. Это требует регистрации виртуальной машины в качестве приложения, развернутых ресурсов, совместно использующих гипервизор и наконец, отправки задания для запуска виртуальной машины. Для этого пользователи должны:

1. Получить зарегистрированную виртуальную машину. Виртуальные машины должны быть зарегистрированы как приложение в планировщике.
2. Отправьте задание на запуск виртуальной машины, в конечном итоге предоставив ее открытый ключ SSH и попросив порт подключиться к
3. Задание назначается ресурсу, совместно использующему гипервизор
4. Если был запрошен порт, задание автоматически получает виртуальный сокет, который будет прослушивать SSH-демон (смотрите «Виртуализация сети iEx.ec»).
5. Если был запрошен порт, задание автоматически подключается к локальному прокси-серверу SmartSocket, отвечающему за соединение виртуального адреса с локальным IP-адресом, на стороне рабочего
6. Если был запрошен порт, получить задание Виртуальный адрес SmartSocket
7. Если был запрошен порт, запустить прокси-сервер SmartSocket для задания, предоставляя локальный порт на локальном компьютере пользователя, на котором установлен клиент iEx.ec
8. Прокси подключается к виртуальному адресу задания
9. Прокси слушает локальный порт
10. Прокси перенаправляет все сообщения между локальной сетью и виртуальным адресом задания
11. Пользователь может использовать ssh-клиент, как обычно, для подключения к своей виртуальной машине, используя свой локальный секретный ключ, соответствующий открытому ключу, предоставленному при отправке задания. Пользователь не должен пытаться напрямую подключаться к своей виртуальной машине, а к локальному прокси-серверу Smartsocket

Заключение

В этой статье представлен общий доступ поставщика iEx.ec, который позволяет управлять виртуальными машинами через децентрализованное облако. В следующих статьях мы обсудим вопросы совместного использования другими поставщиками, такие как совместное использование данных, которое позволяет планировать данные, или совместное использование графического процессора, которое позволяет использовать GPU приложениям, например такие как Машинное обучение.

Автор: Oleg Lodygensky
Опубликовано: 20 марта 2017
Первоисточник на английском языке:

iEx.ec virtual machine management

Присоединяйтесь к нам:

iExec 🇷🇺

Веб-Сайт • Telegram • VKontakte • Instagram • Twitter • Facebook • Youtube • Medium • Golos •

iExec 🇺🇸

Website • Medium • Slack • Telegram • Reddit • Twitter • Facebook • LinkedIn• Youtube • Github • Kakao • Instagram • Steemit • Katacoda • Docs

___________________________________________________________________