Обзор реплики Hyper-V

Hyper-V реплика — это встроенная функция Hyper-V в Windows Server, которая обеспечивает репликацию виртуальных машин между Hyper-V узлами для обеспечения непрерывности бизнес-процессов и аварийного восстановления (BCDR). Он позволяет делать и поддерживать резервные копии виртуальных машин в автономном режиме на вторичном узле и даже масштабировать до третьего узла, который можно использовать для автоматического переключения при выходе из строя основного узла. Hyper-V Replica недоступна в Hyper-V на клиентских операционных системах Windows.

Hyper-V отказоустойчивая кластеризация и Hyper-V Replica решают различные, но связанные сценарии доступности. Кластер отказоустойчивости Hyper-V обеспечивает локальную высокую доступность для запуска виртуальных машин с помощью нескольких узлов, которые обычно используют общее кластеризованное хранилище. Если узел выходит из строя, служба кластера перезапускает пострадавшую виртуальную машину на другом узле без потери данных или с минимальными потерями, поскольку виртуальные жесткие диски данной машины остаются в общем хранилище. Hyper-V реплика, напротив, — это технология аварийного восстановления, которая поддерживает асинхронную копию хранилища виртуальной машины на другом узле или кластере (часто на другом сайте), поэтому можно вручную инициировать переключение на резервный режим, если основной узел, кластер или сайт становится недоступным. Реплика не требует общего хранилища, представляет целевую точку восстановления (потенциальную потерю данных до интервала репликации) и дополняет, а не заменяет отказоустойчивую кластеризацию. Многие организации используют оба варианта: кластеризация для обеспечения высокой доступности внутри сайта и Hyper-V реплики для обеспечения устойчивости между сайтами и восстановления.

В этой статье представлен обзор Hyper-V Реплика, её ключевых функций, принципов работы и способов использования её для улучшения стратегии BCDR.

Основные функции реплики Hyper-V

Hyper-V Реплика предлагает несколько ключевых функций, которые позволяют использовать мощный и доступный инструмент для репликации виртуальных машин и аварийного восстановления:

• Независящая от типа рабочей нагрузки и приложений: Hyper-V Replica работает на уровне гипервизора, что позволяет реплицировать широкий спектр рабочих нагрузок и приложений, не требуя агентов или конфигураций, специфичных для приложений.

• Асинхронная репликация: изменения, внесенные на основную виртуальную машину, сопоставляются с помощью отказоустойчивого отслеживания изменений (RCT) на уровне блока и могут отправляться на виртуальную машину реплики через регулярные интервалы в 30 секунд, 5 минут или 15 минут в зависимости от требований точки восстановления (RPO). RCT уменьшает потребность в проверках согласованности, потребляющих много времени, и обеспечивает большую устойчивость.

• Плановое и внеплановое переключение на резервный узел: При плановом переключении на резервный узел первичная виртуальная машина завершает работу категорически и реплицирует оставшиеся изменения перед переключением на реплику. При незапланированной отказоустойчивости виртуальная машина реплики запускается без завершения работы основной виртуальной машины. Это может привести к потере части данных. После восстановления основного узла можно выполнить обратную репликацию для синхронизации изменений с исходной первичной виртуальной машиной. Дополнительные сведения см. в разделе "Отработка отказа и восстановление".

• Гибкие топологии: репликация между одними узлами, кластеризованными узлами или сочетанием обоих узлов, что позволяет разработать стратегию репликации, которая соответствует вашей инфраструктуре. Хосты могут располагаться на одном сайте или в разных географических местоположениях.

• Шифрование и проверка подлинности: поддержка как Kerberos (для узлов, присоединенных к домену), так и проверки подлинности на основе сертификатов (для узлов, не присоединенных к домену), обеспечивая гибкость в защите трафика репликации. Шифрование трафика репликации с помощью сертификата для защиты данных при передаче. Вы можете ограничить репликацию между определенными Hyper-V узлами, чтобы повысить безопасность.

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

• Сеть и сжатие: репликация основана на TCP с помощью HTTP или HTTPS. Вы можете включить сжатие для уменьшения использования пропускной способности во время репликации.

• Журнал восстановления: до 24 часовых точек восстановления позволяют вернуться к предыдущему состоянию виртуальной машины при необходимости. Интеграция службы теневого копирования томов (VSS) может предоставлять точки восстановления, согласованные с приложением, для виртуальных машин с поддержкой VSS, таких как Microsoft SQL Server.

• Тестирование отказоустойчивости: выполните тестирование отказоустойчивости, чтобы проверить план аварийного восстановления без влияния на производственную среду. Дополнительные сведения см. в разделе «Переключение при отказе и восстановление».

• Расширенная репликация: можно расширить репликацию с вторичного узла на третий узел Hyper-V, создав топологию репликации трехуровневой. Этот подход обеспечивает дополнительный уровень избыточности и поддерживает более сложные стратегии BCDR. Для расширенной репликации можно использовать другой интервал репликации, чтобы сбалансировать цели точки восстановления (RPO) и использование пропускной способности на разных сайтах. Репликация не происходит с первичного сервера на два других сервера реплики. Вместо этого первичный сервер реплицируется на сервер-реплику, который, в свою очередь, реплицируется на сервер расширенной реплики.

• Отсутствие дополнительных затрат на лицензирование: Реплика Hyper-V включена в Windows Server без дополнительных затрат, что делает её рентабельным решением для репликации виртуальных машин и аварийного восстановления.

компоненты реплики Hyper-V

Hyper-V реплика включает компоненты, описанные в следующей таблице:

Компонент	Description
Подсистема репликации	Управляет начальной репликацией, сведениями о конфигурации репликации, репликацией изменений дельты и операциями переключения на резерв и тестового переключения на резерв. Отслеживает события мобильности виртуальных машин и хранилища и выполняет соответствующие действия при необходимости.
Модуль отслеживания изменений	Отслеживает изменения, возникающие на виртуальной машине на исходном Hyper-V узле, отслеживая операции записи на виртуальные жесткие диски (VHD), независимо от расположения хранилища (локального, SAN, NAS, SMB 3 или более новой общей папки или общего тома кластера).
Сетевой модуль	Обеспечивает безопасный и эффективный способ передачи данных виртуальной машины между Hyper-V узлами. Сводит к минимуму трафик путем сжатия данных по умолчанию и может шифровать данные при использовании HTTPS и проверки подлинности на основе сертификатов.
Брокер реплики Hyper-V	Используется только в том случае, если узел Hyper-V является узлом в отказоустойчивом кластере. Позволяет использовать реплику Hyper-V с высокодоступными виртуальными машинами, которые могут перемещаться между узлами кластера, запрашивая базу данных кластера и перенаправляя запросы на узел, на котором выполняется виртуальная машина.
Средства управления	Настройте и управляйте репликой Hyper-V с помощью диспетчера Hyper-V и Windows PowerShell. Используйте Диспетчер отказоустойчивых кластеров для управления всеми виртуальными машинами и конфигурациями Hyper-V Replica, когда узлы источника или реплики являются частью отказоустойчивого кластера.

Как работает реплика Hyper-V

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

Hyper-V реплика может иметь следующие два экземпляра одной виртуальной машины, размещенные на разных узлах Hyper-V:

• Основная активная виртуальная машина, которая называется первичной виртуальной машиной.
• Автономная копия основной виртуальной машины, которая называется репликой виртуальной машины.

Процесс репликации включает несколько ключевых компонентов и шагов, которые описаны на следующей схеме:

1. При включении Hyper-V реплики для виртуальной машины создается начальная копия виртуальной машины на дополнительном узле. Эту копию можно отправить по сети или с помощью внешнего носителя.

2. Hyper-V использует механизм отслеживания изменений для отслеживания изменений, внесенных на виртуальные жесткие диски основной виртуальной машины (VHD). Он сохраняет изменения в .hrl файлах в том же расположении. Этот подход позволяет Hyper-V определить, какие блоки данных изменились с момента последнего цикла репликации.

3. В настроенный интервал репликации (30 секунд, 5 минут или 15 минут) Hyper-V отправляет изменения вторичному узлу. Процесс репликации является асинхронным, поэтому основная виртуальная машина продолжает работать, пока Hyper-V реплицирует изменения.

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

5. Если основной хост завершается сбоем, вы инициируете переключение на виртуальную машину-реплику. В зависимости от того, является ли это плановая или незапланированная отработка отказа, процесс немного отличается, но конечный результат заключается в том, что реплика ВМ становится новой основной ВМ. Вы можете инициировать переключение на резервный узел вручную или с помощью сценариев автоматизации.

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

Планирование реплики Hyper-V

При планировании реализации Hyper-V Replica как часть вашей стратегии BCDR рассмотрите и примите решения по следующим проектным аспектам:

Точка принятия решений	Вспомогательные сведения
Какие рабочие нагрузки необходимо реплицировать?	Вывод списка целевых виртуальных машин и их рабочих нагрузок. Репликация по умолчанию защищает состояние ОС, а не состояние приложения в полете. Если необходимо восстановить состояние приложения, включите (и запланируйте) точки восстановления, согласованные с приложением.
Какие виртуальные жесткие диски необходимо реплицировать?	Исключите диски, данные которых изменяются, но не требуются после переключения на резервную систему (например, диски данных страниц или временные диски) для экономии пропускной способности и хранилища. Исключения документов.
Как часто требуется синхронизировать данные?	Выберите 30 секунд, 5 минут или 15 минут на основе RPO, критичности и пропускной способности. Более высокая критичность и более низкая RPO требует более коротких интервалов; проверьте доступную сетевую емкость.
Какова скорость изменения данных на каждой виртуальной машине?	Высокая скорость обработки увеличивает пропускную способность и потребление хранилища реплик. Если произойдет насыщение, рассмотрите возможность сжатия или увеличения интервала. Включите каждую виртуальную машину в расчёт размеров.
Какой метод проверки подлинности будет использоваться и требуется шифрование?	Используйте Kerberos, если оба узла присоединены к домену и не требуют шифрования. Используйте проверку подлинности на основе сертификатов для шифрования трафика реплики, а также в случае, если любой из узлов не присоединен к домену; заранее подготовьте и доверьте требуемые сертификаты.
Необходимо ли выполнить переключение на предшествующий момент времени?	По умолчанию используется одна (последняя) точка восстановления. Настройте до 24 часовых точек для восстановления на определенный момент времени; больше точек увеличивают объем хранилища и нагрузки на ввод-вывод.
Как будет выполняться начальная репликация данных виртуальной машины?	Options: — немедленно отправьте по сети. — Планирование сетевой передачи для последующего периода времени. — Используйте существующую восстановленную виртуальную машину на узле реплики. — Экспорт на внешний носитель, отправку и импорт на сайте реплики.

Резервирование при отказе и восстановление

Важно регулярно тестировать план BCDR, чтобы убедиться, что реплика Hyper-V работает должным образом и вы можете успешно выполнить переключение на отказ и восстановление виртуальных машин. Следует провести пробные переключения на резерв, проверить контрольные точки восстановления и убедиться, что все компоненты стратегии репликации работают правильно. Регулярное тестирование помогает выявить потенциальные проблемы и убедиться, что ваша команда знакома с процессами переключения на резервный и восстановления.

Существует три типа сценариев переключения в Hyper-V Replica:

• Тестовое переключение на резерв можно выполнить в любой момент, не влияя на рабочую среду. Тестирование отказоустойчивости создает временную копию реплики виртуальной машины на вторичном узле, что позволяет проверить процесс отказоустойчивости и убедиться, что виртуальная машина запускается правильно. Тестовая виртуальная машина изолирована от рабочей сети, чтобы предотвратить конфликты. Основная виртуальная машина продолжает выполняться во время тестового переключения, поэтому не возникает времени простоя, и процесс репликации не затрагивается. После завершения теста, включая другие компоненты плана BCDR, вы можете удалить тестовую виртуальную машину без влияния на виртуальную машину реплики или основную виртуальную машину.

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

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

Дополнительные сведения о выполнении операций отработки отказа и восстановления с помощью Hyper-V Replica см. статью Отработка отказа на реплицированной виртуальной машине с помощью Hyper-V Replica.

Следующий шаг

Чтобы настроить реплику Hyper-V, выберите одну из следующих статей в зависимости от среды:

Включение Hyper-V Replica в отказоустойчивом кластере

Включить Hyper-V репликацию на одном узле