IBM WebSphere Developer Technical Journal: System management for WebSphere Application Server V6 -- Part 1

Overview of system management enhancements

This is the first in a series of articles covering the significant system management functionality enhancements in IBM® WebSphere® Application Server V6. Part 1 provides an overview of each system management enhancement, with subsequent articles focusing on the details related to a single feature.

Leigh Williamson (leighw@us.ibm.com), WebSphere System Management Architect, IBM

Leigh Williamson is a Senior Technical Staff Member software engineer at the IBM Software Development Lab in Austin, Texas. As System Management Architect for WebSphere Application Server, he currently leads the evolution of WebSphere product management capabilities.



26 January 2005

Introduction

IBM WebSphere Application Server V6 contains many significant enhancements in system management functionality over the previous release, Version 5. This article is the first in a series that covers the evolution of the product in this area. This first article provides a brief overview of each Version 6 system management enhancement, with subsequent articles focusing on the details related to a single feature.

This series is intended for users who are already familiar with the system administration infrastructure for WebSphere Application Server V5. Readers without exposure to these concepts can review a similar series of articles written for Version 5, also published in the IBM WebSphere Developer Technical Journal, and the IBM Press book IBM WebSphere V5 System Administration (see Resources).

The following enhancements will be described in this overview:

  1. Incremental cell upgrade
  2. WebSphere profiles
  3. Backward compatibility
  4. Port conflict resolution
  5. Fine-grained application update
  6. Application rollout for updates
  7. Enhanced EAR file support
  8. Configuration archives
  9. Administrative command tasks
  10. Web server administration
  11. Integration with the operating system
  12. J2EE 1.4 management specifications
  13. System applications
  14. Node groups.

Incremental cell upgrade

The WebSphere Application Server V6 deployment manager can manage both WebSphere Application Server V6 (hereafter referred to as Version 6) and WebSphere Application Server V5 (hereafter referred to as Version 5) nodes. This allows the cell to be upgraded to the new release one node at a time, with minimal impact to the applications that are running within the cell. Figure 1 illustrates a cell in the midst of being upgraded from Version 5 to Version 6.

Figure 1. Mixed release cells in Version 6
Figure 1. Mixed release cells in Version 6

The incremental migration process begins with migration of your Version 5 deployment manager to Version 6. The deployment manager must always be the first part of the cell migrated to the new release level, and it must always be at the highest release and fix level of any node within a cell to allow it to manage all nodes in the cell regardless of their release level.

When the deployment manager is migrated to Version 6, the nodes in the cell remain unchanged at whatever release level they supported prior to the deployment manager upgrade. Once the deployment manager has been upgraded to Version 6, the individual nodes in the cell can be upgraded. As the incremental upgrade proceeds, the central configuration repository for the cell will contain both Version 5 and Version 6 configuration documents. Configuration synchronization will ensure that only configuration documents that can be consumed by Version 5 runtimes are replicated to those nodes.

Clusters in Version 6 can operate in one of two modes:

  • Compatibility mode enables both Version 5 and Version 6 application servers to be part of the same cluster.
  • Performance mode enables a cluster containing all Version 6 servers to execute workload balancing and failover more efficiently.

WebSphere product migration logic automatically sets the mode for compatibility when there are nodes at different levels in the cell.

In Version 6, information about a node (such as operating system platform and product features) is maintained in the configuration repository in a properties file specific to that node. The Version 6 mixed release cell administration logic uses this information to determine which administrative functions are appropriate and valid for a given resource on a particular node. For instance, Version 6 features are not displayed in the admin console when Version 5 servers are shown. When displaying the properties for a node, node agent, or server, the administrative console is aware of the version of the node on which the object resides, and will only display those properties that are valid for that version. This feature is known as the Adapt-A-View enhancement for Version 6 administrative information.

The wsadmin scripting client is also aware of the version of node on which a configuration object resides. An exception is thrown if you attempt to view or modify a property that is not valid for the version. A warning is logged if you attempt to show or modify a property that has been deprecated.

In Version 6, all applications are classified as either Version 5 or Version 6 compatible applications, based on the WebSphere Application Server features that the applications make use of. All applications may be updated using the administrative functions for reinstallation, editing, or remapping modules to new targets. When remapping a module, the new target for a Version 6 module may not be a Version 5 target (an application server or cluster containing Version 5 members).

There are many more details related to the incremental cell upgrade and mixed release cell management feature in Version 6. A subsequent article in this series will cover this important new feature in greater detail.

Temporary restrictions on Version 5 nodes in the mixed release cell

There are some restrictions on what can be done with the Version 5 nodes in a cell, once the incremental upgrade to Version 6 has begun. These restrictions will be lifted in subsequent maintenance releases for Versions 5 and 6.

A new Version 5 node cannot be added to a Version 6 cell. However, a similar result can be obtained by first upgrading the node to Version 6 before adding it to the cell. A Version 5 node in a Version 6 cell cannot be removed from the cell. The same result can be obtained in either of the following ways:

  • Upgrade node to Version 6, followed by removeNode, or
  • Uninstall the Version 5 node, followed by executing cleanupNode on the deployment manager to remove references to the uninstalled node from the master cell repository.

Once the incremental upgrade process is underway, defining new application servers on Version 5 nodes is not allowed. A future maintenance release for Version 6 will add the back-level configuration templates that will lift this restriction.


WebSphere profiles

The Version 6 product installation program places the files it creates into one of two separate environments. It installs the core product files (the "system" files) in one location, and in a separate location it creates an initial profile, which is a run time execution environment that includes configuration files, the default location for deployed applications, logs, and other data. All profiles on a machine can share the same core product files, which they cannot modify.

A Version 6 profile is made up of the fileset that is owned and writeable by an end user, and the processes that execute under that end user's identity. On UNIX/Linux systems, all files and directories in the created profile have the same group and owner permissions as the user who executed the utility to create the profile. One way to think about the WebSphere profile is to consider it as the user data partition -- the equivalent of the user's home directory in UNIX®/Linux® operating system environments.

The WebSphere profile is physically separate from the WebSphere product binaries, or system files, which are only read by the end user processes and never modified by them. The WebSphere system files are only modified by product maintenance updates, such as fix packs and ifixes. WebSphere system files may be modified by the installation of products that extend the WebSphere platform, but this is considered product maintenance as well.

Examples of the files that are stored and updated within the profile include the following:

  • configuration repository for WebSphere processes that execute under this profile
  • log files of all varieties (SystemOut.log, tranlog, FFDC, activity.log, and so on)
  • certificates (at least, the initial set that is shipped with the product)
  • installed (expanded) application binaries
  • installed JCA Resource Adapter libraries
  • properties files
  • temporary working directories
  • Cloudscape database
  • profile environment setup file.

There are different types of profiles supported in Version 6. The profile type defines how the partition is customized to support a specific functional environment for the end user. There are currently three profile types supported in Version 6:

  • application server -- Standalone application server environment used for the Express and Application Server Base packages, and Network Deployment (ND) standalone AppServer packaging. Contains one default application server definition in the initial profile.
  • dmgr -- The deployment manager environment, only available for the ND edition (equivalent to the ND edition in Version 5).
  • custom -- An automatically federated node containing no predefined application server definitions. An empty managed node, ready for the central cell deployment manager to add resource and server definitions.

Multiple instances of the same profile type (or different profile types) can be created and associated with the same product installation (that is, the same shared system files). Each instance of a profile, regardless of its type or location, is registered in a profile registry, which is an XML file located in the properties directory under the product root installation directory tree.

A subsequent article in this series will cover WebSphere profiles in greater detail.


Backward compatibility

There has been significant investment in backward compatibility for the system management functions in Version 6. The new features have been generally built on top of the same product management infrastructure used for Version 5. For instance, the structure and concepts for the configuration repository in Version 6 are the same as in Version 5. Version 6, however, added some new directories to the existing ones and added some new files in the pre-existing directories. Therefore, if you look in the node configuration directory of a Version 6 installation, you will see the same files that you would see in Version 5, plus some new ones.

The commitment to backward compatibility extends beyond static configuration files, and includes work that was done to support interoperability between Version 5 and Version 6 administration programs. The Version 5 wsadmin program can connect to and communicate with Version 6 application servers, and Version 6 deployment managers can communicate with Version 5 node agents to manage back-level installations of the product in the same cell.

Wsadmin script compatibility

Despite significant attempts to eliminate the impact of Version 6 features on any wsadmin scripts that were written and executed against Version 5, there are a few areas where impact to scripting was unavoidable.

When migrating Version 5 deployment manager and application server nodes to Version 6, the migrated configuration is in, by default, compatibility mode, meaning that the old Version 5 configuration is preserved and the old scripts will continue to work. The runtime is aware of the old configuration and will continue to honor settings in those older locations as long as a newer configuration does not exist in conflict with it. Warning messages are logged by the runtime when the old configuration location is still being used.

The convertScriptCompatibility tool is provided to upgrade the configuration once all scripts have been converted to Version 6 style. The best practice recommendation is to upgrade scripts to Version 6 style as soon as possible, because newly created configurations (such as, new application server definitions) use the new Version 6 configuration (for example, for channels), and old scripts do not work against them.

The following list describes the specific differences between Version 5 and Version 6 that affect scripts:

  • Transaction logs -- The location of the transaction logs directory attribute has changed from ApplicationServer::TransactionService to ServerEntry::recoveryLogs. The value from the old location will continue to be used for as long as the new location is not used. Scripts that modify the old location can still be used; that value will be in effect until a value in the new location is set.
  • HTTP transports -- The new architecture for Version 6 uses the new channel framework for communication and associated endpoint configuration. HTTP definitions for the Web container are mapped on top of this channel framework support. When compatibility mode is chosen for Version 5 migration, the old HTTPTransport objects are left in the configuration so that existing scripts can modify these objects and will run unchanged. The channel framework runtime code will recognize the presence of old the HTTPTransport configuration and issue a warning message in the logs to indicate that the configuration should be upgraded.
  • Server process definition -- The name of the server process definition configuration object has changed from processDef to processDefs.
  • regexp command -- A new version of Jacl (1.3.1) is shipped with WebSphere Application Server V6. With this Jacl version, the regexp command supports only tcl 8.0 regexp command syntax.

ConfigIDs

Due to changes in the JMX specification for allowed format of the ObjectName class, the configID used in Version 6 contains a vertical bar character ("|") instead of a colon character (":") as a delimiter. This change in configID format should not present a problem for most wsadmin scripts because configIDs are not guaranteed to be consistent between wsadmin executions and should not be stored persistently for reuse. ConfigIDs should always be retrieved from a query of the configuration executed right before their usage in a script.


Port conflict resolution

WebSphere Application Server defines a number of ports which servers use, and each must be unique across all the running servers on a single host computer system. Improvements have been made in the administrative tooling to help ensure that port definitions are not in conflict. The process of ensuring that ports are not reused differs between different tools in the product.

The Profile Creation Tool that is executed as part of the product installation displays a list of ports which are unique across all WebSphere Application Server installations on the host system. Although not required, you have the option to modify those port numbers to whatever you want.

If you use silent install, you need to modify the response file so that the ports are unique. The default response file contains a list of ports which, in the simple case, do not conflict (the default application server ports do not conflict with the default deployment manager ports). If you have more than one server of a specific type, the list of ports will need to be modified.

The addNode utility has also been enhanced to perform some amount of port conflict avoidance for the node agent which is created. The addNode program looks at ports defined in the current installation, and across all profiles associated with that installation, to discover and resolve conflicts in port definition. This is sufficient if you have one WebSphere Application Server installation on a single host system and multiple profiles defined. If you have multiple WebSphere installations on a single host system, you can define specific ports to use for the node agent with a new command line option for addNode: -portprops <filename>. The file specified should contain a list of key-value properties, using the port names defined in the serverindex.xml configuration file that is stored in the node directory in the configuration tree. For example:

Listing 1
BOOTSTRAP_ADDRESS=9001
SOAP_CONNECTOR_ADDRESS=9002
ORB_LISTENER_ADDRESS=9003

Any ports not specified will take their default values, which will be unique across the current installation, but are not guaranteed to be unique across multiple installations on the same host system.


Fine-grained application update

There are a number of useful enhancements to application management in WebSphere Application Server V6.

Redeploying an application is significantly more efficient in Version 6. When updating an application, only the portion of the application code that actually changed needs to be presented to the system. The application management logic will calculate the minimum actions that the system needs to execute in order to update the application with the least disruptive impact.

Under certain circumstances, the update can occur without stopping any portion of the running application. However, since a typical application update does cause a service interruption in the application server, there are additional features in Version 6 that are recommended for use in conjunction with fine-grained application updates for customers who must avoid service interruption. The Rollout Application Update Option, described next, provides improved service availability for application updates.

Previous releases of WebSphere Application Server only supported replacement of an entire application (that is, a complete .ear file), and always stopped and restarted the entire application for any change. Version 6 introduces enhanced interfaces in wsadmin scripting, the administrative console, and the Java™ APIs for application management that can update deployed applications or modules in the following ways:

  • Replace, add, or remove a single module (.war, EJB .jar, or connector .rar file)
  • Replace, add, or remove a single file
  • Replace, add and/or remove multiple files contained in a compressed (.zip) file.

If the application is updated while it is running, WebSphere Application Server automatically stops only the affected components required by the update.

Any part of the application that is stopped during the update process is automatically restarted after the changes to the application code have been put in place. The deployment information that is unaffected by an application update is preserved. When an entire application is updated, all the deployment related information (such as, classloader settings, shared libraries) and deployment target configurations (such as, session management settings) are preserved in addition to the application bindings.

A subsequent article in this series will cover application management enhancements in considerable detail, compared with the overview provided here.


Application rollout for updates

Version 6 adds a new administrative function that incorporates into the product a procedure for updating applications that are deployed into clusters in a manner that ensures no service interruption of the application. Customers were recommended to automate this procedure using wsadmin scripts in Version 5, but in Version 6 the logic is embedded in the administrative program implementation.

The default application update logic in Version 5 created gaps in application availability during the distribution and startup of the update. The root cause for these gaps is an asynchronous update process applied to running servers that form a WebSphere cluster.

Application Rollout has been added as a built-in application update option. When this option is selected, the automatic cell synchronization is disabled and the following steps will be applied to each cluster member in turn:

  1. Stop all cluster members on a given node, enabling the application clients to failover to cluster members on other nodes.
  2. Distribute the application update to the node.
  3. Re-start cluster member, enabling it to begin processing application requests again but executing the new Version of the application.

This function only works well when the update to the application is "compatible" with the prior version of the application. In other words, it must be feasible for both versions of the application to be executing at the same time in the same cluster, and clients should be able to direct requests to either version of the application without failure. Many modifications to applications fall into the category of compatible updates, but it does require consideration by the application developers to know which are and which are not.

This new function is exposed through both the admin console and through wsadmin scripting. In the admin console, it is exposed as the Rollout Update button on the Enterprise Applications page. It is exposed through wsadmin scripting by invoking the updateCluster operation on the AppManagement MBean.


Enhanced EAR file support

In previous releases of WebSphere Application Server, customers had to set up the WebSphere environment configuration to support an application as separate steps before deploying the application. The resources and variables used by the application always had to exist in the WebSphere configuration prior to application installation.

In Version 6, the companion Application Server Toolkit enables customers to define WebSphere configuration elements, such as datasources and virtual hosts, as a part of the application. These WebSphere configuration elements and settings can be packaged into the .ear file exported from the development tooling. At deployment time, customers may choose to process these embedded configuration elements which set up the WebSphere configuration automatically for the application as part of its deployment.


Configuration archives

WebSphere Application Server V6 adds the ability to export and import parts of the WebSphere configuration repository from one environment to another.

Customers can propagate the configuration from one WebSphere profile to another by exporting a profile (or a part of a profile) to a configuration archive and then importing it to another profile. This mechanism works between profiles of the same installation or different installations. One restriction in this release is that this mechanism only works for unfederated WebSphere profiles.

The exportServer and exportWasprofile commands enable either fragments of the configuration to be exported to an archive, or the entire profile configuration to be exported. The importServer and importWasprofile commands allow those archives to be brought into an existing environment and merged with the configuration that exists in that target environment. The configuration data in the archive takes on the names of the local cell, node, and server when imported into the target environment.

A subsequent article in this series will cover configuration archives in greater detail.


Administrative command tasks

Automation of administrative tasks in Version 6 is made easier through the new AdminTask feature of wsadmin. Many of the more involved tasks for administration have been implemented using this new feature, which supports interactive execution and combines many individual scripting commands into a single task oriented command. Examples of tasks that offer automation through a high level admin task include server management, cluster management, and resource management.

The AdminTask feature provides a variety of user friendly and task oriented wsadmin commands. AdminTask commands may have multiple steps for some complicated administrative operations similar to the wizard in the console, and are grouped based on their functional areas. (Detailed help information for AdminTask commands and command groups is available through various AdminTask help commands.) All AdminTask commands can be executed in interactive mode, which walks the user through each step in the operation. At the end of the interactive command session, the entire corresponding AdminTask command is generated to help users learn the AdminTask command syntax.

A subsequent article in this series will provide more information on these new Admin Command Tasks.


Web server administration

In WebSphere Application Server V6, the HTTP Web server is represented as a specific server type; a server type is just the identity of a particular group of configuration templates. There is one new server type defined in Version 6 for Web servers, with two different Web server configuration templates: one for the IHS Web server, and another for all of the other "generic" Web servers that WebSphere supports.

Many benefits are gained by representing the Web server explicitly in the WebSphere topology. All of the configuration properties used in the plugin-cfg.xml file for the Web server plug-in are exposed and accessible for modification from the admin console and from wsadmin scripting automation. Individual tailored plugin-cfg.xml files are generated for each Web server based on its configuration and association with the application servers. That association with application servers is established by selecting the Web server as one of the deployment targets for an application when the application is installed. By associating the Web server and application servers with each other through the linkage of the deployed applications, the plugin-cfg.xml associations are dynamically regenerated as applications are deployed or modified.

A subsequent article in this series describes details of the new Web server administration in Version 6.


Integration with the operating system

In Version 6, all WebSphere application servers in the Express, Base, and Network Deployment (ND) standalone environments may be set up as registered Microsoft® Windows® operating system services when the product is installed on Microsoft Windows systems. When the server is registered as a Windows service, the operating system is responsible for starting and stopping the process. As a result, the WebSphere system management command line utilities have been modified to account for the possibility that they can be executed on a Windows operating system and should use the operating system service to control the server, rather than launch it or stop it directly.

This affects the following command line utilities:

  • stopServer
  • addNode/removeNode
  • backup/restoreConfig
  • any other code that stops or starts the servers.

Enhancements were also made for the WASService.exe utility that performs the registration of the WebSphere servers as Windows OS services.

A subsequent article in this series describes this Version 6 feature.


J2EE 1.4 management specifications

The J2EE™ 1.4 specification added several requirements for application server vendors to implement in support of administration. This revision of the J2EE specification adds requirements to support:

  • Java Management Extensions (JMX 1.2)
  • J2EE Management Specificiation (JSR 77)
  • J2EE Deployment (JSR 88)
  • J2EE Connector Architecture (JCA 1.5).

In addition to J2EE specification related administration features, the embedded messaging component of WebSphere that support Java Messaging Service (JMS) has been redesigned to be significantly better integrated with the application server administration.

A subsequent article in this series describes the new management functions in the J2EE 1.4 specification and delivered by WebSphere Application Server V6.


System applications

A new concept in WebSphere Application Server V6 is that of system applications, which are applications that have been developed as standard J2EE applications but are intended to be an integral part of the WebSphere Application Server product, not subject to end user manipulation.

System applications are shared amongst all of the profiles associated with a single installation of WebSphere Application Server. There is only one set of files containing the logic for these applications per installation, and those application files are located with the rest of the core product binary files. System applications are considered to be "owned" and controlled by the WebSphere product logic, as opposed to end user applications which are under the control of the WebSphere Application Server user.

Examples of WebSphere Application Server V6 system applications include adminconsole.ear and filetransfer.ear. Not all applications shipped with WebSphere Application Server are system applications; J2EE Samples, for example, are not system applications.

System applications are not exposed in the console and are not shown in the list returned from the wsadmin $AdminApp list command.


Node groups

WebSphere Application Server nodes support varying functional capabilities, based on the underlying operating system, the version of the WebSphere product installed, and any extension products installed on the same node. It might be inappropriate to perform certain functions on a node if that node does not support compatible capabilities. For example, it would be inappropriate to include zSeries nodes with nodes of other operating systems in a WebSphere cluster, since the workload balancing logic between zSeries and other platforms is not compatible. There are other examples where distinguishing between node capabilities and compatibility is important, such as when a cell includes nodes that have WebSphere Business Integration installed and you need to ensure that clusters defined to host WebSphere Business Integration applications include only nodes that have WebSphere Business Integration installed.

In Version 6, the concept of node groups is introduced to assist with distinguishing between nodes of different capabilities. Unless explicitly specified, all nodes in a cell are contained in a DefaultNodeGroup. However, as nodes are federated into the cell, they can be assigned to different node groups to distinguish the capabilities of different sets of nodes in the cell. For instance, if the DefaultNodeGroup for a cell contains distributed nodes, any zSeries nodes must be explicitly associated with a separate node group than nodes on other operating system platforms. There is a new -nodegroupname option on the addNode command for explicitly specifying the NodeGroup into which the node being federated should be placed.

Certain administrative operations require that the nodes involved are all compatible and belong to the same node group. When adding additional members to a WebSphere cluster, the nodes where the new cluster members reside must be from the same node group as the other servers in the cluster.


Conclusion

This article, the first in a series, provided an overview of the new system administration features in WebSphere Application Server V6.. Future articles in this series will explore management and administration issues in Version 6 in-depth. In particular, future articles will cover:

  • The incremental cell upgrade process
  • Profiles and the config archive
  • Redesigned Web server management
  • Application updates and the Rollout Application Update Tool
  • New admin command tasks
  • Windows integration of WebSphere Application Server V6
  • J2EE 1.4 support

WebSphere Application Server V6 builds value on top of the foundation put in place by WebSphere Application Server V5, and this series will help you become more familiar with Version 6 administration. Be sure to watch for subsequent articles in this series.

Resources

Tech Journal Series on WebSphere Version 5 System Administration

Other resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=33309
ArticleTitle=IBM WebSphere Developer Technical Journal: System management for WebSphere Application Server V6 -- Part 1
publish-date=01262005