SRM 6.1 is a very exciting release and I think SPPGs are best part of it. What makes them so impactful is that SPPGs make it incredibly easy to set up true dynamic policy based protection for your virtual machines. In my “What’s New in SRM 6.1” post I covered SPPGs at a high level, in this post I want to dive into a lot more detail so let’s get to it.
Before we get started on SPPGs I want to make sure you are familiar with vSphere Storage Policy-Based Management. The central idea here is to better align storage consumer needs with storage provider capabilities. This makes it easier for users to consume storage by only needing to understand what capabilities they require rather than what capabilities each part of their storage provides. For more details on vSphere Storage Policy-Based Management check out this two part post.
If you need a refresher on Protection Groups and how they fit into SRM and Recovery Plans check out this post.
So why create a new type of protection group? Until now working with protection groups in SRM has been a mostly manual process utilizing the UI or in a limited fashion the API. This works well for smaller numbers of VMs and more static environments but becomes challenging quickly when we start dealing with larger numbers of VMs or things get more dynamic. Tieing Storage Policies together with Protection Groups provides a way to reduce opereration expenses for managing VM protection while increasing flexibility.
What is so special about SPPGs?
SPPGs make the protection of VMs and datastores simple and dynamic. Need to protect a VM? Associate it with a storage policy and place it onto compliant storage and it’s protected. This means that administrators can spend less time managing protection and end users can get their workloads protected faster.
What does it take to configure SPPGs?
To configure an SPPG requires a Storage Policy. Currently the only type of storage policy supported with SPPGs are tag based. The required steps are (more details on these processes are available here and here):
- Create Tag Category (only required if you don’t already have an existing tag category that you want to use)
- Create a Tag (only required if you don’t already have an existing datastore tag that you want to use)
- Tag replicated datastores using the above mentioned tag
- Create storage policy using the above mentioned tag
- Create SPPG associated with the above storage policy
- Associate VM(s) with storage policy and place onto compliant storage. Placing them onto compliant storage can be done either during provisioning or storage migration
What is the same and different between SPPGs and the other protection group types?
First, what is different?
- VMs and datastores are dynamically protected and unprotected when using SPPGs
- All new features of SRM 6.1 are enabled by SPPGs. To use stretched storage and enhanced NSX integration requires using SPPGs
- SPPGs do not currently support vSphere Replication
- It is not possible to create per-VM overrides of inventory mappings for VMs protected by SPPGs
- SPPGs don’t support protecting VMs with non-replicated disks or RDMs or templates
- SPPGs can’t be in the same recovery plan as ABR or VR based protection groups
And what do they have in common:
- Support for array-based replication
- All recovery workflows: test, cleanup, failover (DR & planned migration) & reprotect all function the same. They do have additional steps but the functionality is the same.
- Priority tiers, VM dependencies, IP customization, scripts and callouts all function the same
- Inventory mappings work the same as without SPPGs. They actually take on an increased importance because
You can read more about SPPGs in the SRM 6.1 Administration Guide. If you want a deep-dive on SPPGs including a number of demos, check out this session I did with the incredible Aleksey Pershin “STO6137 – Site Recovery Manager and Policy Based DR Deep Dive” from VMworld 2015.
