Выпуск Windows Server 2012 стал колоссальным событием, и особенно важные изменения связаны с виртуализацией и «облачными» службами. Один из крупнейших новых компонентов - Hyper-V Replica, обеспечивающий асинхронную репликацию виртуальной машины на второй узел Hyper-V. Целевой сервер Hyper-V (то есть реплика) не обязательно должен быть частью кластера с основным узлом Hyper-V. В действительности реплика не может быть в одном кластере с основным узлом. Не требуется реплике и общего хранилища и даже выделенной сетевой инфраструктуры для репликации. Цель Hyper-V Replica - обеспечить восстановление после аварии для любой среды Hyper-V без сложных предварительных условий через асинхронную репликацию. В некоторых SAN также предусмотрена асинхронная репликация данных с основного узла в реплику, но не в реальном времени. Действия записи выполняются на основном узле, подтверждаются для процесса записи, а затем реплицируются, когда возможно. Существует задержка между записью на основном узле и на реплике. В зависимости от задержки на сервере реплики может не оказаться определенного количества данных, которые будут потеряны в случае отказа основного узла. Возможный пропуск часто именуют целевой точкой восстановления recovery point objective (RPO). В сущности, он определяет максимальный размер потери данных, приемлемый при аварии. Например, значение RPO, равное 5 минутам, означает, что будут потеряны данные не более чем за 5 минут.
Асинхронная репликация на уровне SAN для многих компаний нежелательна, так как для основной площадки и реплики требуется один и тот же поставщик. Но Hyper-V Replica использует асинхронную репликацию очень эффективно. На верхнем уровне Hyper-V Replica функционирует следующим образом.
1. Когда виртуальная машина подготовлена для репликации, создается новая виртуальная машина на узле реплики Hypcr-V. Виртуальная машина-реплика имеет такую же конфигурацию, как основная виртуальная машина; она отключена.
2. Хранилище основной виртуальной машины реплицируется в виртуальную машину - реплику на сервере реплики Hypcr-V. На основном узле Hyper-V формируется журнал для сохранения записей на реплицированных виртуальных жестких дисках (VHD). Файл журнала хранится в том же месте, что и исходный VHD.
3. После завершения начальной репликации хранилища файл журнала закрывается. Формируется новый файл журнала для отслеживания текущих изменений; закрытый файл журнала отсылается на узел реплики Hyper-V и объединяется с виртуальными жесткими дисками для реплики виртуальной машины. Реплика виртуальной машины остается отключенной.
4. Через каждые пять минут файл журнала закрывается, создается новый, а закрытый файл объединяется с репликой. Благодаря асинхронной репликации в Hyper-V Replica репликация становится возможной во многих компаниях и сценариях аварийного восстановления:
репликация между центрами обработки данных для приложений уровня 1 в компаниях без репликации на уровне SAN (малые и средние компании);
репликация между центрами обработки данных для приложений уровня 2 в компаниях с репликацией на уровне SAN, но не желающих использовать ее для приложений, отличных от уровня 1;
репликация филиал - главный офис для защиты приложений, размещенных в филиале; репликация между поставщиками услуг хостинга;
репликация на поставщика услуг хостинга для аварийного восстановления в небольших компаниях, не имеющих второго центра обработки данных. Существует и множество других возможных сценариев. Главное, что благодаря Hyper-V Replica репликация виртуальных машин доступна любой компании.