System Center Configuration Manager and Cluster Aware Updating
Microsoft have created a new feature in Windows Server 2012 for updating clusters called Cluster Aware Updating.
The premise is simple: it coordinates updating your clusters for you i,e. moves roles to other nodes, updates the node, moves roles back, updates the other node, puts everything back in its place – job done.
It’s great if you’re not using Microsoft flag ship configuration management application – System Center Configuration Manager (ConfigMgr)…
If you’ve just using WSUS for updates then it’s relatively straight forward to get up and running.
If you’re using ConfigMgr you need a hell of a lot more software to make this work and there are no straight forward tick boxes to make this work. Helpfully Neil Patterson has created some runbooks for System Center Orchestrator to make this all work.
So what have I done?
I’m yet to roll out all of the System Center suite so have I implemented a separate WSUS environment from my ConfigMgr environment? No
All my clustered servers are imaginatively titled. For example my 2 node file cluster is called HQ-File, made up of HQ-File1 and HQ-File2… All other clusters are the same, Print (Print1, Print2), HQ-SCSQL (HQ-SCSQL1, HQ-SCSQL2) etc.
In ConfigMgr I’ve created three query based collections based on my “Windows Server 2102 Servers – Non-Hyper-V Hosts” device collection.
- Cluster Servers 1: the criteria is very simple:
- System Resource.Name is like “%1” AND
- Services.Name is equal to “ClusSvc” AND
- Services.Start Mode is equal to “Auto”
- Limiting collection: “Windows Server 2102 Servers – Non-Hyper-V Hosts” (prevents hyper-v hosts being included – they’re special and I patch those manually at the moment)
- Cluster Servers 2: the same as above except:
- System Resource.Name is like “%2” AND
- Windows 2012 Non-Clustered Servers:
- Include Collection “Windows Server 2102 Servers – Non-Hyper-V Hosts”
- Exclude collection “Cluster Servers 1”
- Exclude collection “Cluster Servers 2”
Net result is 3 collections to deploy Windows Updates to. I have other collections for application updates like SQL, Exchange, etc. but that is outside this post. I’ll go through those another day.
So when updates are released I generally deploy the updates in this order:
- “Windows 2012 Non-Clustered Servers” to be installed on day X by B time (very much out of hours due to no redundancy on the services those installs are providing)
- “Cluster Servers 1” to installed on day X+1 by C time (this is usually sometime in business hours – shock – so I can remediate if necessary before the 2nd cluster group updates)
- “Cluster Servers 2” to installed on day X+2 by C time (this is usually sometime in business hours – shock – so I can remediate if necessary)
Whilst this isn’t necessarily the best way of doing this it works for me (I usually end up watching/running the installations to make sure it all goes well – unless they’re server core).
This results in all the servers getting updated as required. There is a risk that between patching Cluster Servers 1 and Cluster Servers 2 the roles move around and bad things happen… So far so good.
When it comes to server application updates that is an entirely different issue. Moving databases between SQL 2012 SP1 and SQL 2012, for example, is a bad plan and will probably end up killing your database! Same goes for Exchange. Updating server applications is usually more “dangerous” than Windows updates when it comes to application stability!