Storage Policy-Based Management with vSphere 6.0
I've been following the vSphere 6.0 release process for what seems like forever, but I still need to make sure I understand a few of the key concepts before upgrading my lab environments. In particular, I need a better grasp of a few of the new storage concepts. It's pretty clear there are key changes to storage as we know it, and storage policy-based profile management (SPBM) is what I'll look at in this post.
SPBM becomes increasingly important as new vSphere storage features are considered and implemented. This is applicable in particular to VMware Virtual SAN and vSphere Virtual Volumes (VVOLs), but it also applies to traditional vSphere storage options. The concept of SPBM isn't exactly new, but with vSphere 6.0 it's become much more important.
I frequently look at new features and ask myself, What's the biggest problem this will solve? From my research and limited lab work, these are the top benefits SPBM brings:
- Make storage arrays VM-aware (specifically for VVOLs)
- Common management across storage tiers
- More efficient VM tasks such as clones and snapshots
- Changes in storage policy may not necessarily mean it has to move on the back-end
- It forces us to look closer at our storage and its requirements
This list is a pragmatic or even possibly pessimistic approach (remember, I'm a grumpy evangelist by day) to these new features. But the rubber meets the road on the last point. I can't go on any more not really knowing what's going on in the datacenter, and what type of storage is needed from my VMs. There was a day when free space was the only consideration. Then datastore latency was the thing to watch. Then IOPs on VMs were the sharpshooter's tool. When you put it all together now, you're going to need policies and centralized configuration to do it right. The point is that having features like SPBM is great; but it still doesn't solve the problem of not having enough of the right kind of storage.
The crucial aspect of SPBM is ensuring that any key infrastructure changes adhere to policy.This is especially important when you consider ways that VMs can move around or be recreated. One way is storage Distributed Resource Scheduler (DRS), which can automatically move a VM to a new storage resource based on performance measurements.
Another consideration is the process of backing up and then restoring a VM that may have been accidentally deleted. When a storage policy is in place, these events need to be considered, as the VM may move around. Specifically, consider the policies you make and ensure they'll be enforceable for these types of events. Otherwise, why bother setting up storage policies?
Of course, there are always situations where you might need to violate performance or availability policies; but keep in mind in that you might need to have storage resources in place to satisfy the VM's storage policy. Figure 1 shows what can happen.
[Click on image for larger view.]
Figure 1. This isn't what you want from storage policy-based profile management.
I'm just starting to upgrade my environments to vSphere 6.0, and SPBM will be part of the journey. Even if I don't migrate to VMware Virtual SAN or start using VVOLs, SPBM can apply to the storage practices I've used previously, and provide that additional level of insight.
Have you started playing with SPBM yet? Share your experiences, tips and tricks below.
Posted by Rick Vanover on 04/28/2015 at 7:10 AM