Deployment Manager

The Deployment Manager is commonly regarded as a single point of failure from a systems management point of view in a WAS environment. Note that it is not considered a single point of failure when considering the runtime functionality of the application servers in the cell. Still, making the Deployment Manager available using HACMP is a sensible idea.


Installation

To install the Deployment Manager and create the profile, do the following:

  1. Start the HACMP services on the first LPAR and mount the shared file system.

  2. Install IBM WAS Network Deployment V6 on the first LPAR. The installation path must be on the shared file system.

  3. If necessary, install any needed WebSphere Refresh Packs or Fix Packs. (WebSphere Install Factory can be used to streamline this process.)

  4. Create a Deployment Manager profile on the first LPAR. The profile directory should be a subdirectory of the WebSphere <install_root>, which is on the shared file system. If we select a different profile directory, then ensure that it is on the shared file system. When creating the profile, use the virtual host name as the Host name. Do not use the physical host name or physical IP address.

  5. Start the Deployment Manager and add nodes to the cell as needed. Use the virtual host name when you specify the Host name or IP address of the Deployment Manager.


Configuration

To configure HACMP to run the Deployment Manager, do the following:

    Add the Deployment Manager stop and start commands to the respective HACMP stop (ha.stop) and start (ha.start) scripts on both LPARs. The Deployment Manager stop and start scripts can be quite simple, calling existing scripts to stop and start.

    For example, the stop script could call as follows:

    /usr/WebSphere6/AppServer/profiles/Dmgr01/bin/stopManager.sh

    The start script could call as follows:

    /usr/WebSphere6/AppServer/profiles/Dmgr01/bin/startManager.sh

  1. Verify the HACMP services are active on the second LPAR.


Testing

Because the Deployment Manager is not required for client access to the application, failover should be completely transparent to clients. Administrative clients may not be able to administer the system while the failure is in place.

It would be prudent, at a minimum, to test the following failover scenarios: