Part 1 – Covered the hardware, network configuration and some performance testing.

Part 2 – Covered the storage configuration, cluster configuration and started to talk about the use of differential disks and the CSV block cache.

In Part 3, I'm going to cover the differential disks in much more detail, how they work, why you want to use them in a test lab. I'll also start talking about the automation parts, in this post, focusing on basic VM provisioning.

Differential Disks

The huge performance gains from the CSV block cache described in Part 2 are seen because of a combination of the CSV cache and the use of Differential Disks. Differential Disks work by having a read only copy of a master disk that multiple VMs are attached to. All differences between those VMs are stored in the 'differential' disk attached to the VMs. It's best explained by the high level process used to set it up.

1. Create a VM (The VHDX can be fixed or dynamic, does not matter, but for a lab dynamic is a good idea)
2. Install the Operating System (MDT comes in handy here, I've got some cool zero touch role deployment stuff using MDT that integrates with VM templates, but that's for another post)
3. Patch the Operating System
4. Sysprep the Operating System
5. Delete the VM (The VHDX file with the patched, syspreped OS will be retained)
6. Mark the VHDX file as read only

That's the preparation work. Now you can create a VM using the differential disk. Here are the high level steps

1. Create a new differential VHDX linked to the parent disk (created in the previous steps)
2. Create the VM and attach the disk created in step 1.

Done! Boot the VM and it will run through its mini-setup. Then you have a new VM with a patched OS. There are two main advantages to doing this. Firstly, rapid provisioning. When using PowerShell to perform VM creation, you can have a new patched VM in minutes (and most of that time is the machine running mini-setup). Secondly, because most OS disk reads for multiple VMs are coming from the same disk, you see huge performance gains from the CSV block cache.

Differential Disk Limitations

You would normally not use differential disks in Production environments (there are exceptions, such as Citrix PVS), and there are several reasons for this.

Resiliency – When you have multiple VMs running of the same master VHDX, the risk profile goes up. If the master disk gets corrupted or accidently deleted, then you don't lose one VM, you lose all the VMs linked to that master. Because of this, it is very important to back up the parent VHDX file to some other storage.

Performance – As all reads are coming from the same disk, that disk will get smashed with read I/O. So you either need to throw very fast disk at it and/or use caching (we're using caching).

Patching Lifecycle – Once the master has been marked read only, you can't patch it. And no, you can't remove the read only tag, patch it and mark it as read only again. Why? Well, the child disk looks at the parent and knows something changed in the parent since it was originally linked, but it can't know what. From that point it simply assumes the parent disk has become corrupted and the VM based off that disk won't start. While it is possible to correct this by reconnecting to the parent drive (and ignoring the ID mismatch). It's not recommended for stability reasons and it's certainly not recommended as a regular patching strategy. While it's tempting to take these kinds of shortcuts in a lab, just remember this. Stability and reliability are critical in a lab. When you're in your lab, you're learning and testing. If something is not working, you want it to be because of something you've done wrong in the configuration, not because you've done something doggy with patching and caused instability in the system. It can also take many, many hours to track down those kind of faults.

The say a picture is worth a thousand words. So I've included an illustration of the makeup of differential disks.

When you deploy the first VMs off the parent, the VMs deploy quickly, because at that point in time they are fully patched. But as time rolls on they become more and more out of date. One of the main reasons to do this is rapid provisioning. So after a while you'll want to create a new set of parent disks that are more up to date.

I've got automation to do this, but that will be the content of another post. In this post I'll cover off the automation for VM provisioning. This first set of automation will be basic and will cover off provisioning with Hyper-V only. In the next post I'll cover off more advanced provisioning using System Centre 2012 SP1 – Virtual Machine Manager.

The key to automation in Windows and System Centre is PowerShell. If you work in IT System Administration you owe it to yourself to know PowerShell and know it well. If you're not sure where to get started with PowerShell, some good places are here, here and here. The last link is to a Virtual Academy course on PowerShell, and it's an excellent way to get started.

Here is the script, and then I'll discuss a few interesting points.

#Ask for Server Name

$MachineName = Read-Host "Please enter the Machine name"

$ParentVHD = "C:\ClusterStorage\Volume1\ParentVHDs\Diff2012_2_disk_1.vhdx"

$DefaultVHDPath = "C:\ClusterStorage\Volume2\"

 $VHDXName = $DefaultVHDPath + $MachineName + "_C.vhdx"

 #Create new disk from parent

 New-VHD -ParentPath $ParentVHD -Path $VHDXName -Differencing

 #Create new VM with diff disk

 New-VM -VHDPath $VHDXName -Name $MachineName -MemoryStartupBytes 2147483648 -SwitchName "External"

 # Set additional VM Config

 Set-VMMemory -VMName $MachineName -DynamicMemoryEnabled $true -MaximumBytes 4294967296 -MinimumBytes 536870912

Set-VMProcessor -VMName $MachineName -Count 2

 #Add Machine to Failover Cluster

 Add-ClusterVirtualMachineRole -VirtualMachine $MachineName

 Start-VM -name $MachineName

The first line asks for the server name to be build and stores it in the $MachineName variable. The next three lines set up the paths for the virtual hard drives. Please note the C:\ClusterStorage\Volume1 and C:\ClusterStorage\Volume2 paths. This is the CSV namespace for the clustered volumes, the parent disk stored on volume 1, which is the slower spindle storage and Volume 2 is hosted on the SSD (refer back to Part 2 for details of this setup). The first step of creating the differencing VHDX is done using the New-VHD cmdlet. As you can see from the PowerShell, this is very, very easy to do. The next line creates the VM and attaches the newly created VHDX file. In addition, it sets the startup memory for the VM and attaches it to the 'External' virtual switch. The next two lines set Dynamic Memory on the VM, minimum of 512Mb, maximum of 4GB and gives it two vCPUs. If you leave it there, the VM will be created with the VHDX on the clustered storage, but it will not be highly available because the cluster service is not aware of it. The Add-ClusterVirtualMachineRole command will add the VM to the cluster service. The last line in the script starts the VM.

From here you'll have to do manual steps such as set the machine name in the Operating System (The script set the external VM name, this can be different to the machine name in the OS), the IP address and joining to the lab Domain. In the next post I'll cover off the automation for provisioning using Virtual Machine Manager, which will take care of these manual steps.

Let's see how rapid the provision of a VM is using this method. I want to fire up a new server to do some awesome testing, from entering the server name at the script prompt and pressing enter, my VM is booted and ready for work in 2 minutes and 21 seconds. This includes running mini-setup. In fact the mini-setup takes most of the time as the VM is provisioned, added to the cluster and booting after about 20 seconds.

Oh, I almost forgot to mention, make sure you have the CSV namespace set as the default path for the Virtual Machines in Hyper-V Settings. If you don't the script will place the VM configuration on the host's local hard drive and not the clustered storage (that's the config files, not the VHDX files). Everything will seem OK from the Hyper-V and Cluster Manager UI, but you'll notice the problem soon enough the first time you try and Live Migrate a VM.

In Part 2, I'll cover the Hyper-V and cluster configuration, where I run the VMs from and why. And the optimisation of Read performance using Differential disks and the CSV block cache.

To expand on Part 1, I have four physical machines in the test lab.

• 2 x Hyper-V Cluster hosts running Windows Server 2012 Hyper-V (Server Core)
• 1 x Windows Server 2012 box running as an iSCSI target to provide shared storage to the Cluster
• 1 x Gaming rig running Windows 8 Pro

As briefly mentioned in part 1. The Gaming rig is a home system. So it's not joined to the test lab domain. This makes it easy to work that system into a home group network, so stuff can be shared with the Home Theatre PC and the 10 thousand tablets I have in the house.

The great thing about Windows 8 Pro is Hyper-V client. This allows me to run some VMs that are independent from the cluster. There is no sacrifice VM performance because client Hyper-V is a Type 1 bare-metal hypervisor just like Windows Server Hyper-V.

I have three VMs running on the Gaming Rig. The test lab Domain Controller, an MDT box and an RDS Server. With the hardware I used (Itemised in Part 1), I was able to bare-metal build the two Hyper-V Cluster hosts over the network using MDT, using a standard server deployment task sequence. I did not have to worry about and additional driver injection, everything just worked out-of-box. For those not familiar with MDT (Microsoft Deployment Toolkit), it is simply the best way of accelerating Windows Image deployment. If you need to get image deployment happening quickly, MDT is the way to do it.

http://technet.microsoft.com/en-us/solutionaccelerators/dd407791.aspx

The new hardware will hit the MDT box via Pre-Execute Environment (PXE). This will be require the WDS and DHCP server roles to be installed on the MDT box.

I won't go into the step by step detail of how to set up the deployment share and importing Operating Systems. This is very well covered in the MDT documentation, the 'Quick Start Guide for Lite Touch Installation' is a good place to start.

The task sequence I show here is as about out of box as it gets. Windows has all the drivers out of box, so I did not have to worry about any additional drivers. I have set the Task Sequence to detect the model type and if being deployed to my physical hardware, it will run the additional of tasks to set-up Hyper-V.

Below you can see the server build Task Sequence. Before you say 'that looks like a lot of work', all of the steps except for the activities under the 'Hyper-V Cluster Node' group, are generated automatically by MDT.

The Options tab is where you set the logic for the group of tasks to only run if certain hardware is detected.

I didn't have to do any scripting here, the 'Product' variable is populated by the ZTIGather script, which runs as part of an MDT task sequence by default.

The custom actions were also quite easy, the first two actions enable the Hyper-V role and install the Failover Cluster feature (you could do this as a single step, but I like to keep things modular).

The next two steps set my MDSN MAK product key and activate Windows. This works because the lab has access to the internet.

You can set the product key when setting up the Task Sequence, but the other way to do it is using the slmgr.vbs script in windows. The /ipk switch sets the product key and the /ato switch activates Windows.

The last step it to import the MDT boot media into WDS so it can answer the PXE request from your bare metal servers.

Launch the Windows Deployment Services manager. Navigate to 'Boot Images' item and right click. Select 'Add Boot Image' and navigate to deployment share directory\Boot and select the LiteTouchPE_x64.wim file. Once imported, WDS will serve the MDT boot image to any client it answers a PXE request from.

I was able to kick both builds off a same time and in 15 minutes I had two fully build Hyper-V Hosts ready for the cluster configuration.

iSCSI SAN

A Hyper-V cluster requires common storage, and that's where the server running as an iSCSI target comes in. This is just stupid easy to set up. I have Windows Server 2012 (Full UI) installed and simply allocated each drive (SSD and Spindle) to each LUN.

The following is a great blog on the setup and use of the iSCSI Target in Windows Server 2012.

As the blog covers things in great detail, I won't go into the setup to much here. As you can see, I have two LUNs presented (one fast SSD and the other slower Spindle). Plus another LUN provided for the cluster Witness disk.

From there I'm using the built in iSCSI initiator software on the Hyper-V host to make the connection from the Hyper-V hosts.

When the connection is made, the LUNs created on the 2012 iSCSI server come in as normal disks.

Cluster Configuration

While it's true I could probably get better capacity by putting the same amount of money into a single machine, I gain a good degree of flexibility by having a cluster. Zero down-time fabric patching is just one advantage (I'll cover this in a latter blog post).

Clusters in Windows Server 2012 are not that hard to understand. The most complex things in a production design are the networking and the storage.

I've covered the storage above. The Network setup is by no means to best practise. I am dedicating a single 1Gb NIC to iSCSI and some cluster functions, so the second NIC will be used for just about everything else.

The following table illustrates the networks needed by a Hyper-V cluster and how I've applied them.

IP Addressing

Just for an example and so you get the idea, I've included the IP addressing scheme I've used.

Here is the NICs look in Windows in the Hyper-V Server.

Hang on, I've got two NICs and three are displaying here – what gives? Well, when you create a virtual swtich in Hyper-V and bind it to a physical adaptor (that will be the adaptor that transmits and recieves the VM traffic), it makes that adaptor unusable to the host directly. As you can see from the screenshot, it unbinds just about everything execpt the virtual switch.

On a server, this would be fine as I would have this NIC (or teamed NIC) dedicated to VM traffic. But in my home lab, I need to use that NIC for other stuff.

Setting the VM Network

Open the Hyper-V MMC, then select the Virtual Switch Manager. Create a new virtual switch (I've just called mine 'External') and pick the adaptor you wish to bind it to.

Notice there is a check box that says 'Allow management operating system to share this network adaptor'. By checking that, the Hyper-V host will create a new logical adaptor the host can use for other stuff, and that's the third NIC displayed in the screenshot above.

I'm going to side track for a second because I want to spell this out. Because I can't tell you how many times I've seen people get this wrong or misunderstand how this works.

Hyper-V Host before the vSwitch is created

After an external vSwitch is created

If the enable host management on the switch is enabled

There is an option just below this to set a VLAN tag. If you do this, you are NOT, I repeat NOT, VLAN tagging the virtual switch. You are tagging the new logical NIC that was just created in the host.

If a VLAN Tag is set when you create the vSwitch

If you're after the visio stencils I used, they can be found here.

You may have noticed at the start of the blog I stated I was using Server Core on the Hyper-V Servers, but all the screen shots have been from the full UI version. In Windows Server 2012 you can switch between the full UI and Server Core very easily. Here is a good blog on the difference between the three options on Windows Server 2012: Server Core, Minimal Server Interface and the Full UI.

You can switch between Server Core and Full UI using the following PowerShell Commands:

To go from Server Core to full UI.

If you installed the Server Core SKU, you will not have the binaries to run the full UI and you will need to run the following:

Dism /online /enable-feature /featurename: ServerCore-FullServer /source:"path to source"\sources\sxs

Then to enable the full UI:

Add-WindowsFeature Server-GUI-Shell

To go from full UI to Server Core:

Remove-WindowsFeature Server-gui-mgmt-infra

Create the Cluster

This process is fairly easy, you need to make sure the failover cluster feature is installed on all nodes. Then launch the failover cluster manager and select 'Create Cluster'.

Step through the create cluster wizard. The first task is to select the nodes you wish to be in the cluster (you can browse by AD computer object). You'll then be asked to validate the cluster. While this is not a production environment, you don't technically need to run it, but I would still recommend it. The Cluster validation process is the best way of finding issues that will prevent the cluster from working. After the validation, enter a name and IP address for the cluster. The Setup Cluster wizard takes care of the rest.

Setting the Quorum configuration

From the Top level of cluster failover manager, select 'More Actions' in the Actions section.

From there select 'Configure Cluster Quorum Settings'. One of the great new features of Windows Server 2012 is that it can dynamically set the quorum mode. In a Hyper-V cluster, you can have several quorum modes, the most common and node majority (just uses the hosts and does not use a witness disk) or node and disk majority (which uses the hosts and a witness disk). As long as you have a disk available to be the witness (as was configured earlier) the cluster will dynamically set the best quorum mode, based on the number of active nodes in the cluster.

How to set the LM network

Now we need to tell the cluster which network we want to use for which function. Starting with the Live Migration network. This is easy to set, a bit tricky to find in the UI. Again, in the Failover cluster manager, right click on the Networks item.

Then select 'Live Migration Settings'. From here you can select the network(s) and set priorities.

How to set the CSV network

To set a preferred network here, you use metric setting in PowerShell. To set the priority network for CSV redirection it needs to be set to 900

(Get-ClusterNetwork "Cluster Network 2").Metric = 900

To verify the setting use the following command

Get-ClusterNetwork | ft Name, Metric, AutoMetric, Role

Configure the CSV volumes

This was interesting to find in the UI in 2008 R2. In 2012 it's so easy it should be illegal.

Simply right click on the disk and select 'Add to Cluster Shared Volumes'

VMs and boot order

With all the different machines and dependencies, the order in which these things are fired up matters. I've included a table of which VM is hosted where and the boot order.

CSV Block cache and boot times

As you could see from the hardware specs in part 1, I don't have a lot of disk to throw at this config. So the idea is to use every little trick to extract the maximum performance. By far the biggest gain in the lab is to use differential disks and the CSV block cache. I'll go into more detail of what differential disks are, how they work and how to set them up in Part 3. For now I'll explain a little on the CSV block cache and how to enable it.

For an overview of the CSV block cache and a bit more detail, refer to this blog. However, in summary, blocks read from the storage are stored in RAM on the Hyper-V host. When the block is accessed again, it's read directly from memory on the host and not the storage, giving a huge boost in performance. The cache is split 50/50 between common reads and uncommon reads. This ensures the cache is maximising performance for both data read all the time and data read more infrequently. The difference it can make can be quite large.

To illustrate the difference, I performed a demo at TechED Australia in 2012 where I did a comparative test between booting 5 Windows 2012 Server VMs (using differential disks) with the cache off and then with the cache on. To boot the 5 VMs with the cache off took 2 minutes and 38 seconds. With the cache on, the 5 VMs booted in 47 seconds. If you want to see the demo, it's on-line here. Apologies for my voice if you watch the video, I was losing it. To save you some pain, the first part of the demo is at 43:55 and the second part of the demo is at 56:45. If you're in the mood, that session also has a very cool demo showing how a VM can remain running even if it loses its storage using the CSV redirect, and that's at 35:55.

Enabling the cache is done from PowerShell. It's also not on by default (2012. It's enabled by default on 2012 R2), so if you want to utilise it, you'll have to turn it on. The default size of the cache is 512MB, in the lab I've found that allocated a 1GB works well, to do that use the following command:

(Get-Cluster).SharedVolumeBlockCacheSizeInMB = 1024

Please note, that's the command for Windows Server 2012, it's different in 2012 R2

(Get-Cluster). BlockCacheSize = 1024

The Cache is enabled on a CSV by CSV basis. This enables you to be selective on which CSV LUNs you cache. In my lab, I have the parent VHDX on the slow spindle disk with the cache enabled and all the differencing disks on the fast SSD with the cache disabled. This ensures the cache is maximised for the reads from the slow disk and I can save storage on the fast disk.

If you're running 2012, use the following command to enable the cache:

Get-ClusterSharedVolume "Cluster Disk 2" | Set-ClusterParameter  CsvEnableBlockCache 1

To verify the setting, use:

Get-ClusterSharedVolume "Cluster Disk 2" | Get-ClusterParameter  CsvEnableBlockCache

As you can see from the warning, the disk needs to be taken offline and then online again for the change to take effect.

One final point - this is why I use iSCSI to the 2012 SAN rather than SMB 3.0. You can't enable CSV on SMB shares, only on LUNs connected to the hosts. No CSV means no Block Cache, and that's the only reason I don't use SMB. If SMB had a similar caching function, I would certainly use it, as it's much easier to set up.

That wraps up part 2. In Part 3, I'll cover the use of differential disks in the lab and start to cover off the automation I use so I don't spend all my lab time doing grunge work.

In this blog series I'm going to show how I have my lab setup, which was designed to accomplish a few things

• Give me the maximum performance 'bang for buck'
• Utilise some existing hardware
• Provide a HA Hyper-V Cluster
• Automate tedious tasks like server provisioning and patching
• Take up as little desk space as possible
• Utilise 'out of box' Microsoft capabilities

DISCLAIMERS

• Many things in this blog will NOT be Microsoft recommended practise. It's a home lab, so I can take some shortcuts, things you would never do in production. I'll do my best to call out when I've done this.
• All equipment quoted are done so as examples only. This is how I've done it. I'm not saying it's the only way or the best way to do it, nor am I recommending one product over another.
• Any prices quoted are in Australian Dollars, and are what I paid at the time. It might be less or more for you, depending on what and when you buy and your location

   

As this is a home lab, I care about two things, my money and my time. I don't want to spend more money than I have to. I don't know about you, but I would just as soon spend my free time playing games than studying and working in my lab. So I don't want to spend hours watching blue (or green) bars go across the screen if I can make that task quick, or automate it.

Part 1 will be about the hardware, storage and network setups. In future parts I'll cover off the provisioning and automation parts.

When I set this up, I set a budget of $3000 for compute, storage and network. For the purposes of this blog, I'll assume as an IT Pro, you have a TechNet or MSDN subscription, so I won't be including any software pricing.

I also have an existing Gaming rig that I wanted to utilise. That machine has to remain as a home system that can utilise HomeGroup and can function easily disconnected from the home network (when I take it to LANs). So that machine needed to stay out of the test lab domain and run a consumer Operating System.

One of the great things about Windows 8 Pro is client Hyper-V. This allows me to run some of the VMs outside of the primary cluster (I'll explain why that's handy latter). I won't go into huge details on the specs of this box, as it's pre-existing and not part of the $3000 budget, in brief it's a dual core i7 Intel and has 16Gb RAM, with a reasonable amount of storage. Just as you'd expect to find in any IT Pro's house as a gaming rig.

Storage

I didn't want to spend the money on any kind of NAS device, plus I wanted the flexibility to play around with SMB 3.0 clusters (a design I abandoned, I'll explain why in part 2). So I built a PC with storage, installed Windows Server 2012 and used storage spaces to carve up the disk and presented LUNs using the Windows iSCSI target software.

Hardware Specs and Cost

Total for the hosts - $1774.84 – looking good to stay under the $3000 limit!

Total for the storage $1218.03 Total overall was $2991.87. I was able to keep it under the $3000 limit!

Here are a couple of photos of the build of the Hyper-V hosts. It will give you an idea of the case size.

Networking

Each host has two 1Gb NICs, one for VM and host Traffic and one for iSCSI. The iSCSI Server has three 1Gb NICs, one for host traffic and two for iSCSI. This made a performance difference as illustrated in the performance testing section.

The following diagram illustrates the physical network setup for the lab. The Host Network is in a 10.100.0.x range and the iSCSI network is in the 192.168.0.x range. Putting the iSCSI in a different range is the easiest way to ensure those adaptors are used for iSCSI exclusively.

Network and Disk Performance Testing

Is it really worth having two NICs in the iSCSI server? How much difference will a SSD Drive make? I could have put 3 x 1TB spindle drives in for slightly more than the single SSD and single Spindle drive. How does the performance compare. Well, I've done both and tested it. Here are the results.

In the test I really wanted to determine the sweet spot for disk write. I was not so concerned about read (I'll explain why in part 2). The test involved taking approx. 8.5GB of data (all the ISOs for System Centre 2012) and copying to the iSCSI Server. This was done from a single Hyper-V host to the iSCSI Server to set a benchmark, then from both Hyper-V Hosts at the same time.

Test 1

Copy of test data from a single Hyper-V host to the iSCSI server over dedicated 1Gb link.

Configuration

Copy Time

That was not the first copy, so the time of 30 seconds is little deceptive as there is some caching going on.

Network Util

As you can see, the throughput was excellent, and that level was sustained for the duration of the copy. I thought it was excellent given its consumer grade equipment.

Disk Queue

The numbers to look at the Avg. Disk Queue and Avg. Disk Write Queue Length. If either are more than 5 (number of physical drives plus 2) then the copy is disk constrained. At a number of 0.451, we are nowhere near saturating the disks.

Test 2

Copy of test data from both Hyper-V hosts to the iSCSI server over dedicated 1Gb link at the same time. The copy was done to separate directories on the iSCSI Server.

Configuration

Copy Time

Same deal as the first, this was not the first copy run, so there is some caching. But the copy times have increased from 30 seconds to 1:16 on one host and 2:00 on the other.

Network Util

The screen shot from the other host is much the same. Hard up at half a Gb. This indicates the single 1Gb NIC on the iSCSI server is saturated.

Disk Queue

Double the previous numbers, but still not pushing the disk.

So from here it would seem that I am network bound. So adding an additional 1Gb NIC to the iSCSI server to give each host a dedicated 1Gb path (rather than a shared 1Gb path) will improve the performance. So, let's see what the testing says.

Test 3

Copy of test data from both Hyper-V hosts to the iSCSI server over two dedicated 1Gb links at the same time. The copy was done to separate directories on the iSCSI Server.

Configuration

Copy Time

Copy times have gone down. From 1:16 to 1:04 and 2:00 to 1:20 respectively. So better, but not that much better. I expected more given it's now got twice the bandwidth.

Network Util

So, breaking over the half Gb mark, but not my much. Very choppy graph, not coming anywhere near saturating the network. The graph from the other host showed the same.

Disk Queue

Woah, where the hell did that number come from! From 0.8 to 185.6. That little bit of extra network has pushed the disk over the edge. Just goes to show, gravity's unforgiving when you drop off the edge of the performance cliff. Time to put in an SSD and run the test again.

Test 4

Copy of test data from both Hyper-V hosts to the iSCSI server over two dedicated 1Gb links at the same time using an SSD drive as the target. The copy was done to separate directories on the iSCSI Server.

Configuration

Copy Time

Copy times have gone down. From 1:04 to 53 seconds and 1:20 to 51 seconds respectively. An improvement of roughly 57% on the second node. It's also noteworthy the copy times are more aligned between the two nodes.

Network Util

Not reaching full saturation at 1Gb and still a bit choppy, but much better sustained throughput than before. Given the network is not being saturated, there must still be a disk bottleneck.

Disk Queue

Disk queue at 46, so I'm still disk bound (I suspect I might be controller bound). So not perfect but much better than 185!

I think I've found the configuration sweet spot from a performance point of view (and staying within budget). I hope you found it useful

In the next post, I'll cover how I have configured the virtualisation layer, where VMs are placed, and how to maximise read performance using the CSV block cache.