Planning for Hyper-V Replica

Before tackling this article, ensure that you already know what Hyper-V Replica is. If not, follow this link. I also trust that you understand that you are not building a replacement for backup. This post will help you verify that you have what you need so that you can create a successful Hyper-V Replica deployment. We are saving the “how-to” for building that system for a later article.

Hyper-V Replica Prerequisites

Hyper-V Replica originally released with the 2012 Server platform. I am deliberately talking only about the 2012 R2 and 2016 platforms. Most of what I say here will apply to 2012, but I don’t believe that there are enough new installations on that version to justify covering the differences. If you’re one of the handful of exceptions, I doubt that you’ll have many troubles.

Before you begin, you must have all of these items:

• At least two systems running a server edition of Hyper-V. For best results, use the same version. Hyper-V Replica does work up-level from 2012 R2 to 2016. As long as the virtual machine configuration version remains at 5.0, 2016 can replicate down to 2012 R2. 2012 can replicate up to 2012 R2, but 2012 R2 cannot reverse replication down to 2012.  I would not expect 2012 to 2016 to work at all, but I didn’t test it and could not find anything about it.
• Sufficient storage on the replica server to hold the replica, with extra room for change logs and recovery points. The extra space needed depends on the rapidity of changes in the virtual machine(s) and on how many recovery points you wish to keep.
• Reliable network connectivity between the source and replica hosts.
• All hosts involved in Replica must be in the same or trusting domains to use Kerberos authentication.
• All hosts involved in Replica must be able to validate certificates presented by the other host(s) in order to use certificate authentication. The certificates used must be enabled for “Server Authentication” enhanced key usage.
• A configurable firewall. Replica defaults to port 80 for Kerberos authentication or 443 for certificate authentication.

Preparing to Use Hyper-V Replica Securely

Today’s world demands that you think securely from the beginning of a project. The most common use for Hyper-V Replica involves transmitting data across the Internet. Walk into this project knowing that your data can be intercepted.

Mutual Host Authentication is Required

Hyper-V Replica will not function if the source host cannot verify the identity of the target host and vice versa. This is a good thing, but it can also be a bothersome thing. You have two options: Kerberos authentication and certificate-based authentication.

If your replica traffic will directly traverse an unsecured network (the Internet), do not use Kerberos authentication. The source and replica servers will securely authenticate each other’s identities, but the replica traffic is not encrypted. However, if you are using a secured tunnel such as a site-to-site VPN, then feel free to use Kerberos. There is little value in using an encrypted tunnel to carry encrypted traffic. Also, because certificate-based encryption is asymmetrical, the encrypted packets are much larger than the unencrypted source. Double encryption dramatically increases the payload size.

Pros of Kerberos-based Authentication

• If both hosts are in the same or trusting domains, Kerberos authentication is “fire-and-forget” simple. Just select that dot on their configuration pages and you’re set.
• Synchronization traffic is unencrypted, so it requires the least amount of processing and network resources.
• Simple, centralized emergency management of the hosts. If a system at a remote site is compromised, you can disable its object in Active Directory and it will no longer be valid for replication.

Cons of Kerberos-based Authentication

• No option to encrypt synchronization traffic within Hyper-V. IPSec and encrypted VPN tunnels are viable alternatives.
• Cannot fail over a domain controller covered by Hyper-V Replica unless another domain controller is available. You can eliminate this problem by allowing Active Directory to replicate itself.
• “Only” works for domain-joined hosts. Leaving Hyper-V hosts out of the domain isn’t smart practice anyway, so competent administration eliminates this problem unless using an outside service provider.

Pros of Certificate-Based Authentication

• Hosts do not need any other method to authenticate each other. This approach works well for service providers.
• All traffic is encrypted. As long as the hosts’ private keys are adequately protected, it’s as safe as anything can be to transmit certificate-based Hyper-V Replica traffic directly across the Internet.

Cons of Certificate-Based Authentication

• Certificate-based encryption results in higher CPU usage and much larger traffic requirements.
• PKI and certificates can be difficult and confusing for those that don’t use PKI often.
• Certificates expire periodically and must be manually renewed, redistributed, and selected in Replica configuration screens.
• If you don’t maintain your own PKI, you’ll need to purchase certificates from a third party. This might also be necessary when working with a Hyper-V Replica service provider.

Make the decision about which type of authentication to use before proceeding.

Acquiring Certificates to Use with Hyper-V Replica

It is possible to use self-signed certificates for Hyper-V Replica, but it is not recommended. Self-signed certificates do not utilize any type of external arbiter, therefore the hosts are not truly able to authenticate each other.

There are two recommended ways to acquire certificates for Hyper-V Replica:

• A third-party trusted certificate provider. These certificates cost money, but all of the not-fun bits of managing a PKI are left to someone else. If you shop around, you can usually find certificates at a reasonable price. These are most useful when you do not own all of the Hyper-V hosts in the replica chain.
• An internal Certificate Authority. If you own all of the Hyper-V hosts, then it won’t matter a great deal that they only use your resources for authentication. Even if some or all of the Hyper-V hosts aren’t in your domain, you can add your CA’s certificate to their trusted lists and then they’ll trust the certificates that they issue.

Making certificate requests is really not difficult, but there are a lot of steps involved. The most comprehensive walkthrough that I’m aware of is the one that I wrote for the Hyper-V Security book that I co-wrote with Andy Syrewicze. The bad news is that, since it seems to be one-of-a-kind, I can’t duplicate it here. You can find several other examples, although there are so many variables and possibilities that you may struggle a bit to find one that perfectly matches your situation. This certificate enrollment walkthrough looks promising: https://social.technet.microsoft.com/wiki/contents/articles/10377.create-a-certificate-request-using-microsoft-management-console-mmc.aspx. It’s for domains, but it does show you how to get the CSR text. You’ll need that if you’re going to request from a third-party or a disconnected system.

If you want to set up your own Active Directory-based PKI, be warned that you are facing a non-trivial task made worse by poorly designed and documented tools. The “official” documentation isn’t great. I’ve had better luck with this: https://www.derekseaman.com/2014/01/windows-server-2012-r2-two-tier-pki-ca-pt-1.html. It’s not perfect either, but it’s better than the “official” documentation. If you don’t have any other use for PKI, I recommend that you save your sanity by spending a few dollars on some cheap third-party certificates.

Hyper-V Replica Certificate Requirements

If you already know how to make a certificate request, this is a simple checklist of the requirements:

• Enhanced Key Usage must be: Client Authentication, Server Authentication. This is the default for the Computer certificate template if you are using a Windows PKI.
• Common Name (on the Subject tab) must be the name of the system as it will be presented to the other Replica server(s) that it communicates with. So, if you’re connecting over the Internet to target.mydomain.com, then that must be the the Common Name on the Subject of the certificate and/or a Subject Alternate Name.
• Subject Alternate Name (SAN). This is also on the Subject tab. You want to add DNS entries. If your replica host is going to be addressed by a name other than its computer name, then that name must at least appear in the Subject Alternate Name list. If the target system is a cluster and the other Replica server(s) will be connecting to it via its Cluster Name Object, then your certificate must use that FQDN as the Common Name or as one of the Subject Alternate Names. Because the certificate can be used for more purposes than just replica, I typically use all of these items in the SAN fields:
  • Cluster Name Object DNS name
  • Replica Name Object DNS name
  • Internal DNS name of each node
• 2048 bit encryption. The default is 1024 bit, so ensure that you change it.

A warning note on Subject Alternate Name: If you are using an internal Active Directory-based PKI, the default configuration for the Computer certificate template may prevent you from using Subject Alternate Names. You may fill out the fields correctly, but then discover that the issued certificate contains no SANs. I typically create my own certificate templates from scratch to avoid any issues.

Have your certificates installed on each host before you configure Hyper-V Replica.

Selecting Virtual Machines to Use with Replica

It’s not a given that you’ll want to replicate every virtual machine. The very first link in this article spends some time on this topic, so I’m only going to briefly touch upon it here. Avoid using Hyper-V Replica with any technology that has its own replication mechanisms. Active Directory, Exchange Server, and SQL Server are technologies that I strongly discourage mixing with Hyper-V Replica.

Remember that Hyper-V Replica does not save on licensing in most configurations. You cannot build a virtual machine running Active Directory Domain Services and then create a replica of it for free. The replica virtual machine must also be licensed. If you have Software Assurance on the license that covers the source virtual machine, then that does cover the replica. However, that’s not “free”. I do not know how replica is handled by the licensing terms of non-operating system software, so consult with your licensing reseller. Do not make assumptions and do not attempt to use replica to side-step licensing requirements. The fines are prohibitively high and auditors never accept ignorance as an excuse.

Selecting Virtual Machine Data to Exclude from Replica

Just because you want a virtual machine replicated means that you want all of that virtual machine replicated. Hyper-V Replica has the ability to skip specified disks. Many people will move the page file for a virtual machine to a separate disk just to keep it out of replica. There are other uses for this ability as well. Think through what you want left out.

Selecting Hardware to Use with Replica

If you want to make the simplest choice, buy the same hardware for Hyper-V Replica that you use for your primary systems. That’s rarely the most fiscally sound choice, however.

Consider:

• Hyper-V Replica is intended for recovery and/or continuity through a disaster, not as an ordinary running mode
• Disasters tend to alter usage patterns; staff re-tasks to other duties, customers have other things to do, etc.
• Using hardware in another physical location will likely cause other logistical access restrictions. For example, your primary office location may house fifty on-site staff. Your replica site may have sufficient room for five.

I am unable to make any solid general recommendations. If you’re not certain, I would recommend purchasing a system that is at least similar to your primary. If you’re really uncertain, hire a consultant.

If you’re thinking about using a smaller system for the replica site, remember these things:

• You can replicate from a cluster to a standalone host and vice versa.
• You can replicate from a cluster to a smaller cluster and vice versa.

Replica Site Networking

Set aside time to think through your networking design for replica. You absolutely do not want to be stumbling over it in the middle of a crisis. There are three basic ways to approach this.

Use Completely Separate Networks

My preferred way is to build distinct networks at each site. You’ll invest more effort in this design, but you’ll need substantially less to maintain it. You do not need to build an elaborate system.

One option that you have to make this work is DHCP. The very simplest way is to have all services configured to use DNS names and just allow DHCP and DNS to do their jobs. That concept makes a lot of people nervous, though, and you won’t always have that option anyway. In that case, set each virtual machine to use a static MAC address. Since you are hopefully keeping an active domain controller in each site, throw DHCP and DNS in as well (separate servers, if it suits your environment). Use DHCP reservations unique to each site.

If you don’t want to use DHCP, then you can configure failover IPs for each virtual machine individually. That’s the most work, but it gives you a guaranteed outcome.

The nice thing about this setup is that it will work even if you haven’t got a VPN. Active Directory also works wonderfully. You configure the second IP range as its own site in Active Directory Sites and Services, and it just knows what to do… if there’s a VPN. Active Directory replication does work over a VPN-less Internet connection, but you’ll need to do some configuration.

Use a Stretched Network

A “stretched network”, sometimes called a “stretched VLAN”, exists when layer 2 traffic can move freely from one site to another. A stretched network allows you to keep the same IP addresses for your source and replica systems. It’s conceptually simple and requires little effort on the part of the Hyper-V administrator, but networking can be a challenge.

When all is well, a stretched network isn’t a big deal. However, you’re building replica specifically for the times when all is not well. The shown 192.168.100.0/24 network will need a router so that the virtual machines can communicate off of their VLAN. So, let’s say that we have a router with 192.168.100.1 in the primary site. What happens when site 1 is down and you’re running from replicas? 192.168.100.1 is in the primary site and unreachable. There are ways to deal with this, but someone needs to have the networking know-how to make it work. For instance, you could have a 192.168.100.2 router in site B and have it inserted into each machine’s routing table. But how? If it’s a persistent mapping with .1 as a default, then any machines in site 2 will always route through site 1 even though it’s inefficient. If you take some sort of dynamic approach, you then have another thing to deal with during a crisis.

Active Directory won’t like this setup. It will work, but it will function as though all systems were in the same site. It’s not ideal.

I recommend against a stretched network unless you have sufficient networking knowledge available to deal with these sorts of issues.

Use a Mirrored Network

I’m fairly certain that “mirrored network” isn’t a real term, so I’m just going to make it up for this article. What I mean by a “mirrored network” is that the same IP range appears in each site, but they aren’t really the same network. This would get around the routing problem of the stretched VLAN. Unfortunately, it introduces other issues.

The big difference here is that the two sites have no direct connectivity of any kind. They’ll reference each other by external IPs. That’s what makes this “mirrored” network possible.

The issues that you’re going to encounter will be around anything Active Directory related. You won’t be able to have two sites for the same reason that you couldn’t with a stretched network. You might be able to do some finagling to get them to communicate over the Internet, but you have to be careful that you don’t inadvertently cause a collision between your two networks that have the same IPs but aren’t the same.

I can see the appeal in this design, but I don’t like it for anything but very small systems. Even then I’m not sure that I like it.

Replica Site User Access

If you wanted to describe Hyper-V Replica in the least abstract way possible, you could say that it transfers your data center to an alternative site. It doesn’t move your users, though. How you attach users to the services in the new location will depend on a great many factors. For things like Outlook Anywhere, it’s a DNS change. For other things, you’re going to need to bring people on site. I can’t give great advice here because there are so many possibilities. You need to make many decisions. They need to be made before Replica begins.

Initial (Seed) Replication

You might have a great deal of data to move to your replica site. For instance, let’s say that you have a 1 terabyte database and your remote site is at the other end of a T1 line. At peak transmission rates, that’s nearly four days of transfer time, just for the database. With asymmetrical encryption, that four days automatically turns into eight days.

Hyper-V Replica allows you to perform the initial replication using portable media. It’s much faster, but it’s still going to require time. And portable media. Have all of this planned and ready to go.

Planned Failovers

It’s imperative that you test failover on a regular basis. You won’t necessarily need to test every virtual machine, but you need to test at least one. Consider building a virtual machine just for this purpose. Failovers need to be on the calendar. Responsible staff need to be designated and held accountable.

Unplanned Failover Criteria

It needs to be made clear to all interested parties that a Hyper-V Replica failover is a non-trivial event. A failover requires downtime. There are often unforeseen problems with using a replica site. The decision to fail to a replica site needs to be made by management staff. The criteria for “crisis situation demanding a replica failover” needs to be plotted when there isn’t a crisis, not in the middle of one. Clearly define who will make the determination that a failover is required.

Build the Replica System

Once all of these items have been satisfied, you can begin building your replica system. We’ll have an upcoming article that explains the procedure. But, if you have all of the items in this article prepared, you’ll find that you have already done all of the hard work.