Before going into virtualization, let me provide a corporate background on Avanade. Avanade offers business technology services that connect insight, innovation, and expertise in Microsoft® technologies to help customers realize results. The company applies Microsoft expertise from its global network of consultants. This means that we often put new technology through its paces earlier than many other folks.
That’s especially true for one of my teams, Avanade’s Dynamic Computing Services (DCS). DCS is a global platform for development, stress testing, and proof of concept to support both internal efforts and customer engagements. Our work often leads to Avanade’s recommended customer and partner solutions and configurations. I want to offer some guidance based on our recent experience using Microsoft virtualization technology (Microsoft Windows Server® 2008 R2 with Hyper-V™ and Microsoft System Center suite) and NetApp® shared storage. This article covers:
Current Virtual Server Environment
When I say that we run a “dynamic” computing services environment, here’s an example of what I mean. In the time a new provisioning request or change might flow through Avanade’s internal production environment, our group might do 10 or 20. We may have 30 to 40 different projects running in parallel. Our customers have just about every enterprise application in operation, so our VM environment also supports nearly every Microsoft and non-Microsoft application available. Our current Microsoft virtualization environment includes:
We manage the environment with Microsoft System Center Virtual Machine Manager 2008 R2 and System Center Operations Manager 2007 R2. Figure 1 shows a conceptual view of this architecture, along with the layout of the underlying NetApp aggregates (shown in light blue at center), volumes (gray) and LUNs (white). We’ll discuss more about our storage configuration later in this article.
Figure 1)Avanade DCS Hyper-V R2 environment.
Our Experience Moving to Hyper-V R2
We’d been looking forward to the Hyper-V R2 high-availability features like live migration and cluster shared volumes. Those were two critical features I wanted to see. I had already decided that when R2 became available we would go there, and go there fast. Within 24 hours of getting our hands on the R2 bits, we had our first cluster up with virtual machines running on it. Two weeks after, we’d moved our entire Hyper-V R1 system (and several hundred VMs) to R2.
The R2 migration experience was fantastic. Our daily use of CSVs and live migration has already made quite a difference in our operations. Some of the top benefits we’ve seen since the R2 move include:
Building for Performance
Several factors contributed to the 20% to 30% performance boost we’ve seen in our Hyper-V R2 environment. There were performance improvements in Hyper-V itself. Plus, as part of our recent move to new corporate headquarters, we were able to upgrade a number of components, including:
Planning for Live Migration
Some planning is definitely required to support live migration. This is part of a bigger discussion surrounding the design of your network and how many physical network adapters your servers need in order to properly support different types of traffic. Microsoft and NetApp both offer excellent guidance on this topic specific to Hyper-V. Here are a couple of tips:
Live migration will absolutely dominate the network. When we live migrate virtual machines from one node to another, we see our network links go to near 100% utilization during the migration. Saturating trunked gigabit NICs (or even single gigabit NICs) is generally difficult to do, but because so much of the live migration activity involves copying the contents of RAM from one system to another, extremely high network utilization is the norm. That kind of load puts a new level of demand on your servers and network infrastructure. It also exposes any weaknesses fairly rapidly.
We chose to segregate our iSCSI traffic onto two separate, dedicated links (see Figure 1). Now, during live migrations we’re assured that storage communications are not affected.
Storage Tips for Cluster Shared Volumes
Cluster shared volumes are another new feature in R2 that simplifies storage configurations and allows better support of Windows Server 2008 R2’s Failover Clustering with Hyper-V. Before, in Hyper-V R1, there was a design limit that required the creation of dedicated LUNs to support highly available VMs. This meant you either had to sacrifice storage complexity for availability or vice versa. With R2, CSVs allow you to house many VMs on the same LUN while also making them highly available.
Microsoft senior program manager Steve Ekren did a great job explaining this difference in his TechEd 2009 session. An excerpt from his discussion appears in Figures 2 and 3.
Source: Copyright Microsoft, TechEd 2009
Source: Copyright Microsoft, TechEd 2009
Cluster shared volumes, however, offer both good news and bad news for storage system designers.
Here’s the bad news: CSVs require a storage architecture that can be shared among all cluster nodes. Collapsing multiple VMs multiplies the I/O load placed on your storage volume. This means you need to make sure that your physical storage system is designed to accommodate the extra load. Otherwise, bad things can happen, including reduced performance, application timeouts, and possibly even system crashes or data corruption.
Now here’s the good news: Using the right storage system with careful design can overcome these issues. I’ve seen a big difference in this area with NetApp. We’ve had great experience with NetApp’s integration with Microsoft Windows Server 2008 R2 with Hyper-V. Combining NetApp storage with clustered Hyper-V hosts has been very easy to do, much easier than with a lot of other tools.
Supporting multiserver access with NetApp is easy because of the tight integration NetApp has with Microsoft. Things like multiprotocol support and direct storage integration through SnapDrive® make Windows® cluster builds a breeze.
For us, looking at how the load would be balanced across NetApp aggregates and spindles was very important. Figures 4 and 5 show details of our configuration.
Figure 4)Layout of NetApp aggregates.
Figure 5)Layout of NetApp volumes and LUNs on each aggregate.
Here are a few more tips for storage design with CSV:
Our continued experience with both Hyper-V and NetApp remains very positive. As we move forward, we will be exploring other integrated NetApp solutions for Microsoft virtualization. This includes the prospect of augmenting our data protection with NetApp SnapManager® for Hyper-V. We’ll be looking at use of NetApp ApplianceWatch™ PRO 2.0 as well, for more centralized monitoring of NetApp storage via Microsoft System Center Operations Manager.
We have also been working with NetApp to develop an internal self-service portal that allows someone to request a virtual machine for a short period, such as three weeks. This portal leverages NetApp FlexClone® technology to rapidly provision the virtual environment. We’ll be implementing that through a combination of Microsoft Virtual Machine Manager and Microsoft PowerShell™ scripting.
Got opinions about Hyper-V?
Ask questions, exchange ideas, and share your thoughts online in NetApp Communities.
This NetApp Community is public and open website that is indexed by search engines such as Google. Participation in the NetApp Community is voluntary. All content posted on the NetApp Community is publicly viewable and available. This includes the rich text editor which is not encrypted for https.