Virtual Wood Blog

VMware, vSphere, ESX, ESXi, PowerCLi and everything else

Virtual Wood Blog - VMware, vSphere, ESX, ESXi, PowerCLi and everything else

Tag Archives: Storage

How to reverse engineer IOPS

In a situation where the IOPS cannot be gathered from the physical SAN storage due to either limitations or access. The IOPS is required to see if the current solution will run the workload once it has been virtualised and if the hardware it will end up living on has the capacity.

The calculation is (MBps / Block size) * 1024.

To use the calculation the block size of the SAN needs to be understood and in the following it is assumed that a 64k block size has been used.

So… We have run PerfMon for 24 hours over the weekend and the same in the week. This is against the virtual machine or physical that is to be moved. I this case it is a SQL servers to give us the peak data throughput. Using PerfMon will allow us to see the average and peak.

The findings are listed below:

  • Physical – Read 282 MBps
  • Physical– Write 175 MBps
  • Virtual – Read 495 MBps
  • Virtual – Write 326 MBps

From these I can work out the I/O

  • Physical – Read (282 / 64) * 1024 = 4512
  • Physical – Write (175 / 64) * 1024 = 2800
  • Virtual – Read (495 / 64) *1024 = 7943
  • Virtual – Write (326 / 64) * 1024 = 5216

Now, with the virtual server it is known to have some caching that is involved, and that the actual data being written to the disk is 2900 IOPS Read and 1600 Write (Reported from the SAN console).

Which roughly translates to 36% of the 7943 is actual disk I/O and 64% is cached for reads and 31% is actual disk I/O and 69% is cached for writes.

Taking these numbers, I can apply the same percentages to the physical server

Reads total being 4512 IOPS, these are then broken down into 1624 IOPS actual disk I/O and 2888 IOPS cached. Writes total being 2800 IOPS, broken down to 868 IOPS actual disk I/O and 1932 IOPS cached.

Physical server would need 2492 total IOPS

I hope this helps people out when you are not able to run any other tool to gather the data required.

By Paul Wood

Configure a LAB with simple PowerCLi commands Part 3

This blog will carry on from part 2 adding more simple functionality to the LAB being created.

In this blog we will look at adding iSCSI storage to the LAB through PowerCLi. To do this the LAB will need storage of which many are available on the internet (this can be real or virtual). The script is designed to allow the addition of a datastore with a specific ip address and name. This has not been tested in a situation where multiple iSCSI targets could reply.

This is not as hard as it may seem and with the aid of using a script every host can be configured with the same datastore in one simple script. Scripts take away human error and misconfiguration making the life of an administrator that much easier. The vSphere PowerCLI Administration Guide is a great place to start for simple scripts to help in the day to day operation of a virtual infrastructure. The following has its base taken from this guide but converted to allow the configuration of all the hosts through one script.

Below is the complete script which I will break down underneath.

<br />
  $hosts = Get-VMHost<br />
  $name = $hosts</p>
<p>Foreach ($name in $hosts) {<br />
  Get-VMHostStorage $name | Set-VMHostStorage -SoftwareIScsiEnabled $true<br />
  $iscsiHba = Get-VMHostHba -Type iScsi<br />
  $iscsiHba | New-IScsiHbaTarget -Address 10.10.1.10 -Type Send<br />
  Get-VMHostStorage $name -RescanAllHba<br />
  $lunPath = Get-ScsiLun -VMHost $name -CanonicalName ($iscsiHba.Device + &quot;*&quot;) | Get-ScsiLunPath<br />
  New-Datastore -Vmfs -VMHost $name -Path $lunpath.LunPath -Name iSCSI<br />
  }<br />

At the start the following two lines are carried out. This gets all the hosts that are managed by the current virtual center and stores them in $host. This information is then stored in $name to be used during the rest of the script

<br />
  $hosts = Get-VMHost<br />
  $name = $hosts<br />

As we want this script to run against every host that is stored in $name a Foreach is being used. This allows the script to run through each host until each is completed. The next line is retrieving the host storages on the host and then enabling the iSCSI adapter

<br />
  Get-VMHostStorage $name | Set-VMHostStorage -SoftwareIScsiEnabled $true<br />

The next reads in the HBA data but only for iSCSI and stores it in $iscsiHba

<br />
  $iscsiHba = Get-VMHostHba -Type iScsi<br />

The $iscsiHba information is then used in the following line to setup a new dynamic target with a specific ip address (using the default 3260 port. If another is needed then add –Port xxxx)

<br />
  $iscsiHba | New-IScsiHbaTarget -Address 10.10.1.10 -Type Send<br />

The HBA needs to be rescanned now as it would if this was being done manually so the next line does exactly that

<br />
  Get-VMHostStorage $name -RescanAllHba<br />

The next line is getting the canonical name of the iSCSi lun and storing this information in $lunPath

<br />
  $lunPath = Get-ScsiLun -VMHost $name -CanonicalName ($iscsiHba.Device + &quot;*&quot;) | Get-ScsiLunPath<br />

The last line adds the datastore that has been found during the above process. It will add a Vmfs file system to a host using the canonical name the previous line obtained and give the datastore a name if iSCSI (If the datastore with the name specified already exists then this datastore is just added to the host and can be used. I have not tested with a datastore that is not formatted to confirm that it would be formatted, named and added)

<br />
  New-Datastore -Vmfs -VMHost $name -Path $lunpath.LunPath -Name iSCSI<br />

By Paul Wood