Using HCIBench to benchmark vSAN – Part 1: Deploy

Using HCIBench to benchmark vSAN – Part 1: Deploy

The first thing you’ll want to do with your shiny new vSAN cluster is put it through it’s paces, this series of posts will take you through benchmarking your vSAN cluster with a handy little Fling that’ll do the job perfectly- HCIBench.

 

Being a Fling the HCIBench benchmarking tool is frequently updated with new features and enhancements added all the time, so be sure to check the HCIBench Fling page for all the latest details.

‘Hang on though vMustard, I’ve been using IOMeter for fifty years for benchmarking so why can’t I use that?’ I hear you cry!
Good point and thanks for bringing it up. The main difference is that IOMeter must be configured very specifically in order to achieve accurate result, number of disks (workers) and queue depth (outstanding IO) particularly make an enormous difference in the results you’ll pull back. Ignore all results you have unless you’ve set the Outstanding IO to 16- all SSD ‘back-of-the-box’ benchmark figures are based on this parameter value and you should base your benchmark on the same. For more details on using IOMeter check out this VMware blog post from Wade Holmes, it’s based on 5.5 but the params are still valid.

HCIBench on the other hand is built specifically for performance-testing Hyper-converged infrastructure so all tests are optimized to show you what you can really get out of your cluster.
Essentially an abstraction layer to the open source Vdbench, HCIBench will install a Controller VM (rough spec 8 vCPU, 4GB RAM 15GB disk space) which will automate the benchmarking of your cluster using one or more ‘Worker’ VMs (4 vCPU 4GB 15GB) to run the workloads. Neat huh?

So here we go. HCIBench is supplied as an OVA ready to deploy, go to the HCIBench Fling site to grab it.

vMustard_HCIBench_FIG1

Now most of these steps should be fairly obvious and straightforward but I’ll include them all for completeness. Now is probably as good a time as any to say that though it’s possible, it is recommended NOT to deploy the Controller VM on the vSAN cluster you wish to test as it could skew the results- stick it somewhere else if at all possible.

First, you’ll need to deploy the Controller VM from the OVA.

Tick the box to Accept the extra configuration options, you won’t be able to deploy the OVA without these so you don’t really have a choice! Next…

Accept the EULA (the sharp of eye among you will notice that the EULA is for Photon OS which is what the VM runs. Scenes!)

Give the VM a name and choose the location of your shiny new VM

Choose a datastore and disk format, exciting times! Next…

Now we’re getting serious. So the ‘Public Network’ should map to the port group associated with the network on which you will access and manage the HCIBench Controller VM. The ‘Private Network’ is the network on which all the ‘Worker’ VMs will be deployed. DHCP is required on the Private Network however do not fear if you don’t have a DHCP server to oblige, the HCIBench Controller can be your DHCP server. Clever stuff.

Enter the IP address details for your VM (on the ‘Public’ network) or leave the DHCP selection as default if required. Enter the root password and click Next

Then just review your settings, select Power on after deployment if you’re that way inclined and hit Finish to fire up the deploy!

So that’s your HCIBench Controller VM deployed and ready to go, check out the next post in the series- Part 2: Configuration for how to set HCIBench up ready for testing!

 

vM

Related posts