Professional Documents
Culture Documents
Deployment 1 Publish
Deployment 1 Publish
Barry Searle [mailto:searle@ca.ibm.com] Architect, WebSphere Tools for Automated Build and Deployment IBM Toronto Lab Ellen Matheson McKay [mailto:ecmckay@ca.ibm.com] WebSphere Information Developer IBM Toronto Lab 2004 International Business Machines Corporation. All rights reserved.
Abstract
This two-part article discusses application deployment, particularly automated updates, to IBM WebSphere Application Server in a large-scale enterprise environment. It applies to WebSphere Application Server version 5.0, version 5.1, and version 6.0, and also includes an introduction to a few version 6.0 enhancements. This article is not intended to be used as a reference for all the details of WebSphere Application Server administration, but it does describe the key concepts used, and contains a list of references. Although the beginning of the article reviews some fairly basic base server and managed server concepts and operations, much of the remainder of the article will discuss certain complex concepts or operational considerations that will be new even to very experienced enterprise application server administrators. This first part of the article discusses wsadmin deployment to base and managed servers. It discusses why phased deployments are needed to maintain applications in a WebSphere Application Server NetworkDeployment managed cell, and how to maintain high availability in such an environment. Part 2 of the article discusses pre- and post-deployment validation, and it discusses gradual deployment of incompatible versions of applications. It also discusses the design and implementation of a downloadable Automated Deployment example program that illustrates how to automate the deployment of randomly built collections of enterprise applications or updates, and how to automatically target those applications or updates to the correct servers, including stage-specific application setup.
The problem
It is quite easy to deploy (install) an application into a WebSphere Application Server setup typically it just takes a one-line command. For your local running base server, it can be as simple as: wsadmin -c "$AdminApp install X:/MyApp.ear" -lang jacl However, this simplicity is deceiving, and the preceding example is really just the Hello World of deployment a nice demo, but not typical of the real world. In a real enterprise environment, there are hundreds of interrelated applications spread over dozens of remote application servers, and regular updates that need to be deployed to the right servers, all the while maintaining application availability to users. Even worse, most large enterprises have different sets of operating environments, or stages, each requiring different setups for the same application. For example, the security role mappings and the database used for a specific application in a Microsoft Windows integration stage are likely different from those used for that same application on a Linux production server. The result might be that at 3 a.m., when some random group of 20 applications have just been rebuilt because of an automated production build of Library Control System (LCS) code changes, those particular 20 applications Page 1 Automated Deployment of Enterprise Application (EAR) Updates
each need to have their updates deployed to their correct individual application servers somewhere in the enterprise. And, although it is 3 a.m. in North America, it is prime time elsewhere in the world, so the application updates need to be done in a way that maintains high application availability. This update build and deployment process is regularly repeated, each time involving a randomly different set of updated applications.
Server 1
Server 2 Application B
This approach provides a nice solution for a build machine and one or two remote base servers. But as the number of independent base servers increases, it rapidly becomes desirable to have centralized administration to manage the collection of servers as a single administrative cell.
Application A
Application C
Server 1
Server 2 Application A
Server 4
Server 5
Application C
Application B
Application C
Application D
How do you have a build machine deploy to remote production servers? Earlier we said that you could have WebSphere Application Server installed on a build machine, without requiring a server to be actually configured or running. Therefore, you can just start wsadmin using the host and port parameters to specify the remote Deployment Manager for the production cell, and everything works as expected. Note that the Deployment Manager must always be at the same version plus service level as all servers within the cell, or at a later version. Note that WebSphere Application Server version 6.0 provides support for multiple server profiles (an expanded implementation of version 5.1 instances), where each server profile is essentially a totally independent server (independent configurations sharing a common set of runtime programs). The wsadmin command will operate against its default server profile (determined by the profile location you are executing from), but you can use the parameter profileName MyProfile to override that default and specify the actual server profile (and hence its particular Deployment Manager) to be used, or you can use the host and port parameters to directly specify the destination (typically a Deployment Manager).
Enterprise Applications
Node Agent Application Server-1 (Other cells or major organizations) Application Server-N Machine C Tier-1 Tier-2 Tier-3 Enterprise Data
Stop all affected servers in selected node NodeSync (update all affected servers) Restart all affected servers in selected node Reactivate all affected servers in selected node
YES
Remaining nodes ?
1. Save the current setting and then disable AutoSync on all affected nodes: a. Can also optionally save and disable SyncOnStartup. 2. Sequentially, for each affected node, phasedeploy the update: a. Select the next affected node to be updated. b. Optionally quiesce all its affected servers (reroute new work requests). c. Stop all its affected servers. d. NodeSync that node to retrieve the update and to install it in each affected server. o Note: Wait to ensure the EAR expansion is complete. e. Restart the affected servers. o Note: Test and wait to ensure the server is running. f. Optionally reactivate the affected servers (to process new work requests). g. Optionally validate installed application operation. h. Optionally request manual confirmation to accept (or reject and restore) this update. i. Repeat for the next affected node. 2. Restore the previous AutoSync settings for all affected nodes: a. Including SyncOnStartup if it was optionally disabled.
NO
The above process involves a lot of manual operations and is very error-prone. A script can be created to perform the specific steps, but a different script is required for each different application and each applications Page 10 Automated Deployment of Enterprise Application (EAR) Updates
different set of associated target servers. The scripts can be quite complex and difficult to create, and require ongoing maintenance as the environment changes. There are two special notes in the above steps. First, after performing the NodeSync, the application update (EAR) has been distributed down to the node, but the EAR file must still be expanded into the server installed application directory. Until this EAR expansion is complete, attempting to start the server will produce indeterminate results. An IBM Problem Report has been created about this, and there may, in the future, be a downloadable WebSphere Application Server Interim Fix to allow scripts to test for the completion of the EAR expansion. Second, after returning from the wsadmin startServer command, the command has been processed by the Node Agent but the actual server startup may not yet be complete. Scripts need to test that the server has completed startup and is running. Note that WebSphere Application Server version 6.0 has a new cluster-update feature to distribute (in phases) an update to each of a clusters members one node at a time, including the stopping and restarting of affected servers being updated. Where server-failure and session-recovery have been configured and provide sufficient functionality, this will provide very good high availability during cluster updates. This feature currently cannot be used to phase distribute an update to unclustered servers, and does not do preemptive quiescing or reactivation of work rerouting. If multiple cluster members are on the same node (vertical clustering for scalability), then they will be simultaneously updated (and simultaneously unavailable) as if the Node Agent had performed a regular NodeSync. Also WebSphere Application Server version 6.0 cluster update can only be done for one application at a time. If multiple applications need to be updated within a cluster, then multiple cluster-update operations must be individually performed, and each cluster member node and its affected servers will be cycled again during each individual cluster-update. In summary, the WebSphere Application Server version 6.0 new cluster-update feature is a convenient way to distribute a single update throughout a horizontal cluster with cluster members across multiple nodes, and does so while maintaining high-availability.
1. Analyze the set of all current updates to be deployed. 2. For each application, determine (read) its specific set of target nodes and servers. 3. From the total set of affected nodes and servers, calculate the subset of unique affected nodes and unique affected servers. 4. Perform the previously described phased distribution for each affected node.
As for the phased deployment of single applications, the above process involves a lot of manual operations and is very error-prone. Additional scripts can be created to assist in the above steps, but with ever-increasing numbers of different applications, target servers, and stage environment and applications settings, the number and complexity of specialized scripts becomes an enormous challenge to create and then to maintain.
Ellen Matheson McKay is an Information Developer for IBM Canada Ltd. She writes online help and publications for Rational Application Developer. You can reach Ellen at ecmckay@ca.ibm.com Page 12 Automated Deployment of Enterprise Application (EAR) Updates
Trademarks IBM and WebSphere are registered trademarks of International Business Machines Corporation in the United States, other countries, or both. Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, and service names may be trademarks or service marks of others.