I'm exhausted. For three days I have battled, like Hemingway's Old Man battling the fish. Like Jacob wrestling the angel for a blessing, which he did obtain at the price of limping the remainder of his life. Like Rocky Balboa facing Apollo Creed (the second time, when he won).
I've been battling an evil like no other. It's not the new massively multiplayer online game "Star Wars: The Old Republic," but a multiple-subnet Active Directory and Exchange deployment for database availability group (DAG) high-availability configuration.
[ Also on InfoWorld: J. Peter Bruzzese figures Hyper-V in Windows 8 Server could finally beat VMware. | Read the InfoWorld Test Center's take on Microsoft Windows Server 2008 R2 Hyper-V in the virtualization shoot-out. | Stay abreast of key Microsoft technologies in our Technology: Microsoft newsletter. ]
In wanting to truly grasp the nuances of a DAG failover across sites, I needed to build a lab that exceeds all others I've worked with. Typically when you consult, you walk into an existing setup with connectivity in place, or if you are building from the ground up, you might hire folks to handle all the wiring and hardware side for connectivity. But if you've ever tried to build a dual-site lab with multiple subnets, you could find yourself struggling simply because your lab may not have the same-quality hardware you expect in a real world deployment.
I was working with two Dell servers (a T310 with two NICs) and a T110 (with a single NIC) setup with Windows Server 2008 R2 with Hyper-V. I had two addressing schemes in play -- 192.168.1.x and 10.x.x.x -- to illustrate the distinction between the two networks. I had all my 192-address servers on one Hyper-V box and all my 10-address servers on the other Hyper-V box. It was time to get these two communicating with each other and with the Internet.
I grabbed a couple of basic $50 home routers and started setting up the subnets. The problem is that home routers are simply four-port switches that have a single WAN connection out to the Internet. They don't actually route anything, and it's impossible to have two subnets with Internet access through these devices. I was stuck.
Typically in a business deployment, I'd go with a Cisco business router to resolve this problem, but here I was forced to look at solutions, both old and new, to make things work. I also had the twist of working with Hyper-V, which sets up virtual networks that are a bit funky compared to the VMware counterpart. I needed additional brainstorming help, so I contacted two colleagues at TrainSignal, David Davis (a noted vExpert) and Ed Liberman (a technical speaker and network infrastructure guru), to see what they recommended. I also consulted a great article to better understand basic networking, Hyper-V, and virtual switches to help me master the concepts.