In March 2014, we released the IBM Workload Automation as a service (WAaaS) offering, hosted on the public Softlayer cloud. One of the major characteristics of this offering is the automated delivery process that allows us to deploy the latest available product features, controlling a continuously testing and code promotion flow (QA -> Staging -> Production).
In this blog I want to show you how we provide continuity of service to our customers.
Using IBM UrbanCode Deploy to implement our delivery process we built, in the SoftLayer cloud environment, an upgrade process that guarantee the high availability of our offering.
The IBM Workload Automation environment is composed of many sub-environments, which are called offering instances. Each offering instance is composed of two nodes that are virtual images of an operating system: a primary node and a secondary node.Workload Automation components are installed on both the machines to provide high availability.
When you design an upgrade process, consider the following constraints:
To avoid interruption of service, the upgrade of the components on the primary and secondary nodes cannot occur simultaneously.
The update operations must run on the entire environment.
They must synchronize the primary and the secondary node of the same sub environment.
Given Constraint 1, the upgrade process cannot be performed in a single step.
In this example, it occurs in four phases:
During this phase all secondary nodes are upgraded. Because the secondary nodes are inactive (the primary node is the active node), the upgrade operation does not create a service interruption.
During this phase, the primary role is switched from the primary nodes to the secondary nodes. This switch causes the secondary nodes to become the active node.
During this phase all the primary nodes are upgraded. After Phase 2, the primary nodes are not active; therefore, this operation does not create a service interruption.
In this phase, the primary role is switched back from the secondary nodes to the primary nodes.
Each phase can start only if the previous phase is completed.
Constraint 2 implies that you need to implement a synchronization mechanism between the two nodes of each sub-environment, without affecting all the other sub-environments.
By using this method, if the update process fails on a few environments during the Phase 1, all the remaining environments can continue and can be successfully upgraded.
3 Steps to implement the solution in uDeploy
Define all the offering instances as a single UrbanCode Deploy environment and group the nodes of the same sub-environments. The environment is composed of many sub-environments. Each sub-environment is composed of a few nodes.
Define the version status. Configure the UrbanCode Deploy version status that is used to synchronize the application processes.
Define the application processes to implement the 4 phases:
Phase 1 application process.
Implement the process to update all the secondary nodes and set the version status to indicate that Phase 1 is complete and Phase 2 can start.
Phase 2 application process.
Implement the process to switch the responsibility from the primary to the secondary node and set the version status to indicate that Phase 2 is complete and Phase 3 can start.
Phase 3 application process.
Implement the process to update all the primary nodes and set the version status to indicate that Phase 3 is complete and Phase 4 can start.
Phase 4 application process.
Implement the process to switch back the responsibility from the secondary to the primary nodes.
So, what do you think about? If you want more information see “Managing a continuous delivery process by providing continuity of service”.
If you want to discuss more about any concerns you could have adopting IBM UrbanCode Deploy and in general about the WAaaS implementation of the Continuous Delivery, follow , follow us on Twitter @GorgaIlaria and @FabioBarillari, or leave a comment below. Thanks for your time!