Shulou(Shulou.com)06/02 Report--

Most people may only know that Hyper-V replication is a new virtual machine replication feature introduced in 2012, but they do not know that Hyper-V replication supports very flexible architectures, such as stand-alone, stand-alone-to-cluster, cluster-to-stand, cluster-to-cluster, so what is the relationship between Hyper-V replication and cluster?

Starting with WSFC 2012, WSFC has added a new Hyper-V replica agent role, as shown in the following figure

Lao Wang thinks that this role should be called cluster external replication agent, otherwise it is easy for people to misunderstand that it is intra-cluster replication. It can be understood that Microsoft implements the integration of hyper-v replication and WSFC as a cluster external replication coordination engine. When we configure this role, we enter a name that serves as the client access point for the replication agent role, regardless of whether the cluster is the source or destination. When the replication wizard fills in the name, it will fill in the replication agent name instead of a single node. The replication agent will automatically coordinate the virtual machine replication nodes within the cluster. When an external replication request is dropped to the cluster, the replication agent engine will automatically coordinate a node to participate in the replication. When the node selected to participate in the replication goes down, the virtual machine will be failed over to other nodes in the cluster to continue replication. Leverage WSFC failover and replication engine mechanisms to ensure that virtual machine replication is not affected by the downtime of a single host

Summarize the external replication agent functions of the cluster as follows

As a unified external agent of the cluster, it provides a unified replication name.

Select and coordinate the hosts within the cluster to participate in replication, sense failover, and inform the outside that replication request traffic should eventually reach the host.

Ensure that the addition of nodes within the cluster does not affect ongoing replication

The Broker role writes the replication configuration to the cluster database and triggers a notification, the virtual machine management service on each node is replicated, and each node uses the latest copy of the replication settings

Support real-time migration of replica virtual machines within the cluster. When replica virtual machines are migrated to other nodes, replication traffic is automatically rerouted without human intervention.

2012 R2J Hypermurv replication also introduces important new features, expanding replication, further closer to practical applications, using this function we can achieve cluster-cluster-cluster, cluster-stand-alone-stand-alone, stand-alone-cluster, cluster-stand-alone-cluster and other more flexible scenarios.

Looking at Hyper-V replication from a cross-site, cross-cluster perspective

First of all, compared with storage replication, one of the biggest advantages of Hyper-V replication is that WSFC has a flexible architecture, which can be free from architecture restrictions, storage restrictions, and support enough scenarios. However, if it is not integrated with the cluster, stand-alone Hyper-V replication also has the biggest disadvantage, that is, planned maintenance requires downtime, which has been tested by Lao Wang and his friend Zhang Junsen. It is found that in a planned maintenance scenario, if the host is to be maintained, the virtual machine has to be shut down before the planned failover of Hyper-V replication can be carried out. this is a deficiency in the stand-alone scenario, but it will not be a problem if the cluster can be built. The replication agent engine will automatically select the nodes participating in the replication, even if one of the nodes is down, or the planned maintenance shutdown is required. The replication agent engine will also immediately select other hosts to participate in replication. From the point of view of availability, replication agents can add a layer of replication agent double insurance to the external Hyper-V replication mechanism to ensure that there are always nodes that can participate in replication as long as the cluster is alive by coordinating replication nodes within the cluster.

In addition, Hyper-V replication has the following advantages: it supports multiple restore points, can be rolled back to different time nodes directly through the Hyper-V window without using other backup tools, supports application consistency awareness, supports certificate verification SSL 443encryption, supports fixed port release to other network docking replication, and supports Azure cloud integration replication.

As for the disadvantages, in addition to the maintenance of stand-alone, we also discuss with my friend Zhang Junsen that the replication interval of Hyper-V replication is still too long. The replication interval of both parties is 30 seconds, 5 minutes and 15 minutes, and the extended replication is 5 minutes and 15 minutes. For some core and key businesses, we may want a shorter replication interval to reduce data loss.

It is recommended to use Hyper-V replication in the actual environment. If it is a stand-alone-to-stand-alone scenario, Lao Wang does not recommend running important business. General business can be handled by Hyper-V replication to reduce costs. The planned maintenance and shutdown of virtual machines should be completed in the maintenance window time. If the environment permits, for the sake of availability, Lao Wang suggests setting up at least one cluster for stand-alone scenarios. In this way, we can safely run some business, the virtual machine normally operates in one node in the cluster, and then the cluster replicates the virtual machine asynchronously to a stand-alone machine to prevent the cluster from collapsing. Once a single node in the cluster is down, the replication agent coordinates another node to automatically participate in replication, and manually fails over the virtual machine in the stand-alone node once the cluster crashes.

The biggest advantage of WSFC over Hyper-V replication is automatic failover. Whether Hyper-V replication is stand-alone, cluster-to-stand, cluster-to-cluster, assuming that one party suddenly goes down, the administrator needs to manually complete the failover. Cross-site downtime may be more delayed. If WSFC is built, as long as the network, storage, arbitration and DNS delay are reasonably designed. Placement policies, application retry and other cluster configurations, applications can be quickly automatic failover. Whether it is Hyper-V replication or WSFC, if you design a cross-site availability solution, you need to consider network and storage. Hyper-V replication has no requirements for storage, which can be shared storage or local storage. What you need to pay attention to is network latency, and the higher the network bandwidth requirements for different replication frequencies. If you really consider cross-site application of Hyper-V replication, you may also need to set up a direct connect.

WSFC currently has two models for cross-site availability solutions.

WSFC 2016 + built-in storage replication to build an extended cluster

WSFC 2008R2Universe 2012R2Universe 2016 + third party storage replication / device replication

In terms of the current architecture, the cross-site storage of WSFC still needs to be taken into account. The reason is that S2D cannot distribute data across sites, but can only achieve cross-rack level. Therefore, storage availability needs to be considered. No matter which solution, WSFC cross-site also requires high network quality.

Hyper-V replication and WSFC, Hyper-V replication is cheaper, no storage restrictions, asynchronous replication, flexible architecture, but needs to be integrated with the cluster to achieve higher availability, failover recovery time is longer, manual unplanned failover is required, WSFC can achieve automatic failover, but there are technical requirements for administrators, administrators must be familiar with cross-site cluster network, storage Conceptual designs such as arbitration, DNS latency, placement strategy, application retry, etc., both of which require high network requirements, should be taken into account if you want to make cross-site high availability. When actually deciding to adopt the solution, you should also take into account the managers' familiarity with hyper-v replication and WSFC.

Cross site or cross cluster

WSFC has supported clustering multiple subnets since 2008, which really promotes the cross-site clustering scenario and supports adjusting cross-subnet heartbeat detection thresholds. 2008R2 introduces HostRecordTTL mechanism to reduce DNS replication delay during cross-site failover, introduces RegisterAllProvidersIP attribute to enable supported applications to quickly retry multiple subnets, and supports adjustment of cross-network cluster detection communication encryption attributes. 2012R2 adds dynamic arbitration, anti-correlation, and enhanced priority setting to facilitate availability policies for cross-site failover. Many new features have been added in the 2016 era for cross-site, site awareness, storage site awareness, cluster site awareness, preferred site, cross-site heartbeat detection threshold, through configuration to achieve application default local site transfer, local site downtime cross-site failover, virtual machine followCSV,CSV transfer to other sites, virtual machine transfer is also followed. Multiple cluster groups are always running at different sites by configuring cluster group site awareness. Through the site attribute configuration of 50 stroke 50 case wins, through the site attribute configuration of the local subnet across the subnet outside the threshold rule. It all stems from the introduction of the concept of failure domain in 2016, where administrators can manually define fault domain attributes such as Site,Rack,Chassis, and then the application will perceive the definition of failure domain for failover or policy application. For example, the new functions described above are all around the Site attributes defined in the failure domain to apply and design cross-site failover policies, and the implementation effect of S2D at the failover level is the best. For example, if a rack fault domain definition is detected, extent can be scattered to different rack

The failure domain, site awareness and other strategies of WSFC 2016 are essential to consider when designing the 2016 cluster architecture. Reasonable planning can help reduce a lot of downtime. By WSFC 2019, all 2016 new features have been extended, and new ClusterSet features have been added.

ClusterSet and Hyper-V replication agents are a bit like, but not all like

It seems that they both have a common effect, not putting eggs in one basket, not all betting on a single cluster.

ClusterSet has previously written a separate article to talk to you. To put it simply, it is a mechanism for running virtual machines based on a unified namespace path and managing clusters to schedule member clusters, so that multiple clusters form a large Set, and all clustered virtual machines flow under the same large namespace. Virtual machines can be migrated and failed over in real time across clusters / availability sets for four main purposes. Extend single cluster virtualization or S2D boundaries to enable virtual machines to flow across clusters and across availability sets, making it easy for cluster lifecycle management and compatible with different storage architecture clusters.

ClusterSet is completely a new mechanism introduced by WSFC. The disadvantage of this technology is that it consumes too much resources. In order to build and manage clusters and member clusters, administrators also need to understand the concept of 2019SOFS, and at present, configuration can only use Powershell, which is technically difficult, so it is more suitable for enterprise users preparing to build large data centers, private clouds and hybrid clouds.

The technology of Hyper-V replication agent is relatively easier to understand and is not as complex as ClusterSet, but its disadvantage is that once one of the parties collapses, the entire replication relationship has to be failed over unplanned, only through manual failover, and ClusterSet can be done automatically.

The common advantage of ClusterSet and Hyper-V replication is that there is no need for cross-site configuration of Care clusters. Imagine that if ClusterSet has a management cluster in Beijing, a member cluster in Tianjin, and a member cluster in Zhangjiakou, each cluster is a local site, so you don't need to consider the concepts of cross-site network, storage, arbitration, site policy, and so on. Hyper-V replication is also a truth. If the Beijing cluster is replicated to the Tianjin cluster, both clusters are local sites, so this cross-cluster solution, as well as cross-cluster replication of storage replication, do not need to pay attention to the concepts involved in a single cluster cross-site.

But the disadvantage is that Hyper-V replication agent, storage replication, cross-cluster failover need to be performed manually, if not cross-cluster, then consider a single-cluster cross-site solution, combined with storage replication, can achieve the highest availability, but need administrators to be familiar with cross-site clustering strategy, in practical application, we can think a lot about whether it is necessary to cross-cluster or cross-site That technology is the most suitable.

Experimental environment

At the end of this paper, Lao Wang will implement a cluster-to-cluster Hyper-V replication scenario for everyone. Beijing site 12node1re12node2, Tianjin site 12node3mem12node4, respectively connect to the shared storage of their respective sites. I will establish a replication agent-to-replication agent Hyper-V replication relationship between the two clusters and verify the theory one by one.

Beijing cluster

Tianjin cluster

Beijing Cluster adds Hyper-V replica Agent Cluster role

Enter the name of the client access point, and then the cluster will be replicated through this name regardless of whether the cluster is the source or destination of Hyper-V replication. As a tip, if you want to limit the network used in replication, you can select the network subnet of the cluster network type 1 as the client access point IP, and then add the FQDN name of the replication agent client access point in each cluster node or stand-alone opposite The NetBIOS name enters the hosts file, because the name of the replication agent is only used during replication and is not external, so the network can be defined through the hosts file.

Configure Tianjin site replication Agent

Currently, there is a virtual machine on the Beijing site, and the virtual machine storage is located in the CSV of the Beijing site.

Right-click the virtual machine to enable replication

Enter the replication configuration wizard and enter the external replication agent name of the Tianjin site cluster

Configure the Hyper-V replication agent configuration on both sides of the cluster, and the storage location can be SOFS or CSV path

Other configurations depend on the actual situation.

Click on the cluster virtual machine, right-click to view the replication status, and you can view the Hyper-V replication operation as a whole. If there is an extended replication, it will also be shown here. You can see the replication hosts selected by the current Beijing site replication agent and Tianjin site replication agent respectively.

The virtual machine is migrated to the Beijing site 12node2 in real time without downtime, and the 12node1 can be maintained without downtime by removing other roles above the 12node1.

Review the replication health again and find that the replication host has been automatically selected as 12node2

Direct downtime of 12node2, replication engine aware of failover, re-coordination of replication by 12node1

The cluster of the downtime 12node1 Beijing site is all shut down, and the virtual machine of the Tianjin site is shut down at this time, so manual failover is required.

Right-click virtual machine-replication-failover

Select the recovery point to use

Virtual machine cross-cluster replication started successfully.

At this point, if the 12node4 of the Tianjin site crashes, the virtual machine and replication agent roles will fail over to 12node3. As long as the arbitration design is reasonable, the virtual machine can survive to the last node.

Then each node resumes one after another, right-click virtual machine-replication-reverse replication on the Tianjin site cluster, and reverse synchronize the data back to the Beijing site.

Hyper-V cross-cluster replication is not as complex as ClusterSet, and it does not need to be proficient in cross-site cluster tuning strategy. It is very simple, but it can also achieve good results. As long as you master the operation method correctly and find a failure and manual failover in time, you can minimize downtime as much as possible. Maybe you deserve it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.