Server Cluster patching with Opalis – Part 1

I’m using this post to document my experiments with Opalis.  One of the things I’ve been thinking about is using Opalis to orchestrate complicated patching scenarios that have traditionally been difficult to do with tools like System Center Configuration Manager alone (or at least would have involved lots of scripting).  For example patching a cluster would normally involve some manual tasks like failing over the active node before patching, then patching the offline nodes and cycling through the cluster.

In this post I’m going to document the initial setup of the policy (or at least, what I think it’s going to look like at this point).

The first thing that I’m going to set up is the different sets of policies – I’ve divided them into four parts:

1. Policy Initiation (more on this later) and looping

2. Node pre-activity (for instance – in a Hyper-V node putting the node into maintenance mode)

3. The actual patching

4. Node post-activity (confirming the node has returned to service successfully)

I’ll create four empty policies – you can see the policy names in the screenshot below:

In that screenshot you can also see the first steps I’ve set up.  I’m using a “Read Line” task to read a text file containing my cluster node names, although in the future I’ll modify this to execute powershell against the cluster to get the node names.  This task then passes into a Trigger Policy task which is used to start the next step in the policy chain.

There is one key configuration to change on the “Trigger Policy” step which I’ve highlighted below.  The “Wait for completion” option will allow the following steps to be executed sequentially for each node in the cluster, and the next node will only start once the previous node has completely finished.

The other thing I’m going to do is setup a custom start action in policies 2-4 and define an input parameter for each of “Computer Name” – there may be other parameters to pass in later, but at this point I’ll keep it simple (and I expect I’ll discover the other things I need as I develop this further).

Then in policies 1-3 I set up a “Trigger Policy” action as you can see in the first screenshot – this calls the next policy in line and passes the Computer Name as the parameter.  You can see this in the second screenshot – the parameter is defined as Computer Name, and in this instance I’ve used the “Subscribe to published data” option to subscribe to information read in from the text file.  In subsequent policies I’ll pass that parameter between policies.

That’s the start of my cluster patching policy, stay tuned as I develop this further.

Comments

• Anonymous
  January 01, 2003
  Look forward to this set of posts...Thx, John Bradshaw