Живая миграция (Операционные Системы)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 20:31, 25 июня 2016.
Open book.svg Авторство
В.И. Ромашов
Согласовано: 03.04.2016
Рис.1. Живая миграция

Живая миграция — перенос виртуальной машины с одного физического сервера на другой без прекращения работы виртуальной машины и остановки сервисов. Живая миграция применяется в компьютерных системах с высокой доступностью (англ. High Availability, HA). Живая миграция возможна между серверами, находящимися в кластере.

Технология Hyper-V Live Migration разработана для перемещения запущенных виртуальных машин незаметно для конечных пользователей. За счет пре-копирования страниц памяти виртуальной машины на хост назначения достигается минимизация времени, затраченного на перенос, а гостевая операционная система вообще «не замечает», что ее куда-то переносили, соответственно использование Live Migration не требует какой-либо дополнительной настройки внутри гостевой ОС.

Применение

Живая миграция необходима в проектах, работу которых нежелательно прерывать: сервисы обслуживания магистральных и провайдерских сетей (например, DNS), высокопосещаемые web-ресурсы, крупные сервисы электронной почты. Живая миграция также применяется для распределения нагрузки на физические серверы в кластере (например, при проведении научных расчётов).

Процесс живой миграции

  • Минимум два сервера в кластере.
  • Диск виртуальной машины должен находиться на ресурсе доступном обоим серверам кластера — старом и новом местонахождении.
  • Путь к диску виртуальной машины на физических серверах должен быть идентичен.
  • Серверы должны иметь доступ к одной подсети, в которой находится сетевой интерфейс виртуальной машины.
  • Гипервизоры должны быть одинаковых, либо совместимых версий.
  • Принципиальная очередность процесса живой миграции (на практике требуются дополнительные операции):
  • Остановка выполнения виртуальной машины.
  • Передача параметров виртуальной машины с сервера исходного расположения на сервер целевого расположения.
  • Передача образа оперативной памяти с сервера исходного расположения виртуальной машины на сервер целевого расположения.
  • Создание виртуально домена и размещение образа оперативной памяти в RAM сервера целевого расположения.
  • Запуск выполнения виртуальной машины на сервере целевого расположения.

Гипервизоры с поддержкой живой миграции

  • Virtuozzo
  • Xen
    Рис. 2. Подготовка к Живой Миграции
  • OpenVZ
  • Parallels Cloud сервера
  • Integrity Virtual Machines
  • КМК
  • Сервер Oracle VM для x86
  • Oracle VM сервер для SPARC
  • POWER Hypervisor (PHYP)
  • VMware ESX
  • Hyper-V Server 2008 R2
  • VirtualBox

Принципы работы Live Migration

Как уже было сказано, технология Live Migration была разработана для перемещения виртуальных машин с одного физического хоста на другой за минимальное время. Процесс Live Migration инициируется администратором с помощью одного из трех методов (см. ниже). Фактическая скорость процесса миграции зависит как от характеристик используемого оборудования, так и от пропускной способности сети.

Итак, существует три способа запуска процесса Live Migration:

  1. Администратор может запустить процесс миграции с использованием оснастки MMC Failover Cluster Management.
  2. Через консоль System Center Virtual Machine Manager (если используется).
  3. С помощью скрипта с использованием WMI или PowerShell.

Любая гостевая ОС будет продолжать работу в процессе миграции. После запуска процесса Live Migration, происходит следующее:

Подготовка к миграции

На первой стадии процесса Live Migration, хост-источник устанавливает TCP-соединение с хостом назначения. Это соединение используется для передачи конфигурации виртуальной машины на хост назначения. На хосте назначения создается «виртуальная машина – скелет» и ей выделяется необходимый объем памяти. (см. Рис. 2)

Передача страниц памяти на хост назначения

На второй стадии процесса миграции, содержимое области памяти, выделенной виртуальной машине копируется по сети на хост назначения страницами по 4 килобайта. Объем памяти, выделенной конкретной виртуальной машины далее будем называть «рабочим объемом памяти» виртуальной машины. (см. Рис. 3)

Рис. 3. Передача содержимого памяти

К примеру, имеется виртуальная машина пож названием NYC-SVR2, сконфигурированная с объемом памяти 1024MB мигрирует на другой хост под управлением Hyper-V. Эти 1024MB и составляют ее рабочий объем памяти. Используемые страницы памяти внутри рабочего объема NYC-SVR2 копируются на сервер назначения.

Параллельно с копированием рабочего объема, гипервизор хоста-источника следит за состоянием памяти NYC-SVR2. Как только какие-либо страницы памяти подвергаются изменению, они тотчас же отмечаются как «модифицированные». Таким образом формируется список страниц, подвергшихся модификации с начала процесса копирования.

Во время процесса миграции виртуальная машина продолжает работать. Процессс копирования содержимого памяти повторяется итерационно, при этом копируются только те страницы, которые подверглись изменению с момента последнего копирования, соответственно с каждой итерацией этот объем становится все меньше.

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

Передача измененных страниц памяти

После того, как рабочий объем памяти виртуальной машины был скопирован, происходит копирование последних измененных страниц, а так же передача состояния регистров и устройств виртуальной машины на хост назначения.

В течение этой стадии, процесс миграции сильно зависит от пропускной способности сети, поэтому рекомендуется использовать высокоскоростное сетевое соединение – как минимум Gigabit Ethernet. Чем быстрее будут передаваться измененные страницы памяти – тем быстрее завершится процесс миграции.

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

После того, как все измененные страницы были полностью скопированы, на хосте назначения появляется точная копия рабочего объема памяти NYC-SVR2.

Примечание - Процесс Live Migration может быть прерван в любое время до момента начала этой стадии.

На четвертой стадии миграции, управление хранилищами данных, связанными с NYC-SVR2, как-то: VHD-файлами и pass-through дисками, передается хосту назначения.

Рис. 4. Виртуальная машина запускается на сервере назначения

Запуск виртуальной машины на сервере назначения

На пятой стадии на хосте назначения создается абсолютно точная копия рабочего объема памяти виртуальной машины и доступ ко всем используемым ею хранилищам данных. Теперь виртуальная машина запускается на хосте назначения. (см. Рис. 4)

Обновление ARP-таблицы

Виртуальная машина успешно запущена на хосте назначения. После этого сетевому коммутатору посылается ARP-пакет, и коммутатор «узнает» новый MAC-адрес мигрировавшей виртуальной машины, и сетевой трафик перенаправляется на соответствующий порт.

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

  • Количество измененных страниц памяти виртуальной машины: чем больше страниц подвергается модификации, тем больше времени займет процесс миграции.
  • Пропускная способность сети между двумя хостами.
  • Конфигурация оборудования хостов.
  • Пропускная способность соединения между хостами и общим хранилищем данных (SAN).

Сценарии использования Live Migration

Приведем несколько возможных ситуаций, при которой использование Live Migration будет полезным:

Рис. 5. Виртуальные машины перемещаются на менее нагруженный хост.

Техническое обслуживание серверов

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

Динамический датацентр

С использованием технологии Live Migration, организации могут разворачивать динамическую IT-инфраструктуру. Динамическая инфраструктура позволяет более рационально использовать ресурсы серверов в зависимости от фактической загруженности. Например, если используется некое Web-приложение, и число запросов к нему значительно выросло – Virtual Machine Manager может автоматически предоставить один или несколько дополнительных Web-серверов. При предоставлении этих веб-серверов, Virtual Machine Manager принимает во внимание нагрузку на аппаратные сервера. При возрастании нагрузки Virtual Machine Manager может переключится на дополнительные физические хосты и запустить больше виртуальных машин – чтобы справиться с возросшей нагрузкой. (см. Рис. 5)

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

Green IT

Порядка 33% энергии, потребляемой датацентрами, расходуется на охлаждение и поддержку инфраструктуры. Гибкая балансировка нагрузки, возможная благодаря использованию технологии Live Migration, позволяет снизить общее энергопотребление датацентра. Если нагрузка на оборудование датацентра постоянно меняется, можно использовать автоматизацию с помощью скриптов и Live Migration для повышения консолидации виртуальных машин при относительно невысокой загруженности. Если удается запустить большее число виртуальных машин на меньшем числе физических хостов – неиспользуемые сервера могут быть выключены, что позволит снизить энергопотребление и требования к охлаждению в помещении датацентра. При пиковых нагрузках, отключенные сервера могут быть вновь автоматически запущены и виртуальные машины будут перераспределены по свободным хостам с использованием технологий Live Migration. (см. Рис. 6)

Источники

  1. http://itband.ru/2009/07/windows-server-2008-r2-hyper-v-live-migration/
  2. Hacking, Stuart, et al., Improving the live migration process of large enterprise applications, VTDC'09
  3. https://technet.microsoft.com/en-us/library/dd446679.aspx
  4. Журнал “Системный Администратор”, октябрь 2009г.