Upgrading an application to a new version without loss of availability to users is called a rolling upgrade. Carefully managing the two versions of the application across the upgrade ensures that current users of the application complete their tasks without interruption, while new users transparently get the new version of the application. With a rolling upgrade, users are unaware that the upgrade occurs.
Rolling upgrades pose varying degrees of difficulty depending on the magnitude of changes between the two application versions.
If the changes are superficial, for example, changes to static text and images, the two versions of the application are compatible and can both run at once in the same cluster. Compatible applications must:
Use the same session information
Use compatible database schemas
Have generally compatible application-level business logic
Use the same physical data source
You can perform a rolling upgrade of a compatible application in either a single cluster or multiple clusters. For more information, see Upgrading In a Single Cluster
If the two versions of an application do not meet all the above criteria, then the applications are considered incompatible. Executing incompatible versions of an application in one cluster can corrupt application data and cause session failover to not function correctly. The problems depend on the type and extent of the incompatibility. It is good practice to upgrade an incompatible application by creating a “shadow cluster” to which to deploy the new version and slowly quiesce the old cluster and application. For more information, see Upgrading Incompatible Applications
The application developer and administrator are the best people to determine whether application versions are compatible. If in doubt, assume that the versions are incompatible, since this is the safest approach.
You can perform a rolling upgrade of an application deployed to a single cluster, providing the cluster’s configuration is not shared with any other cluster.
Save an old version of the application or back up the domain.
To back up the domain use the asadmin backup-domain command.
Turn off dynamic reconfiguration (if enabled) for the cluster.
To do this with Admin Console:
Expand the Configurations node.
Click the name of the cluster’s configuration.
On the Configuration System Properties page, uncheck the Dynamic Reconfiguration Enabled box.
Click Save
Alternatively, use this command:
asadmin set --user user --passwordfile password_file cluster_name -config.dynamic-reconfiguration-enabled=false
Redeploy the upgraded application to the target domain.
If you redeploy using the Admin Console, the domain is automatically the target. If you use asadmin, specify the target domain. Because dynamic reconfiguration is disabled, the old application continues to run on the cluster.
Enable the redeployed application for the instances using asadmin enable-http-lb-application.
Quiesce one server instance in the cluster from the load balancer.
Follow these steps:
Disable the server instance using asadmin disable-http-lb-server.
Export the load balancer configuration file using asadmin export-http-lb-config.
Copy the exported configuration file to the web server instance’s configuration directory.
For example, for Sun Java System Web Server, the location is web_server_install_dir/ https- host-name /config/loadbalancer.xml . To ensure that the load balancer loads the new configuration file, be sure that dynamic reconfiguration is enabled by setting the reloadinterval in the load balancer configuration.
Wait until the timeout has expired.
Monitor the load balancer’s log file to make sure the instance is offline. If users see a retry URL, skip the quiescing period and restart the server immediately.
Restart the disabled server instance while the other instances in the cluster are still running.
Restarting causes the server to synchronize with the domain and update the application.
Test the application on the restarted server to make sure it runs correctly.
Re-enable the server instance in load balancer.
Follow these steps:
Enable the server instance using asadmin enable-http-lb-server.
Export the load balancer configuration file using asadmin export-http-lb-config.
Copy the configuration file to the web server’s configuration directory as described in Upgrading In a Single Cluster of Upgrading In a Single Cluster .
Repeat steps 5 through 8 for each instance in the cluster.
When all server instances have the new application and are running, you can re-enable dynamic reconfiguration for the cluster again.
Save an old version of the application or back up the domain.
To back up the domain use the asadmin backup-domain command.
Turn off dynamic reconfiguration (if enabled) for all clusters.
To do this with Admin Console:
Expand the Configurations node.
Click the name of one cluster’s configuration.
On the Configuration System Properties page, uncheck the Dynamic Reconfiguration Enabled box.
Click Save
Repeat for the other clusters
Alternatively, use this command:
asadmin set --user user --passwordfile password_file cluster_name-config.dynamic-reconfiguration-enabled=false
Redeploy the upgraded application to the target domain.
If you redeploy using the Admin Console, the domain is automatically the target. If you use asadmin, specify the target domain. Because dynamic reconfiguration is disabled, the old application continues to run on the clusters.
Enable the redeployed application for the clusters using asadmin enable-http-lb-application.
Quiesce one cluster from the load balancer
Disable the cluster using asadmin disable-http-lb-server.
Export the load balancer configuration file using asadmin export-http-lb-config.
Copy the exported configuration file to the web server instance’s configuration directory.
For example, for Sun Java System Web Server, the location is web_server_install_dir/ https- host-name /config/loadbalancer.xml . Dynamic reconfiguration must be enabled for the load balancer (by setting the reloadinterval in the load balancer configuration), so that the new load balancer configuration file is loaded automatically.
Wait until the timeout has expired.
Monitor the load balancer’s log file to make sure the instance is offline. If users see a retry URL, skip the quiescing period and restart the server immediately.
Restart the disabled cluster while the other clusters are still running.
Restarting causes the cluster to synchronize with the domain and update the application.
Test the application on the restarted cluster to make sure it runs correctly.
Re-enable the cluster in load balancer:
Repeat steps 5 through 8 for the other clusters.
When all server instances have the new application and are running, you can reenable dynamic reconfiguration for all clusters again.
For information on what makes applications compatible, see Application Compatibility the new version of the application is incompatible with the old. Also, you must upgrade incompatible application in two or more clusters. If you have only one cluster, create a “shadow cluster” for the upgrade, as described below.
When upgrading an incompatible application:
Give the new version of the application a different name from the old version of the application. The steps below assume that the application is renamed.
If the data schemas are incompatible, use different physical data sources after planning for data migration.
Deploy the new version to a different cluster from the cluster where the old version is deployed.
Set an appropriately long timeout for the cluster running the old application before you take it offline, because the requests for the application won’t fail over to the new cluster. These user sessions will simply fail.
Save an old version of the application or back up the domain.
To back up the domain use the asadmin backup-domain command.
Create a “shadow cluster” on the same or a different set of machines as the existing cluster.
Use the Admin Console to create the new cluster and reference the existing cluster’s named configuration.
Customize the ports for the new instances on each machine to avoid conflict with existing active ports.
For all resources associated with the cluster, add a resource reference to the newly created cluster using asadmin create-resource-ref.
Create a reference to all other applications deployed to the cluster (except the current redeployed application) from the newly created cluster using asadmin create-application-ref.
Configure the cluster to be highly available using asadmin configure-ha-cluster.
Create reference to the newly-created cluster in the load balancer configuration file using asadmin create-http-lb-ref.
Give the new version of application a different name from the old version.
Deploy the new application with the new cluster as the target. Use a different context root or roots.
Enable the deployed new application for the clusters using asadmin enable-http-lb-application.
Start the new cluster while the other cluster is still running.
The start causes the cluster to synchronize with the domain and be updated with the new application.
Test the application on the new cluster to make sure it runs correctly.
Disable the old cluster from the load balancer using asadmin disable-http-lb-server.
Set a timeout for how long lingering sessions survive.
Enable the new cluster from the load balancer using asadmin enable-http-lb-server.
Export the load balancer configuration file using asadmin export-http-lb-config.
Copy the exported configuration file to the web server instance’s configuration directory.
For example, for Sun Java System Web Server, the location is web_server_install_dir/ https- host-name /config/loadbalancer.xml . Dynamic reconfiguration must be enabled for the load balancer (by setting the reloadinterval in the load balancer configuration), so that the new load balancer configuration file is loaded automatically.
After the timeout period expires or after all users of the old application have exited, stop the old cluster and delete the old application.