What I love about Hyper-V Replica is that (a) it is free (b) it just works and (c) it works for a wide variety of customers/partners (large and small). It’s great that you can get your VMs from site A operational in site B with a maximum RPO of 5 minutes and an RTO of however long it takes to orchestrate the start of your VMs (from seconds, depending on how many VMs you have to order). But one question remains – how do I address those VMs in the DR site?
I am not a networking guy. The term I know is stretched VLANs, but network folks have other mechanisms for this. Basically, concept is that you enable your subnets to reside and route in the primary and secondary site. That means a VM with the address of 192.168.1.20 can operate, route, and be accessible to clients (from anywhere) in either site. That’s great for networks of a certain size. Small businesses probably can’t do this, and larger enterprises look at the complexity and laugh.
IP Address Injection
With this approach, the Hyper-V administrator pre-configures DR site IP addresses for the VM. The address is injected into the VM during failover using Key Value Pairs (KVP). This allows site A and site B to have different IP ranges. This solution will work pretty well for smaller customers where they own both the primary and the secondary sites.
I hate using DHCP addresses for static resources like servers (including VMs). But you can do it. With this approach, you have DHCP in the primary site to assign reserved IPs to the VMs in the primary site. You have something similar in the secondary site, but with a scope that is suitable for there. Note, you must use static MAC addresses for reservations to work – so be sure to use export/import to move VMs out of band. This is the one solution that I have the least faith in. You might want to look at WS2012 DHCP failover to ensure your DHCP is highly available because it has become a very important factor in your business continuing to operate.
Hyper-V Network Virtualization (HNV)
HNV, or software defined networking (SDN), is a very scalable solution. It also allows VMs to operate with their normal IP addresses (consumer addresses) while really communicating with the physical network via provider addresses. The VM simply moves/starts on a predefined VM Network(s) in the DR site and continues to communicate. For this to work in production, you need VMM 2012 SP1 and a network virtualization gateway (see Iron Networks. F5 also have something coming).
This solution is a nice one for large enterprises that want to use SDN to abstract networks from a central console). It also allows service providers to support many tenants with overlapping subnets (192.168.1.0/24 or 10.0.0.0).
OK, great, so we get VMs operational in the DR site. Some of these solutions require the VM to change IP address while some don’t. If the IP changes, how do clients find the servers? DNS will be out of date!
You can reduce the TTL for the A records of your VMs to something small. If there’s a disaster, is it a big deal if VMs can’t resolve the names of servers for 5 minutes? Keep in mind DNS replication to local sites – so this might become 15, 20, 60 minutes, depending on TTLs and replication windows. You can force replication to happen and DNS server caches to flush, but those are manual tasks (and prone to not happening in a disaster).
IP Address Abstraction
Imagine this scenario: a large corporate has an offsite data centre. The business operates across a WAN. A DR data centre is deployed, also offsite. A network appliance(s) are deployed and configured to abstract the actual IP addresses of the servers. This allows servers to use IP-A in site A and IP-B in site B. However, the servers are known to the network via IP-C, the abstracted IP managed by the device(s). This solution is for the very largest of businesses. For clients on the WAN, DNS is simple: there is only one A record and it’s for IP-C, the abstracted IP.
Personally, I find SDN to be the most elegant solution but there are requirements of scale to make it work. For the smaller biz, maybe DHCP or IP address injection are the way forward. There are options – it is up to you to choose the right one. And I am certainly not going to claim that I have presented all options.
You can learn more about Hyper-V DR and Hyper-V Replica from two chapters on those subjects in Windows Server 2012 Hyper-V from the book, Windows Server 2012 Hyper-V Installation And Configuration Guide: