Previous | Home | Next


Work with deployment manager

Deployment manager configuration settings

A deployment manager is built by creating a deployment manager profile. After it is built, there is usually not much needed to do regarding the configuration of the deployment manager. However, there are settings that we can modify from the administration tools:

To view the deployment manager from the dmgr console, click System administration | Deployment manager. You have two pages available, the Runtime tab and the Configuration tab.

The four options on this window to note are:


Deployment manager Runtime tab

The dmgr console contains a Runtime tab for the deployment manager. To view the Runtime tab, click System administration | Deployment manager, and click the Runtime tab at the top of the page.

The state is Started; otherwise, we cannot access the dmgr console. The items on this window panel to note, are:


Other common deployment manager configurations

In busy environments, you might consider adjusting the maximum file size and the maximum number of the historical log files for the JVM logs of the deployment manager process. To do this, change the file size values of the System.out and System.err and the maximum number of historical log files to be saved.

Consider having all of your server logs in a file system outside of the default location by setting...

Sometimes, for example, when we have a large cell with many managed nodes and applications, you need more memory for the deployment manager process to run in the java run time. In this case, adjust the values of the initial heap size and maximum heap size properties in the Configuration tab of the Deployment manager | Process definition | JVM window. The default value for the maximum heap size is 256 MB.


Start and stop the deployment manager

The deployment manager can be started and stopped using command line utilities (commands). The dmgr console is not available unless the deployment manager is running.


Starting the deployment manager with startManager

The startManager command is used to start the deployment manager on distributed systems.

Run this command from the deployment manager PROFILE_HOME/bin directory. If you run it from the INSTALL_ROOT/bin directory, use the -profileName parameter to ensure the command is run against the deployment manager profile.

The syntax of the startManager command is:

startManager options... 

Usage: startManager [options]
 
options: 
    -nowait
    -quiet 
    -logfile <filename> 
    -replacelog 
    -trace 
    -script [<script filename>] [-background] 
    -timeout <seconds> 
    -statusport <portnumber> 
    -profileName <profile> 
    -recovery 
    -help
All arguments are optional.


Starting the deployment manager on z/OS (START command)

On z/OS, the deployment manager can be started using a JCL start procedure. The exact command can be found in the BBOCCINS instruction member of the JCL generated to create the profile. For example:

The meaning of the command syntax is:

Starting the deployment manager also starts the following components:

daemon In our example, it is named WPDEMN. There is one daemon per cell, per MVS image. One of the functions of the daemon server is to provide the location name service for the cell. All daemons in the cell are fully aware of all of the objects in the cell and use the same port values.
controller region In our example, it is named WPDMGR. The controller region serves many functions, including acting as the endpoint for communications.
servant region In our example, it is named WPDMGRS. The servant region contains the JVM where the applications are run.

  • If we are using messaging, we can also see a control region adjunct the server start. Stopping the deployment manager

    The deployment manager is stopped with the stopManager command. If administrative security is enabled, provide an administrative user name and password for the command. We can provide this information using the -username and -password options on the command line. If we do not provide the options on the command line, you are prompted to provide credentials.


    stopManager command

      PROFILE_HOME/bin/stopManager.sh
      ADMU0116I: Tool information is being logged in file PROFILE_HOME/logs/dmgr/stopServer.log
      ADMU0128I: Starting tool with the dmgr_85_01 profile
      ADMU3100I: Reading configuration for server: dmgr
      ADMU3201I: Server stop request issued. Waiting for stop status.
      ADMU4000I: Server dmgr stop completed.


    Syntax of stopManager

    The syntax of the stopManager command is:

      stopManager.bat(sh) [options]

    startManager options 

    Usage: stopManager [options]

 options: 
    -nowait
    -quiet
    -logfile <filename>
    -replacelog
    -trace 
    -timeout <seconds>
    -statusport <portnumber>
    -conntype <connector type>
    -port <portnumber>
    -username <username>
    -password <password>
    -profileName <profile>
    -help

    All arguments are optional.


    Stopping the deployment manager on z/OS (STOP command)

    To stop the deployment manager with a STOP command, use the following format:

      STOP dmgr_job

    For example:

      STOP WPDMGR

    Stopping the daemon server also stops all servers for that cell, and all the servers on that daemon instance’s MVS image are stopped in an orderly fashion, one by one. For example:

      STOP WPDEMN


    Windows start menu and services

    On a Windows system, we have the option of starting and stopping the deployment manager using the Start menu, for example, click...

      Start | All Programs | IBM WebSphere | IBM WAS ND V8.5 | Profiles | profile_name | Start the deployment manager

    Also, on a Windows system, we have the option of registering the deployment manager as a Windows service. To have it registered, select this option when you create the deployment manager profile or register it later using the WASService command.

    If the deployment manager is registered as a Windows service, all other options for starting the dmgr process are unchanged from the administrator's point of view. However, the command used starts or stops the process through the Windows service. In addition, we have the option to allow the service to be started automatically when the operating system starts.


    The high-availability deployment manager function

    The high availability (HA) deployment manager function is configured using a shared-file system. When this configuration option is chosen, multiple deployment managers are configured. The benefit of the HA deployment manager function is the deployment manager is no longer the single point of failure for cell administration. This is important in environments relying on automated operations, including application deployment and server monitoring.

    The deployment managers exist as peers. One is considered active, also known as primary, and hosts the administrative function of the cell. The others are backups in standby mode. If the active manager fails, a standby takes over and is designated the new active deployment manager. A command line utility is provided to clone the original cell deployment manager into additional deployment managers. Each deployment manager is installed and configured to run on a different physical or logical computer. The deployment managers need not be hosted on homogenous operating platforms, although like platforms are recommended. Each deployment manager shares the same instance of the master configuration repository and workspace area. These must be located on a shared file system.

    The file system must support fast lock recovery. The IBM General Parallel File System (GPFS) is recommended, and the Network File System Version 4 (NFS) is also an option. If you use the high-availability deployment manager on AIX v5.3 and are using NFS Version 4, have bos.net.nfs.client version 5.3.0.60 or later.

    Normal operation includes starting at least two deployment managers. A new highly-available deployment manager component runs in each deployment manager to control which deployment manager is elected as the active one. Any other deployment manager in the configuration is in standby mode. The on demand router (ODR) is configured with the communication endpoints for the dmgr console, wsadmin, and scripting. The ODR recognizes which deployment manager instance is active and routes all administrative communication to that instance. The HA deployment manager function supports only use of the JMX SOAP connector. The JMX RMI connector is not supported in this configuration.