CPU Masking

Several months ago, I ended up in an unfortunate situation. We invested a sizeable amount of money on a powerhouse server to add to our ESX cluster. While the server was the same model as the rest of the machines in our cluster, the vendor had added SSSE3 support to this latest revision, something I was not aware of at the time of purchase. The end result of adding these new instructions to the cluster was vMotion incompatibility between this server and our other ESX hosts.

While not supported by VMWare, CPU masking is a feature available in Virtual Center that will allow you to overcome situations like this. While in my case, SSE3 servers to an SSSE3 server, compatibility certainly cannot be guaranteed in these situations and I must emphasize that you proceed with caution. In addition, if the differences in my CPU's were more profound (say AMD vs. Intel), I would never attempt this, especially in a production environment.

In some situations, Enhanced vMotion will allow you to overcome minor CPU differences and I would certainly recommend that as a first attempt. You will need to be running at least Virtual Center 2.5 Update 2 and ESX 3.5 Update 2 to enable this. You will also need to recreate your cluster. You can find information on EVC as well as supported processors in KB 1003212.

VMWare outlines the process of CPU masking in KB 1993. In my case, I wanted to mask only the needed instruction sets and it took a little while to figure out exactly which combination of masks to use between each of the registers leveraged. The end result was to navigate to C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter and edit the vpxd.cfg XML configuration file. The section of text below was all that was needed to accomodate the differences between these processors. Sorry for the screenshot, but formatting XML for web presentation is a pain...

Adding Raw Device Mappings for Maximum Performance

We know that adding an RDM to your SQL and Exchange hosts can have an enormous impact on IO performance. In addition, under Windows Server guests prior to Server 2008, the partition must be properly aligned when accessing a RAID volume in order to achieve maximum performance. This is due to the fact that with a physical disk that maintains 64 sectors per track, Windows always creates the partition starting at the sixty-forth sector, therefore misaligning it with the underlying physical disk. In some cases, aligning a partition can boost IO performance by up to 50 percent! Here is a step by step guide to creating, attaching and aligning an RDM partition in ESX 3.5 on Server 2003.

Attaching a Raw Device Mapping

1. Log on to your SAN and create your LUN. Make this LUN available to all ESX hosts in your cluster. The steps needed to do this will vary by SAN and Fibre switch, so consult your vendor’s documentation for more info.
2. Log in to Virtual Infrastructure Client and connect to your Virtual Center instance.
3. Click on an ESX host and choose the Configuration tab.
4. Click on Storage adapters and rescan for new storage devices. Your new LUNs should show up. You do NOT want to create a VMFS here.
5. Repeat this procedure for each ESX host in your cluster.
6. Right click on the guest OS that you will be attaching the RDM to and click on Edit Settings.
7. Click Add in the hardware tab, choose Hard Disk and then Raw Device mapping.

Adding your new disk to the guest OS

1. Log on to your guest OS and launch Device Manager.
2. Scan for hardware changes.
3. Open Disk Management and initialize the new disk. Do not create a partition at this time.

Adding a properly aligned partition to the RDM

1. Log on to the server.
2. Type diskpart at the command line to launch the diskpart utility.
3. Type list disk to see a list of disks present. For my example, I will be creating a partition on Disk 2 and it will be the only partition on this disk.
4. Type select . In my example, you would type SELECT Disk 2.
5. Type create partition primary align=64 to create a primary partition that takes up the entire disk. You can use the size keyword if you are creating more than one partition on the disk.
6. After you have finished here, you will need to go in to Disk Management, format the partition and assign it a drive letter as you would normally.

Running SQL Server on ESX

There is currently a lot of debate going on about whether or not you should be running SQL server or Exchange on ESX. Rather than jump into the middle of this debate, I'll offer the best way that you could possibly run a high performance SQL server on virtual hardware.



I/O

I/O is by and large the biggest concern when running a database on an ESX cluster. Your main concern here is going to be ensuring that your database files are not impacted by I/O operations on your other VMs. We can ensure this through Raw Device Mappings.

Generally, for a high-performance database, you'll want your data files, log files, tempdb and program/OS/backup files to all live on separate spindles. To accomplish this, we do the following:

Data Files - RAID5 or RAID10 (RAID5 is more economical but you will suffer a hit on write performance).

Log Files - RAID10

TempDB - RAID10

OS/Program Files/Backup/File Share - This can be run from a standard VMDK.


Memory

In addition to I/O, memory is very important. If a database server has sufficient memory, it will not need to go to disk for its data as often, vastly improving performance. To be absolutely sure that your server receives sufficient memory, you can set your memory reservation equal to the amount of memory given to your VM. This will ensure that ESX never swaps out active memory from your database and that the SQL query optimizer can make accurate predictions about hardware performance.


CPU

On my key instances, CPU has never been much of a bottleneck, so I generally treat this as I would with any other VM.