Home | Contact | Sign in

Windows Infrastructure

Real life Active Directory, Hyper-V, Forefront , Performance and Security experiences By Erik den Burger

The benefits of VMQ (part 1)

Tags:  Performance · Hyper-V

One of the big improvements in windows 2008R2 regarding the performance of networking in a Hyper-V environment is the implementation of Virtual Machines Queues (VMQ). VMQ uses hardware packet filtering to deliver packet data from the external network to your virtual servers directly and doing so, reduces the overhead of routing packets between the management OS and virtual servers.

To make us of VMQ you should be running Windows 2008R2, the physical NIC should support VMQ (or VMDq as Intel calls it) and your virtual machines should be running Windows 7, Windows Server 2008R2 or Windows 2008/Vista with the windows 2008R2 Integration Services installed. Older versions cannot make us of VMQ.

Most Intel 10Gig NIC do support VMDq. In the gigabit range you should go for an Intel ET, ET2, EF or VT Based card. Other vendors have announced they will support VMQ in the near future, at this moment I'm not aware of any vendor, other than Intel that has support for VMQ.

When VMQ is enabled a dedicated queue is established on the physical NIC for each virtual NIC that has requested a queue. Because queues are allocated on a first-come-first-served basis it would be a bad idea to enable VMQ for all your VM's. So identify your heavy traffic VM's and enable VMQ for those VM's only. Because VMQ works primary to improve receive side performance, providing the VM's that receive the most packets will benefit most from enabling VMQ.

To enable VMQ for a Virtual Machine, you first need to enable VMQ for a physical NIC. After you have enabled it you can enable VMQ on the Hyper-V Server. Finally you need to configure the virtual NIC of your virtual machine to use VMQ.

These steps will be covered in Part 2. In part 3 we will fine tune VMQ a bit more and see some results of VMQ in action. All I can say at this moment that VMQ is well worth having on your Hyper-V implementations.

August 25, 2010 · Posted by Erik den Burger · 0 Comments

Increase network throughput under load in Hyper-V

Tags:  Hyper-V · Performance

The default buffer size used by a virtual switch used by Hyper-V may provide not enough space to buffer all the network traffic, therefore resulting in packet loss. This may happen when hyper-V is put under a significant load. Default buffer size is 1 MB and may be increased to provide better performance.

Comparable to a normal traffic jam, where there are too many cars trying to drive the same piece of road, the same can happen to network traffic. This can result in poor network performance. Especially in virtual environments these problems can be complex with several child partitions fighting for the same physical NIC. Hyper-V or better the VMBus of the Hyper-V supervisor is regulating the access to the physical NIC by using buffers and queues to keep all data flowing. However when these buffers run out of space some data packets will be dropped. In Windows Server 2008R2 the default size for this buffer is 1 MB, giving room for 655 packet buffers of 1600 bytes each. Although in most situations this value will give you more than enough room to play it may be advisable in some larger and busier Hyper-V environments to increase this value to 2 MB or even 4 MB. Anything more is not useful.

The process of increasing this buffer size isn't done with a fancy setting hidden in the GUI but should be done in the registry of the guest partition. We need to have a GUID and index of the network adapter which we can find by opening the Device manager, expand network adapters, right click the MS Virtual Machine Bus driver and choose properties. In the details tab we select the driver key. We no get the GUID/Index we need. We can now go to the registry editor and go to HKLM\SYSTEM\CurrentControlSet\Control\Class\<GUID>\<Index> where we can create to new DWORD values: ReceiveBufferSize and SendBufferSize. These values are representing the amount of memory that will be used as a buffer in 1 Kb units. 0x400, the default value, will result in a cache of 1 MB. Now I almost forget to mention that changing the registry is dangerous and you should have made a backup before you were changing any settings.

With most Hyper-V servers having plenty of memory nowadays, it is a good idea to increase the buffer size to give you a better network performance and protect you from packet-loss.

February 6, 2010 · Posted by Erik den Burger · 0 Comments

Power Management

Tags:  Windows Infrastructure · Performance

Last year Microsoft released a SCOM Management Pack for monitoring and managing the power consumption of Windows 2008R2 servers. This management pack gives you some insight into the power consumption of the servers and, even more interesting, gives you the ability to control the power savings and therefore reducing the total consumption of a server. And keep in mind that every Watt you can save with your servers is another Watt saved in you cooling.

 

One of the interesting features of windows 2008R2 that will reduce your power consumption is the use of Core Parking. Modern servers are using multiple multicore processors, giving you a lot of horsepower. But this horsepower is not always needed. When the system is not using all of the cores Windows 2008R2 actually put these unused cores in a park mode. If necessary, Windows will wake these cores when needed. This feature, combined with reducing the speed of the processors can significantly lower the power consumption.

If you want to see the 2008R2 Core Parking in action, you can use the performance monitor of Windows 2008R2, this will give information about the usage of the different cores.

 

So, Microsoft is getting serious with their power savings tooling. After the announcement of SCCM 2007R3, which is very useful to reduce the power consumption of your workstations, the use of the power management pack for SCOM can really save a lot of energy, and thus a lot of money.


 

February 2, 2010 · Posted by Erik den Burger · 0 Comments

DFS replication on a failover cluster

Tags:  Performance · Windows Infrastructure

One of the cool new features of Windows 2008 R2 is the possibility to add a windows failover cluster as a member of a DFS-r replication group. This possibility creates a highly available replication service.

A useful scenario for a failover clustered DFS-r service is the clustering of a central DFSR-Node in a multi-site replication group. The data of the branch offices is replicated to the central site, where it is safely stored, archived and backupped.

As you can see above, in the central site we have created a two-node failover cluster. Both nodes are connected to a shared storage medium. This can be a shared SCSI or SAS solution but also a FC or iSCSI SAN solution. In event of a failure of the priamary node, the windows failover clustering service will delegate the DFS-R related roles to the secondary node without having to reconfigure the DFS-R service.

But how do we create a DFSR replication group that is using a cluster instead of a fileserver. With the Windows 2008R2 management tools this is really not that hard to do.

  1. Built your central File-server failover cluster using the built in wizard. Building a cluster has become really easy nowadays.
  2. Add a file server application/service to your cluster. Again using the builtin wizard. During this process a Client Access Point is created.
  3. Now we can create a replication group. Remember that the cluster should be running 2008R2. The branch office servers (non clustered) can be running Windows 2003R2 of Windows 2008.
  4. When we need to add the cluster to the replication group we are using the previously created Client Access Point as the replication member.

That's it for building a highly available DFS-r replication solution.

 

A more complete guide can be found at the blog of the Windows Storage Team: http://blogs.technet.com/filecab/archive/2009/06/29/deploying-dfs-replication-on-a-windows-failover-cluster-part-i.aspx

January 12, 2010 · Posted by Erik den Burger · 0 Comments