What is the Hyper-V Replica Broker?

Replica is one of the many compelling features of Hyper-V. It allows you to create a comprehensive disaster recovery system with very little effort. It’s simple to design and deploy. What’s not always so easy about Hyper-V Replica is understanding many of its constituent components and some of the operations. In this article, the focus will be on the Replica Broker.

What we’re not going to talk about is how to configure Replica or the Broker. That’s fairly well-documented in previous posts and on the Microsoft TechNet site. You don’t necessarily need to have a functioning Replica system before you start reading this article. The TechNet documentation is focused on the “how”. This article is intended to be explanatory.

The basic purpose of the broker is the easy part. First, consider the most simple Replica configuration: one Hyper-V host acting as a Replica client and one Hyper-V host acting as a Replica server. The client pushes data from its virtual machines to the server, which maintains the replicas.

Simple Replica

Enter the cluster. Clustering Hyper-V hosts changes everything, which includes Replica. From a purely technological standpoint, the broker is not entirely necessary. A Hyper-V host that is a member of a cluster is still a Hyper-V host. The issue is that clustering causes a virtual machine’s home to become quite malleable.

Why Clustering is a Problem for Replica

I should take care to point out that the above diagram is just for show; you can’t actually configure Replica to operate this way. Hopefully, it presents the problem clearly, however. There’s no consistent host-to-host authentication for any given guest to the target Replica server, and computers don’t like inconsistency. This problem is solved by the Replica Broker.

The Replica Broker is a computer account. It exists in Active Directory like any other. It can be assigned a certificate, which makes it viable for both Kerberos and HTTPS operations. What really happens, then, is this:

Replica Communications

No matter where a guest goes, authentication is always handled by the Replica Broker. This provides multiple advantages:

• All configuration is made one time for the broker instead of per host
• Certificate management for HTTPS is scoped only to the Broker and the destination server
• Individual nodes can be added and removed without reconfiguring Replica
• Guests can migrate without interrupting Replica
• Replica actions for an entire cluster are coordinated to address potential overlap or resource contention issues

As with any other clustered resource, the Replica Broker is only owned by one node at any given time. The natural question is then: which of the source hosts is responsible for transmitting any given Replica? Most administrators find the answer to be favorable: the host that owns the virtual machine performs the transmission. The Replica Broker is exactly what its name says that it is: a broker. It handles the authentication between the client and the server and has the authority to perform actions on behalf of the client, but it uses the client’s resources to perform the task. This means that there is no unnecessary communication of data from the VM’s host to the Replica Broker’s host, if they happen to be on different computers. The downside would be for environments that use outbound firewalls; each host will need direct connectivity to the target replica system.

Replica Broker as a Target

Thus far, I’ve only talked about a Broker that connects to a stand-alone host. The nice thing is that this process also works in reverse; inbound authentication to a cluster is handled via its Broker. Furthermore, it also handles inbound connectivity. You don’t need a complicated firewall or port-forwarding setup to make this work. Simply ensure that whatever configuration of ports 80 and 443 you’ve configured Replica to operate on that the relevant traffic from the source can correctly find its way to the destination Broker’s IP address. It will handle everything from there.

Broker Limitations

With all the wonderful things that the Broker can do for your Replica configuration, it’s worth noting that it’s not perfect as yet. The biggest problem with the Broker is that it can only see highly-available virtual machines. That makes perfect sense, given that it is a component of Failover Clustering and not Hyper-V. The problem is that when a Hyper-V host joins a cluster, it prohibits you from configuring Replica locally. This means that if you have a non-clustered virtual machine on a clustered host, Microsoft does not provide any tool at all to replicate it. While I don’t know what others use this sort of configuration for, I only employ it for domain controllers. Since Active Directory has its own replication technology that serves it far better than Hyper-V Replica would, this limitation is not meaningful for me. It is something to be aware of as you build out your clustered Replica configurations.

The second limitation is that you cannot perform intra-cluster replication. I’ve seen some administrators attempt to set up a fancy stretched cluster that they also want to utilize replication. While I haven’t spent a great deal of time analyzing any of these deployments to detect if there are merits to their efforts, it doesn’t really pass the sniff test. My initial reaction is that there is an architectural issue somewhere either due to a misunderstanding of the technology or an attempt to overcomplicate the situation. Regardless of any value that such a build might have, it isn’t possible. The same barrier that prevents you from configuring a non-clustered virtual machine on a clustered host from being replicated also prevents any cluster node from participating in Replica with other nodes on the same cluster.