In an ideal situation it probably shouldn’t matter which node of a failover cluster your resources and roles are hosted on, but the real world is often far from ideal. This post will talk through how we can record the current owner nodes and then use Pester to ensure we’re in the ideal configuration. This could be useful post maintenance activities or as a daily check to ensure things are as you expect.
Step 1 – Store the current resource owners
If we are going to test that we’re in our expected configuration, we need to record what that configuration looks like. I have a hard coded list of cluster names. However, you could easily pull them from a text file, or a database. Once we have the list of clusters we can use
Get-ClusterGroup to determine the cluster roles and their current owners.
To persist this owner information I’m using
ConvertTo-Json and then outputting it to a file. This creates a file that can easily be read back into PowerShell as an object using
It’s also probably worth mentioning that this ideal configuration can be stored in source control. That’ll keep the file safe and you can easily keep track of any changes that are made to it.
You’ll notice I’m creating a
PSCustomObject to pipe to the
ConvertTo-Json. Without that, the object from
Get-ClusterGroup is exploded, with all properties, including nested properties exported into the JSON output. This is more than we need, and I think there is some value in having a clear concise output file.
I’m also using
-as [string] on the state property. PowerShell automatically translates the real state to a text value when outputted as it’s an enumeration type – but when you pipe that to
ConvertTo-Json you get the raw integer value.
Step 2 – Test the current configuration
When it’s time to test our configuration we can read in our ClusterGroupOwners.json and then convert it back to a PowerShell object using
ConvertFrom-Json. Now we have a PowerShell object of our ideal configuration we can loop through each cluster, checking the current group owners using
Get-ClusterGroup again. This current state can then be matched against the desired configuration.
I am using a pretty simple pester test for this work, saving it as Check-ClusterOwners.tests.ps1.
We’ll call this test using
If everything is as expected we’ll get output similar to this for each cluster – depending on the resources you have set up in your cluster.
This method of testing can be useful to ensure you’re in the ideal state in many scenarios. For example you could store any databases in your estate that are not ‘online’ and then confirm post reboots/patching that all the databases are in the expected state.