One of the new features in System Center Configuration Manager (SCCM) 2016 Technical Preview 3 is the “Service A Server Cluster” feature. Since I’ve done some work with SCVMM’s Cluster Aware Updating recently, I wanted to compare these 2 features.
SCVMM’s Cluster Aware Updating
First let’s look at the feature that has been available since System Center 2012.
In the SCVMM console, navigate to Fabric > Servers, and click on the Compliance button in the top menu. As you can see in this example, one of the clusters is not compliant.
If you right-click on the cluster, you can select Compliance Properties to see which updates are missing, and from which cluster nodes.
On the Compliance Properties dialog, you can select to install all missing updates, or only a specific set.
Also, you can create an Exception so that the specific update(s) will not be installed on that cluster/node, etc.
When you create an Exception, the update will still show in the list of the Compliance Properties; but will be identified as Exempt.
You can easily remove an exemption by selecting it and clicking the Remove button. However, when you do, the specific update(s) will show a state of “Unknown”. You will need to re-scan the system against the Compliance Baseline before it will be identified as being Compliant or Non Compliant.
Right-click on the Cluster, choose Remediate from the context menu.
On the Update Remediation screen, you can specify which updates to install. Also notice at the bottom that you can choose to not restart the server after, and for Hyper-V clusters, perform either a Live Migration or Save State of the VMs.
The nice thing about patching feature in SCVMM is that, in the case of a Hyper-V cluster, it can migrate VMs from one host to another. Gone are the days of needing to manually migrate all the VMs from one host, patch it, reboot, possibly check for missed patches a second time, migrate the VMs back, and then start on the second node in the cluster.
But what if you’re not patching a Hyper-V cluster? Then what? Well, that’s where the new SCCM Service A Server Cluster patching feature comes in.
SCCM’s Service A Server Cluster
Now let’s take a look at the new feature in SCCM 2016 TP3.
Per the TechNet article: “You can now create a collection that contains servers in a cluster, and then configure the cluster settings to use when you deploy updates to the cluster. You can control the percentage of servers that are online at any given time, as well as to configure pre-deployment and post-deployment PowerShell scripts to run custom actions.”
So to start testing this, I created a Collection and added the 2 Cluster Nodes.
Once the Collection is created, right-click on it and choose Properties. You will notice a new option in for form of a checkbox labelled “All devices are part of the same server cluster”.
If you select this checkbox, the Settings button will become enabled. Clicking Settings will open the Cluster Settings dialog. In here we can specify the percentage of the cluster that can go offline while applying patches.
You also see that you can provide a Node Drain/Resume script as part of the process.
Unfortunately I couldn’t fully test this feature in my lab environment. But it is interesting to see SCCM being able to balance updates across a cluster.
As it comes down to it, you could use both of these technologies for patching/updating clusters. However, keep a few things in mind. For example, if you want to strictly use SCCM to patch a Hyper-V cluster, then you’ll have to factor in proper Hyper-V host configuration, since SCCM won’t live migrate VMs off the of host gracefully. Instead, the shutdown/reboot action on the Host “should” fail any virtual machines over, but it’s not as reassuring (at least in my mind).
Also, if you have many guest-based clusters in your environment, then you will need to create an SCCM Collection for each cluster. Remember, the Collection properties settings says “All devices are part of the same server cluster”. Therefore, you can’t just put “all” your guest-cluster VMs into one Collection.
Alternatively, some organizations opt to take an “A and B” approach to guest-based cluster patching. For example, all of the even-numbered servers are patched on Saturday, while all of the odd-numbered servers are patched on Sunday (of course, subjective to your naming convention).
Ultimately though, I would still opt to using SCVMM for Host-based cluster patching, especially Hyper-V, since it will live migrate the guests to another Host before it starts patching; versus SCCM which will start patching (factoring in deadlines, maintenance windows, etc.) and then the host reboot will force the live migration.
So that completes our look and comparison between the VMM cluster aware updating, and the new SCCM 2016 TP3 “Service A Server Cluster” feature.