[V5.1 and later]Establishing multimachine environments

 

Setting up a Network Deployment environment involves several steps performed on each of the systems that comprise the cell.

  1. (Optional)   Start the administrative server from an earlier version of WAS.

    If you intend to migrate the applications and configuration from an earlier version, you might need to start the administrative server so that the installation wizard can use XMLConfig to export the configuration data repository as it performs the automated migration that you can select in the next step.

    Start the administrative server of WAS Standard Edition (V3.5.x) or WAS Advanced Edition (Versions 3.5.x or 4.0.x).

    It is not necessary to start the administrative server for WAS Advanced Single Server Edition, V4. The migration tools use the XMI configuration files directly.

  2. Install the base WAS product on each machine to create a WAS node on the machine.

    Install the base WAS product for the machine to become a node in the cell. The installation procedure is the same for a node that federates into a cell as it is for a stand-alone Application Server. You can install the base WAS product more than once on a single machine using coexistence.

    There are several ways to federate a stand-alone Application Server installation instance into the deployment manager cell.

    You can install the base WAS product once and create multiple configuration instances on the machine, using the wsinstance command. You can also install the Network Deployment product once and create multiple configuration instances of the deployment manager. Creating multiple V5 configuration instances. Each deployment manager configuration instance can federate stand-alone base WAS product installation instances, but a deployment manager cannot federate base product configuration instances.

    Migrate applications, security settings, and the remaining configuration from WAS, V3.5.x and later, or WAS, V4.0.x and later. You can also choose to coexist with WAS, Versions 3.5.5 and later, or Versions 4.0.2 and later. Both migration and coexistence are described in the installation procedure for the base WAS product, which is available from the information center for the WAS product.

    Stop the administrative server from the earlier version before you perform the installation verification test, which starts the new server. This avoids potential port conflicts.

  3. Install the WAS Network Deployment product on a machine. Only one system hosts the deployment manager.

    As the deployment manager federates base WAS nodes, it expands the cell that it manages. Although you can install a base WAS on the same machine as the deployment manager, it is not usual in a production environment unless you have a machine with the capacity to host both products.

    The deployment manager is the central administrative manager. It does not install the base WAS product on other machines. The only functions supported in the Network Deployment installation are the deployment manager and its associated administrative programs.

    Migrate applications, security settings, and the remaining configuration from WAS, V3.5.x and later, or WAS, V4.0.x and later. You can also choose to coexist with WAS, Versions 3.5.5 and later, or Versions 4.0.2 and later. Migration and coexistence are described in the installation procedure for the WAS Network Deployment product.

  4. Start the deployment manager process.

    There are two ways to start the deployment manager:

    Run startManager.sh from the /bin directory of the installation root of the deployment manager.

    For production systems, running the deployment manager as a monitored process is recommended.

  5. Run the addNode command script on every node that you plan to federate into the cell.

    The addNode command incorporates a base WAS product node into a deployment manager cell. You must run this tool on every system that you plan to make part of a Network Deployment cell. There are several parameters for the addNode command, but the most important are includeapps, the host name of the deployment manager node, the JMX connector type, and the JMX port of the deployment manager node.

    For example:

    ./addNode.sh wasdoct 8889 -includeapps

    The example adds the base node on which the command runs to the cell managed by the wasdoct deployment manager node, using the default SOAP JMX connector type at port 8889. (Port 8889 is a coexistence value for the SOAP port. On the wasdoct development machine, the base node uses the default SOAP port.) The command adds all applications on the base node into the cell configuration.

    As it federates the base node in response to the addNode command, the deployment manager also instantiates the node agent process, nodeagent, on the Application Server node. If you installed the embedded messaging server feature on the base node, the deployment manager instantiates the JMS provider that WAS provides, as the jmsserver process on the base node.

    Alternatively, you can use the administrative console of the deployment manager to add running Application Server nodes to the cell.

  6. Enable the appropriate level of security after the installation is complete.

  7. Develop and unit test application components

    Load existing application components and modules into your development environment and debug them.

  8. Assemble code into a main application module or EAR file

  9. Start all servers in the test environment

  10. Deploy your applications in the test environment

  11. Test all applications thoroughly

    Follow normal test procedures as you move the test environment into production. Review the information in the Migrating topic to understand what look for. In particular, review the table at the end of the topic that links you to specific recommendations and practices.

    Configure your migrating applications to verify that they migrate correctly

  12. Prepare and monitor the environment into which you deploy applications

  13. Adjust application code, configurations, and system settings to improve performance

  14. Fix any known problems

  15. Set up your production system by configuring all server processes for monitoring by their operating systems

Use the administrative console or use other administrative tools to observe and control the incorporated nodes, and the resources on these nodes. The console provides a central location for configuring, monitoring, and controlling all Application Servers on all nodes within the cell.

 

Related tasks

  1. Setting up a multinode environment
  2. Migrating and coexisting
  3. Creating servers in coexistence or multiple instance environments
  4. Changing HTTP transport ports
  5. Automatically restarting server processes
  6. addNode command
  7. removeNode command
  8. serverStatus command
  9. startNode command
  10. startServer command
  11. stopNode command
  12. stopServer command
  13. startManager command
  14. stopManager command
  15. Port number settings in WAS versions