Библиотека сайта rus-linux.net
SnowFlock
Глава 18 из 1 тома книги "Архитектура приложений с открытым исходным кодом".
Оригинал: SnowFlock
Авторы: Roy Bryant, Andres Lagar-Cavilla
Дата публикации: 7 Июля 2012 г.
Перевод: А.Панин
Дата перевода: 29 Марта 2013 г.
Creative Commons. Перевод был сделан в соответствие с лицензией Creative Commons. С русским вариантом лицензии можно ознакомиться здесь.
18.6. Компоненты на стороне клонированных виртуальных машин
Клонированные виртуальные машины представляют из себя пустые программные оболочки сразу после создания с помощью архитектурного дескриптора, поэтому как и в случае людей им требуется значительная помощь со стороны родителей во время роста: дочерние виртуальные машины покидают домашнее пространство, но всегда обращаются к нему в случаях, когда обнаруживают факт отсутствия каких-либо необходимых им данных, прося родительские виртуальные машины отправить им эти данные незамедлительно.
18.6.1. Процесс memtap
Присоединяясь к каждой клонированной виртуальной машине после ее создания, процесс memtap является жизненно важным для нее программным компонентом. Он отображает всю память клонированной виртуальной машины и заполняет ее данными в случае необходимости. Для реализации некоторых ключевых функций используется гипервизор Xen: права доступа к страницам памяти клонированных виртуальных машин не устанавливаются, поэтому аппаратные ошибки, вызванные первыми попытками доступа к страницам, перенаправляются гипервизором процессу memtap.
В простейшем случае процесс memtap просто запрашивает страницу, при обращении к которой произошла ошибка, у сервера памяти, но возможны и более сложные сценарии работы. Во-первых, вспомогательные процессы memtap используют службу mcdist. Это значит, что в любой момент времени любая страница может быть доставлена только из-за того, что она была запрошена другой виртуальной машиной - в этом заключается красота асинхронного распространения данных. Во-вторых, мы позволяем виртуальным машинам SnowFlock быть многопроцессорными виртуальными машинами. В ином случае работа с ними не доставляла бы удовольствия. Это значит, что множество ошибок должно обрабатываться параллельно, возможно даже для одной и той же страницы. В-третьих, в поздних версиях memtap вспомогательные процессы могут явно получать данные для группы страниц, которые могут быть доставлены в любом порядке ввиду отсутствия гарантий доставки данных в определенном порядке сервером mcdist. Любые из этих факторов ведут к кошмару параллелизма, а нам необходимо учитывать все эти факторы.
Архитектура memtap разрабатывалась с учетом главенствующей роли битовой маски наличия страниц. Битовая маска создается и инициализируется в момент обработки архитектурного дескриптора с целью создания клонированной виртуальной машины. Битовая маска является плоским массивом размера, соответствующего допустимому количеству страниц памяти виртуальной машины. Процессоры Intel поддерживают полезные атомарные инструкции для осуществления битовых преобразований: установка значения бита или проверка значения и его установка может происходить гарантированно атомарно по отношению к другим процессорам системы. Это обстоятельство позволяет нам избежать блокировок в большинстве случаев и, таким образом, предоставить доступ к битовой маске различным объектам из различных защищенных областей: гипервизору Xen, процессу memtap и самому гостевому ядру клонированной виртуальной машины.
Когда Xen обрабатывает аппаратную ошибку при первом доступе к странице, он использует битовую маску для принятия решения о том, нужно ли взаимодействовать с memtap. Он также использует битовую маску для включения в очередь нескольких виртуальных процессоров как зависящих от одной отсутствующей страницы. Процесс memtap добавляет страницы в буфер в той последовательности, в которой они прибывают. Когда буфер заполняется или прибывает явно запрошенная страница, работа виртуальной машины приостанавливается и битовая маска используется для удаления из буфера всех доставленных дублей страниц, которые уже присутствовали. После этого все оставшиеся необходимые страницы копируются в память виртуальной машины и устанавливаются соответствующие биты в битовой маске.
18.6.2. Оптимально работающие клонированные виртуальные машины избегают чрезмерных запросов
Мы только что упомянули о том, что битовая маска наличия страниц доступна для ядра, работающего в клонированной виртуальной машине, а также о том, что для ее модификации не требуется блокировок. Это позволяет клонированным виртуальным машинам использовать мощную "возможность оптимизации": они могут предотвратить запросы страниц, модифицировав битовую маску и указав, что заданные страницы присутствуют. Эта возможность особенно полезна в плане повышения производительности и безопасна в тех случаях, когда страницы полностью перезаписываются перед использованием.
Ситуации, в которых можно избежать запросов страниц, достаточно распространены. Все операции резервирования памяти в ядре (с использованием функций vmalloc, kzalloc, get_free_page, функции пространства пользователя brk и других подобных функций) в конце концов осуществляются с помощью механизма резервирования страниц ядра. Обычно резервирование страниц инициируется промежуточными системами резервирования, которые работают с небольшими участками памяти: системой распределения памяти slab, системой распределения памяти для процессов пространства пользователя malloc из состава glibc, и.т.д. Однако, в случаях явного или неявного резервирования памяти одно ключевое семантическое заключение всегда верно: никто не беспокоится о содержимом страницы памяти, так как ее содержимое будет перезаписано произвольным образом. Зачем тогда получать содержимое такой страницы? Для этого нет причин и эмпирический опыт говорит о том, что отказ от получения таких страниц чрезвычайно выгоден.
Далее: 18.7. Интерфейс приложений для клонирования виртуальных машин