Как было сделано демо Windows Server 2008 на запуске в Киеве

После мероприятия, которое прошло в Киеве 3 апреля 2008, и на котором я демонстрировал технологию Quick Migration для виртуальных машин под управлением Hyper-V в Windows Server 2008, я получил массу вопросов – как устных (на самом мероприятии), так и письменных (по почте, через блог, Live Messenger)…  Основные вопросы, собственно – «А это не хитрое постановочное демо?», «А как это было сделано?», «Какое оборудование и софт необходим?», «Для каких сценариев, кроме продемонстрированного потокового видео, данная технология применима?», «Что делать с реальной нагрузкой, каковы вероятные задержки в реальной жизни?»… В данном посте попробую вкратце ответить на эти (и некоторые другие) вопросы…

Сценарий.
Итак, напомню краткий сценарий работы демо – на одном из физических серверов запускается виртуальная машина под управлением Windows Server 2008 Hyper-V, на которой установлены сервисы Windows Media, обеспечивающие широкое вещание видео потока. Клиентский ПК запускает Windows MediaPlayer, и принимает с виртуального сервера данный видео поток. Работающая виртуальная машина посредством технологии Quick Migration перемещается с одного физического сервера на другой с простоем примерно 20 сек и кратковременной остановкой видео на клиенте, которое тут же восстанавливается и продолжает воспроизводиться с точки останова. Аналогичная ситуация наблюдается и при «пинговании» виртуальной машины с клиента – теряются 3-5 пакетов, отправленных на адрес виртуальной машины, после чего пинги восстанавливаются.

Теория.
Одна из задач виртуализации – изоляция на одном физическом сервере (хосте) ролей сервера с целью большей безопасности, надежности и совместимости, гарантированного распределения аппаратных ресурсов. Но узким место такого решения является устойчивость и доступность физического хоста, на котором будут выполняться виртуальные машины с разными ролями. Задача высокой доступности физического сервера решалась и решается путем отказоустойчивой кластеризации (Windows Server Failover Clustering), при которой выполняемые на том или ином физическом сервер (узле кластера) сервисы «передаются» на другой узел. Целостность данных достигается наличием общего для всех узлов дискового хранилища, на котором и сохраняются данные сервиса, и что обеспечивает доступность данных, не зависимо от того, на каком именно узле сервис выполняется. Виртуальная машина с точки зрения кластеризации является обычным сервисом, который следует остановить на одном узле, сохранив его данные на общем хранилище, и запустить на другом узле. При этом виртуальная машина не просто сохраняет данные (собственно, ее основные данные – виртуальный диск – и так находятся на общем хранилище кластера), а сервис вирутализации приостанавливает работу переносимой виртуальной машины и сохраняет состояние ее оперативной памяти в виде файла на диске. Далее, этот файл восстанавливается на другом узле как память запускаемой там ранее остановленной виртуальной машины. Вот и все – мы получаем виртуальную машины, для которой, собственно, ничего не произошло, все ее состояние идентично моменту останова. Собственно, именно такой процесс и называется Quick Migration. Его эффективность (время простоя виртуальной машины при передаче) в большей степени зависит от скорости работы дисковой или сетевой подсистемы (в зависимости от используемого типа) общего хранилища кластера, на который будет сохраняться оперативная память виртуальной машины и, собственно, от объема этой самой памяти (согласитесь, записать/считать 512МБ – это не тоже самое по времени, что и 8ГБ). Также на время простоя виртуальной машины незначительно влияет эффективность работы самого кластера – время размонтирования на одном узле и монтирования на другом узле кластера диска общего хранилища с данными переносимой виртуальной машины, а также – время публикации сетевого интерфейса виртуальной машины в публичной сети кластера.

Практика.
Для построения демонстрационного примера по Quick Migration, подобного продемонстрированному на запуске, требуется:
2 ПК, выступающие в роли узлов кластера, поскольку речь идет о работе с виртуализацией под управлением Microsoft Hyper-V – обязательна поддержка процессором режимов х64, аппаратной виртуализации от Intel (I-VT) или AMD (AMD-V), запрета исполнения NX/XD, и достаточно памяти для выполнения собственно виртуальных машин. Желательно также наличие нескольких – 2х или более – сетевых  интерфейсов для разделения сетей кластера – публичной, внутренней, хранилища. В реальном примере это роль играли лезвия от HP BladeSystem c3000, в которых было установлено по 2 Intel Xeon (4 core) и 8ГБ ОЗУ.
1 ПК, выступающий в роли контроллера домена Active Directory: FC-кластеризация Windows Server 2008 обязательно требует участия узлов кластера в домене. В примере – также лезвие BladeSystem.
Общий дисковый массив, хранилище. Поскольку под рукой не оказалось ничего из аппаратных средств, что могло бы хоть как-то реализовать данную задачу (хотя лезвия c3000 были оснащены всем необходимым – FiberChannel контроллерами), то было принято простое решение – реализовать общее хранилище посредством iSCSI.
Здесь следует сказать пару слов – iSCSI – протокол, который обеспечивает передачу пакетов SCSI по сетям TCP/IP, т.е. позволяет представить ПК сетевые дисковые ресурсы как локальные дисковые устройства SCSI, и тем самым обеспечивает необходимые требования для реализации общего хранилища кластера. Для функционирования iSCSI требуется 2 основных компонента – сервер iSCSI (iSCSI Target) и клиент iSCSI (iSCSI Initiator). iSCSI Target – это аппаратное устройство или программное обеспечение, которое обеспечивает предоставление доступа к установленным локальным дискам клиентам iSCSI. iSCSI Initiator – клиент, являющийся программным модулем, обычно – драйвером дискового контроллера ОС (но может быть реализованным и аппаратно), обеспечивающий соединение с iSCSI Target и представляющий ОС диски iSCSI Target как локальные физические через точки подключения (target). Эффективность работы iSCSI напрямую зависит от пропускной способности сети, благо, в используемом решении HP BladeSystem c3000 с этим никаких проблем не наблюдается, особенно – между лезвиями.

Для организации общего дискового хранилища будущего кластера был выбран самый доступный, и, при этом, достаточно эффективный вариант реализации iSCSI – программый iSCSI Target, реализованный как сервис в Microsoft Windows Storage Server. Особенностью реализации является то, что он позволяет предоставлять доступ по iSCSI к дискам, которые представляются не локальными физическими дисковыми накопителями, а позволяет предоставить клиентам в виде диска файл формата .VHD, расположенный на любом разделе файловой системы и имеющий необходимый размер. Оснастка iSCSI Target позволяет создавать требуемые .VHD диски, определять режим создания «снимков» для их резервного копирования, и, собственно, описывать точки (target) подключения сетевых клиентов iSCSI – безопасность, аутенификация, режим работы – с наборами подключенных к этим точкам дисков .VHD. Если к точке подключено несколько дисков, каждый диск получает свой LUN ID, а если несколько точек – фактически для клиента это разные дисковые контроллеры. В качестве хранилища, как вы поняли, было использовано еще одно лезвие.
Создаем  при помощи оснастки iSCSI Target необходимую точку подключения и конфигурируем ее. Следует обратить внимание на перечень клиентов, которым будет разрешено подключаться к iSCSI – указываем либо IP-адреса их интерфейсов, либо IQN (уникальное имя внутри iSCSI сети), либо FQDN. Создаем два .VHD диска, один размером 2ГБ для будущего диска кворума кластера, и 30ГБ для хранения данных будущей виртуальной машины.
Таким образом, все необходимые компоненты кластера – узлы и общее хранилище – готовы.

Правильно настроенные сетевые интерфейсы – один из аспектов надежной и производительной работы кластера. Если это возможно – изолируйте интерфейсы, на которых будут работать публичная сеть, внутренняя сеть и сеть хранилища (в варианте iSCSI) разными физическими сетями или VLAN. В нашем случае, с лезвиями, которые имеют 2 сетевых интерфейса, мы изолировали интерфейсы для публичной сети (по ней узлы будут  общаться с контроллером домена и предоставлять кластеризуемые сервисы, для примера – сеть 192.168.100.0/24 ) и объединили сеть хранилища, по которой будет работать iSCSI и внутреннюю, приватную сеть кластера, по которой идет взаимодействие узлов, сеть 10.0.0.0/24. Также, в приватную сеть кластера был подключен один из сетевых интерфейсов лезвия с iSCSI Target.
На будущих узлах кластера конфигурируем сетевые интерфейсы, добавляем их в домен.

Подключаем диски общего хранилища через iSCSI. Для этого используем штатную утилиту Windows – клиент iSCSI Initiator. Запускаем ее на первом узле будущего кластера. При первом старте запрашиваются параметры автоматического старта службы Microsoft iSCSI – подтверждаем, и конфигурирования службы Windows Firewall для работы с iSCSI – также подтверждаем. В окне iSCSI Initiator Properties указываем в закладке Discovery в разделе Target Portals IP-адрес сетевого интерфейса сервера хранилища, подключенного у приватной сети (10.0.0.0/24). В дополнительных свойствах (кнопка Advanced) при указании адреса также указываем, что исходящий адрес на клиенте также из сети 10.0.0.0/24. Там же, в дополнительных свойствах, можно указать параметры аутентификации соединения, использования IPsec, проверки целостности данных.
При успешном подключении переходим в закладку Targets, где отображаются все доступные для клиента точки подключения (не диски, которые они публикуют) и их статус на клиента – подключены/не подключены. Выбираем созданную нами точку подключения, содержащую диски для будущего кластера, нажимаем кнопку Log on. В открывшемся диалоговом окне указываем опции для восстановления соединения при перезагрузке и поддержку multi-path. В дополнительных свойствах (кнопка Advanced), аналогично с подключением самой точки, указываем, что локальным адаптером является Microsoft iSCSI Initiator, IP-адрес источника – адрес интерфейса узла из сети 10.0.0.0/24, адрес портала – IP-адрес сетевого сервера хранилища также из сети 10.0.0.0/24. Если подключение успешно, то в списке точек подключения закладки Targets статус нужного нам подключения будет Connected. Если что-то не так – читаем документацию, полная инструкция по работе с клиентом iSCSI здесь - http://go.microsoft.com/fwlink/?LinkId=40963.
Повторяем операции по подключению клиента iSCSI через Microsoft iSCSI Initiator и на втором узле кластера. Таким образом, общее хранилище подключено.

На первом узле кластера при помощи Disk Management  переводим появившиеся диски iSCSI (отображаются как обыкновенные локальные диски) из состояния offline в online, инициализируем, создаем на каждом по одному разделу и форматируем их под NTFS с установками по умолчанию. Для удобства работы с дисками меньшему диску (2ГБ, для кворума кластера) назначаем метку Quorum и букву Q:, большему (30ГБ, для данных виртуальной  машины) – Storage и S:.
На втором узле кластера достаточно только вывести диски в режим online и назначить аналогичные первому кластеру буквы.

Установка и конфигурирование кластера.
На каждом из будущих узлов при помощи Server Manager добавляем функционал Failover Clustering из раздела Features. Также, перед конфигурацией кластера, на обоих узлах рекомендуется установить роль Hyper-V, предварительно обновив ее до версии RC0. На каждом узле сконфигурируйте виртуальный сетевой адаптер Hyper-V как внешний и «привяжите» его к сетевому интерфейсу публичной сети (192.168.100.0/24) обоих узлов. Важно, чтобы этот виртуальный адаптер имел одно и то же имя на каждом узле.

На первом узле кластера запускаем из Start|Administration Tools оснастку Failover Cluster Management, выбираем команду создания нового кластера, указываем мастеру создания кластера имена обеих подготовленных узлов.  Выбираем опцию выполнения тестов работоспособности будущего кластера, дожидаемся выполнения всех тестов, которые могут занять до 30-45минут времени. При успешном окончании тестов указываем имя кластера и его IP-адрес (из публичной сети 192.168.100.0/24, отличный от адресов самих узлов). Кластер готов к работе.

Создание виртуальной машины, которая будет отказоустойчивой благодаря Quick Migration и регистрация ее как приложения кластера.
На первом узле кластера из оснастки роли Hyper-V консоли Server Manager создаем новую виртуальную машину. Основные требования к виртуальной машине – это размещение файла ее конфигурации и виртуального диска на общем диске кластера S:, использование виртуального сетевого адаптера с общим именем. Если по какой-то причине диск находится под управлением второго узла – выполните создание виртуальной машины на втором узле.
Установите Windows Server 2008 в виртуальную машину, установите также на него обновления Hyper-V до RC0. По окончании установки и конфигурации остановите виртуальную машину.
На том узле, котором создавалась виртуальная машина, запустите оснастку Failover Cluster Management, подключитесь к «свежесозданному» кластеру, и выберите раздел Services or Applications, а в его опциях – Configure a Service or Application.

В мастере конфигурирования сервисов и приложений кластера из списка выберите Virtual Machine, на следующем шаге мастера – из списка непосредственно виртуальных машин выберите созданную вами на общем диске виртуальную машину. Мастер добавит ее как приложение в раздел Services or Applications.
Из перечня опций виртуальной машины на кластере выберите Bring this service or application online – вирутуальная машина запустится уже как ресурс кластера.
Для тестирования попробуйте выполнить команду ping или получить какой-то доступ к ее службам.
Для выполнения операции Quick Migration по переносу виртуальной машины на другой узел кластера выберите из опций Move this service or application to another node. В этот момент вы можете увидеть, как идет сохранение состояния машины на общий диск, передача управления диска другому узлу, восстановление состояния на новом узле.

Ссылки по теме:
Microsoft iSCSI – http://www.microsoft.com/iscsi
Виртуализация и Hyper-V – http://www.microsoft.com/virtualization
Кластера Windows Server 2008 - http://technet2.microsoft.com/windowsserver2008/en/library/adbf1eb3-a225-4344-9086-115a9389a2691033.mspx?mfr=true

Comments

• Anonymous
  January 01, 2003
  Конечно, мне бы хотелось донести вам благую весть… Но, увы, шара имеет объем – он равен 4/3 * Пи * радиус

• Anonymous
  January 01, 2003
  После успешной установки и недельной эксплуатации клиента Windows 7 пришла очередь и Windows Server 2008

• Anonymous
  January 01, 2003
  Я регулярно отслеживаю через статистику Microsoft adCenter, какие страницы наиболее популярны, что ищут

• Anonymous
  January 01, 2003
  почему "требуется"? Желательно... Особенно в примере с виртуализацие очень желательно, потому как поизводительность виртуальной машины и, особенно, время переноса - напрямую зависят от способности сети пропускать iSCSI пакеты на строедж. А с другой стороны - интенсивное общение с iSCSI будет мешать работе внутренней сети кластера по обмену heartbeats, что негативно будет сказываться на операциях обнаружения проблем... но, как показал опыт, для нужд демо или тестирования самого процесса - никаких серьезных неудобст это не создает. В примере мы объединили внутреннюю сеть и сеть iSCSI.

• Anonymous
  January 01, 2003
  Цитата из поста: "Правильно настроенные сетевые интерфейсы – один из аспектов надежной и производительной работы кластера. Если это возможно – изолируйте интерфейсы, на которых будут работать публичная сеть, внутренняя сеть и сеть хранилища (в варианте iSCSI) разными физическими сетями или VLAN" - и так должно быть в продакшене. ;)

• Anonymous
  April 14, 2008
  Игорь привет. Может подскажешь, почему в кластере для iSCSI требуется выделять отдельную сеть, которая не будет пересекатся с Public (клиентской) и Private (кластерной) сетями? Насколько критичной является эта рекомендация?

• Anonymous
  April 14, 2008
  Вопрос возник по той причине, что в документации указано следущее- "The network you use for iSCSI cannot be used for network communication". В моем примере, я обьединял внешнюю сеть и сеть iSCSI, тоже все работает, хотя визард и предупреждал, что нельзя использовать внешнюю сеть для сети iSCSI. Вот поэтому и хотелось узнать, это рекомендация или требование ;) Значит будем считать, что это возможно, но все таки лучше выделять на каждой ноде три сетевых интерфейса под Public, Private и iSCSI сети.