Rolling upgrade of SailFin demonstrated
What is rolling upgrade?
Rolling upgrade is a zero downtime upgrade of the SailFin cluster.
It can broadly be classfied into the following types :
- Upgrade of your running application.
- Upgrade of your hardware hosting the SailFin cluster.
- Upgrade of your running SailFin cluster from version 'x' to version 'y' ('y' should be backward compatible with 'x')
- As simple as applying a bugfix patches to your running SailFin cluster.
Goal of this write up is to give a preview of Rolling Upgrade feature in SailFin, with an example of application upgrade.
To achieve any type of rolling upgrade, you need to have at least 2 instance cluster with your application deployed as high-availability (HA) enabled (i.e., you need to have your application deployed with : asadmin deploy --target <your-cluster> --availabilityenabled=true <your-app>)
Example of rolling upgrade of an application in SailFin cluster:
In this example, we will go through :
- How the application looks before the rolling upgrade
- Performing the rolling upgrade.
- How the application looks after the rolling upgrade
Before the rolling upgrade:
Now the call is in progress between Alice and Bob, and your (i.e., Alice's) web browser displays the call history as shown the figure below (Note that I also clicked 'Call Adam', 'Call Eve' before clicking 'Call Bob', so the 'Call History' shows those statuses as well) :
Figure 1. Alice's browser showing the call call history, login time, etc [Before the Rolling Upgrade]
Now, without logging out from the browser, and without disconnecting the call between Alice and Bob, let us perform the rolling upgrade of Basic3pcc sample application.
Performing the Rolling Upgrade:
- % cd SF_HOME/samples/sipservlet/Basic3pcc
It would point to the sailfin sample 'Basic3pcc' directory
- % SF_HOME/lib/ant/bin/ant do-rollingupgrade
It would do the rolling upgrade of Basic3pcc sample application. This step may take a while, wait for its completion.
Internal details (what takes place during do-rollingupgrade) :
1. Upgrading the application: In this example, I wanted to provide a better user interface than what is shown in Figure 1. So, I upgraded 3pccConvergedApp.sar by updating its .jsp files, and adding some new .css, image files, etc.
2. Disabling dynamic reconfiguration: This is required so that the upgraded application does not get distributed immediately to the cluster instead it gets re-deployed instance-by-instance as we do the rolling of each instance in the cluster.
3. Deploying the upgraded application. Because of step (2), the instances in the cluster will still be running the older version of the application, until we execute the following step.
4. Rolling an instance (this step should be performed for all the instances in the cluster one-by-one)
- Disable the instance: CLB will remove this instance from its healthy instances list, and will no longer route any requests to this instance.
- Finish replicating: Ensure that any outstanding (asynchronous) replications are finished.
- Restart the instance: Stop the instance and start it back.
- Restore the sessions: Bring back all the sessions which were replicated by this instance prior to doing the rolling.
- Enable the instance: CLB will add this instance to its healthy instances list, and will start routing the requests to this instance.
- Reconile the sessions: Ensure that all the sessions are of correct/highest version. Since there was no downtime during the rolling upgrade, the sessions might have been accessed from a different instance, hence those sessions need to be brought back to this instance during this step. (Note : After enabling and before reconciling, a separate technique is used to ensure that highest version of the session is discovered and used).
After the rolling upgrade:
Figure 2. Alice's browser showing the call call history, login time, etc [After the Rolling Upgrade]
You can also see that the ongoing call between Alice and Bob also gets handled by rolled instance (instance4) gracefully.
You can check that out by clicking "Hang Up" button in Alice's phone. The BYE request sent from Alice's phone gets routed to the rolled instance4 and the upgraded ConvergedApp running in instance4 will process the BYE request using the same session which was created before doing the rolling upgrade. So the call will between Alice and Bob gets ended gracefully.