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

UnixForum





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

SnowFlock

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

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

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


18.5. Компоненты на стороне родительской виртуальной машины

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

18.5.1. Процесс сервера памяти

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

Сервер памяти будет предоставлять всем клонированным виртуальным машинам участки памяти, которые они потребуют от родительской виртуальной машины. Единица распространения данных памяти идентична странице памяти архитектуры x86 (4 килобайта). В простейшем случае сервер памяти ожидает запросов страниц от клонированных виртуальных машин и обслуживает одну страницу памяти и одну виртуальную машину в каждый момент работы.

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

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

18.5.2. Многоадресное распространение данных с помощью службы mcdist

Клонированные виртуальные машины обычно страдают экзистенциальным синдромом, известным под названием "детерминизм судьбы". Мы создаем клонированные виртуальные машины с одной и той же целью: например, для выравнивания цепочек X-хромосом ДНК относительно сегмента цепочки Y-хромосом из базы данных. Более того, мы создаем множества клонированных виртуальных машин для выполнения одинаковых действий, возможно, выравнивания одних и тех же цепочек X-хромосом относительно различных сегментов цепочек из базы данных или выравнивания различных цепочек относительно одного и того же сегмента цепочки Y-хромосом. В данном случае большая часть попыток доступа к памяти клонированными виртуальными машинами будет идентично локализована: они исполняют одинаковый код и используют большие объемы сходных данных.

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

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

Три специфические для SnowFlock оптимизации, проведенные в рамках службы mcdist:
  • Определение порядка: При временной локализации несколько клонированных виртуальных машин запрашивают одну и ту же страницу в одинаковой последовательности. Сервер mcdist игнорирует все запросы за исключением первого.
  • Управление потоком: Получатели ответов регулируют частоту приема ответов на запросы. Сервер устанавливает частоту отправки ответов равной средневзвешенной частоте приема ответов клиентами. В противном случае получатели ответов были бы чрезмерно загружены обработкой множества страниц, отправленных сервером.
  • Конец игры: Когда сервер отправил большинство страниц, он переходит в режим одноадресной передачи ответов. На данный момент большинство запросов являются повторами, поэтому передача страницы всем узлам не обязательна.

18.5.3. Виртуальный диск

Клонированные с помощью SnowFlock виртуальные машины, ввиду их короткого времени жизни и "детерменизма судьбы", редко используют диск. На виртуальном диске для виртуальной машины SnowFlock размещается корневой раздел с бинарными файлами, библиотеками и файлами конфигурации. Обработка больших объемов данных производится с использованием таких подходящих для этого файловых систем, как HDFS или PVFS. Следовательно, когда клонированные виртуальные машины SnowFlock принимают решение о необходимости чтения данных с корневого раздела диска, их запросы обычно обслуживаются кэшем страниц файловых систем из состава ядра.

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


Далее: 18.6. Компоненты на стороне клонированных виртуальных машин