Джон Сэвилл (jsavill@windowsitpro.com) — директор по технической инфраструктуре компании Geniant, имеет сертификаты CISSP, Security and Messaging MCSE для Windows Server 2003 и звание MVP

Если бы меня попросили одним словом описать мою реакцию на новые возможности Microsoft Hyper-V в системе Windows Server 8, это был бы возглас: «Вау!». Вне всякого сомнения, эти возможности ставят Hyper-V не то что на один уровень, а даже выше конкурентов, если детально сравнивать функции платформ виртуализации.

.

Немного истории

Компонент Hyper-V был выпущен вскоре после выхода Windows Server 2008. Данное решение обладало хорошей производительностью, но мобильность была ограничена только возможностью быстрой миграции (quick migration), для которой требовалось сохранение на диск содержимого оперативной памяти и состояния виртуальной машины. Поскольку общий диск не был по-настоящему разделяемым хранилищем, его необходимо было размонтировать на текущем и смонтировать на новом узле, после чего загрузить с диска содержимое памяти и состояние виртуальной машины, а затем запустить эту виртуальную машину. Клиенты были отключены от виртуальной машины в течение всего процесса быстрой миграции, что не добавляло данной операции популярности. Hyper-V в Server 2008 не поддерживал и объединение сетевых адаптеров (NIC teaming).

Версия Server 2008 R2 добавила динамическую миграцию (live migration), обеспечивающую нулевой простой при плановой миграции и позволяющую всем узлам кластера одновременно читать и записывать информацию на разделяемом томе NTFS (функция общих томов кластера Cluster Shared Volumes). Hyper-V в Server 2008 R2 поддерживает объединение сетевых адаптеров, хотя ее реализация зависит от производителей адаптеров. Кроме того, были добавлены такие сетевые возможности как кадры крупных размеров (jumbo frames) и очередь виртуальных машин (virtual machine queue, VMQ). В Server 2008 R2 Service Pack 1 (SP1) появилась поддержка динамической памяти для оптимизации управления памятью и технологии Microsoft RemoteFX для обработки графики на стороне сервера в инфраструктуре виртуальных настольных систем Virtual Desktop Infrastructure (VDI). Однако возможности виртуализации были по-прежнему ограничены четырьмя виртуальными процессорами (vCPU) на одну виртуальную машину, памятью 64 Гбайт на виртуальную машину и 16 узлами в кластере.

В большинстве организаций Server 2008 R2 SP1 и Microsoft System Center Virtual Machine Manager (SCVMM) удовлетворяют требованиям виртуализации систем и предоставляют широкие возможности использования. Однако некоторым компаниям требуются улучшения в определенных областях. Судя по информации от моих клиентов, им хотелось бы получить следующие возможности:

— масштабируемость виртуальных машин (более 4 vCPU на виртуальную машину);

— миграция хранилища виртуальной машины без прерывания работы;

— возможность слияния моментальных снимков (snapshot) без прерывания работы виртуальной машины;

— большее число узлов в кластере;

— динамическая миграция нескольких виртуальных машин одновременно, а также миграция между узлами, не входящими в кластер;

— полнофункциональное встроенное в систему решение для объединения сетевых адаптеров, позволяющее использовать адаптеры различных производителей;

— виртуализация сети и изоляция;

— встроенное решение для обновления кластеров Hyper-V;

— возможность использования для хранения виртуальной машины не только локальных дисков и массивов SAN, но и общих сетевых папок;

— поддержка виртуальных дисков Microsoft Virtual Hard Disk (VHD) больших размеров;

— устранение дублирования данных и файлов VHD размером более 2 Тбайт.

Hyper-V в Windows Server 8 обещает обеспечить все это и даже больше: 32 vCPU на виртуальную машину, 512 Гбайт памяти на виртуальную машину, 63 узла в кластере, файлы формата VHDX до 16 Тбайт и встроенная поддержка объединения сетевых адаптеров. И всем этим управляют с помощью нового диспетчера сервера с интерфейсом в стиле Metro и оболочки Windows PowerShell. В данной статье мы рассмотрим улучшения, относящиеся к обеспечению высокой доступности и осуществлению миграции. Откровенно говоря, они просто поражают.

Поддержка общих файловых ресурсов SMB

До Windows Server 8 миграция с нулевым временем простоя требовала наличия хранилища, общего для двух узлов, участвующих в переносе виртуальной машины. Оба узла должны были одновременно «видеть» это хранилище для получения доступа к конфигурации виртуальной машины и ее дискам. Единственный тип хранилища с такими возможностями — это внешнее хранилище, такое как массив SAN, к которому подключены все узлы кластера (с помощью iSCSI или Fibre Channel) и к которому возможен одновременный доступ через общие тома кластера Cluster Shared Volumes.

Требование внешнего хранилища может стать основной проблемой для организаций, которые не желают инвестировать в данный тип инфраструктуры или предпочитают решения NAS. Для таких компаний в Windows 8 реализован протокол совместного доступа к файлам Server Message Block (SMB) версии 2.2, который позволяет хранить виртуальные машины на сетевых общих папках с сохранением подключений ко всем файлам виртуальной машины и обеспечением их целостности.

Для использования сетевых общих папок и на файловом сервере, и на серверах Hyper-V должна работать система Windows Server 8. Виртуальные машины могут храниться в сетевых общих папках как для изолированных серверов Hyper-V, так и для серверов, которые являются узлами высокодоступного отказоустойчивого кластера (рисунок 1). Использование общих SMB-ресурсов для хранения виртуальной машины сравнимо с решениями виртуализации, использующими NFS в качестве удаленного файлового хранилища. Для большей гибкости отдельный узел или кластер могут задействовать несколько общих папок.

 

Использование сетевой общей папки на основе протокола SMB версии 2.2
Рисунок 1. Использование сетевой общей папки на основе протокола SMB версии 2.2

Другие улучшения в протоколе SMB в Windows Server 8, такие как постоянно доступные сетевые папки, поставщик VSS для удаленных общих папок и многоканальные подключения для повышения пропускной способности и отказоустойчивости, делают использование SMB для хранилища виртуальной машины просто первоклассным решением.

Динамическая миграция

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

Динамическая миграция обеспечила возможность использования в SCVMM технологий оптимизации Performance and Resource Optimization (PRO) и Dynamic Optimization. PRO и Dynamic Optimization проверяют уровень использования ресурсов и автоматически перемещают виртуальные машины, обеспечивая их оптимальную производительность с помощью распределения по узлам кластера при изменении потребности в ресурсах. Оптимизация энергопотребления Power Optimization в SCVMM также может использовать динамическую миграцию для консолидации виртуальных машин на небольшом числе узлов в периоды малой нагрузки и временно отключать незадействованные узлы для экономии электроэнергии (а затем при необходимости запускать их).

Windows Server 8 использует успех технологии динамической миграции, расширяя ее использование и масштабируемость для новых сценариев и инфраструктурных изменений, наблюдаемых в большинстве центров обработки данных. В частности, добавлена возможность осуществления параллельной динамической миграции, динамической миграции с общим файловым ресурсом (SMB live migration), динамической миграции хранилища, а также миграций, в которых виртуальной машины не имеют никаких общих ресурсов, кроме подключения Ethernet.

Параллельные динамические миграции. Динамическая миграция в Server 2008 R2 была ограничена выполнением в данный момент времени только одной операции динамической миграции между двумя узлами кластера, участвующими в данной операции: текущим и будущим владельцами виртуальной машины. Основание для такого ограничения было довольно простое. Большинство центров обработки данных используют сетевую инфраструктуру с пропускной способностью 1 Гбит/с. Динамическая миграция очень интенсивно использует полосу пропускания сети; вся оперативная память копируется по сети между узлами, и поскольку виртуальная машина в процессе копирования продолжает работать, требуются дополнительные действия по копированию тех фрагментов памяти, которые изменились с момента предыдущего копирования. Операции копирования с каждым разом выполняются все быстрее, так как объем передаваемых данных с каждым разом уменьшается.

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

Рассмотрим пример с выливанием содержимого бутылки с водой через воронку. Выливание четырех бутылок через одну воронку займет в четыре раза больше времени, поскольку воронка здесь — самое узкое место. А теперь представим, что пока вы выливаете воду из какой-либо бутылки, кто-то понемногу добавляет в нее воды, и так происходит до тех пор, пока бутылка не опустеет. В результате, чем дольше вы опустошаете бутылку, тем больше в итоге будет вылито воды, увеличивая общее время переливания. В данном случае выливание из бутылок по очереди приведет к минимальному суммарному времени, необходимому для переливания из всех четырех бутылок.

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

Как происходит ускорение передачи данных? Сейчас в центрах обработки данных преобладают 10-гигабитные сети, и единичная динамическая миграция не сможет заполнить весь 10-гигабитный канал (представим себе очень большую воронку). Учитывая эти изменения, Windows Server 8 позволяет выполнять несколько параллельных динамических миграций между узлами. Максимальное фиксированное количество параллельных динамических миграций отсутствует, хотя вы можете задать такое максимальное число в настройках узла Hyper-V. Hyper-V проверяет текущую пропускную способность сети, определяет доступную полосу пропускания и, исходя из текущих условий, настраивает количество параллельных динамических миграций для обеспечения наилучшей производительности.

Динамическая миграция с общим файловым ресурсом. Улучшения в динамической миграции в высокодоступной среде впечатляют. Однако одним из самых значительных изменений стала возможность выполнения динамической миграции виртуальной машины в некластеризованной конфигурации. Это дает возможность переносить виртуальные машины между двумя узлами Hyper-V, которые не являются частью отказоустойчивого кластера. Имеется два типа динамической миграции вне кластерной среды — динамическая миграция с общим файловым ресурсом и динамическая миграция без кластеров и общих дисков (shared-nothing live migration).

В миграции с общим файловым ресурсом два узла Hyper-V подключаются к одной и той же сетевой общей папке, в которой размещены файлы VHD и конфигурационные файлы виртуальной машины, которую предстоит перенести. Единственное требование к общей папке — учетные записи обоих узлов Hyper-V должны иметь для данного ресурса как сетевые, так и локальные разрешения «Полный доступ». Базовый механизм динамической миграции здесь такой же, как и для миграции в отказоустойчивом кластере. Однако, поскольку сама виртуальная машина здесь не является общим ресурсом, выполняются некоторые дополнительные действия.

  1. Устанавливается TCP-соединение между исходным узлом, на котором работает виртуальная машина, и целевым узлом. Конфигурационные данные виртуальной машины пересылаются на целевой узел, позволяя создать на нем основу для виртуальной машины и выделить необходимый объем памяти.
  2. Оперативная память виртуальной машины копируется с исходного узла на целевой. Так же, как и при обычной динамической миграции, данный процесс состоит из первоначального полного копирования памяти, за которым следуют несколько итераций копирования изменившихся страниц памяти.
  3. Когда объем памяти, оставшийся для передачи, может быть скопирован без существенного влияния на время «замораживания» виртуальной машины, данная виртуальная машина временно останавливается. Оставшаяся память, состояние процессора и устройств копируются на целевой узел.
  4. С исходного узла на целевой пересылаются дескрипторы открытых в общей сетевой папке файлов, а также любое физическое хранилище, которое может быть подключено с помощью нового виртуального адаптера Fibre Channel (еще одна замечательная возможность Hyper-V в Windows Server 8).
  5. Виртуальная машина на целевом узле возобновляет работу. Исходная виртуальная машина удаляется.
  6. В сеть отправляется пакет обратного протокола преобразования адресов (reverse ARP), заставляя сетевые коммутаторы обновить привязку IP-адреса виртуальной машины к MAC-адресу нового узла.

Виртуальная машина при этом недоступна лишь несколько миллисекунд, что не выходит за рамки допустимого тайм-аута для TCP-соединения и не сказывается на работе пользователей. Если наблюдать за откликами на команду ping той виртуальной машины, перенос которой осуществляется, то можно заметить время отклика чуть больше обычного только для одного пакета (или даже потерянный пакет), что совершенно незаметно для пользователя и не приводит к разрыву соединения.

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

-перемещение виртуальной машины с локального хранилища в массив SAN;

-перемещение виртуальной машины между массивами SAN для балансировки операций ввода/вывода или для осуществления обслуживания массива SAN;

-перемещение виртуальной машины на общий сетевой ресурс SMB;

-удаление виртуальной машины с тома NTFS для запуска утилиты chkdsk.

Независимо от сценария, динамическое перемещение хранилища позволяет переносить файлы виртуальной машины между всеми поддерживаемыми видами хранилищ — локальные жесткие диски (DAS), массивы SAN, файловые ресурсы (например, SMB) — без прекращения работы виртуальной машины.

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

Как показано на рисунке 2, процесс динамической миграции хранилища состоит из нескольких шагов, которые решают проблему относительной медлительности физических дисков. На шаге 1 создается начальная копия хранилища, которая включает файлы VHD, конфигурационные файлы, моментальные снимки и прочую информацию, относящуюся к виртуальной машине. На данном этапе виртуальная машина читает и пишет данные на исходном хранилище. На шаге 2, после завершения создания начальной копии, стек VHD пишет данные зеркально на исходное и целевое хранилища, одновременно с этим копируются блоки данных, изменившиеся в исходном хранилище во время создания первоначальной копии диска. Наконец, на шаге 3 исходное и целевое хранилища синхронизируются. Стек VHD переключает виртуальную машину на использование только целевого хранилища и затем удаляет данные из исходного. В результате мы получаем перемещение хранилища, связанного с виртуальной машиной, без прерывания ее работы.

 

Три основных этапа выполнения динамической миграции хранилища
Рисунок 2. Три основных этапа выполнения динамической миграции хранилища

Динамическая миграция без кластеров и общих дисков (Shared-nothing live migration). Самой впечатляющей для меня оказалась возможность переноса виртуальной машины между серверами Hyper-V, которые не являются частью одного кластера и не имеют общего хранилища, а имеют только гигабитное сетевое подключение друг к другу — и все это без прекращения работы виртуальной машины!

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

При динамической миграции без кластеров и общих дисков мы можем перемещать виртуальные машины между любыми узлами с Windows Server 8 Hyper-V, даже если они не имеют никаких общих ресурсов, кроме кабеля Ethernet. Я наблюдал динамическую миграцию без кластеров и общих дисков между двумя ноутбуками, имеющими только локальные диски. Работающая виртуальная машина, использовавшая локальный жесткий диск, была перенесена на второй ноутбук без прерывания работы. Теперь представим применение этой возможности для перемещения виртуальной машины между кластерами, узлами или даже между поставщиками услуг инфраструктуры частных и публичных «облаков».

Hyper-V Replica

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

Имеются различные решения для осуществления восстановления среды Hyper-V после сбоев. Однако эти решения, как правило, требуют дорогостоящих хранилищ, которые не по карману малым и средним предприятиям. Реплика Hyper-V (Hyper-V Replica), еще одна новая возможность Windows Server 8, позволяет осуществлять асинхронную репликацию хранилища виртуальных машин с одного узла Hyper-V на другой, даже если эти узлы используют различные типы систем хранения. Начальная репликация исходного хранилища виртуальной машины выполняется по сети (используя прямое подключение между исходным сервером и сервером-репликой) или путем сохранения хранилища виртуальной машины на сетевой ресурс, с которого сервер-реплика впоследствии загрузит информацию. Такой подход называется заполнением вне сети (off-the-network seeding).

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

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

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

Настройка репликации Hyper-V Replica представляет собой довольно простой процесс. Репликацию нужно настроить на всех серверах Hyper-V. Для этого надо выбрать использование либо интегрированной проверки подлинности Windows с репликацией изменений через порт 80 (HTTP), либо проверки подлинности с помощью сертификатов с репликацией через порт 443 (HTTPS). Во втором случае также осуществляется шифрование передаваемых по сети изменений виртуальной машины. Используемые порты могут быть изменены при настройке репликации. Кроме того, сервер может быть настроен для получения данных репликации от любого сервера Hyper-V или от указанного списка серверов, как показано на экране 1. Единственный дополнительный шаг на целевом сервере — включение правил на брандмауэре для разрешения подключений на заданные порты.

 

Настройка сервера в качестве целевого сервера репликации
Экран 1. Настройка сервера в качестве целевого сервера репликации

Когда имеется доступный сервер Hyper-V с включенной репликацией, для любой виртуальной машины можно настроить создание реплики с помощью действия Enable Replication («Разрешить репликацию»). Как только включается репликация, администратору выдается запрос на указание целевого сервера-реплики, а также на способ выполнения начальной репликации. Репликация также позволяет создать определенное количество дополнительных точек восстановления, являющихся ежечасными VSS-снимками, которые обеспечивают целостность заданных точек восстановления из реплик. В процессе репликации виртуальной машины состояние репликации может быть проверено в любой момент с помощью отчета о состоянии, показывающего количество циклов репликации, средний размер репликации и время, затраченное на репликацию (см. экран 2). Также можно настроить альтернативную конфигурацию TCP/IP для реплики виртуальной машины, когда она активируется. Альтернативная конфигурация должна быть встроена в виртуальную машину, если реплика размещена в другой сети и не используется виртуализация сети (еще одна замечательная возможность Windows Server 8).

 

Отчет о состоянии реплики и управление отработкой отказа
Экран 2. Отчет о состоянии реплики и управление отработкой отказа

Понять действие Hyper-V Replica очень важно. Данная функция предназначена для малых и средних предприятий, которым нужна возможность восстановления после сбоя на запасной площадке. Hyper-V Replica выполняет периодическую отправку обновлений хранилища виртуальной машины на резервную площадку. В случае аварии активируется реплика виртуальной машины, и система запускается в рабочем состоянии, зафиксированном на момент получения последнего дельта-обновления от исходной системы. Если данное состояние не удовлетворяет нашим требованиям и при этом была включена возможность создания точек восстановления, администратор может выбрать одну из них. Данная точка запускает реплику на момент создания снимка VSS, что гарантирует рабочее состояние виртуальной машины. Это встроенное в Windows Server 8 решение предоставляет хороший уровень защиты от сбоев без обязательного наличия высокоскоростных сетей и поддерживает любые типы хранилищ, поддерживаемые Hyper-V. Однако данная возможность не обеспечивает автоматическую защиту в реальном времени, поэтому если вам необходим более высокий уровень функциональности, обратите внимание на сторонние решения для Hyper-V.

Впечатляющие новые возможности

Реализованные в Windows Server 8 новые функции для миграции виртуальной машины и репликации предоставляют организациям замечательные возможности для поддержания доступности и мобильности виртуальной машины в масштабах ИТ-инфраструктуры всего предприятия, причем без внесения сложных и дорогостоящих изменений в инфраструктуру. Возможности динамической миграции и репликации в Hyper-V — это всего лишь часть улучшений, к тому же я имел в своем распоряжении лишь бета-версию Windows Server 8. Но все эти компоненты уже сейчас дают представление об уровне улучшений, которыми мы будем пользоваться в следующей версии Hyper-V и Windows Server.

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF