So you’ve got your HCIBench Controller VM, what next?
Welcome to Part Two of this blog series, walking you through putting your vSAN environment through it’s paces with HCIBench. We deployed the Controller VM in Part One, let’s get on and configure it ready for testing.
So first, power on your new Controller VM if it is not powered on already, then point a web browser to http://<Your_HCIBench_IP>:8080 where <Your_HCIBench_IP> is the public IP address you gave it during the OVF deployment, or the DHCP address it picked up. Log in with the root credentials also specified during the deployment and you’ll get the Configuration UI ready to roll…
Go down the list filling in the details of your test environment as you go.
You’ll need to enter:
vCenter FQDN or IP – name or IP address of the vCenter managing your cluster
vCenter username – needs to be in username@domain format
vCenter password – the password, surprisingly
Datacenter Name – name of the vDC in vCenter where your hosts reside
Cluster Name – The name of your vSAN (other HCI platforms are available) cluster- this will be the cluster where the worker VMs will be deployed
Network Name – optional, but if you don’t enter anything it’ll assume ‘VM Network’
You’ll then see a check box for enabling DHCP. DHCP is required for all the Vdbench worker VMs HCIBench will spawn so if you don’t already have DHCP on the ‘Private Network’ specified in the deployment then you’ll need to check this box. Now I had some issues with this as I couldn’t find an (easy) way to configurue the scope or even the interface of the IP on the private network so I found it easier to knock up a quick DHCP server first.
Next enter the Datastore Name of the Datastore that you want HCIBench to test, so for testing vSAN you will enter ‘vsanDatastore’
You then have the option to clear the cache before testing, this is for vSAN only and I recommend you give this a tick to make sure the test results aren’t skewed by any data lurking in the cache, especially if you’ve been running multiple tests.
Next you have the option to Deploy the Worker VMs directly to your hosts or whether HCIBench should leverage your vCenter instance to deploy them. Now unless you’re planning on deploying enough Worker VMs to put undue strain on your vCenter (in which case deploying direct to host is preferable, obv) then you can leave this section and let HCIBench do it’s thing via vCenter.
What’s more, if you’re testing against vSAN you can tick EASY RUN and as if by magic, the next section of options will disappear! That’s because ‘EASY RUN’ will deploy a pre-defined built-in set of Worker VMs and parameters tailor-made specifically optimised for vSAN environments. Neat. If you’re not testing against vSAN or fancy playing with the options you can specify how many worker VMs, number of disks, size of disk and also link in an existing Vdbench parameter file if you’re lucky or savvy enough to have one to hand. Uber Neat. But because I’m testing vSAN here (and I’m extremely lazy) I’m using Easy Run.
Next, before running HCIBench for the first time in anger you’ll need to download Vdbench from the Oracle website, then Upload it to your Controller VM. Handily, there are buttons right there in the UI to do exactly that, so download it (you’ll need an Oracle account), then choose the downloaded file, then (you’ve guessed it) upload! Super Neat.
(HINT: If you want to download Vdbench then ACCEPT the license agreement on the Oracle website. Don’t DECLINE it, Oracle doesn’t appreciate such honesty and won’t let you download it, the swines)
Once that’s done you should be nearly good to go. Hit ‘Save Configuration’- now if you’re NOT choosing to deploy directly to hosts you may need to play around checking and un-checking the ‘Deploy on Hosts’ checkbox to get the host username and password fields to un-asterisk themselves and get the form to realise they aren’t required, otherwise you wont be able to save config, the validate will fail and you won’t be able to run the test!
Once you’ve saved, click ‘Validate’. This will sanity check all the details you’ve entered, as well as checking the environment to make sure it has all the required access as well as whether deploying the workers will kill your cluster or not, which is nice.
Once the validation completes you’ll get a summary of the results and hopefully, the all clear to kick off the test. All good?
Great! Check out the next and final post in this series which will run through the actual testing and the exciting bit- the results! Head to Part Three: Test to kick things off.