Thus far we’ve been using a single iWorkflow platform. However, in a production environment you will want to implement a higher-level of fault tolerance than a single instance can provide. So, in this episode we will go through the steps to configure an iWorkflow cluster.
NOTE: this episode assumes you have been through the licensing and initial setup of you iWorkflow platforms. If you missed that part, read iWorkflow 101 (episode #2) - Install and Setup.
The recommended deployment is to have three iWorkflow platforms in a cluster. Ideally, each of these will reside on a different Virtual Host, with each host connected to separate power supplies.
The environment
To identify each of the devices, we’ll change our original iWorkflow platform “iworkflow.n8lab.local" to “iworkflow1.n8lab.local” and the two newly licensed platforms will be named "iworkflow2.n8lab.local" and "iworkflow3.n8lab.local”. The new environment will look like this:
The iWorkflow platforms to form the cluster have the following IP Addresses:
- iWorkflow1.n8lab.local - 10.128.1.130
- iWorkflow2.n8lab.local - 10.128.1.131
- iWorkflow3.n8lab.local - 10.128.1.132
Cluster Setup
First we login to iworkflow1.n8lab.local platforms and navigate to the “System” section:
Within the System section you’ll note that the first tab is for iWorkflow Cluster configuration. There are two entires already in this tab: “High Availability Cluster” and “localhost” (the iWorkflow you are currently logged in to).
Double clicking on the ‘localhost’ entry will show you properties of this iWorkflow platform:
Clicking on “High Availability Cluster” will show you properties that effect the entire cluster. Within “High Availability Cluster" there are three sections: Properties, Services, and Auth Provider. The iWorkflow Cluster Properties allowed you to set login related messaging:
The iWorkflow Cluster Services are the settings prompted during the initial setup wizard (NOTE: don’t forget to set your NTP server):
iWorkflow Cluster Auth Provider:
To build a cluster you must add another iWorkflow platform to the list for “localhost” to synchronize with. This is performed by clicking the + on the iWorkflow Cluster tab. You will then be presented with the “New iWorkflow Cluster Member” form:
Here’s the Cluster setup process in video format:
Important
In the 301 series we’re going to write some Node.js micro-services that will live on the iWorkflow platform. These things are seriously rad! They live here: "/usr/share/rest/node/src”. They are replicated across the cluster as part of the synchronization process! #win
That’s clustering covered. Now we move on to the iWorkflow backup.
iWorkflow Backup
Some things to know about the iWorkflow backup feature.
What does it backup?
The iWorkflow platform does backups of iWorkflow. It doesn’t do backup’s of the BIG-IP devices. Why? We’re really targeting orchestrated environments where the orchestrators re-deployment of an environment is what recovers from disaster instead of a backup & restore procedure. Thinks in terms of the ability to have an architecture ‘reset’ workflow that can redeploy the data center!
Standalone
The iWorkflow Backup feature takes a full snapshot (no incremental) of the iWorkflow configuration. This can be performed as a one-off or setup as a recurring event. Backups are performed by an Administrator role and are not visible to iWorkflow Tenants.
Restoring a configuration in a cluster
I you require to restore a backup within an iWorkflow Cluster, you should first Break the cluster. Next restore the backup on one of the iWorkflow platforms. Then, on that same iWorkflow platform with the newly restored configuration, add the remaining iWorkflows so that they can consume the restored configuration.
Following is a video overview of the backup feature:
Conclusion
Use the iWorkflow Clustering feature. Don’t put all the iWorkflow platform VM’s on the same host serviced by the same power supply.
Backup your stuff!
Live long and prosper.