In a previous article, I suggested that hyperconverged is just a step on a path to simpler IT infrastructure. Before I look at the specific technology areas that I think will become simplified, I’d like to look at how the simplification works. I see simplification coming in two parts. The first is very advanced complexity, in which there is a lot of automated complexity that removes human decision-making. The second is making the required human activities as simple as possible.
Articles Tagged with DRS
By Greg Schulz, Server and StorageIO @storageio
Recently VMware announced version 5.0 of their vSphere virtualization solution with a theme of reducing complexity, enabling automation, and supporting scaling with confidence. As a key component for supporting cloud, virtual and dynamic infrastructure environments, vSphere V5.0 includes many storage related enhancements and new features.
I have been a big fan of VMware’s Distributed Resource Scheduler (DRS). VMware DRS is a service or feature that will dynamically allocate and balance computing resources across the hosts in a cluster. In all of the environments I have work with so far, DRS has been a fantastic tool for getting and maintaining that balance across all the hosts in a cluster. Recently though I have come across a limitation of VMware’s DRS that is worth mentioning.
DRS is one of the most useful and interesting features of VMware vSphere (to be more specific – feature of versions of vSphere from Enterprise on up). DRS is useful because it prevents workloads (VM’s) that are consuming more than the expected amount of resources, from potentially harming the performance of their neighbors in the same host with this “excess” resource consumption. DRS is interesting because the idea of dynamically balancing the load of a system in order to ensure the performance of the critical workloads running on that system is something that was taken for granted in the days of the mainframe, but has not as yet been well implemented on distributed Intel architecture systems.
With the release of vSphere 4.1 there have been some great enhancements that have been added with this release. In one of my earlier post I took a look at the vSphere 4.1 release of ESXi. This post I am going to take a look at vSphere 4.1 availability options and enhancements. So what has changed with this release? A maximum of 320 virtual machines per host has been firmly set. In vSphere 4.0 there were different VM/Host limitations for DRS as well as different rules for VMware HA. VMware has also raised the number of virtual machines that can be run in a single cluster from 1280 in 4.0 to 3000 in the vSphere 4.1 release. How do these improvements affect your upgrade planning?
I just finished writing all the content for my next book entitled VMware ESX and ESXi in the Enterprise: Planning Deployment of Virtualization Servers (2nd Edition) which continues the discussion on Dynamic Resource Load Balancing (DRLB). DRLB is the balancing of virtualized workloads across all hosts within a cluster of virtualization hosts without human intervention. This is the ultimate goal of automation with respect to virtualization and therefore the cloud. In effect, with DRLB the virtualization administrators job has been simplified to configuration and trouble shooting leaving the virtual environment to load balance work loads on its own.
This is a lofty goal, and we are not quite there yet, but we are further along than when I wrote VMware ESX Server in the Enterprise: Planning and Securing Virtualization Servers when ESX 3.0 first shipped. But what has really changed, as I talk to people, much of the automation is still done by hand coding specifics to all environments. I think we are close, and take some of the real innovations as writ and move on from there.