- Alternatives to native hyper-v replication
- Configuring replication on the first server
- Configuring windows firewall
- Copying the exported certificates to the second server
- Creating certificates on the primary server
- Exporting a certificate from the first server
- Exporting the root certificate from the first server
- Ip-адресация
- Overview of the main steps
- Using a ca inside your ad domain
- Why use certificates for hyper-v
- Windows server 2021: configuring hyper-v replica in a workgroup environment – part1
- Архитектура
- Безопасность
- Как включить репликацию вм в windows server 2021 hyper-v
- Минимальные требования
- Настройка hyper-v replica
- Настройка виртуальных машин для репликации
- Настройка репликации виртуальной машины
- Принцип работы
- Установка роли hyper-v replica broker
- Экономичный выбор
- Conclusion
Alternatives to native hyper-v replication
Built-in Hyper-V functionality to perform replication is useful. But sometimes you may need extended functionality to perform Hyper-V replication and virtual machine failover. There is a good alternative to native Hyper-V replication.
NAKIVO Backup & Replication is a universal data protection solution that can back up Hyper-V virtual machines and perform VM failover. The product supports Hyper-V replication in Active Directory domains and Workgroups. The following functionality is included:
There are many useful features that you can use in addition to Hyper-V replication, such as Hyper-V VM backup, VMware VM backup and replication, physical machine backup (Linux and Windows), etc. You can recover a machine from a physical server backup to a VM, or recover a Hyper-V VM backup to a VMware VM. Don’t wait for a disaster – download NAKIVO Backup & Replication and protect your Hyper-V VMs today.
Configuring replication on the first server
Create a VM on a primary Hyper-V server to replicate. Make sure that the source VM doesn’t have any snapshots before you enable replication. Enable replication on the first machine, which is the primary server (Hyper-v-prim.test.net in our case).
Right-click a VM, and, in the context menu, hit Enable Replication.
The Enable Replication wizard opens.
Before you Begin. Hit Next to continue.
Specify Replica Server. Enter the name of your replica server. In our case, we use Hyper-v-repl.test.net as a replica server.
Configuring windows firewall
Configure firewall to enable inbound traffic. Enable inbound TCP connections on port 443 on the replica server (or disable the firewall temporary for test purposes).
Copying the exported certificates to the second server
Copy the two exported certificate files (Hyper-v-repl.pfx and TestRoot.cer) from the first server to the second server.
We copy files to C:temp on the second server.
We can use the network path \Hyper-v-replC$ or \192.168.101.213C$ to copy certificates via network (where 192.168.101.213 is the IP address of the replica server in our case). Firewall configuration must allow connections for the SMB protocol.
Creating certificates on the primary server
Certificates can be created by using multiple methods. The command line interface is usually used for this purpose. The first option is to use the MakeCert tool to create self-signed certificates. Now the MakeCert tool is deprecated, and we are going to use another solution.
Use the New-SelfSignedCertificate cmdlet as a modern alternative to the MakeCert tool to create self-signed certificates.
Exporting a certificate from the first server
On the first server, select the certificate needed for the second server (Hyper-v-repl.test.net) that is located in Personal/Certificates. Right-click the certificate and in the context menu click All Tasks > Export.
The Certificate Export Wizard opens.
1. Welcome. There is nothing to configure on the welcome screen. Hit Next at each step to continue.
2. Export Private Key. Select Yes, export the private key.
3. Export File Format. Select Personal Information Exchange – PKCS #12 (.PFX), and select Include all certificatesin the certification path if possible.
4. Security. Enter a password to maintain security and protect the private key.
5. File to Export. Specify the name and location of the file you want to export, for example, C:tempHyper-v-repl.pfx
6. Completing the Certificate Export Wizard. Check configuration and hit Finish.
You should see the message: The export was successful. It means that everything is OK.
Exporting the root certificate from the first server
Two certificates have been exported. Now you should export the root certificate the same way. Actions are performed on the first server (Hyper-v-prim.test.net).
Select the CertReq Test Root certificate located in Trusted Root Certification Authorities / Certificates.
Right-click the certificate; click All Tasks > Export.
The Certificate Export Wizard opens.
1. Welcome. Hit Next to continue.
2. Export File Format. Select the format you want to use:
DER encoded binary X.509 (.CER)
3. File to Export. Enter the file name and path to save the file, for example, C:temptestRoot.cer
4. Completing the Certificate Export Wizard. Check configuration and finish export.
Certificates are exported to Hyper-v-repl.pfx and TestRoot.cer files that are now located in C:temp on the first server.
Ip-адресация
В завершение стоит рассмотреть сеть, в которой размещаются виртуальные машины. Необходимо принять во внимание схему IP-адресации основных сайтов/серверов и реплик в сети. Например, предположим, что схема IP-адресации основного сервера-реплики — 1.x, а схема IP-адресации вторичного сервера-реплики — 192.168.x.
Если в сетях применяется протокол DHCP, и виртуальная машина использует DHCP, то виртуальную машину получит адрес с DHCP-сервера. Это рекомендуемый подход при размещении серверов Hyper-V Replica в различных сетях. Если для виртуальной машины используются статические IP-адреса, то виртуальной машине нужно назначить несколько IP-адресов (по одному для каждой сети, в которой она участвует).
Это необходимо, чтобы установить связь виртуальной машины с сетью. В приведенном выше примере, если имеется виртуальная машина с IP-адресом 1.1.1.1 (на основном сервере-реплике), а адрес вторичного сервера-реплики — 192.168.1.1, то связь с сетью становится проблематичной.
Эти настройки TCP/IP отработки отказов виртуальной машины следует назначить для сервера/сайта реплики. Те же службы Integration Services должны выполняться как на основном сервере, так и на сервере-реплике, чтобы настройки TCP/IP отработки отказов содержали нужный IP-адрес для виртуальной машины в зависимости от сервера, на котором она выполняется в данный момент.
Overview of the main steps
Before starting a detailed explanation of the workflow, let’s list the main steps that should be performed to configure Hyper-V replication in a Workgroup by using certificates.
In our blog post, we use two Windows Server 2021 machines with a Hyper-V role installed.
Using a ca inside your ad domain
I personally recommend creating a new certificate template for your Hyper-V needs. In my particular case I created a duplicate off of the Web Server template and added the Client Authentication by default. I found out that if you don’t use the template the Client Authentication it won’t put it on the certificate even if you try to add it manually… Maybe I did something wrong but this way I don’t forget to add it.
Also, I increased the validity of the certificate, 2 years for an internal server seems too little. So there you have it, better make those things the defaults and set up a template based on that. I had a few servers to configure but if you only have one I can understand doing a template might be too much trouble.
Look for the UTG here and on Appendix C you will find how to generate a self signed certificate. Although that is a lot of help, the real important part is the command you need to execute in order to have Hyper-V not check for the CRL of the certificate (revocation, etc that is provided when you use a CA).
Quick Summary:
I. Create a Self Signed Certificate Authority (if that makes any sense):
makecert -pe -n “CN=PrimarySampleRootCA” -ss root -sr LocalMachine -sky signature -r “PrimarySampleRootCA.cer”
II. Create a Self Signed Certificate using the CA crated above:
makecert -pe -n “CN=ServerName.domain.local” -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in “PrimarySampleRootCA” -is root -ir LocalMachine -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12 PrimarySampleCert.cer
III. Do the same for the destination failover replica server (create a self signed CA and Certificate)
IV. Add the Self Signed CAs you created to the trusted roots of the servers that are going to connect to that host using this command:
certutil -addstore -f Root “PrimarySampleRootCA.cer”
V. Disable the certificate revocation check:
reg add “HKLMSOFTWAREMicrosoftWindows NTCurrentVersionVirtualizationReplication” /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f
Enjoy!
Why use certificates for hyper-v
Certificate-based replication allows you to replicate virtual machines without adding Hyper-V hosts to a Windows domain or cluster. This feature is especially useful for small companies that have three or four servers and don’t want to deploy a cluster and configure a domain using Active Directory.
Windows server 2021: configuring hyper-v replica in a workgroup environment – part1
In contradistinction to workgroup clusters which were made available only in Windows Server 2021 – I wrote about them in Windows Server 2021: Testing Workgroup Cluster – Part1 and Windows Server 2021: Testing Workgroup Cluster – Part2 – certificate based replication was presented in the earlier version of Windows Server: the possibility of having a non-domain replica server is a great feature for any company, not speaking of the ones with only 2-3 servers at their disposal.
In a workgroup environment the most common way to create the certificates for Hyper-V hosts was to use the makecert utility but, given that this utility is depricated now and the new cmdlet New-SelfSignedCertificate is available instead in Windows Server 2021, the process of configuring workgroup replicas became a bit easier. In these two articles I’d like to walk all the steps required for setting up replication in Windows Server 2021 workgroup as well the steps required for the testing of the newly-created replica.
It is ridiculous but I failed to find any COMPLETE step by step explanation from MS regarding setting up replication in a non-domain environment so I will explain here all issues an administrator may be facing with while configuring replication according to the few articles found on msdn/technet sites.
Let’s get started by finding out whether any prerequisites exist for deploying a workgroup replica.
As you already may know there are two types of authentication in Hyper-V: Kerberos and HTTPS certificates. Considering Kerberos is available only in domain environments we have no any other choice but to use the certificate based authentication. The prerequisites for this type of authentication are rather simple: the Subject field of a certificate should be set to Hyper-V server name (either primary or replica server) and the Enhanced Key Usage should be the Client and Server authentication – here is the full explanation of the prerequisites.
Of course, https traffic should be allowed on server firewalls (I’ve disabled the firewalls on my host servers so I won’t publish the corresponding screenshots).
One more thing to note: virtual machine to be replicated should not have any checkpoints – there should be only one vhdx file available for replication so I delete the single checkpoint of the vm – DC – that I’m going to replicate:
Having determined the prerequisites I can proceed to creating these certificates with the New-SelfSignedCertificate cmdlet…. But although it’s not a prerequisite I prefer adding the main dns suffix to those of my workgroup servers which are used in cluster/hyper-v deployments (for example, adding the main dns suffix is the prerequisite for a workgroup cluster as I wrote in Windows Server 2021: Testing Workgroup Cluster*) so my very first action will be this:
Now my goal is to create the two certificates: for Host3.Testenterprise.com and Host2.Testenterprise.com.
On Host3 I run the following commands:
New-SelfSignedCertificate -DnsName “Host3.TestEnterprise.com” –
CertStoreLocation “cert:LocalMachineMy” -TestRoot
New-SelfSignedCertificate -DnsName “Host2.TestEnterprise.com” –
CertStoreLocation “cert:LocalMachineMy” -TestRoot
– as a result, the three certificates will be created: one for each server with the Enhanced Usage Key set to Client and Server authentication (although that was not explicitly stated!) and the test root CA certificate – CertReq Test Root – which by default will be placed in the Intermidiate Certification Authorities.
I’d like to stress the need for the -TestRoot parameter: you may create certificates without it but Hyper-V will not allow to use self-signed certificates for replication!
The two server certificates:
As the CertReq Test Root certificate is NOT in the Trusted Root Certification Authorities these certificates will be untrusted:
The root test CA certificate:
After moving/coping the CertReq Test Root certificate to the Trusted Root Certification Authorities the server certificates become trusted:
The properties of the Host2.TestEnterprise.com certificate:
The certificates for the primary server – Host3.Testenterprise.com – have been configured. The next step is to export the host2 server certificate along with the CertReq Test Root certificate and import them into Host2.Testenterprise.com.
Host2.Testenterprise.com certificate:
CertReq Test Root certificate:
I then copy these two certificate files to \host2c$ …
…and run the Import wizard on Host2.Testenterprise.com for two times.
1. CertificatePersonalCertificates:
2. Trusted Root Certification Authorities:
The result – Host2.TestEnterprise.com certificate is trusted:
After all certificates have been created we must add the following registry key on both host servers:
reg add “HKLMSOFTWAREMicrosoftWindows NTCurrentVersionVirtualizationReplication” /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f
– it will disable certificate revocation checking for the test certificates.
It’s time to configure Hyper-V replication settings on the replica server – Host2.TestEnterprise.com:
After selecting the options as depicted above (in this case my DC virtual machine should be stored on D:) and pressing the Select Certificate… button the following window is displayed:
– Hyper-V suggests to use the server certificate I’ve added recently – I press OK …
…and Apply – configuration of the replica server is complete.
The last step in configuring replication is to enable replication of a certain virtual machine – obviously this should be done on the primary server – Host3.TestEnterprise.com:
Again, Hyper-V suggests to use the newly-installed server certificate for the replication of the DC virtual machine – press OK.
If a virtual machine to be replicated had several virtual hard drives you could exclude some of them from replication here:
Replication frequency:
In the next window an administrator should choose whether there’ll be only the last recovery point available or any number of additional (<=24) recovery points (created hourly), and – if required – he/she may tick Volume Shadow Copy Service (VSS) snapshot frequency (in hours) checkbox to enable creation of application-consistent snapshots.
In short, recovery points are the incremental file-consistent archives that don’t take into account the content of memory of replicated VMs – in case of a planned failover it won’t be a problem because a VM must be shut down before a planned failover, thus making a VM “fully consistent”, but in case of unplanned failover many programs will lose their open transactions held in memory (SQL, Exchange…) making file-consistent archives (the recovery points) rather useless. In contrast, application-consistent archives (snapshots) guarantee the application will work inside the replica even after unplanned failover because VSS service will do all required job regarding the information in memory. More information on this here.
If a VM’s size is to big you can first deliver the VM to the replica server to save time for the initial replication.
Checking the replication health right after completion of the replication wizard: 
.. and some time later:
The replica VM:
In this part we’ve seen how to enable replication in a workgroup using two Windows Server 2021 based hosts. The next part will be devoted to testing the replica VM.
Архитектура
Архитектурно Hyper-V Replica состоит из следующих компонентов:
Безопасность
Одним из плюсов технологии Hyper-V Replica является то, что нахождение основного сервера и сервера-реплики в одном домене/рабочей группе не является обязательным. Если вы используете репликацию между некластерными узлами, то членство в домене совсем не обязательно (для кластеров, естественно, домен необходим). В связи с этим стоит затронуть некоторые вопросы безопасности:
Как включить репликацию вм в windows server 2021 hyper-v
Чтобы настроить репликацию конкретной ВМ в Hyper-V Windows Server 2021, просто щелкните правой кнопкой мыши по нужной виртуальной машине и выберите пункт меню Enable Replication.
Запустится мастер настройки репликации. Тут, прежде чем продолжить, позволю себе небольшую ремарку касательно моей инфраструктуры.
У меня имеется один отдельностоящий хост Hyper-V на Windows Server 2021, одну из виртуальных машин которого я хочу реплицировать на созданный ранее кластер Hyper-V. При реплицаии ВМ на кластер нужно указать имя сервера-брокера — Hyper-V Replica Broker.
Это особая кластерная роль, которую нужно настроить на кластере перед настройкой репликации. При попытке настроить репликацию с кластером, у которого отсутствует эта роль, появится ошибка (“The specified replica server is part of a failover cluster”).
Минимальные требования
Решение Hyper-V Replica доступно по цене и не требует сложной настройки. При условии, что оба сайта работают с Server 2021 Hyper-V и связаны через сеть, такой способ восстановления после аварии, несомненно, заслуживает внимания. Hyper-V Replica функционирует только с Server 2021, но не с клиентом (Windows 8) Hyper-V. Для использования Hyper-V Replica необходимо выполнить следующие минимальные условия:
* оборудование должно поддерживать роль Hyper-V в Server 2021;
* основной сервер и серверы-реплики должны располагать достаточным хранилищем данных и физической памятью для размещения виртуальных машин;
* местоположения основного сервера и серверов-реплик должны быть связаны через сеть;
* в правилах брандмауэра должна быть разрешена репликация между основным сайтом и сайтами реплик;
* требуется сертификат X.509v3 для взаимной проверки подлинности с использованием сертификатов (при необходимости).
Настройка hyper-v replica
Настройка виртуальных машин для репликации
После того, как настройка репликации завершена, необходимо подготовить виртуальные машины для репликации. Hyper-V Replica включается для отдельных виртуальных машин. Можно задействовать все виртуальные машины или их набор, но каждую виртуальную машину нужно настраивать отдельно.
1. На основном сервере Hyper-V щелкните виртуальную машину правой кнопкой мыши и выберите пункт Enable Replication («Включить репликацию») из раскрывающегося списка, чтобы запустить мастер Enable Replication для виртуальной машины.
2. На экране Specify Replica Server введите имя NetBIOS или имя FQDN для сервера-реплики в поле Replica server, а затем нажмите кнопку Next.
3. На экране Specify Connection Parameters введите порт и тип проверки подлинности. Если включен режим удаленного доступа к WMI, эти параметры будут заполнены автоматически. Перепроверьте их, поскольку если они неточны, будет выдано сообщение об ошибке и реплика окажется неработоспособной.
4. На экране Choose Replication VHDs вы увидите список всех VHD-файлов, имеющихся у виртуальной машины. Можно выбрать диск или диски, которые нужно реплицировать для виртуальной машины, а затем нажать кнопку Next. Помните, что если нужно обратиться к реплике, то ранее не выбранные VHD-файлы показаны не будут. Если диск содержит важные для виртуальной машины данные, то они окажутся недоступными.
5. Изменения репликации передаются на сервер-реплику через каждые пять минут. На экране Configure Recovery History (экран 2) укажите число и типы точек восстановления, отправляемых на сервер-реплику. Если выбрать только Only the latest recovery point («Только последняя точка восстановления»), лишь родительский VHD будет передан во время первоначальной репликации, и все изменения будут внесены в этот VHD.
6. На экране Choose Initial Replication Method (экран 3) доступно несколько методов для начальной репликации виртуальной машины на сервер-реплику. Метод по умолчанию — Send initial copy over the network (Передать начальную копию по сети). В этом режиме немедленно запускается репликация через сеть на сервер-реплику.
Если вы не хотите выполнять немедленную репликацию, можно запланировать ее на определенное время и дату. Если вы не хотите пересылать начальную копию через сеть, можно выбрать режим Send initial copy using external media (Передать начальную копию с помощью внешнего носителя).
Нажмите кнопку Finish. Если порт брандмауэра не открыт, то будет выдано сообщение об ошибке.
После завершения работы мастера в консоли Hyper-V Manager отображается имя виртуальной машины на основном сервере и сервере-реплике. Имя можно изменить. Hyper-V Replica отслеживает виртуальную машину по идентификатору виртуальной машины. Поэтому на основном сервере ее можно назвать Windows8, а на сервере-реплике — Windows8-Replica.
Мне часто задают вопрос, можно ли подготовить несколько реплик. Этого сделать нельзя, так как могут существовать только один основной сервер, на котором работает виртуальная машина, и один сервер-реплика с копией виртуальной машины. Однако в реплике могут участвовать несколько серверов Hyper-V.
Чтобы этого добиться, необходимо обратиться к настройкам Hyper-V на всех физических компьютерах. В приведенном выше примере на экране 1 все будет в порядке, если настроен режим Allow replication from any authenticated server («Разрешить репликацию с любого прошедшего проверку сервера»).
Если выбран режим Allow replication from the specified servers («Разрешить репликацию с любого прошедшего проверку сервера»), то необходимо, чтобы оба других компьютера были в списке. При выполнении мастера Enable Replication for Acct-File-Server на странице Specify Replica Server («Укажите сервер-реплику») будет показан сервер HyperV2.
Выполнив все настройки, можно переходить к следующей задаче. Если щелкнуть по имени виртуальной машины правой кнопкой мыши, то появляется раскрывающийся список Replication с несколькими вариантами, зависящими от того, где вы находитесь — на основном сервере или сервере-реплике.
На основном сервере отображаются варианты Planned Failover («Плановая отработка отказа»), Pause Replication («Приостановить репликацию»), View Replication Health («Просмотреть состояние работоспособности репликации») и Remove Replication («Удалить репликацию»).
Плановая отработка отказа. Плановая отработка отказа — контролируемое действие, которое выполняется, если известно, что основной сервер или сайт Hyper-V прекратит работу. После плановой отработки отказа сервер-реплика станет основным, и наоборот. Действие доступно только на основном сервере-реплике. Ниже перечислены несколько проверок перед плановой отработкой отказа и ряд действий, выполняемых в процессе.
Предварительные проверки:
* убедитесь, что виртуальная машина отключена;
* проверьте конфигурацию, чтобы разрешить обратную репликацию.
Действия:
* отправить не реплицированные данные на сервер-реплику;
* переключиться на сервер-реплику;
* изменить направление репликации;
* запустить виртуальную машину реплики.
Отработка отказа. Отработка отказа — действие, выполняемое в случае незапланированного отключения. В случае отказа основного сайта необходимо выбрать отработку со вторичного сервера-реплики на виртуальную машину, чтобы он стал основным сайтом и начал работать.
После того, как работоспособность основного сайта будет восстановлена, следует выбрать плановую отработку отказа, чтобы восстановить исходное состояние. Этот пункт доступен только на сервере-реплике. Дополнительная проверка покажет допустимость этого действия.
Будет предпринята попытка установить контакт с основным сервером. Если связаться не удалось, то попытки будут продолжаться. Если связь установлена, нужно определить, включена ли виртуальная машина. Если да, то процесс продолжается. Если отработка отказа выбрана случайно, можно выбрать команду Cancel Failover («Отменить отработку отказа») на вторичном сервере-реплике из раскрывающегося списка Replication.
Тестовая отработка отказа. Это контролируемое действие, которое выполняется, если нужно просто убедиться, что реплика виртуальной машины на реплике сайта будет запущена. Если выбрано это действие, то создается новая виртуальная машина на сервере-реплике с именем Test, чтобы ее можно было легко узнать.
Это может занять много времени, так как выполняется копирование всей основной виртуальной машины. При этом происходит обычная репликация изменений между основным сервером и оригинальным. Убедившись в исправном функционировании, можно просто отключить виртуальную машину Test и удалить ее из Hyper-V.
Приостановить репликацию. Это контролируемое действие, которое выполняется, если известно, что сервер-реплика будет отключен. После того, как сервер-реплика запущен, можно выбрать команду Resume Replication («Возобновить репликацию»). Это действие применимо как на основном сервере, так и на сервере-реплике.
Просмотреть состояние работоспособности репликации. Это действие, позволяющее убедиться, что репликация работает и все изменения вносятся. Статистические данные можно сбросить, обновить или сохранить в CSV-файле. Режим доступен как из основного сервера, так и из сервера-реплики. Во всплывающем диалоговом окне содержатся следующие элементы:
* состояние репликации;
* тип репликации;
* текущий основной сервер;
* текущий сервер-реплика;
* состояние работоспособности репликации;
* статистические данные:
— время начала;
— время окончания;
— средний размер;
— максимальный размер;
— средняя задержка;
— обнаруженные ошибки;
— успешные циклы репликации;
* ожидание репликации;
— размер данных, которые еще предстоит реплицировать;
— время последней синхронизации.
Hyper-V Replica на отказоустойчивом кластере
Hyper-V Replica также можно использовать на отказоустойчивом кластере Server 2021. Чтобы подготовить отказоустойчивый кластер, необходимо создать роль Replica Broker Role («Брокер реплики Hyper-V») в Failover Management. В результате будет создана группа в кластере, для которой формируется точка доступа клиента (CAP), содержащая имя, к которому будет выполнено подключение. Эта возможность обеспечивает дополнительное преимущество высокой доступности для реплики или основного сайта.
При запуске Hyper-V Replica на отказоустойчивом кластере какие-либо изменения в консоль Hyper-V Manager внести не удастся. При переходе в Hyper-V Manager, Hyper-V Settings и Enable Replication все варианты затеняются. В нижней части окна содержится сообщение This server is part of a failover cluster.
Use the Failover Cluster Manager to change replication settings («Этот сервер является частью отказоустойчивого кластера. Для изменения параметров репликации используйте диспетчер отказоустойчивости кластеров»). При запуске на отказоустойчивом кластере любые настройки Replica Configuration необходимы только на одном из узлов кластера. Поскольку ресурс кластерный, все изменения будут реплицированы на другие узлы.
Настройка репликации виртуальной машины
Еще раз включаем репликацию для ВМ. Указываем имя сервера-брокера репликации Hyper-V. У меня появилось предупреждение:
“The specified Replica server is not configured to receive replication from this server”
В этом случае нужно нажать на кнопку Configure Server для запуска окна настройки брокера в кластере.
Включите опции:
Принцип работы
Сначала между основным сервером и репликой устанавливается соединение и производится первоначальная репликация (Initial Replication), в ходе которой на резервной площадке создается реплика виртуальной машины. Реплика находится в выключеном состоянии и по умолчанию не подключена к виртуальной сети.
Затем в дело вступает механизм Delta Replication. На основном узле все изменения, происходящие с VHD-дисками соответствующей ВМ отслеживаются и записываются в лог репликации (Hyper-V Replica Log file, HRL). Это файл с расширением .hrl, находящийся в той же директории, что и VHD.
Примечание. Реплицируются лишь дисковые изменения, состояние памяти ВМ не затрагивается.
Установка роли hyper-v replica broker
Чтобы настроить роль Hyper-V Replica Broker, нужно открыть консоль управления кластером Failover Cluster Manager. Щелкните ПКМ по имени кластера и выберите опцию Configure Role.
Выберите роль Hyper-V Replica Broker.
Нужно указать имя кластерной службы и IP адрес.
На этом все. В Active Directory появится новое имя, а на кластере новая роль.
Экономичный выбор
Помните о нескольких факторах. Hyper-V Replica — экономичный вариант аварийного восстановления виртуальных машин. Это не автоматическая отработка отказа для запуска реплики; речь идет о действиях, выполняемых администратором вручную. Убедитесь в наличии достаточной памяти и места на диске и учтите соответствие схемы сети параметрам виртуальной машины, запускаемой на сервере-реплике.
Hyper-V Replica функционирует только на Server 2021, но не на Windows 8 Hyper-V. Можно перейти с автономного Hyper-V Server к другому автономному серверу. Можно переключаться между отказоустойчивым кластером с Hyper-V и другим отказоустойчивым кластером с Hyper-V.
Conclusion
Hyper-V replication is important to protect Hyper-V virtual machines and ensure that you can recover data and workloads in a short time after any failure. Sometimes you may need to configure Hyper-V replication in non-domain environments when Hyper-V servers are not members of an Active Directory domain and belong to a Workgroup.
You need to create self-signed certificates to replicate Hyper-V VMs in a Workgroup and configure authentication for Hyper-V servers by using these certificates. Configuration applies to hostnames, firewall, and certificate revocation checking before configuring VM replication on Hyper-V hosts. If you want to simplify configuration for Hyper-V replication, use NAKIVO Backup & Replication.