Наши партнеры

Библиотека сайта rus-linux.net

SnowFlock

Глава 18 из 1 тома книги "Архитектура приложений с открытым исходным кодом".

Оригинал: SnowFlock
Авторы: Roy Bryant, Andres Lagar-Cavilla
Перевод: А.Панин

Creative Commons. Перевод был сделан в соответствие с лицензией Creative Commons. С русским вариантом лицензии можно ознакомиться здесь.

18.7. Интерфейс приложений для клонирования виртуальных машин

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

18.7.1. Реализация API

Функции клонирования виртуальных машин доступны приложениям посредством простого API SnowFlock, схематично изображенного на Рисунке 18.1. Клонирование, в основном, является двухэтапным процессом. Вначале вы осуществляете запрос резервирования ресурсов для клонированных виртуальных машин, при этом, в зависимости от используемых системных политик, может быть зарезервирован объем ресурсов меньший, чем запрошенный. После этого вы сможете использовать зарезервированные ресурсы для клонирования виртуальной машины. Ключевым условием является то, что ваша виртуальная машина должна выполнять одну операцию. Клонирование виртуальных машин применяется в случаях их использования для выполнения единственного приложения, например, поддержки работы веб-сервера или компонента фермы рендеринга. Если вы используете окружение рабочего стола, в котором множество приложений параллельно вызывают функции клонирования виртуальных машин, вы на пути к хаосу.

`sf_request_ticket(n)`	Запрашивает резервирование системных ресурсов для клонирования `n` виртуальных машин. Возвращает структуру `ticket`, описывающую ресурсы для `m≤n` клонированных виртуальных машин.
`sf_clone(ticket)`	Клонирует виртуальную машину, используя структуру `ticket`, описывающую зарезервированные ресурсы. Возвращает идентификатор клонированной виртуальной машины `ID`, `0≤ID≤m`.
`sf_checkpoint_parent()`	Подготавливает неизменную контрольную точку `C` для родительской виртуальной машины, которая может быть использована для клонирования этой машины по прошествии сколь угодно долгого периода времени.
`sf_create_clones(C, ticket)`	Аналогична функции `sf_clone`, но использует контрольную точку `C`. Клонированные виртуальные машины начнут работу с того момента, когда была вызвана соответствующая функция `sf_checkpoint_parent()`.
`sf_exit()`	Завершает работу дочерней виртуальной машины `(1≤ID≤m)`.
`sf_join(ticket)`	Блокирует родительскую виртуальную машину `(ID=0)` до того момента, как все дочерние виртуальные машины, описанные в структуре `ticket`, достигнут вызова `sf_exit`. В этот момент все дочерние виртуальные машины прекратят свою работу и структура `ticket` станет недействительной.
`sf_kill(ticket)`	Используется только для родительской виртуальной машины, делает недействительной структуру `ticket` и немедленно завершает работу всех дочерних виртуальных машин.

Таблица 18.1: API клонирования виртуальных машин SnowFlock

API просто формирует сообщения и передает их XenStore, интерфейсу на основе разделяемой памяти с низкой пропускной способностью, используемому Xen для передачи управляющих сообщений. Локальный демон SnowFlock (SnowFlock Local Daemon - SFLD) запускает гипервизор и ожидает запросов. Сообщения извлекаются из очереди, после чего выполняются переданные в них команды и отправляются ответы.

Программы могут контролировать процесс клонирования виртуальных машин напрямую с помощью API, доступного для языков программирования C, C++, Python и Java. Сценарии оболочки, связанные с выполнением программы, могут использовать поставляемые инструменты с интерфейсом командной строки вместо данного API. Такие фреймворки для параллельных вычислений, как MPI, могут включать API в свой состав: программы на основе MPI смогут использовать SnowFlock, не располагая фактами об этом и без модификации исходного кода. Балансировщики нагрузки, используемые перед веб-серверами или серверами приложений, могут использовать API для клонирования подконтрольных им серверов.

Локальные демоны SnowFlock управляют исполнением запросов клонирования виртуальных машин. Они создают и отправляют архитектурные дескрипторы, создают клонированные виртуальные машины, запускают серверы диска и памяти и запускают вспомогательные процессы memtap. Они представляют собой миниатюрную распределенную систему, ответственную за управление виртуальными машинами в рамках физического кластера.

Локальные демоны SnowFlock отправляют данные о резервировании ресурсов центральному мастер-демону SnowFlock. Мастер-демон SnowFlock просто взаимодействует с соответствующим программным обеспечением для управления кластером. Мы не видим необходимости повторно изобретать колесо в данном случае, поэтому доверяем выполнение задач резервирования ресурсов, установки квот, политик, и.т.д., такому предназначенному для этих целей программному обеспечению, как Sun Grid Engine или Platform EGO.

18.7.2. Необходимые изменения

После клонирования большинство процессов виртуальных машин не информированы о том, что они уже выполняются не в родительской виртуальной машине, а в ее копии. В большинстве случаев данный подход просто работает и не вызывает нареканий. Все-таки главной задачей операционной системы является изоляция приложений от специфических низкоуровневых данных, таких, как сетевая идентичность. Все же, беспрепятственный процесс клонирования требует использования дополнительного набора механизмов. Основной проблемой является управление сетевой идентичностью клонированной виртуальной системы; для того, чтобы избежать конфликтов и путаницы, мы должны произвести незначительные модификации данных в ходе процесса клонирования. Также из-за того, что эти модификации могут повлечь за собой высокоуровневые адаптации, должно быть предусмотрено включение в цепочку обработчиков для того, чтобы пользователь имел возможность настроить выполнение любых необходимых задач, таких, как (пере)монтирование сетевых файловых систем, которые зависят от сетевой идентичности клонированной виртуальной машины.

Клонированные виртуальные машины появляются в мире, который в большей степени не ожидает их появления. Родительская виртуальная машина является частью сети, наиболее вероятно управляемой DHCP-сервером или любым другим из несметного числа способов, которые используют системные администраторы в своей работе. Вместо предположения о неминуемо негибком сценарии работы, мы поместим родительскую и все клонированные виртуальные машины в их отдельную частную виртуальную сеть. Клонированные виртуальные машины от одного родителя связаны с уникальными идентификаторами и их IP-адреса в этой частной сети автоматически устанавливаются во время клонирования с помощью функции, зависящей от идентификатора. Это гарантирует то, что вмешательство системного администратора не является необходимым, а также никогда не возникнет коллизий IP-адресов.

Смена IP-адресов производится непосредственно с помощью включенной в цепочку обработчиков драйвера виртуальной сети соответствующей функции. При этом мы также используем драйвер для автоматической генерации синтетических ответов DHCP. Таким образом, независимо от вашего выбора дистрибутива, ваш виртуальный сетевой интерфейс позволит передать корректные данные IP гостевой операционной системе, даже в случае перезагрузки.

Для того, чтобы избежать ситуации, при которой различные родительские виртуальные машины проникают в чужие частные виртуальные сети, а также происходят внутренние DDoS-атаки, виртуальные сети для клонированных виртуальных машин разделяются на канальном уровне (уровне 2 OSI). Мы заимствуем диапазон уникальных для организаций MAC-адресов (Ethernet MAC OUI)³ и назначим их клонированным виртуальным машинам. Назначение уникального MAC-адреса будет зависеть от родительской виртуальной машины. Аналогично тому, как IP-адрес виртуальной машины устанавливается в зависимости от ее идентификатора, ее MAC-адрес, не относящийся к полученному диапазону адресов, также зависит от идентификатора. Драйвер виртуальной сети преобразует MAC-адрес виртуальной машины, предполагая его зависимость от идентификатора, и отфильтровывает весь трафик, движущийся в обоих направлениях в частной виртуальной сети с использованием другого диапазона MAC-адресов. Данное разделение трафика эквивалентно разделению, реализуемому при помощи ebtables, но при этом реализуется значительно проще.

Реализация режима обмена данными виртуальных машин друг с другом является замечательной идеей, но ее не достаточно. Иногда мы хотим, чтобы наши клонированные виртуальные машины отвечали на HTTP-запросы из Интернет или подключались к публичным репозиториям данных. Мы снабдим любое множество родительских и клонированных виртуальных машин отдельной виртуальной машиной для маршрутизации. Эта небольшая виртуальная машина работает как межсетевой экран, управляет пропускной способностью канала и осуществляет преобразование сетевых адресов для трафика, направленного от клонированных виртуальных машин в Интернет. Она также ограничивает входящие соединения к родительской виртуальной машине и к портам с известными номерами. Виртуальная машина для маршрутизации не затрачивает большое количество ресурсов, но является единой точкой централизации для сетевого трафика, что может серьезно ограничить масштабируемость. Одни и те же правила функционирования сети могут быть распределены и применены к каждому узлу, на котором работает клонированная виртуальная машина. Мы пока не выпустили этот экспериментальный патч.

Локальные демоны SnowFlock назначают идентификаторы виртуальных машин и передают драйверам виртуальной сети данные, на основе которых они смогут провести настройку: внутренние MAC- и IP-адреса, директивы DHCP, координаты виртуальной машины для маршрутизации, правила фильтрации трафика, и.т.д.

Далее: 18.8. Заключение