There are a lot of new features to vSphere 5, and for some reason I gravitate most heavily towards Storage Distributed Resource Scheduler (DRS), which will be further written in this post as SDRS. At first blush, most people I talk to blanch a bit when thinking of vCenter moving around files on datastores, and if it were implemented in vSphere 4 I would agree that it would not be something I would be turning to “fully automated” in the short term. However, vSphere 5 grew up a bit, went to Storage school, got certified in the fundamentals (latency, I/O, and capacity), and truly does deserve to be a part of managing storage. I won’t delve deep into how exactly SDRS works as there are plenty of articles that do a great job of that already, but will instead focus on the administration side of things.
So, with that, let’s take a look into how Datastore Clusters will improve your daily operations in regards to storage.
The Datastore Cluster Defined
The gist is this: you can logically arrange datastores into clusters, and vCenter will keep track of vital statistics for each datastore in the cluster. It understands utilized space and I/O latency, and based on user defined parameters, can shift workloads around to stay within tolerance, much like with CPU and memory. vCenter also tracks the largest contiguous free space (which datastore has the most open space) and the type of datastores (VMFS, NFS). These are all big improvements over the previous generation of vSphere.
Let’s take a look at my lab datastore cluster. This cluster includes a pair of mis-matched SCSI attached storage from an MSA box. I’ve left the thresholds at default, which is 80% space and 15 ms of I/O latency. I’ve also highlighted the general details, such as used, free, and largest free space, along with the type – in this case, VMFS 5.
Placing VMs
One great time saver is that I can point a new VM to the datastore cluster and vCenter will then decide where to put the disk based on free space and I/O latency. I don’t have to hunt around for a LUN / Volume. In my lab example, this doesn’t really save much time as there are only 2 LUNs. However, imagine if you had 10 (or more) LUNs that could be candidates for a VM.
Dealing With LUN Sizing
Management of storage has traditionally had a pretty reasonable impact to sizing. It would be very difficult to handle a bunch of 250GB datastores, as you would need a ton of them to hold a lot of VMs and would most likely hit the storage maximums (4.1 = 64 NFS exports and 256 LUNs). While I wouldn’t really advise 250GB LUNs, you certainly could micro-divide up your storage and then pool it together using SDRS if that makes sense for your environment.
Scheduling SDRS
SDRS also has a scheduling feature built in. You can pick specific times and days of the week for custom profiles to be applied. In my picture below, I have a SDRS running two custom schedules during weekday and weekend hours, then return to the previous default values. I’d imagine that like me, you probably have regular flows of load on your VM environment. This will allow you to choose when to be aggressive or conservative with SDRS without having to tune it for a worst case scenario only.
Example: Imagine if you have a planned defrag or virus scan “storm” for early Sunday morning. You can schedule SDRS to not care about this and keep workloads very stationary during the time period.
Keeping Planned VM I/O Separate
SDRS can also maintain VM or VMDK anti-affinity rules. As an example in the lab picture below, I’ve marked my two VMware View base images to remain apart. The ideas here are endless, but suffice to say you can split up VMs that have similar I/O patterns.
Thoughts
The bottom line is that the new SDRS feature saves a lot of time and really empowers you in the arena of storage. No more pulling reports or toggling to the performance charts necessary. I’m a big fan.
