Библиотека сайта rus-linux.net
SnowFlock
Глава 18 из 1 тома книги "Архитектура приложений с открытым исходным кодом".
Оригинал: SnowFlock
Авторы: Roy Bryant, Andres Lagar-Cavilla
Перевод: А.Панин
Creative Commons. Перевод был сделан в соответствие с лицензией Creative Commons. С русским вариантом лицензии можно ознакомиться здесь.
18.2. Технология клонирования виртуальных машин
Как становится ясно из названия, клонированные виртуальные машины (практически) полностью идентичны родительской виртуальной машине. Существуют некоторые незначительные, но необходимые различия для решения таких проблем, как конфликты MAC-адресов, но мы вернемся к рассмотрению этого вопроса позднее. Для создания клонированной виртуальной машины данные локального диска и оперативной памяти должны быть доступны в полном объеме, что заставляет нас рассмотреть первое важное архитектурное решение: должны ли мы скопировать эти данные незамедлительно или по мере необходимости?
Простейшим способом реализации механизма клонирования виртуальной машины является реализации стандартной возможности "миграции" виртуальной машины. Обычно миграция осуществляется в том случае, когда работающая виртуальная машина должна быть перенесена на другой узел, например, в том случае, когда узел находится в перегруженном состоянии или может быть отключен для технического обслуживания. Так как виртуальная машина является программным решением, ее состояние может быть сохранено в файле данных, после чего этот файл может быть скопирован на новый, более подходящий узел, на котором работа виртуальной машины продолжится после кратковременного перерыва. Для выполнения этой задачи существующие мониторы виртуальных машин создают файл, содержащий "данные контрольной точки" виртуальной машины, включающие в себя локальную файловую систему, образ памяти, регистры виртуального центрального процессора (VCPU), и.т.д. При миграции новая загруженная копия подменяет оригинал, но процесс может быть модифицирован таким образом, чтобы система клонировалась, а работа оригинальной системы не прерывалась. В ходе этого "активного" процесса все данные виртуальной машины передаются незамедлительно, что позволяет достичь лучшей начальной производительности. Недостатком активной репликации является тот факт, что сложный процесс копирования всех данных виртуальной машины должен быть завершен перед началом работы виртуальной машины, что значительно замедляет инициализацию.
Диаметрально противоположным способом, реализованным в SnowFlock, является "отложенная" репликация данных. Вместо копирования всех данных, которые могут понадобиться виртуальной машине, SnowFlock передает только необходимые для запуска данные, а остальные данные передаются позднее, когда они понадобятся клонированной виртуальной машине. Этот способ имеет два преимущества. Во-первых, он позволяет минимизировать задержку, выполняя незамедлительно настолько малое количество работы, насколько это возможно. Во-вторых, он позволяет повысить эффективность работы, копируя только те данные, которые действительно используются клонированной виртуальной машиной. Повышение эффективности работы клонированной виртуальной машины, конечно же, зависит от выполняемой задачи, но только малая часть приложений использует каждую страницу памяти и каждый файл из локальной файловой системы.
Однако, достоинства отложенной репликации не обуславливают отсутствие недостатков. Так как передача данных откладывается до последнего, клонированная виртуальная машина будет ожидать их приема до момента продолжения работы. Эта ситуация аналогична сохранению страниц памяти в раздел подкачки диска в многозадачной системе: приложения блокируются, ожидая получения данных из источника с длительной задержкой. В случае SnowFlock блокировка в некоторой степени снижает производительность клонированной виртуальной машины; степень снижения производительности зависит от приложения. Для высокопроизводительных вычислительных приложений мы не обнаружили значительного снижения производительности, но производительность клонированного сервера базы данных в первое время будет низкой. Следует учесть, что этот эффект кратковременен: он длится несколько минут, после чего все необходимые данные передаются и производительность клонированной виртуальной машины сравнивается с производительностью родительской виртуальной машины.
Кстати, если вы располагаете большим опытом работы с виртуальными машинами, вас наверняка интересует вопрос о том, будут ли полезны оптимизации, используемые при миграции "в реальном времени" в данном случае. Процесс миграции в реальном времени оптимизируется с целью сокращения интервала между отключением оригинальной виртуальной машины и возобновлением выполнения работы с помощью ее копии. Для этого монитор виртуальной машины (VMM) предварительно копирует данные виртуальной машины в то время, как оригинальная машина все еще работает, поэтому после завершения ее работы необходимо передать только недавно измененные страницы памяти. Эта техника не влияет на интервал между запросом миграции и началом выполнения работы копией виртуальной машины, а значит, не способна уменьшить задержку запуска виртуальной машины при "активном" клонировании.
Далее: 18.3. Подход SnowFlock