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:

Deploy and execute the Basic3pcc cluster sample as explained in my previous blog post by following "Instructions to deploy" and "Instructions to execute" sections.

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:

1. % cd SF_HOME/samples/sipservlet/Basic3pcc
   It would point to the sailfin sample 'Basic3pcc' directory


2. % 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.

• 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:

Click on "Refresh Page" link in your (i.e., Alice's) browser, and you will see a all new upgraded user interface, and with no loss of your session:



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.

Summary :