Поддержка кластеров в виртуальных машинах Hyper-V

Месяц назад руководитель направления кластеризации и высокой доступности в Microsoft изложил официальную позицию о поддержке кластеров внутри виртуальных машин VMware. Мой перевод данной заметки вызвал бурные дискуссии у нас в комментариях — и волну негодования в комментариях конкурентов. Меня там даже обвинили в сознательном запугивании заказчиков VMware. Совсем нет — раз мы поговорили о поддержке на стороннем гипервизоре, поговорим и о своём.

Windows NT 4.0 Server Enterprise и Windows 2000 Server Advanced/Datacenter

Как мы уже говорили, для Windows NT 4.0 и Windows 2000 кластеризация внутри виртуальных машин не поддерживается.

Windows Server 2003 Enterprise/Datacenter

В первой части статьи я указывал ссылку на правила оказания технической поддержки для кластеров на базе Windows Server 2003. Решение (не только гипервизор — но полная связка гипервизора конкретной версии с конкретной моделью сервера и моделью общей дисковой системы) должно проходить проверку на соответствие требованиям программы «Designed for Microsoft Windows Server 2003» и быть опубликовано в Windows Server Catalog в категории «Cluster Solutions». С конца 2009 года эта программа закрыта, и новые решения на проверку не принимаются.

Microsoft не стала делать для себя исключений — Hyper-V в этой программе не участвовал. Кластеры Windows Server 2003 в виртуальных машинах Hyper-V лишены технической поддержки.

Windows Server 2008 и Windows Server 2008 R2

Согласно новым правилам оказания технической поддержки, к кластерам на базе Windows Server 2008/R2 не предъявляются требования на проверку всего решения в комплексе. Но каждый компонент в отдельности должен соответствовать требованиям программы Windows Server logo — а сам кластер в сборе должен проходить встроенный в него механизм программной проверки «Validate Cluster Configuration».

Ограничения со стороны Microsoft

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

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

What is the support policy for additional functionality of virtualization products?

With regards to virtualization product functionality that operates without the knowledge or cooperation of the operating system or applications executing within the virtual machine such as, but not limited to; live migration of virtual machines, virtual machine clustering, memory ballooning, virtual machine fault tolerance, etc., these are outside the scope of the Server Virtualization Validation Program.

There are no industry standards to follow in implementing such features, and since 'by design' the operating system [whether that be Windows Server or some other OS] or application is not required to be cognizant of such functionality provided by the virtualization product which operates independently of the operating system or application, there is no practical method of testing these virtualization product features.

Thus, the SVVP program does not test these features or functions, and the virtualization product vendor is solely responsible for testing and supporting them. Any certification the virtualization vendor has with regards to these features is outside the scope of the Server Virtualization Validation Program. However, unless otherwise stated in articles or documents for Windows Server operating systems or for Microsoft server applications, Microsoft does not preclude their use by customers. Customers may contact Microsoft for more information in this regard for specific virtualization product features and functions and Microsoft products.

Данная фраза просто подчёркивает — Microsoft поддерживает свои ОС и продукты в виртуальных машинах на сторонней платформе, которая «эмулирует» аппаратные решения. Никакие технологии, недоступные на обычных физических серверах, в SVVP не тестируются. И Microsoft поддержки системам, испытывающим проблемы из-за использования данных технологий, не оказывает.

А что с самим Hyper-V?

А вот для Hyper-V, очевидно, Microsoft проводит существенное тестирование своих продуктов. И поддерживает с виртуализованными ОС и приложениями все возможности гипервизора — если явно не заявлено обратного. То есть для поддерживаемых ОС внутри виртуальных машин Hyper-V Microsoft поддерживает Live/Quick Migration, Dynamic Memory, RemoteFX, Processor Compatibility и так далее.

Для ряда серверных продуктов Microsoft существуют определенные правила, иногда накладывающие ограничения на поддержку использования расширенных технологий виртуализации  — таких, например, как Live Migration, — или категорически запрещающие виртуализацию некоторых компонентов или ролей серверных приложений. Рассмотрим пару примеров.

Microsoft SQL Server

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

• Использование кластеризации SQL Server внутри виртуальных машин поддерживается для ОС Windows Server 2008 и выше.
• Использование снимков состояния (Shapshots) виртуальных машин с SQL Server не поддерживается — ни для Hyper-V, ни для других производителей.
• Для Hyper-V поддерживаются технологии Live/Quick Migration. Как мы помним, для сторонних гипервизоров аналогичные технологии (например, VMotion и XenMotion) Microsoft не поддерживаются, а должны поддерживаться поставщиком гипервизора. Производители же, в свою очередь, заявляют, что сами не поддерживают эти технологии для виртуальных машин, использующих Failover Clustering.

Office Communication Server

Существует документ, описывающий правила поддержки OCS 2007 R2 в виртуальной среде. Из него можно почерпнуть, что большинство ролей OCS 2007 R2 поддерживаются в виртуальной среде Hyper-V и решениях, участвующих в SVVP. Однако есть и исключения. Например, роли Audio/Video Conferencing, Archiving Server и Monitoring Server. Ограничений на дополнительные технологии виртуализации не накладывается — кроме понимания того, что для сторонних гипервизоров их поддержкой будет заниматься производитель решения виртуализации.

Exchange Server

Документ, регламентирующий поддержку виртуализованного Exchange Server, более суров.

• Виртуализация поддерживается для всех ролей, кроме Unified Messaging.
• Однако не поддерживается использование динамически расширяющихся (Dynamically Expanding) и разностых (Differencing) виртуальных дисков.
• Запрещается построение кластеров Exchange Server внутри виртуальных машин, кластеризованных средствами Hyper-V, VMware HA или любыми другими.
• Запрещается использование снимков состояния (Snapshots).
• Также существует жесткое требование по соотношению количества логических процессоров на физическом сервере виртуализации к суммарному количеству виртуальных процессоров, доступных виртуальным машинам. Оно не должно превышать значения 2:1. То есть на двухпроцессорном сервере с четырехядерными процессорами мы имеем 8 логических процессоров. При этом если мы хотим иметь поддерживаемую конфигурацию Exchange Server в виртуальной среде — то количество виртуальных процессоров, используемых всеми виртуальными машинами на этом сервере, не должно превышать 16. (Как мы помним, безотносительно дополнительных требований, накладываемых гостевыми ОС и/или ПО, для сохранения поддержки со стороны Hyper-V это соотношение не должно превышать 8:1).

Матрица поддержки

По вертикали — версия ОС, работащей в виртуальных машинах, объединённых в кластер. По горизонтали — версия родительской ОС, выполняющей роль Hyper-V.

Построение кластеров из физических и виртуальных серверов

Кластеризация ОС и серверных продуктов Microsoft допускает использования в одном кластере как физических, так и виртуальных машин. Такой кластер по-прежнему должен проходить проверку мастером.

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