m (1 revision) |
(→Application Upgrade) |
||
| Line 1: | Line 1: | ||
{{AwdDocHeader}} | {{AwdDocHeader}} | ||
==Application Upgrade== | ==Application Upgrade== | ||
| + | |||
| + | Application upgrade provides the ability to upgrade a single application (SAF Service Group) without affecting any nodes or any other applications in the cluster. Two upgrade algorithms are supported: single step and rolling. | ||
| + | |||
| + | A single step upgrade is so named because it stops all processes in the SG and restarts them running the new version simultaneously (in one step). This is therefore a service affecting upgrade. However, the system minimizes the downtime to seconds by installing all software and making all necessary configuration changes before service is affected. | ||
| + | |||
| + | A rolling upgrade ensures application availability by restarting the application's processes on one node (SAF Service Unit) at a time. Therefore there is always at least one application process providing service. However, this means that during the transition there will be times when two versions of application software will in active/standby configuration. So the application must be written and tested for this configuration. | ||
| + | |||
| + | The choice of single step or rolling upgrade can occur each time an upgrade is executed. It is often easy to determine that simple bug fixes are version-compatible, but new features or changes that affect the active/standby communications or checkpointing database may need careful programming and testing to verify interoperability. Therefore for some features/bugs the single step upgrade provides a significant advantage to application programmers (and development cost reductions) because two versions of the application are never running in active/standby configuration. | ||
| + | |||
| + | Application upgrade is available through the Web GUI or via high-level APIs. | ||
| + | |||
| + | ===Bundling=== | ||
| + | |||
| + | To deliver a new version of an application, the engineer needs to bundle it in the same manner as is used in application deployment, described [[Doc:Sdk_4.1/awdguide/appbundle#Application_Bundle_Format | here]] | ||
| + | |||
| + | ===Upgrade via the Web GUI=== | ||
After an application deployment is scheduled for an upgrade (by selecting it and clicking on the "upgrade" button in various places in the GUI). It appears in this upgrade page. Multiple upgradeable deployments can appear here simultaneously and you may run the upgrades simultaneously or sequentially as you wish. | After an application deployment is scheduled for an upgrade (by selecting it and clicking on the "upgrade" button in various places in the GUI). It appears in this upgrade page. Multiple upgradeable deployments can appear here simultaneously and you may run the upgrades simultaneously or sequentially as you wish. | ||
| Line 17: | Line 33: | ||
When the upgrade is complete and you are satisfied with the correct operation, click "Commit" to remove it from the upgrade page. | When the upgrade is complete and you are satisfied with the correct operation, click "Commit" to remove it from the upgrade page. | ||
| + | |||
| + | ===Upgrade via APIs=== | ||
| + | |||
| + | The first step is to copy your application bundle to the node running this code. How this is accomplished is beyond the scope of this document and can occur via network transfer through your management application (as is done in the Runtime Director GUI shown above) or even via physical media in the case of a FAE-assisted onsite upgrade. | ||
| + | |||
| + | The first step to execute an upgrade via APIs is to create an application bundle repository object. In this case, I create it in a subdirectory called "apps" off of the SAFplus "deployment" directory. | ||
| + | <code><pre> | ||
| + | appDb = aspApp.AppDb(os.getenv("ASP_DIR","/tmp") + "/apps") | ||
| + | ci.setAppDb(appDb) # Hook them up (so clusterinfo knows about application versions) | ||
| + | </pre></code> | ||
| + | |||
| + | Next, it is important that this node knows how to "ssh" into the other nodes in the cluster because it will use "scp" to deploy the software. Most of the time, this information is automatically supplied to the AMF by the other nodes, so you are likely to not need this step. It is included here for completeness. | ||
| + | <code><pre> | ||
| + | if ci.entities[myNode].localUser == 'unknown': | ||
| + | ci.entities[myNode].setIntraclusterAccess("192.168.66.130","root","",os.getenv("ASP_DIR","/tmp")) | ||
| + | </pre></code> | ||
| + | |||
| + | The above example sets 1 node. For the application deployment example below to work, you must set all of the nodes containing applications to upgrade to the correct values. | ||
| + | |||
| + | Now, let the application bundle manager know about your bundle: | ||
| + | <code><pre> | ||
| + | appDb.NewAppFile("/code/vipapp1.4.0.0.tgz") | ||
| + | </pre></code> | ||
| + | |||
| + | Next, create an upgrade manager object (or reuse an existing one) | ||
| + | <code><pre> | ||
| + | # Start the upgrade manager... | ||
| + | umgr = upgrade.UpgradeMgr() | ||
| + | </pre></code> | ||
| + | |||
| + | Add the service group you want to upgrade to the manager. You can find the service group via the ClusterInfo object hierarchy described elsewhere in this document. In this example it is stored in the "mySg" variable. | ||
| + | <code><pre> | ||
| + | umgr.add(mySg) # Add my Service Group to it. | ||
| + | </pre></code> | ||
| + | |||
| + | This will create an upgrade object that tracks the status of this application upgrade. Now get this object and change its configuration (if needed). | ||
| + | <code><pre> | ||
| + | upSg = umgr.entities[mySgName] # Get my sg's upgrade entity | ||
| + | upSg.upMethod = upgrade.RollingUpgrade | ||
| + | </pre></code> | ||
| + | |||
| + | Now kick off the upgrade! | ||
| + | <code><pre> | ||
| + | print mySg.appVer.version | ||
| + | # Start the upgrade... | ||
| + | upSg.Upgrade(appDb.apps['virtualIp'].version['1.4.0.1']) | ||
| + | </pre></code> | ||
| + | |||
| + | Finally, if the upgrade is successful commit it, otherwise roll back | ||
| + | <code><pre> | ||
| + | upSg.commit() | ||
| + | </pre></code> | ||
Revision as of 16:26, 30 January 2013
Contents |
Application Upgrade
Application upgrade provides the ability to upgrade a single application (SAF Service Group) without affecting any nodes or any other applications in the cluster. Two upgrade algorithms are supported: single step and rolling.
A single step upgrade is so named because it stops all processes in the SG and restarts them running the new version simultaneously (in one step). This is therefore a service affecting upgrade. However, the system minimizes the downtime to seconds by installing all software and making all necessary configuration changes before service is affected.
A rolling upgrade ensures application availability by restarting the application's processes on one node (SAF Service Unit) at a time. Therefore there is always at least one application process providing service. However, this means that during the transition there will be times when two versions of application software will in active/standby configuration. So the application must be written and tested for this configuration.
The choice of single step or rolling upgrade can occur each time an upgrade is executed. It is often easy to determine that simple bug fixes are version-compatible, but new features or changes that affect the active/standby communications or checkpointing database may need careful programming and testing to verify interoperability. Therefore for some features/bugs the single step upgrade provides a significant advantage to application programmers (and development cost reductions) because two versions of the application are never running in active/standby configuration.
Application upgrade is available through the Web GUI or via high-level APIs.
Bundling
To deliver a new version of an application, the engineer needs to bundle it in the same manner as is used in application deployment, described here
Upgrade via the Web GUI
After an application deployment is scheduled for an upgrade (by selecting it and clicking on the "upgrade" button in various places in the GUI). It appears in this upgrade page. Multiple upgradeable deployments can appear here simultaneously and you may run the upgrades simultaneously or sequentially as you wish.
Select the application deployments to be upgraded by clicking on the left checkbox. Next choose "rolling" or "single-step" upgrade on the right. "Rolling" upgrade executes an in-service algorithm in which the application is upgraded on each node sequentially ensuring that some nodes always remain to provide the application service. To use this method, applications must be capable of having different versions run simultaneously on the cluster. "Single-step" upgrade upgrades the application on every node simultaneously, causing a short interruption in service. However, this method does not require that application versions interoperate. These upgrade algorithms are explained in detail in the SAF SMF (Software Manageability Framework) specification.
Leave "automatic" as "yes" since manual upgrades are not yet supported.
When ready, click "Start". This page will be updated dynamically so you will see the upgrade's progress.
This is a view of an in-progress rolling upgrade. Note that the payloadI0 node is no longer running the application (its status is "down") and that it is being upgraded. Also note that the "payloadI1" node is up, and active -- it is providing the service during the upgrade of the "payloadI0" node.
When the upgrade is complete and you are satisfied with the correct operation, click "Commit" to remove it from the upgrade page.
Upgrade via APIs
The first step is to copy your application bundle to the node running this code. How this is accomplished is beyond the scope of this document and can occur via network transfer through your management application (as is done in the Runtime Director GUI shown above) or even via physical media in the case of a FAE-assisted onsite upgrade.
The first step to execute an upgrade via APIs is to create an application bundle repository object. In this case, I create it in a subdirectory called "apps" off of the SAFplus "deployment" directory.
appDb = aspApp.AppDb(os.getenv("ASP_DIR","/tmp") + "/apps")
ci.setAppDb(appDb) # Hook them up (so clusterinfo knows about application versions)
Next, it is important that this node knows how to "ssh" into the other nodes in the cluster because it will use "scp" to deploy the software. Most of the time, this information is automatically supplied to the AMF by the other nodes, so you are likely to not need this step. It is included here for completeness.
if ci.entities[myNode].localUser == 'unknown':
ci.entities[myNode].setIntraclusterAccess("192.168.66.130","root","",os.getenv("ASP_DIR","/tmp"))
The above example sets 1 node. For the application deployment example below to work, you must set all of the nodes containing applications to upgrade to the correct values.
Now, let the application bundle manager know about your bundle:
appDb.NewAppFile("/code/vipapp1.4.0.0.tgz")
Next, create an upgrade manager object (or reuse an existing one)
# Start the upgrade manager...
umgr = upgrade.UpgradeMgr()
Add the service group you want to upgrade to the manager. You can find the service group via the ClusterInfo object hierarchy described elsewhere in this document. In this example it is stored in the "mySg" variable.
umgr.add(mySg) # Add my Service Group to it.
This will create an upgrade object that tracks the status of this application upgrade. Now get this object and change its configuration (if needed).
upSg = umgr.entities[mySgName] # Get my sg's upgrade entity
upSg.upMethod = upgrade.RollingUpgrade
Now kick off the upgrade!
print mySg.appVer.version
# Start the upgrade...
upSg.Upgrade(appDb.apps['virtualIp'].version['1.4.0.1'])
Finally, if the upgrade is successful commit it, otherwise roll back
upSg.commit()