Harlem shuffle with VMDKs

Today I was brainstorming with Arnim van Lieshout about how to place all VMDKs on our LUNs, because right now we are facing two problems in our environment:

  • No balancing of IO workloads across LUNs
  • VMDKs often don’t fit nicely into the remaining LUNs space, so we lose a lot of GBs to unused space.

We tried coming up with an algorithm that would deploy the VMDKs over our LUNs based on IO and VMDK size. What we have now is purely an algorithm, we have no idea yet how to do this, but I bet there are others that can make nice tools around this :-)

First we set the following requirements:

  • Each LUN will be equal of size, in our environment this is 500GB.
  • Balancing of disk paths is out of scope, we expect this to be implemented
  • We try to fill the LUNs as much as possible, but leave 50GB free space for snapshots etc.

What we thought of was the following (example is of on of our clusters):

  • Have a list of all VMs (300) with their I/O average of let’s say one week, sorted by highest IO on top.
  • Take the number of LUNs (37) and then split the VM list into sections equal to the number of LUNs. In other words, we would get 300 / 37 = 8,1 = 9 sections of VMs. First section would then hold to top IO consumers.
  • Take the total number of  average I/O and divide it by the number of LUNs to get an average IO per LUN.

Now to divide the VMs over the LUNs we would follow these steps:

  • Take the first (or later on the next) section of VMs and place first VM of that section on LUN1, next VM on LUN2, next on LUN3, etc.
  • When placing a VM on a LUN check the following: Do we still meet minimal free space requirement and are we still below the max I/O we would allow on a single LUN (= average I/O per LUN + x%)
  • For the next run of placing VMs, start placing on LUNs in reverse order. In our example VM-37 would be on LUN 37 and VM-38 would also be on LUN37,  LUN36 would hold VM-36 and VM-39.
  • Then when that section is complete, you start with section 3 top down again, etc, etc.

These are our initial  thoughts on how to find a combination between spreading I/O load without wasting too much disk space. We would like to hear your thoughts on this, so please let us know in the comments field.

Arnim van Lieshout & Gabrie van Zanten

Edit: Also read Arnim’s post about this:   http://www.van-lieshout.com/2009/02/vmware-storage-sudoku/