One of the great things about my role within the Microsoft Organization, is the ability to work directly with customers in order to build robust solutions, while mitigating the risk to their environment and user populations. To that end, I've find that it's helpful to have a pretty robust lab to help with my validation efforts. I am doing a great deal of Office365 (formerly BPOS) work, and I thought this would be a good time to share what I do in my lab. Ready? So let's get started.
My Network Lab (Part I)
In order to ensure my hosting environment will be available for remote access, I decided to build a clustered solution. After doing some research (and more trial and error testing my environment than I would have expected), i have built out a fully realized lab environment, centered around a three node Hyper-V cluster utilizing shared storage on an iSCSI SAN, with everything being maintained through VMM. While I still have some work around monitoring, failover and shoring up the solution, I am very confidant that the core foundation is solid and scalable.
I’ve had the opportunity to discuss with my peers in regards to the configuration and components that I’m using, so I thought I’d do a quick summary for any of those who decide to build their own environment. I’m still learning the nuances of VMM, so I would certainly be interested to hear what strategies other people are using for these types of configurations. I’ve been comparing notes with other members of my team on this topic (and I have to thank Steve Harmon for acting as my bargain basement hunter for hardware deals, for he has saved me quite a bit of money….), and have strived to balance performance and cost across my design decisions. Since my next project is integrating my lab environment with Office365, and moving my data and testing into the cloud, I need to be able to accommodate multiple scenarios depending on a customer configuration. And to be honest, I no longer relish running 3 cabinets of server hardware and storage in my garage….
The Hardware
The whole environment is built on 4 physical (host) machines. These are all running Windows Server 2008 R2 Enterprise Software, but are on desktop class hardware. For the purpose of the lab, there is no reason to spend the additional money for server class hardware for the purpose of testing and development. On an average year, I typically spend about $4500 on lab equipment, just so have enough hardware and storage to simulate most environments.
I already had two machines acting as application servers and just purchased another to two to act as additional Hyper-V nodes. I make it a point to run a standard configuration to keep the environment consistent across the nodes, and I've found that these machines will providing excellent support for Hyper-V, while supporting multiple VMs running simultaneously.
· EVGA X58 3X SLI Motherboard. Includes 2 gigabit NICs.(Overkill probably, but I love the hardware feature set – and I am a gamer at heart.)
· Intel i7 920 processor. These CPU are hyper-threaded with 4 cores.
· 12 GB RAM. Motherboard will support 24 GB , but at 650 per server – price is still and issue.
· Antec Desktop Case with 650 watt power supply. (Hardware Consistency, and Parts availability)
· Eight 500 GB eSATA drives. Used three in each server node, except for storage. In practice, with VMs, you want multiple spindles – two 500 GB are preferable to one 1 TB drive.
Leveraging the hardware configuration above, that provides my lab environment with the following 4 machines for the environment. Note that all Hyper-V machines are running Intel processors – this is required for doing Quick/Live Migration of virtual machines. The processors can be different models (using processor compatibility mode) but have to be the same manufacturer.
Hyper-V Node 1
· Windows Server 2008 R2 Enterprise with Hyper-V
· Intel i7 920
· 12 GB
· Two 500 GB drives and one 150 GB (OS)
Hyper-V Node 2
Hyper-V Node 3
Networked Storage Node
· 6 GB
· Six 500 GB drives and one 150 GB (OS)
Networked Storage
In order to a cluster you need shared storage. Microsoft provides a piece of software that will turn any machine running Windows Server 2008 (R2 not required) into an iSCSI SAN. With that software installed, you create as many VHD s as you want and make them available to the iSCSI targets as shared volumes. It was possible to configure the software in a few minutes, and I now have the flexibility to create whatever shared volumes I want. On the cluster nodes, you just use the iSCSI Initiator available in Windows Server 2008 R2 to connect.
The machine itself doesn’t need to be powerful, and you don’t have to dedicate it to this purpose. You probably want a couple of physical disks to hold the VHDs for performance and two NICs so you can dedicate one to iSCSI. I'll go into more detail on the Networked Storage configuration in my next post.
Active Directory
My Active Directory strategy is to have a DC in a dedicated VM running on each Hyper-V node. I’m not so much worried about multiple DCs for performance, but I like having more than one for backup. Also, the Hyper-V nodes are domain members, and having a DC running each one ensures that I can reboot the physical machine and still have a DC available for it when it comes online. The only issue I have is when everything starts from a powered off state since the first physical machine won’t be able to find a DC when it comes online. Just a matter of starting the one other up (with second DC in a VM) and then restarting the first. All machines in the environment point to the DCs for DNS. I just let them use root hints for public address resolution.
Network
I run wired gigabit on everything. Considering the price of this equipment and the size of media files that we’re typically moving around, anything slower just doesn’t make sense. Most motherboards you get are going to have at least one GB port, and you can add them for about $35 each. I am running a Catalyst 6905 with Gigabit blades for my home infrastructure, and while the smaller switches are nice – I want to be able to play with my configuration and understand changes in the Cisco IOS environment will affect performance. Granted it’s overkill, but I am a propeller head.
At this point, I don’t exercise the use of virtual networks too much. My configurations just have the virtual machines use the physical NIC on the host. In most configurations, the system uses one NIC for the OS and one shared by the VMs. In theory this should limit the bandwidth of the VMs. I’ll bring up a virtual network now and again for customer as needed.
Currently, all machines are configured on the same network. All desktops, physical servers, and VMs are members of the same domain and have an IP in the same subnet. Using that strategy, my desktops pretty much simulate user desktops in an enterprise environment, although I have made allowances for running multiple VM desktops as needed. I have gone so far as to have group policy applied to them and leverage virtualized applications under App-V. I have some other desktops running in VMs with the VDI configuration in Server 2008 R2. The cool thing about that is I really don’t worry about the power of my desktop since I constantly have Remote Desktop sessions to two other Windows 7 machines.
More to Come…. Part 2