Полностью виртуальная инфраструктура в Hyper-V.

Введение.

В этой небольшой статье хотелось бы рассказать про свой опыт использования виртуализации инфраструктуры на базе Hyper-V из состава Windows Server 2008 R2. Статья будет также применима и к Windows Server 2008 (R1). А если конкретно, то хотелось бы рассказать про проблему полной виртуализации инфраструктуры. Под полной виртуальной инфраструктурой я подразумеваю среду, где Hyper-V развернут в конфигурации Failover Cluster и все серверы, включая контроллеры доменов, виртуализируется.

Чтобы было более понятно, рассмотрим следующую инфраструктуру. Есть группа хостов с Windows Server 2008 R2. Вы из этих хостов собрали кластер и хотите перенести всю вашу серверную инфраструктуру из физического состояния в виртуальное. Но встает дилемма. Среди физических серверов, которые вы хотите перенести в среду виртуализации, есть контроллеры доменов. Тут вы вспоминаете, что кластер зависит от службы каталогов и получается, что вам нельзя создавать взаимозависимость: кластер виртуализации от службы каталогов и наоборот.

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

Решение.

Failover-кластеру без службы каталогов очень плохо. Хотя бы по той причине, что служба каталогов используется для аутентификации узлов в кластере.

Вернемся к нашей инфраструктуре. Мы все-таки развернули кластер Hyper-V, перенесли все серверы, в том числе и контроллеры доменов, в виртуальную среду. Физические серверы либо задействовали в качестве узлов кластера, либо полностью вывели из эксплуатации. Виртуальные машины разместили на Cluster Shared Volume (CSV), дабы задействовать замечательную функцию Live Migration. Получилось следующее:



В один прекрасный момент выключается электричество, а вместе с ним через некоторое время выключаются ваши физические хосты и виртуальные машины.

Включают электричество, хосты Hyper-V начинают грузиться, а вот виртуальные машины не стартуют. Это происходит по следующей причине. Виртуальные машины являются ресурсами кластера, служба ClusterSvc должна, в соответствии с зависимостью ресурсов, поочередно их поднять (перевести в online-режим). Но служба кластеров сама зависит от службы каталогов, контроллеры доменов которой являются ресурсами кластера. Получается замкнутый круг.

Есть традиционные способы решения данной проблемы:

Использовать хотя бы один физический сервер для контроллеров доменов. Согласитесь, что при текущей производительности серверов, не совсем целесообразно потратить на контроллер доменов 5-10 тыс. долларов (с последующей утилизацией раз в 3-5 лет). Для инфраструктур, характеризующих себя как централизованные и средние по размерам, хотелось бы максимально утилизировать вычислительные ресурсы, абстрагироваться от аппаратного обеспечения, и все это сделать с минимальными затратами. Децентрализованные инфраструктуры могут такой проблемы не ощущать.

Использовать хост Hyper-V как контроллер доменов. То есть, развертываем роль ADDS на одном из узлов Hyper-V. Это уже лучше, чем первый случай, но все же есть некоторые проблемы:

• Проблема безопасности и проблема делегирования полномочий. Если развернуть RWDC на Hyper-V хосте, то трудно будет ограничить администратора среды виртуализации от возможности воздействовать на службу каталогов. Сразу скажу, что здесь можно долго спорить на эту тему, поскольку можно сказать, что если есть физический доступ к хосту, то без проблем можно получить доступ к виртуальным машинам. И это верно. Поэтому оставлю тему безопасности за рамками данной статьи. Возьмем за веру, что проблема с безопасностью все же есть в этом случае. Также можно установить RODC и это решит некоторые проблемы с безопасностью, но возникают другие проблемы.  Update: чуть позже накопал, что RODC не поддерживается на узлах кластера http://support.microsoft.com/kb/281662/en-us

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

• Проблема с лицензированием. Конечно, с лицензированием проблем здесь нет, но вот у вас проблемы появятся. Если хост Hyper-V выполняет какую-либо роль кроме виртуализации, то вы лишаетесь возможности в полной мере покрыть хостовой лицензией запущенные экземпляры виртуальных машин. Например, в случае с Standard-лицензией вообще лишаетесь возможности использовать хостовую лицензию для лицензирования одной запущенной виртуальной машины, а в случае с Enterprise - одной. То есть с Enterprise-лицензией можете лицензировать запуск не 4х виртуальных машин, а только трех. В оригинале это звучит так: 

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

А теперь, как я решал данную проблему.

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

Тем самым вы решаете проблему взаимозависимости. Теперь контроллеры доменов живут в виртуальных машинах и эти виртуальные машины не являются ресурсами кластера. При отключении электричества все прекрасно стартует.

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

Некоторые рекомендации (и даже требования):

1. Создавайте виртуальные машины с контроллерами доменов на дисках, не являющихся кластерными ресурсами. Это могут быть как локальные диски (DAS), так и диски с СХД.
2. Режим запуска виртуальных машин: Always Automatically Turn On The Virtual Machine или Automatically Turn On The Virtual Machine If It Was Running When The Physical Server Was Stopped
3. Для службы кластеров (ClusterSvc) необходимо произвести настройки восстановления. Те, что на вкладке «Восстановление» свойств службы ClusterSvc оснастки Services.msc. Для всех сбоев необходимо указать перезапуск службы. Не могу сказать какие конкретно значения для «Перезапуск служб через:» вам подойдут, необходимо подбирать их индивидуально. Я использовал 3 минуты.
4. Сократите интервал отображения меню восстановления. Настроить можно с помощью апплета «Система» панели управления.

На самом деле я слукавил, когда чуть выше сказал, что все прекрасно стартует. Не совсем. Может возникнуть дополнительная проблема.

Проблема №2.

Дело в том, что есть еще одна взаимозависимость: служба каталогов от DNS и DNS от службы каталогов.



Возникает она по следующей причине. Контроллер домена, при старте, пытается произвести репликацию своих контекстов именования (это при условии, что контроллер в лесу не один): пока не произведет репликацию, не будет выполнять свои функции. Служба DNS, желая при старте работать с самыми актуальными данными, откладывает загрузку интегрированных в AD зон, до момента, когда служба каталогов реплицирует данные и оповестит об этом службу DNS. Репликация AD, как известно, зависит от DNS: контроллер домена пытается получить IP-адреса своих партнеров по репликации с помощью DNS. А DNS в это время не работает, поскольку ждет AD. AD ждет DNS, DNS ждет AD. В свою очередь от DNS также зависит кластер и аутентификация. Через какое-то время служба каталогов все-таки даст добро службе DNS и та загрузит зоны. Этот timeout зависит от количества разделов, которые обслуживает контроллер доменов и примерно составляет 20 минут для 5 разделов (для контроллеров с 2008 R2 я наблюдал намного меньшую задержку – 5 минут).

20 минут для кого-то могут быть вполне допустимы, а для кого-то нет. Попробуем решить эту проблему.

Способы:

1. Использовать в качестве DNS сервера сервер с другой площадки. Скорее всего, в этом случае у вас не должно возникнуть и первой проблемы. 
2. Установить дополнительный физический сервер с ролью DNS. Этот сервер будет обслуживать вторичную зону для _msdcs корневого домена и доменную зону локального домена (главная задача разрешить DSAGUID партнера по репликации в FQDN и FQDN в IP-адрес) Этот способ конечно не подходит. Мы вернулись опять к проблеме с физическим сервером. В этом случае проще сразу развернуть физический контроллер доменов.
3. Установить роль DNS на хосте Hyper-V? Можно, но получаем те же проблемы, что и обсуждались чуть выше.
4. Отключить начальную репликацию. Это делается установкой значения Repl Perform Initial Synchronizations в 0 для ключа HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. Можно, но не рекомендуется. Не рекомендуется хотя бы по той причине, что таким образом происходит попытка решить проблему с существованием в лесу (или домене) нескольких FSMO. Лучше такой способ не использовать.
5. Использовать не интегрированные в AD зоны (полностью или частично). Знаете да, какие преимущества дает хранение зон в AD? Если вам эти преимущества не нужны, то можете использовать и этот способ.
6. Сделать так, чтобы имя партнера по репликации разрешалось без участия DNS-сервера. Как это можно сделать? Способов много. Дополнительно стоит сказать, что, начиная с Windows Server 2003 SP1, появилась функция name resolution fallback, на тот случай если не удастся разрешить DSAGUID контроллера домена. Цепочка следующая: GUID -> FQDN -> NETBIOS-имя. То есть, если не удается разрешить CNAME GUID, то происходит попытка разрешить FQDN, если и это не удается сделать, то происходит попытка получить IP по NETBIOS-имени. Поэтому проблему можно решить:

• Использованием HOSTS-файла. В хост файл можно внести запись о партнере по репликации. Можно добавить как GUID._msdcs.<имя_корневого_домена>, так и FQDN:

<IP-адрес партнера по репликации> <DSA GUID>._mcdcs.<имя корневого домена>
<IP-адрес партнера по репликации> <FQDN партнера по репликации

• Использованием файла LMHOST. Внести в файл соответствующую запись NETBIOS.
• Использованием WINS-сервера. Наверное, наиболее предпочтительный способ. 
• Использованием NETBIOS-широковещания для разрешения имени. Если контроллеры доменов в одном широковещательном домене и Netbios-over-TCPIP не отключен (включен по умолчанию), то с проблемой №2 вы вообще не должны столкнуться.

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


Надеюсь, что представленные в этой статье рекомендации, помогут вам.


Полезные ссылки:

Как установить Hyper-V кластер: http://lmgtfy.com/?q=how+to+install+hyper-v+cluster

О первоначальной репликации: http://support.microsoft.com/kb/305476/en-us

О проблеме загрузки DNS-зон: http://support.microsoft.com/kb/2001093/en-us

LMHOSTS: http://support.microsoft.com/kb/101927/en-us