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

Динамическую миграцию можно инициировать вручную; если же вы располагаете диспетчером виртуальных машин System Center Virtual Machine Manager 2008 R2 и диспетчером System Center Operations Manager 2007, то можете выполнять эту операцию в автоматическом режиме в ответ на изменение рабочей нагрузки. Чтобы настроить две упомянутые системы для работы с технологией live migration, необходимо выполнить целый ряд манипуляций, и я подробно опишу весь этот процесс. Сначала я разъясню, как функционирует технология динамической миграции. Затем перечислю некоторые из аппаратных и программных компонентов, необходимых для ее работы. И в заключение я подробно остановлюсь на важных этапах настройки Hyper-V и средств отказоустойчивых кластеров; все их необходимо осуществить для обеспечения процесса динамической миграции.

Как функционирует динамическая миграция

Технология live migration предусматривает перенос виртуальной машины с одного хоста Hyper-V на другой (см. диаграмму на рисунке 1). Суть процесса такова. Память виртуальной машины копируется с одного хоста на другой. По завершении копирования виртуальная машина на новом хосте может обращаться к файлам на своем виртуальном жестком диске (virtual hard disk, VHD) и продолжать работу. Оба хоста обращаются к одному и тому же хранилищу, где размещаются файлы VHD. При запуске динамической миграции происходит следующее.

  1. На целевом сервере создается файл настроек новой виртуальной машины.
  2. Первоначальное состояние памяти исходной виртуальной машины копируется на целевую систему.
  3. Модифицированные страницы памяти исходной виртуальной машины тегируются и копируются на целевую систему.
  4. Этот процесс продолжается до тех пор, пока число модифицированных страниц не становится небольшим.
  5. Работа виртуальной машины на исходном узле приостанавливается.
  6. Финальное состояние памяти из исходной виртуальной машины копируется на целевую систему.
  7. Работа виртуальной машины возо­бновляется на целевом сервере.
  8. Для обновления сетевых таблиц маршрутизации применяется протокол Address Resolution Protocol (ARP).

Требования динамической миграции к аппаратным и программным компонентам

Аппаратная часть: для функционирования технологии динамической миграции требуются две системы с совместимыми процессорами x64. Рекомендуется использовать идентичные процессоры, хотя это необязательно. Но в любом случае процессоры должны быть от одного производителя и из одного семейства: выполнять динамическую миграцию в ситуации, когда один процессор изготовлен компанией AMD, а другой — компанией Intel, невозможно. Дополнительные сведения о совместимости процессоров Hyper-V можно найти в руководстве Microsoft «Virtual Machine Processor Compatibility Mode» (download.microsoft.com/download/F/2/1/F2146213-4AC0-4C50?B69A-12428FF0B077/VM%20processor%20compatibility%20mode.doc).

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

Программные компоненты: на всех узлах, участвующих в процессе динамической миграции, должны быть установлены системы Server 2008 R2 x64. Это могут быть версии Standard, Enterprise или Datacenter. Кроме того, динамическую миграцию поддерживает продукт Hyper-V Server 2008 R2. Наконец, на всех серверах, участвующих в процессе динамической миграции, должны быть установлены роль Hyper-V и средства отказоустойчивых кластеров.

К тому же вам потребуется совместное хранилище; это может быть сеть iSCSI SAN или Fibre Channel SAN. В рассматриваемом примере я использовал iSCSI SAN. Имейте в виду, что сеть хранения данных iSCSI SAN должна соответствовать спецификациям iSCSI-3, что предполагает, помимо прочего, способность обеспечивать постоянное резервирование, без которого динамическая миграция невозможна. Некоторые системы iSCSI с открытым исходным кодом, например OpenFiler, на данный момент не имеют такой совместимости. Если вы хотели бы проверить предлагаемые в статье рекомендации в локальной среде и не намереваетесь приобретать дорогостоящие компоненты SAN, вам стоит опробовать бесплатно распространяемый продукт StarWind Server, который можно загрузить по адресу www.starwind.com.

Сетевая настройка отказоустойчивого кластера

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

На этом рисунке для соединения с клиентами серверы используют сеть с адресом 192.168.100.xxx. Хранилище iSCSI SAN функционирует в отдельной физической сети, настроенной с использованием IP-адресов 192.168.0.xxx. Для указания любого из этих диапазонов IP-адресов вы можете задействовать другие значения. Я выбрал эти значения для того, чтобы более четко разграничить две упомянутые сети. В идеале следовало бы использовать дополнительные сетевые интерфейсные платы для управления и дополнительного соединения при осуществлении динамической миграции, но, строго говоря, такие платы не являются необходимыми. Динамическую миграцию можно проводить с минимальным комплектом из двух сетевых плат на каждом сервере.

Настройка хранилища

Для осуществления динамической миграции Hyper-V я использовал сеть хранения данных LeftHand Networks iSCSI, а также тестовую версию SQL Server. В сети iSCSI SAN я создал четыре номера логических устройств (LUN). Один номер — для устройства емкостью 500 Мбайт, он был предназначен для кворума кластера. Еще один — для устройства емкостью в 1024 Гбайт — был предназначен для функционирования 10 виртуальных машин. Оставшиеся два номера предназначались для тестовой версии SQL Server; речь идет об устройстве на 200 Мбайт для службы координатора распределенных транзакций Distributed Transaction Coordina­tor и устройстве на 500 Гбайт для хранения файлов данных SQL Server.

Создав номера логических устройств, я указал инициаторы iSCSI на обоих узлах Windows Server. Чтобы добавить конечные точки iSCSI, в меню Administrative Tools я выбрал пункт iSCSI Initiator и далее на вкладке Discovery — пункт Discover Portal. В результате на экране появилось диалоговое окно Discover Portal, в котором я ввел IP-адрес и порт iSCSI в сети устройств хранения данных. В моем случае это были значения 192.168.0.1 и 3260 соответственно.

Далее в диалоговом окне Connect to Target я ввел имя целевого объекта iSCSI SAN. Это имя было взято из свойств сети хранения данных. Кроме того, оно определяется именем поставщика устройств SAN, именем домена, а также именами создаваемых номеров логических устройств. Я выбрал пункт Add this connection to the list of Favorite Targets. Когда я завершил настройку iSCSI, вкладка iSCSI Initiator Targets была заполнена номерами логических устройств.

Наконец, с помощью оснастки Disk Management я назначил номерам логических устройств буквенные обозначения накопителей. Я открыл оснастку и использовал Q для quorum, R для DTC, S для SQL Server и V для VM. Назначения следует начинать на одном узле, затем переводить диски в автономный режим и выполнять идентичные назначения на втором узле. На экране 1 показано, как выглядит окно Disk Management по завершении назначений для одного из узлов.

Управление дисками накопителей iSCSI

Добавление роли Hyper-V и службы отказоустойчивого кластера

Следующее действие — добавление роли Hyper-V, а затем и функций отказоустойчивого кластера. Обе операции выполняются с помощью диспетчера Server Manager. Чтобы добавить роль Hyper-V, выберите Administrative Tools, пункт Server Manager и щелкните на ссылке Add Role. В диалоговом окне Select Server Roles выберите Hyper-V и нажмите Next. Система предложит создать виртуальные сети Create Virtual Networks. В ходе этой операции, в сущности, создается мост между виртуальными машинами Hyper-V и внешней сетью.

Выберите сетевые интерфейсные платы, которые намереваетесь использовать для трафика виртуальных машин. Удостоверьтесь в том, что выбранные платы не используются для соединения с iSCSI SAN. Нажмите кнопку Next; тем самым работа мастера Add Role Wizard будет завершена. После этого система будет инициализирована повторно. Данный процесс необходимо выполнить на всех узлах кластера.

Теперь добавьте службу отказоустойчивого кластера. Для этого нужно открыть меню Administrative Tools и в нем выбрать элементы Server Manager и Add Feature. Откроется окно мастера Add Features. Просмотрите список функций и выберите Failover Clustering. Завершите работу мастера нажатием кнопки Next. Этот процесс следует выполнить на всех узлах.

Настройка отказоустойчивого кластера

Далее нужно сформировать отказоустойчивый кластер. Это можно сделать на любом из узлов кластера. Откройте меню Administrative Tools и выберите в нем элемент Failover Cluster Manager. На экране будет отображено окно консоли Failover Cluster Management. Щелкнув ссылку Validate a Configuration, запустите мастер настройки. На экране появится диалоговое окно Select Servers or Cluster.

Введите полные доменные имена всех узлов, которые будут входить в кластер, и нажмите кнопку Next. Нажимайте на эту кнопку и на следующих экранах мастера; тем самым вы будете инициировать проверочные испытания кластера, тестирующие версию операционной системы, настройки сети и хранилища всех узлов кластера. На экране будут отображены сводные результаты тестирования. Если проверочные испытания завершились успешно, вы сможете продолжать работу по созданию кластера. Если же система сообщает об ошибках или выдает предупреждения, вы можете отобразить их в отчете, откорректировать то, что нужно, и вновь провести проверочные испытания.

По завершении проверочного тестирования приступайте к созданию кластера. Для этого нужно воспользоваться ссылкой Create a Cluster, расположенной на консоли Failover Cluster Management console. Так же как и процедура проверки, процедура формирования кластера начинается с отображения диалогового окна Select Servers, в котором пользователь указывает имена всех узлов кластера. При нажатии кнопки Next открывается диалоговое окно Access Point for Administering the Cluster.

В этом окне пользователь присваивает кластеру имя и IP-адрес. При этом как имя, так и IP-адрес должны быть уникальными в масштабе сети. Я присвоил кластеру имя WS08R2?CL01 и назначил ему IP-адрес 192.168.100.200. Систему Server 2008 R2 можно настроить таким образом, чтобы IP-адрес назначался по протоколу DHCP, но я предпочитаю назначать IP-адреса моим серверам вручную; такой порядок позволяет назначать серверам одни и те же имена, что облегчает решение задач диагностики.

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

Мастер Create Cluster автоматически назначает хранилище для вашего кворума, но он не всегда выбирает тот диск кворума, который вам нужен. Вы можете проверить и изменить настройки кворума; для этого следует правой кнопкой мыши щелкнуть на имени кластера в консоли Failover Cluster Management и в контекстном меню выбрать пункты More Actions и Configure Cluster Quorum Settings. На экране появится диалоговое окно Select Quorum Configuration. Мастер автоматически выбирает оптимальный тип кворума; его решение определяется главным образом числом узлов в кластере. В моем двухузловом кластере мастер выбрал кворум типа Node and Disk Majority.

Далее на экране появляется диалоговое окно Configure Storage Witness. Здесь я изменил первоначальное значение на диск Q, который хотел использовать в качестве кворума; для этого я выставил флажок. Затем нужно нажать кнопку Next. Тем самым вы сохраните изменения в кворуме.

Включение общих томов кластера

Следующий этап процесса настройки кластера состоит в запуске общих томов кластера. Функция общих томов кластера позволяет нескольким узлам кластера одновременно обращаться к каталогам в общих хранилищах, но по умолчанию эта функция не включена. Чтобы активизировать ее, откройте консоль управления кластерами Failover Cluster Management и правой кнопкой мыши щелкните на имени кластера в верхней части панели навигации. Затем в контекстном меню выберите элемент Enable Cluster Shared Volumes. На экране появится панель со сводной информацией по общим томам кластера. Изначально она пуста.

Для выбора папки общего хранилища, которая будет использоваться как общий том кластера, щелкните на элементе Add Storage панели Action. Откроется диалоговое окно Add Storage. Хранилище для общих томов кластера должно быть видимым из кластера, и оно не должно использоваться для других целей. Установите флажок для хранилища, которое собираетесь использовать. Я выбрал диск V, который на самом деле является номером логического устройства сети хранения данных LeftHand Networks. Нажмите кнопку ОК. Общие тома кластера будут задействованы для выбранного вами накопителя. Еще одним результатом этого действия будет создание точки подключения на всех узлах кластера. По умолчанию точка подключения обозначается C:\ClusterStorage\Volume1.

Создание виртуальных машин на общих томах кластера

Итак, служба отказоустойчивого кластера настроена на всех узлах кластера, функция общих томов кластера задействована, так что все узлы могут одновременно обращаться к хранилищу. Следующий шаг — создание виртуальных машин, которые могут воспользоваться этой инфраструктурой. Виртуальные машины Hyper-V можно создавать либо с помощью диспетчера Hyper-V Manager, либо с помощью System Center Virtual Machine Manager. Чтобы создать новую виртуальную машину с помощью Hyper-V Manager, в меню Start выберите элементы Administrative Tools и Hyper-V Manager, затем на панели Action выберите элемент New. На экране появится окно мастера New Virtual Machine. Вы увидите диалоговое окно Specify Name and Location (экран 2).

Создание VM в хранилище общих томов кластера

На данном экране показано, что виртуальная машина будет иметь имя vWS08?SQL01. Кроме того, стоит отметить, что местоположению виртуальной машины присвоено имя точки подключения общих томов кластера: C:\ClusterStorage\Volume1. Это значит, что файлы настройки виртуальной машины будут создаваться в общем хранилище.

Нажмите кнопку Next для назначения размера оперативной памяти виртуальной машины. Еще раз нажмите Next — теперь вы будете выбирать сетевое соединение для виртуальной машины. Назначать сеть для виртуальной машины необязательно. Однако, если вы все-таки выберете внешнюю сеть, проследите за тем, чтобы на всех узлах Hyper-V она имела одно и то же имя. В рассматриваемом примере для обозначения внешней сети я использовал имя External Virtual Network на всех узлах кластера Hyper-V.

Нажмите кнопку Next, и на экране откроется диалоговое окно Connect Virtual Hard Disk. И здесь опять-таки важно создавать файлы VHD в хранилище общих томов кластера. Вначале в диалоговом окне отображаются значения имени и местоположения, принимаемые диспетчером Hyper-V Manager по умолчанию. Для файла VHD я использовал имя vWS08?SQL01.vhd и изменил его местоположение на C:\ClusterStorage\Volume1. Нажмите кнопку Next, и вы сможете указать параметры установки гостевой операционной системы. Все гостевые операционные системы, включая Linux, могут использоваться при осуществлении динамической миграции. В остальном процесс создания виртуальной машины идентичен обычному процессу формирования виртуальной машины.

По завершении работы мастера New Virtual Machine в хранилище общих томов кластера будет создана новая виртуальная машина. Следующий этап — запуск виртуальной машины и установка гостевой операционной системы, а также приложений, которые вы намереваетесь запускать на этой машине.

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

Откройте консоль управления кластерами Failover Cluster Management, перейдите на узел Services and Applications под именем соответствующего кластера и щелкните правой кнопкой мыши. В раскрывшемся меню выберите элемент Configure Service or Application. На экране появится окно мастера High Availability wizard. В диалоговом окне Select Service or Application выберите из списка представленных служб элемент Virtual Machine и нажмите кнопку Next. На экране появится диалоговое окно Select Virtual Machine.

Прокручивайте список виртуальных машин, пока не найдете виртуальную машину, которую планируете использовать в процессе динамической миграции. Я выделил виртуальную машину vWS08?SQL01, созданную ранее. При выполнении этой операции виртуальная машина не должна функционировать; нужно, чтобы она пребывала в отключенном или сохраненном состоянии.

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

На старт, внимание — миграция!

Вот и все, что я хотел рассказать о настройке среды динамической миграции Hyper-V. Теперь вы можете инициировать динамическую миграцию с помощью диспетчера Failover Cluster Manager. Чтобы запустить процесс динамической миграции, раскройте узел Services and Applications и выберите виртуальную машину, отображаемую под ним. На экране появится панель сводных данных, на которой отображены виртуальные машины, доступные для кластеризации, а также их текущее состояние.

Запуск процесса динамической миграции

На экране 3 видно, что виртуальная машина vWS08?SQL01 в данный момент выполняется и что ее текущим владельцем является узел WS08R2?S1. Чтобы запустить процесс динамической миграции, перейдите на панель Action и выберите вариант Live migrate virtual machine, представленный в верхней трети панели Action. В контекстном меню вам будет предложено ввести имя целевого узла. В моем примере меню содержало такой пункт: 1 — Live migrate to node WS08R2?S2. Нужно щелкнуть на этом пункте, запуская тем самым процесс динамической миграции.

Текущее состояние отображается в окне сводных данных до тех пор, пока не завершится процесс динамической миграции. Время, необходимое для его завершения, зависит от размера и загруженности виртуальной машины, а также от скорости и загруженности сетевых каналов связи между хост-системами Hyper-V. В моей сети процесс динамической миграции занимает, как правило, от 10 секунд до одной минуты. По завершении этого процесса вновь отображается панель сводных данных, и в качестве значения Current Owner подставляется имя целевого узла.

Динамическая миграция позволяет сократить планируемое время простоев серверов и закладывает основы динамического центра обработки данных. Этот процесс состоит из большого числа этапов, но если вы со вниманием отнесетесь к прохождению его критических точек, то окажетесь наконец в земле обетованной динамической миграции Hyper-V.

Майкл Оти (motey@windowsitpro.com) — технический директор Windows IT Pro и SQL Server Magazine, автор Microsoft SQL Server 2008 New Features (Osborne/McGraw-Hill)