{"id":14537,"date":"2013-05-14T14:25:02","date_gmt":"2013-05-14T13:25:02","guid":{"rendered":"https:\/\/aidanfinn.com\/?p=14537"},"modified":"2013-05-14T14:25:02","modified_gmt":"2013-05-14T13:25:02","slug":"ip-assignment-strategies-for-hyper-v-replica","status":"publish","type":"post","link":"https:\/\/aidanfinn.com\/?p=14537","title":{"rendered":"IP Assignment Strategies For Hyper-V Replica"},"content":{"rendered":"

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).\u00a0 It\u2019s 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).\u00a0 But one question remains \u2013 how do I address those VMs in the DR site?<\/p>\n

Stretched Subnets<\/span><\/strong><\/p>\n

I am not a networking guy.\u00a0 The term I know is stretched VLANs, but network folks have other mechanisms for this.\u00a0 Basically, concept is that you enable your subnets to reside and route in the primary and secondary site.\u00a0 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.\u00a0 That\u2019s great for networks of a certain size.\u00a0 Small businesses probably can\u2019t do this, and larger enterprises look at the complexity and laugh.<\/p>\n

IP Address Injection<\/span><\/strong><\/p>\n

With this approach<\/a>, the Hyper-V administrator pre-configures DR site IP addresses for the VM.\u00a0 The address is injected into the VM during failover using Key Value Pairs (KVP).\u00a0 This allows site A and site B to have different IP ranges.\u00a0 This solution will work pretty well for smaller customers where they own both the primary and the secondary sites.<\/p>\n

DHCP<\/span><\/strong><\/p>\n

I hate using DHCP addresses for static resources like servers (including VMs).\u00a0 But you can do it.\u00a0 With this approach, you have DHCP in the primary site to assign reserved IPs to the VMs in the primary site.\u00a0 You have something similar in the secondary site, but with a scope that is suitable for there.\u00a0 Note, you must use static MAC addresses for reservations to work \u2013 so be sure to use export\/import to move VMs out of band.\u00a0 This is the one solution that I have the least faith in.\u00a0 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.<\/p>\n

Hyper-V Network Virtualization (HNV)<\/span><\/strong><\/p>\n

HNV, or software defined networking (SDN), is a very scalable solution.\u00a0 It also allows VMs to operate with their normal IP addresses (consumer addresses) while really communicating with the physical network via provider addresses.\u00a0 The VM simply moves\/starts on a predefined VM Network(s) in the DR site and continues to communicate.\u00a0 For this to work in production, you need VMM 2012 SP1 and a network virtualization gateway (see Iron Networks.\u00a0 F5 also have something coming).<\/p>\n

This solution is a nice one for large enterprises that want to use SDN to abstract networks from a central console).\u00a0 It also allows service providers to support many tenants with overlapping subnets (192.168.1.0\/24 or 10.0.0.0).<\/p>\n

OK, great, so we get VMs operational in the DR site.\u00a0 Some of these solutions require the VM to change IP address while some don\u2019t.\u00a0 If the IP changes, how do clients find the servers?\u00a0 DNS will be out of date!<\/p>\n

DNS TTL<\/span><\/strong><\/p>\n

You can reduce the TTL for the A records of your VMs to something small.\u00a0 If there\u2019s a disaster, is it a big deal if VMs can\u2019t resolve the names of servers for 5 minutes?\u00a0 Keep in mind DNS replication to local sites \u2013 so this might become 15, 20, 60 minutes, depending on TTLs and replication windows.\u00a0 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).<\/p>\n

IP Address Abstraction<\/span><\/strong><\/p>\n

Imagine this scenario: a large corporate has an offsite data centre.\u00a0 The business operates across a WAN.\u00a0 A DR data centre is deployed, also offsite.\u00a0 A network appliance(s) are deployed and configured to abstract the actual IP addresses of the servers.\u00a0 This allows servers to use IP-A in site A and IP-B in site B.\u00a0 However, the servers are known to the network via IP-C, the abstracted IP managed by the device(s).\u00a0 This solution is for the very largest of businesses.\u00a0 For clients on the WAN, DNS is simple: there is only one A record and it\u2019s for IP-C, the abstracted IP.<\/p>\n

Personally, I find SDN to be the most elegant solution but there are requirements of scale to make it work.\u00a0 For the smaller biz, maybe DHCP or IP address injection are the way forward.\u00a0 There are options \u2013 it is up to you to choose the right one.\u00a0 And I am certainly not going to claim that I have presented all options.<\/p>\n

You can learn more about\u00a0Hyper-V DR and Hyper-V Replica from two chapters on those subjects in\u00a0Windows Server 2012 Hyper-V from the book, Windows Server 2012 Hyper-V Installation And Configuration Guide:<\/p>\n