A multinode environment places WebSphere Application Server processes on separate physical machines, under the central management of the deployment manager process, which groups application servers into its managed cell.
Before you begin
You must have the Network Deployment product to create a cell of managed application server processes. The number of application server nodes that you can create and add to the deployment manager cell is limited only by the hardware on which the nodes run.
The physical requirements of nodes on a single machine are cumulative. See the Supported hardware and software Web site for a description of machine requirements.
A good practice is to create an initial number of application server nodes on one machine and add the nodes to the deployment manager that is running on a separate machine. Stress test the performance of the application server nodes on a particular machine by using the applications that are installed on each application server. If performance is good, you can add more nodes on the machine. If performance is poor, remove nodes from the machine.
Why and when to perform this task
Setting up a Network Deployment environment involves performing several steps on each of the systems that comprise the cell. This procedure describes how to set up a deployment manager cell. The reason why you must define a cell is so that you have a single point of management for all of the application server nodes that you add into the cell. Use the administrative console of the deployment manager cell to manage all of the nodes in a cell.
Steps for this task
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 WebSphere Application Server Standard Edition (Version 3.5.x) or WebSphere Application Server Advanced Edition (Versions 3.5.x or 4.0.x).
It is not necessary to start the administrative server for WebSphere Application Server Advanced Single Server Edition, Version 4. The migration tools use the XMI configuration files directly.
Install the base WebSphere Application Server 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 WebSphere Application Server product more than once on a single machine. Coexistence is supported. See Setting up Version 5 coexistence. There are several ways to federate a stand-alone Application Server installation instance into the deployment manager cell. See Federating multiple Version 5 installation instances.
You can install the base WebSphere Application Server 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. See Creating multiple Version 5 configuration instances. Each deployment manager configuration instance can federate stand-alone base WebSphere Application Server product installation instances, but a deployment manager cannot federate base product configuration instances.
Migrate applications, security settings, and the remaining configuration from WebSphere Application Server, Version 3.5.x and later, or WebSphere Application Server, Version 4.0.x and later. You can also choose to coexist with WebSphere Application Server, 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 WebSphere Application Server product, which is available from the information center for the WebSphere Application Server 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.
As the deployment manager federates base WebSphere Application Server nodes, it expands the cell that it manages. Although you can install a base WebSphere Application Server 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 WebSphere Application Server 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 WebSphere Application Server, Version 3.5.x and later, or WebSphere Application Server, Version 4.0.x and later. You can also choose to coexist with WebSphere Application Server, Versions 3.5.5 and later, or Versions 4.0.2 and later. Migration and coexistence are described in the installation procedure for the WebSphere Application Server Network Deployment product. See Installing the product.
There are two ways to start the deployment manager:
Run the startManager.sh or startManager.bat script 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.
Alternatively, you can use the addNode.bat script.
The addNode command incorporates a base WebSphere Application Server 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 -includeappsThe 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 Java Message Service (JMS) provider that WebSphere Application Server 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. See Using the administrative console.
Load existing application components and modules into your development environment and debug them.
Follow normal test procedures as you move the test environment into production. Review the information in the Migrating topic to understand what you must look for. In particular, review the table at the end of the topic that links you to specific recommendations and practices.
You must configure your migrating applications to verify that they migrate correctly, as described in Configuring WebSphere Application Server after migration.
Results
You can create a working WebSphere Application Server cell.What to do next
Use the administrative console as described in Using the administrative console, or use other administrative tools, as described in Welcome to System Administration, 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.