Before you begin reading too far, I am not suggesting that you unbundle your VMware DRS cluster when you install SHO to maximize virtualization optimization. DRS is still required. It is just that having SHO's analysis/ recommendations works in tandem with DRS, making the whole exercise more worthwhile.
What is HP SHO? For those who don’t know, HP’s Service Health Optimizer helps to optimize virtual environments. It does this via the identification of wastage, right-sizing of VMs and placement suggestion for your virtual and physical workloads. In a way, SHO works like a disk defragmentation tool. Defragmentation looks for small, non-contiguous free spaces in your disk/partition and realigns these into meaningful larger blocks—so you can derive better value from the same disk and can get more space. SHO’s optimization does the same thing—if you look at files on the disk as virtual machines in your private cloud or VMware/Hyper-V server farms and replace the idea of your 300-gb disk, with server capacity (CPU, memory, storage).
What is VMware Distributed Resource Scheduling? It is a way to ensure that all VMs running within in a VMware cluster get their expected resources during their runtime. To allow this, a bit of load balancing is also done so that VMs with current increased needs are moved (using a mechanism called vMotion™) to less busy hosts in the cluster.
The differences between SHO and VMware DRS
Apart from the fact that both SHO and DRS eventually offer recommendations for placing VMs on a ‘right’ host in the cluster, there is not much similarity in the process adopted here or in the end-goal here. DRS is more for an immediate response based on short-term data and expected utilization levels to maintain load balance in a VMware cluster. SHO is based on long-term trend analysis and the goal is to derive more value from money spent/to be spent on the hardware. Here are some additional differences:
DRS logic checks every five minutes, wherein it looks at current VM’s expected needs and balances out with other VMs on other hosts. SHO makes a recommendation for VM fitment based on multiple VMs resource usage trends, and avoids getting into situations where multiple VMs may peak at same time.
DRS uses vMotion to move around VMs, in response to high-resource usage situations on one host resulting in imbalance in the cluster—vMotion basically seeks to restore the balance. SHO’s recommendations already avoid this scenario. SHO identifies VM workload trends that go well with one another and do not cause contention to occur and provides fitment suggestion based on this analysis. For example, SHO would recommend a VM that is busy during day and a VM that is busy during the off-hours to be placed together on a same box so these two workloads do not max CPU usage at the same times.
DRS only uses VMs reservation to determine best place to start a VM. SHO uses trend data collected for several days, weeks and years for threshold analysis to suggest where to place a VM. With days to threshold analysis, SHO predicts number of days by which the VM or host would hit a high utilization level, and factors this in the computation for suggesting VM placement. The idea is to maximize DTT so that the critical situation is farthest in time from today.
DRS takes new hosts added into cluster into account, as well as hosts being put into maintenance mode— SHO will not immediately understand configuration changes to cluster but will understand this in the due course of time. Do note that SHO’s forecasting and ‘what-if’ modeling capabilities can actually be put to the test in order to determine the right configuration of new host to be added in a cluster, based on current and future needs of VMs, expansion plans.
DRS in conjunction with DPM (VMware Distributed Power Management) will turn off hosts when excess capacity is available, in addition to what the resource needs – via DPM. SHO has the ability to determine if a cluster has more hosts than required and make a recommendation for fitment/right-sizing of VMs such that one or more hosts may be removed entirely from the cluster. This can also be fine-tuned; keeping future needs in mind via headroom allocation.
DRS does not keep in mind CPU-ready utilization counter. However, with SHO’s right-sizing ready utilization is already brought down, if such ready util is result of an over-allocation of CPUs to idle VMs. Here SHO’s optimization helps to reduce the ready times and right-fitment of VM to hardware—taking care of balance.
DRS takes into account affinity rules and resource pool entitlements—SHO does not. However we need to be careful to not misread the message here—SHO is a long-term optimization tool and must be used that way. SHO’s recommendations should ideally be used to set the affinity rules and resource pool entitlements.
DRS is not storage-aware, until storage DRS/svMotion comes into the picture. Here again SHO makes recommendations based on long-term analysis of storage usage and IOPS for vDisk placement. SHO can provide recommendation for the correct placement of new VMs (a set of new VMs required to be created for next quarter’s business needs, say). DRS cannot be used for this.
Finally, in a word, DRS is tactical, whereas SHO is long-term/strategic*.
Some philosophy before I close—there’s also the interesting argument about the low price of server hardware/blades. The argument is: why not just add servers to the DRS cluster instead of purchasing, running and maintaining a capacity management software and database? The reasoning is somewhat short-sighted because adding hardware usually would not improve performance of VMs. New server hardware purchased to augment capacity on a VMware cluster would not be used optimally either.
It is important to find out first how much capacity is really going unused in the cluster, and then try to reclaim capacity within—before trying to scale up or scale out. Next, the benefits of doing trend analysis far outweigh the xl-sheet type approach where only the peak value of VM usage is taken into account to predict max capacity needs.
For more information and findings, do try HP’s SHO (http://www.hp.com/go/SHO). Don’t miss the point about how HP SHO can actually work with BSM and help to optimize your business service infrastructure in the similar manner.
* DRS uses the last five minutes of data, whereas SHO uses all historical data (up to several weeks, months and years before current date).
Ramkumar Devanathan (twitter: @rdevanathan) is Product Manager for HPE Cloud Optimizer (formerly vPV). He was previously a member of the IOM-Customer Assist Team (CAT) providing technical assistance to HP Software pre-sales and support teams with Operations Management products including vPV, SHO, VISPI. He has experience of more than 14 years in this product line, working in various roles ranging from developer to product architect.