Как раз в том и прелесть данного решения, что не сторонними средствами, а комплексным решением от одного вендора. С другой стороны, даже если утилиты сторонние, но они успешно решают поставленную задачу (как это в случае VmWare Update Manager), то смысл их использования есть.
Подход, при котором установка обновлений производится уже после развертывания виртуальной машины из шаблона, менее безопасен, так как подразумевает, что виртуальная машина без текущих обновлений подключается к сети предприятия, а это несет потенциальную угрозу. Бороться с этим можно методами ограничения доступа к локальной сети до момента установки необходимых обновлений, но это ведет к увеличению времени развертывания виртуальной машины и в большинстве случаев неприемлемо для VDI сценариев, где существует необходимость максимально быстрого предоставления доступа конечному пользователю.
Как раз у VmWare функционал установки обновлений в гостевые операционные системы Windows является сторонним (VmWare OEMит этот функционал у Shavlik Technologies www.shavlik.com/partners-oem.aspx). И есть информация, что в следующей версии vSphere это функционал из Update Manager вообще будет убран.
На мой взгляд, неправильно утверждать, что Virtual Machine Servicing Tool, System Center Virtual Machine Manager, Windows Server Update Services и System Center Configuration Manager – это сторонние инструменты. Все они разработаны компанией Microsoft. Если посмотреть на платформу виртуализации от VmWare, то за функционал установки обновлений отвечает не только гипервизор, а другие компоненты платформы.
На мой взгляд, если это записываемый доменный контроллер, то действительно нежелательно совмещать данную роль с другими ролями. Если же это доменный контроллер только для чтения (RODC), то вполне допустимо совмещение с другими ролями.
Это не совсем точное изложение информации, которая содержится в документе «Лицензионные права на использование продукта 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), то хостовую ОС можно использовать и не только под задачи платформы виртуализации.
Как и с любым программным обеспечением, возможна неработоспособность при очередном обновлении (как самого ПО, так и компонентов аппаратного обеспечения). И если обновление предварительно не протестировано в лаборатории (а как показывает практика, заказчики про это забывают) бывают глобальные сбои.
Вы правы. При использовании роли AD DS на самой ноде кластера по лицензии Ent можно будет использовать только 3 виртуальных машины, работающих на этой ноде.
Противоречия с рекомендациями нет. В рекомендациях от Microsoft указано, что нельзя включать доменные контроллеры, которые были в состоянии Save State больше, чем tombstone time (обычно 180 дней). Эта рекомендация на самом деле относится и к физическим доменным контроллерам (в текущих версиях ОС Windows Server они просто не будут реплицироваться с партнерами по репликации).
С точки зрения того, что будет с репликацией между доменными контроллерами, которые поднимаются из Save State, то ничего страшного не произойдет, так как каждая транзакция в базу AD DS либо полностью пишется, либо полностью откатывается. И данный сценарий, на мой взгляд, не более страшен, чем отключение сетевого кабеля от доменного контроллера (что тоже ведет к потере TCP соединения между доменными контроллерами).
У каждой из платформ есть свои плюсы и минусы, связанные с архитектурными особенностями.
С одной стороны HA-кластер на vSphere и кластер на базе XenServer, в отличие от кластера на платформе Windows, не требует наличия доменных контроллеров.
С другой стороны на физический хост под vSphere или XenServer нельзя поставить роль доменного контроллера, а на физический хост, в кластере на платформе Windows можно поставить, как роль Hyper-V, так и роль AD DS.
Подход, при котором установка обновлений производится уже после развертывания виртуальной машины из шаблона, менее безопасен, так как подразумевает, что виртуальная машина без текущих обновлений подключается к сети предприятия, а это несет потенциальную угрозу. Бороться с этим можно методами ограничения доступа к локальной сети до момента установки необходимых обновлений, но это ведет к увеличению времени развертывания виртуальной машины и в большинстве случаев неприемлемо для VDI сценариев, где существует необходимость максимально быстрого предоставления доступа конечному пользователю.
Вот выдержка со страницы 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), то хостовую ОС можно использовать и не только под задачи платформы виртуализации.
То, что «спали» они узнают, так как при старте виртуальной машины ее время первоначально берется с хоста, а на хосте часы шли.
Но если хочется подстраховаться, то имеет смысл гасить машины.
С точки зрения того, что будет с репликацией между доменными контроллерами, которые поднимаются из Save State, то ничего страшного не произойдет, так как каждая транзакция в базу AD DS либо полностью пишется, либо полностью откатывается. И данный сценарий, на мой взгляд, не более страшен, чем отключение сетевого кабеля от доменного контроллера (что тоже ведет к потере TCP соединения между доменными контроллерами).
С одной стороны HA-кластер на vSphere и кластер на базе XenServer, в отличие от кластера на платформе Windows, не требует наличия доменных контроллеров.
С другой стороны на физический хост под vSphere или XenServer нельзя поставить роль доменного контроллера, а на физический хост, в кластере на платформе Windows можно поставить, как роль Hyper-V, так и роль AD DS.
В остальном, принципиальной разницы в том, какая платформа виртуализации используется — нет.
А так достаточно и в Save State, чтобы они уходили, а при старте из него поднимались.