Комментарии 40
technet.microsoft.com/ru-ru/library/dd348476%28WS.10%29.aspx — ссылка на документ на русском языке.
Ошибся. Вот правильная ссылка на документ на русском языке.
technet.microsoft.com/ru-ru/library/virtual_active_directory_domain_controller_virtualization_hyperv%28WS.10%29.aspx
technet.microsoft.com/ru-ru/library/virtual_active_directory_domain_controller_virtualization_hyperv%28WS.10%29.aspx
помимо компонентов интеграции, лучше еще настроить завершение работы виртуальных контроллеров домена, при выключении хоста
Если готовы мириться с тем, что доменные контроллеры будут достаточно долго стартовать при последующем включении хоста, то можно сделать и завершение.
А так достаточно и в Save State, чтобы они уходили, а при старте из него поднимались.
А так достаточно и в Save State, чтобы они уходили, а при старте из него поднимались.
На счет сохранения состояния — не согласен. Более того, это даже несколько противоречит рекомендациям.
Поясню: у вас несколько контроллеров домена, как они поведут себя после восстановления состояния? Кто из них последний ушел, кто первый очнулся? На каком этапе синхронизации их прервали?
Усложним задачу: у нас лес и много доменов. Вы можете предсказать все варианты развития событий?
Я — нет. Поэтому, риск получить битую базу или устаревшие данные — достаточно велик. И поэтому вариант с сохранением считаю не пригодным.
Поясню: у вас несколько контроллеров домена, как они поведут себя после восстановления состояния? Кто из них последний ушел, кто первый очнулся? На каком этапе синхронизации их прервали?
Усложним задачу: у нас лес и много доменов. Вы можете предсказать все варианты развития событий?
Я — нет. Поэтому, риск получить битую базу или устаревшие данные — достаточно велик. И поэтому вариант с сохранением считаю не пригодным.
Противоречия с рекомендациями нет. В рекомендациях от Microsoft указано, что нельзя включать доменные контроллеры, которые были в состоянии Save State больше, чем tombstone time (обычно 180 дней). Эта рекомендация на самом деле относится и к физическим доменным контроллерам (в текущих версиях ОС Windows Server они просто не будут реплицироваться с партнерами по репликации).
С точки зрения того, что будет с репликацией между доменными контроллерами, которые поднимаются из Save State, то ничего страшного не произойдет, так как каждая транзакция в базу AD DS либо полностью пишется, либо полностью откатывается. И данный сценарий, на мой взгляд, не более страшен, чем отключение сетевого кабеля от доменного контроллера (что тоже ведет к потере TCP соединения между доменными контроллерами).
С точки зрения того, что будет с репликацией между доменными контроллерами, которые поднимаются из Save State, то ничего страшного не произойдет, так как каждая транзакция в базу AD DS либо полностью пишется, либо полностью откатывается. И данный сценарий, на мой взгляд, не более страшен, чем отключение сетевого кабеля от доменного контроллера (что тоже ведет к потере TCP соединения между доменными контроллерами).
Про надгробия и так понятно, дело ведь не в этом.
Кусочек поста: «Восстановление состояния при помощи дифференциальных дисков, снимков виртуальной машины...»
Вы привели неадекватный пример. При выдергивании шнура часы контроллеров продолжают тикать, при сохранении состояния — нет. При этом один рабочий контроллер может продолжать обслуживать клиентов, другой уже уйти «спать». Третий еще чуть позже. Какое время будет при включении — неизвестно. Контроллеры ведь будут не в курсе, что они «спали» :)
Вариантов масса. Поэтому считаю что лучше не рисковать, перестраховаться и подождать на 1-2 минуты больше, нормально включая/выключая контролллер.
Кусочек поста: «Восстановление состояния при помощи дифференциальных дисков, снимков виртуальной машины...»
Вы привели неадекватный пример. При выдергивании шнура часы контроллеров продолжают тикать, при сохранении состояния — нет. При этом один рабочий контроллер может продолжать обслуживать клиентов, другой уже уйти «спать». Третий еще чуть позже. Какое время будет при включении — неизвестно. Контроллеры ведь будут не в курсе, что они «спали» :)
Вариантов масса. Поэтому считаю что лучше не рисковать, перестраховаться и подождать на 1-2 минуты больше, нормально включая/выключая контролллер.
Save State при этом допускается, так как это только снимок памяти, а не диска, в отличие от полного снимка виртуальной машины.
То, что «спали» они узнают, так как при старте виртуальной машины ее время первоначально берется с хоста, а на хосте часы шли.
Но если хочется подстраховаться, то имеет смысл гасить машины.
То, что «спали» они узнают, так как при старте виртуальной машины ее время первоначально берется с хоста, а на хосте часы шли.
Но если хочется подстраховаться, то имеет смысл гасить машины.
•Необходимо отключить синхронизацию времени через компоненты интеграции между виртуальной машиной с ролью доменного контроллера и родительским разделом
С какой стати гость будет брать время с хозяйской ОС?
С какой стати гость будет брать время с хозяйской ОС?
С какой стати гость будет брать время с хозяйской ОС?
С такой стати, что в интеграционных компонентах (Integration Services, VMware Tools, etc.) такая фича имеется.
С такой стати, что в интеграционных компонентах (Integration Services, VMware Tools, etc.) такая фича имеется.
Для КД отключение питания (Turn off) не является штатной процедурой, но тем неменее, они прекрасно это переживают. И это в любом случае лучше чем save state.
На восстановление состояние ему по барабану. Репликация СК учитывает метки времени второстепенно. В первую очередь используются метки версий. Поэтому если мы засейвим состояние, то ничего не поменяется, и контроллер вернется к прежнему состоянию, с теми же метками.
Что будет со временем? Возьмется с parent partition. Поскольку системный таймер в этом случае еще никто не отменял. Просто если будут отключены Integration Service, то синхронизации постоянной не будет. Тем не менее таймер системный используется. Возможно время отстанет немного, но это не беда, если только оно не сильно отстало. В этом случае, либо репликация будет запрещена (половина срока захоронения объектов) либо будет ошибка в аутентификации по Kerberos.
Со снепшотами несколько иначе, поскольку мы откатывает состояние, а значит откатываем и версионность. При этом InvocationID не меняется, да и вообще контроллер не знает, что снепшот откатили. Поэтому начинает считать версии заново (продолжает). Вот тут то мы и получаем мисконфигурасьон.
Что будет со временем? Возьмется с parent partition. Поскольку системный таймер в этом случае еще никто не отменял. Просто если будут отключены Integration Service, то синхронизации постоянной не будет. Тем не менее таймер системный используется. Возможно время отстанет немного, но это не беда, если только оно не сильно отстало. В этом случае, либо репликация будет запрещена (половина срока захоронения объектов) либо будет ошибка в аутентификации по Kerberos.
Со снепшотами несколько иначе, поскольку мы откатывает состояние, а значит откатываем и версионность. При этом InvocationID не меняется, да и вообще контроллер не знает, что снепшот откатили. Поэтому начинает считать версии заново (продолжает). Вот тут то мы и получаем мисконфигурасьон.
хм… америку своим постом не открыли.
ИМХО
ИМХО
Рекомендация последняя: использовать VMware vSphere ;-)
Действительно в последних версиях платформы от VMWare синхронизация времени в гостевой машине с хостом «по умолчанию» отключена.
В остальном, принципиальной разницы в том, какая платформа виртуализации используется — нет.
В остальном, принципиальной разницы в том, какая платформа виртуализации используется — нет.
Чтобы собрать Microsoft Hyper-V кластер узлы должны быть введены в домен, так что в любом случаи нужен физический DC. И все прекрасно знают как работает кластер Microsoft.
В VMWare немного все по другому.
В VMWare немного все по другому.
У каждой из платформ есть свои плюсы и минусы, связанные с архитектурными особенностями.
С одной стороны HA-кластер на vSphere и кластер на базе XenServer, в отличие от кластера на платформе Windows, не требует наличия доменных контроллеров.
С другой стороны на физический хост под vSphere или XenServer нельзя поставить роль доменного контроллера, а на физический хост, в кластере на платформе Windows можно поставить, как роль Hyper-V, так и роль AD DS.
С одной стороны HA-кластер на vSphere и кластер на базе XenServer, в отличие от кластера на платформе Windows, не требует наличия доменных контроллеров.
С другой стороны на физический хост под vSphere или XenServer нельзя поставить роль доменного контроллера, а на физический хост, в кластере на платформе Windows можно поставить, как роль Hyper-V, так и роль AD DS.
На сколько я знаю, если на хост вы добавите какую-то роль кроме hyper-v, то лишаетесь права использовать правило 1+1 для std и 1+4 для ent.
Вы правы. При использовании роли AD DS на самой ноде кластера по лицензии Ent можно будет использовать только 3 виртуальных машины, работающих на этой ноде.
Вы меня смутили, я считал, что вообще нельзя использовать эти 4 виртуальные лицензии если на хосте есть что-то кроме hyper-v. Т.е. все 4 лицензии пропадают, а не 1.
Надо будет этот вопрос уточнить.
Надо будет этот вопрос уточнить.
«Каждая лицензия программного обеспечения позволяет запускать в любой момент четыре экземпляра серверного программного продукта в четырех операционных средах на одном сервере. Если все четыре экземпляра выполняются в виртуальных операционных средах, можно также запустить экземпляр в физической операционной среде исключительно для запуска программы аппаратной виртуализации, предоставления служб аппаратной виртуализации или запуска программы для управления и обслуживания операционных сред на лицензированном сервере. Для краткости мы называем такой подход 1 + 4»
Так что никаких исключений для хостовой системы — только hyper-v.
Так что никаких исключений для хостовой системы — только hyper-v.
Это не совсем точное изложение информации, которая содержится в документе «Лицензионные права на использование продукта Microsoft» (http://www.microsoftvolumelicensing.com/userights/Downloader.aspx?DocumentId=3104).
Вот выдержка со страницы 9 данного документа:
Например, лицензия на использование Windows Server 2008 R2 Enterprise позволяет одновременно запускать экземпляр этой операционной системы максимум в 4 виртуальных операционных средах на одном лицензированном сервере. Для некоторых продуктов (например, для Windows Server 2008 R2 Datacenter) вы можете одновременно запускать любое количество экземпляров, до тех пор пока действует лицензия для каждого физического процессора на лицензированном сервере.
Рис. 4
Количество разрешенных экземпляров для каждой лицензии на использование операционной системы
Операционная система Количество разрешенных экземпляров в физической и виртуальной операционных средах на одном сервере
Windows Server 2008 R2 Standard и
Windows MultiPoint Server 2010 Academic 1* + 1
Windows Server 2008 R2 Enterprise 1* + 4
Windows Server 2008 R2 Datacenter 1 + неограниченное число
Windows Small Business Server 2008 Standard 1* или 1
Windows Server 2003 for Small Business 1* или 1
* Если запущено максимально разрешенное количество экземпляров, экземпляр в физической операционной среде может использоваться только для запуска программного обеспечения виртуализации устройств, обеспечения служб виртуализации устройств или для запуска программного обеспечения для управления операционными средами и их обслуживания на лицензированном сервере.
Так что если у вас запущено не максимально разрешенное количество экземпляров в виртуальной среде (например 3 для Windows Server 2008 R2 Enterprise), то хостовую ОС можно использовать и не только под задачи платформы виртуализации.
Вот выдержка со страницы 9 данного документа:
Например, лицензия на использование Windows Server 2008 R2 Enterprise позволяет одновременно запускать экземпляр этой операционной системы максимум в 4 виртуальных операционных средах на одном лицензированном сервере. Для некоторых продуктов (например, для Windows Server 2008 R2 Datacenter) вы можете одновременно запускать любое количество экземпляров, до тех пор пока действует лицензия для каждого физического процессора на лицензированном сервере.
Рис. 4
Количество разрешенных экземпляров для каждой лицензии на использование операционной системы
Операционная система Количество разрешенных экземпляров в физической и виртуальной операционных средах на одном сервере
Windows Server 2008 R2 Standard и
Windows MultiPoint Server 2010 Academic 1* + 1
Windows Server 2008 R2 Enterprise 1* + 4
Windows Server 2008 R2 Datacenter 1 + неограниченное число
Windows Small Business Server 2008 Standard 1* или 1
Windows Server 2003 for Small Business 1* или 1
* Если запущено максимально разрешенное количество экземпляров, экземпляр в физической операционной среде может использоваться только для запуска программного обеспечения виртуализации устройств, обеспечения служб виртуализации устройств или для запуска программного обеспечения для управления операционными средами и их обслуживания на лицензированном сервере.
Так что если у вас запущено не максимально разрешенное количество экземпляров в виртуальной среде (например 3 для Windows Server 2008 R2 Enterprise), то хостовую ОС можно использовать и не только под задачи платформы виртуализации.
Согласен, возможно я не совсем верно трактую. Свой ответ отновывал на этом документе: download.microsoft.com/documents/rus/licensing/licenzirovanie_servernih_produktovmicrosoft_pri_ispolzovanii_v_virtualnoy_srede.docx
называется он «Лицензирование серверных продуктов Microsoft в виртуальной среде»
То, что в моем комментарии в кавычках — это цитата из него.
Тем не менее, считаю неправильным совмещение роли DC и прочих ролей. Поэтому если есть возможность — пусть живет отдельной ролью на отдельной машине (физ или вирт — не так важно)
называется он «Лицензирование серверных продуктов Microsoft в виртуальной среде»
То, что в моем комментарии в кавычках — это цитата из него.
Тем не менее, считаю неправильным совмещение роли DC и прочих ролей. Поэтому если есть возможность — пусть живет отдельной ролью на отдельной машине (физ или вирт — не так важно)
И все прекрасно знают как работает кластер Microsoft.
Ну-ну, и как же он работает, расскажите? /coolface.jpg
И да, для контроллеров домена не нужна отказоустойчивость на уровне HA-кластеров, достаточно просто два КД.
Ну-ну, и как же он работает, расскажите? /coolface.jpg
И да, для контроллеров домена не нужна отказоустойчивость на уровне HA-кластеров, достаточно просто два КД.
Никто вам не мешает поставить первый КД в отдельную виртуалку, после чего его вывести из использования.
решил тут написать статью о том как поднять hyper-v кластер без физического DC.
gexeg.blogspot.com/2012/06/hyper-v.html
gexeg.blogspot.com/2012/06/hyper-v.html
Про пункт с физической машиной хотелось бы уточнить, к примеру какой может произойти глобальный сбой системы виртуализации при использовании ESXi?
Начнем с жизненного примера — протек бассейн на крыше здания… прямо на серверную.
Хорошее у вас здание, с бассейном. :) И серверная видимо не плохая, катастрофоустойчивая, а в подвале, прямо под серверной, наверное еще и котельная имеется, чтобы отапливать тот бассейн на крыше, который прямо над серверной.
А если серьезно, я видел такое: протекла крыша, затопило кабинет с компами (~15 штук). Далеко не все выжило. Железо поменяли. Крышу не успели (или не доделали, или плохо сделали, точно не знаю), кабинет затопило еще раз.
А если серьезно, я видел такое: протекла крыша, затопило кабинет с компами (~15 штук). Далеко не все выжило. Железо поменяли. Крышу не успели (или не доделали, или плохо сделали, точно не знаю), кабинет затопило еще раз.
Есть более жизненные примеры, например обновление прошивки.
Как и с любым программным обеспечением, возможна неработоспособность при очередном обновлении (как самого ПО, так и компонентов аппаратного обеспечения). И если обновление предварительно не протестировано в лаборатории (а как показывает практика, заказчики про это забывают) бывают глобальные сбои.
Рекомендации один в один схожи с рекомендациями насчет аппаратных КД. Всё сводится к пониманию работы AD.
В который раз читаю этот документ и в который раз не понимаю почему Microsoft так трепетно относится к этой теме. Это же всё очевидные вещи, прямо как не ковыряться гвоздём в розетке.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что нужно учитывать при виртуализации доменных контроллеров?