SANsymphony-V v10 - Hands-on experience part III - Improved vDisk rebalancing

User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive
Published: Monday, 16 June 2014 12:49

As announced in part II of this hands-on experience serie we will now have a look at the new improved pool rebalancing mechanism. As the word "improved" suggests, this feature at the bottomline isn't new to v10, it's simply imroved. Wht is this improvement? To understand this you have to keep in mind what prior v10 installations do while rebalancing. The old rebalancing mechanism only rebalance data across all disks in a pool in regards to the amount of data located on each disk. So e.g. if you have a pool with 10 disks and the total amount of data is 100GB, there is 10GB data per disk. If you add another disk to the pool there will be ~9GB per disk at the end. It doesn't matter how frequently the blocks are accessed so it COULD happen that all hot blocks are located on 2-3 disks and the other disks only have cold blocks. This indeed isn't a very intelligent rebalancing but can already do a bit of "dumb" load balancing.

The new algorithm takes these hot and cold data information into account and will rebalance the data not only equaly across all disks but also takes care that hot blogs are spread over all disks. This way, the performance gain should be definetly higher than with the old version. BTW, it works on a per-vdisk-base.

This by the way could lead to an unbalanced setup regading data on the disks but taht's not that important as you do the rebalancing to get more performance from the disk pool and not to see the data perfectly balanced across all disks in the pool.

Here are some pictures to help understand the new technique.

First we have a look at the allocation map of our vdisk in the pool. As you can see all data is evenly spread across all disks.

As you can see there are only a few hot blocks on the vdisk and all data is equal on all disk.

If you now add another physical disk to the pool, the new algorithm starts working.

First the new disk has to be reclaimed/initialized and therefore is currently all yellow.

As the reclamation frees up available space on the disk, the algorithm immediately takes SAUs from another disk and transfers them to the new disk.

You can see this as the last disk has some yellow bars and the first disk gets blue at the left side. After a few minutes, the allocation tab lokks like this:

You can see that only data from the last disk is being transferred, the other disks stay untouched. In this moment we have a balanced performance configuration but an imbalanced allocation configuration.

After all reclamation and rebalancing work is done, the allocation map now looks "imbalanced" but regarding hot blocks it is fully optimized.

Pool balancing by the way is nothing you can activate or deactive, nor has to be licensed separately. It is included in every base license and activated all the time, so regardless what vL edition you use you can profit from this new feature.

In part IV we will focus on write-aware tiering.