Plan to install ND

 

+

Search Tips   |   Advanced Search

 

Overview

Consider common installation scenarios for IBM WAS ND (WAS ND) to determine how to install your application serving environment. This topic links to procedures for installing each scenario.

WAS ND is an integrated platform that contains...

• appserver
• Web development tools
• Web server
• additional supporting software

In V6.1, installation of WAS ND typically performs two actions. First the installation wizard installs a shared set of core product files. Second, the installation wizard optionally creates a profile.

A profile is a separate data partition that includes the files that define a runtime environment for an appserver process, such as a deployment manager or an appserver.

A running appserver process can create, read, update, or delete the configuration files, data files, and log files in its profile. The appserver process can access the system files, which include command files and other shared product binary files. However, most system files are updated only by installing fix packs, interim fixes, or products that extend ND.

During installation, you can choose to create...

• Application server profile
• Deployment manager profile
• Cell set of profiles (deployment manager and federated appserver)
• Custom profile

The installation wizard also has an option not to create a profile during installation. However, at least one profile must exist to have a functioning appserver environment.

After installation, use the Profile Management Tool to create additional profiles.

 

Scenarios for installation

The following information describes scenarios for installing the product in various topologies on one or more machines. Two types of WAS topologies are possible using the ND product:

1. Topologies for a stand-alone appserver

   Each stand-alone appserver has its own console and runs independently of other appservers. are described in this topic.

   • Scenario 1: Single-machine installation of a stand-alone appserver
   • Scenario 2: Single-machine installation of a stand-alone appserver and a Web server
   • Scenario 3: Two-machine installation of a stand-alone appserver and a Web server
   • Scenario 4: Two-machine installation of multiple stand-alone appservers and a Web server

2. Topologies for a managed group of appservers in a cell

   A cell consists of one deployment manager and one or more federated appservers that are managed nodes.A node can become a managed node in several ways:

   • By creating the cell with a federated node during installation

   • By federating the node within an appserver profile into the cell

   • By federating the node within a custom profile into the cell

   The deployment manager is the single point of administration for all of the managed nodes in the cell. The deployment manager maintains the configuration files for nodes that it manages and deploys applications to those managed nodes. The following topologies for a cell are described in this topic.

   • Scenario 5: Single-machine installation of a cell of appservers
   • Scenario 6: Single-machine installation of a cell of appservers and a Web server
   • Scenario 7: Two-machine installation of a cell of appservers and a Web server
   • Scenario 8: Three-machine installation of a cell of appservers and a Web server

   Scenarios 5, 6, 7, and 8 assume that all nodes in a cell reside on a particular machine and operating system. However, this precise node assignment does not need to apply. The deployment manager node can exist on Machine A, other managed nodes ( federated into the deployment manager) can exist on differing machines and operating systems. Such a configured cell of differing machines or operating systems is called a heterogeneous cell and expands the possible topologies you can consider for your network deployment.

 

Overview

Each of the following scenarios includes a diagram and a list of detailed installation steps.

Some scenarios are more typical in production environments. For example, Scenario 1 supports a lighter workload than Scenario 3 or Scenario 4. However, Scenario 1 is a fully functional environment. Scenarios 3 and 4 are typical production environments for a stand-alone appserver. Scenario 8 is a typical production scenario for a cell environment.

 

Procedure

• Scenario 1: Install a stand-alone appserver on a single machine.

  Installing WAS ND by itself on a single machine lets you create a stand-alone Application Server profile. Each stand-alone appserver profile includes a server1 appserver process. Installing ND creates the set of system files.

  The Profile Management Tool creates the profile for the appserver. The profile is a separate data partition with files that define the stand-alone Application Server environment.

  In this scenario, the appserver uses its internal HTTP transport chain for communication, which is suitable for handling an application with a relatively low request workload. For example, this type of installation can support a simple test environment or a departmental intranet environment.

  

  1. Install WAS ND.

     Create an appserver profile during the installation.

• Scenario 2: Install a stand-alone appserver and a Web server on a single machine.

  Installing a Web server, such as IBM HTTP Server, on the same machine as the appserver provides more configuration options. Installing a Web server plug-in enables the Web server to communicate with the appserver. This installation scenario supports rigorous testing environments or production environments that do not require a firewall. However, this scenario is not a typical production environment because everything is on one machine.

  

  1. Install WAS ND.

     Create an appserver profile during the installation.

  2. Install IBM HTTP Server or another supported Web server.

     While installing IBM HTTP Server, use its installation wizard to install the Web server plug-ins. After installing IBM HTTP Server, proceed to step 4.

  3. If you use another supported Web server or an existing installation of IBM HTTP Server, use the Plug-ins installation wizard to install the Web server plug-ins and configure the Web server. Because the Web server and the appserver are on the same machine, the Plug-ins installation wizard creates a Web server definition and you can skip step 4.

  4. Create a Web server definition using the console. Click...

     Servers | Web servers | New

• Scenario 3: Install a stand-alone appserver and a Web server on separate machines.

  In the typical production environment, the appserver on one machine communicates with a Web server on a separate (remote) machine through the Web server plug-in. Optional firewalls can provide additional security for the appserver machine.

  

  1. Install WAS ND on Machine A.

     Create an appserver profile during the installation.

  2. Install IBM HTTP Server or another supported Web server on Machine B. While installing IBM HTTP Server, use its installation wizard to install the Web server plug-ins.

  3. If you use another supported Web server or an existing installation of IBM HTTP Server, use the Plug-ins installation wizard to install the Web server plug-ins and configure the Web server on Machine B. The Plug-ins installation wizard creates a script named...

     plugins_root/bin/configureWebServerName

     ...on Machine B.

  4. Copy the configureWebServerName script on Machine B to the directory...

     app_server_root/profile_name/bin

     ...on Machine A.

  5. Run the configureWebServerName script on Machine A to create a Web server definition in the console. You can then use the console to manage the Web server.

  6. Propagate the plugin-cfg.xml file on Machine A from the appserver to the Web server using the console. Click...

     Servers | Web servers | WebServerName | Propagate Plug-in

     Web servers other than IBM HTTP Server require manual propagation.

• Scenario 4: Install multiple stand-alone appservers on one machine and a Web server on a separate machine.

  The Profile Management tool can create...

  • Deployment manager profile
  • Application server profile
  • Custom profile

  Each profile is a separate data partition containing the files that define the run-time environment. After creating a profile and installing a dedicated Web server, use the Plug-ins installation wizard to install a plug-in and to update the Web server configuration file. The Web server can then communicate with the appserver.

  This topology lets each profile have unique applications, configuration settings, data, and log files, while sharing the same set of system files. Creating multiple profiles creates multiple appserver environments that you can dedicate to different purposes.

  For example, each appserver on a Web site can serve a different application. In another example, each appserver can be a separate test environment that you assign to a programmer or a development team.

  Another feature of having multiple profiles is enhanced serviceability. For example, when a fix pack updates the system files, all appservers begin using the updated core product files.

  

  1. Install WAS ND on Machine A.

     Create an appserver profile during the installation.

  2. Install IBM HTTP Server or another supported Web server on Machine B. While installing IBM HTTP Server, use its installation wizard to install the Web server plug-ins.

  3. If you use another supported Web server or an existing installation of IBM HTTP Server, use the Plug-ins installation wizard to install the Web server plug-ins and configure the Web server on Machine B. The Plug-ins installation wizard creates a script...

     plugins_root/bin/configureWebServerName

     ...on Machine B.

  4. Copy the configureWebServerName script on Machine B to the directory...

     app_server_root/profile_name/bin

     ...on Machine A.

  5. Run the configureWebServerName script on Machine A to create a Web server definition in the console. You can then use the console to manage the Web server.

  6. Propagate the plugin-cfg.xml file on Machine A from the appserver to the Web server using the console. Click...

     Servers | Web servers | WebServerName | Propagate Plug-in

     Web servers other than IBM HTTP Server require manual propagation.

  7. Create subsequent Application Server profiles using the Profile Management tool on Machine A.

  8. Install subsequent IBM HTTP Servers or other supported Web servers on Machine B. While installing an IBM HTTP Server, use its installation wizard to install the Web server plug-ins.

  9. If you use another supported Web server or an existing installation of IBM HTTP Server, use the Plug-ins installation wizard to configure each additional Web server on Machine B. Installation of the Web server plug-ins creates a script...

     plugins_root/bin/configureWebServerName

     ...on Machine B.

  10. Copy the configureWebServerName script on Machine B to the directory...

      app_server_root/profile_name/bin

      ...on Machine A.

  11. Run the configureWebServerName script on Machine A to create a Web server definition in the console. You can then use the console to manage the Web server.

  12. On Machine A, propagate the plugin-cfg.xml file from the second appserver to the Web server using the administrative console. Click...

      Servers | Web servers | WebServerName | Propagate Plug-in

      Web servers other than IBM HTTP Server require manual propagation.

• Scenario 5: Install a cell of managed appservers on one machine.

  WAS ND can create a cell consisting of a deployment manager and one federated appserver node on a single machine. During installation choose to install the cell set of profiles.

  The Profile Management tool can create other stand-alone appserver profiles or custom profiles. You can use the administrative interface of the deployment manager to federate the additional servers to the cell.

  Stand-alone appserver profiles have their own administrative interface until you federate them into a deployment manager cell, at which point the administrative interface of the deployment manager controls the servers, or managed nodes. An appserver profile has a default appserver process called server1, and optionally might include the default application and Sample applications. A custom profile does not have a default server process nor does it have any applications.

  The deployment manager provides the administration for all managed nodes that are in its cell. Periodically the configuration and application files on a managed node refresh from the master copy of the files hosted on the deployment manager during synchronization.

  In a cell environment, only the managed nodes serve applications, not the deployment manager. The managed node in this scenario uses its internal HTTP transport chain for communication, which is suitable for handling few Web requests. For example, this type of installation can support a simple test environment or a departmental intranet environment.

  

  1. Install WAS ND.

     Create a cell environment during the installation. The cell environment creates a deployment manager profile and an appserver profile that is federated to the deployment manager cell.

  2. Start the deployment manager using its First steps console or by running...

     cd app_server_root/profile_name/bin
     startManager

  3. Start the console of the deployment manager using its First steps console.

  4. Start the node agent process by running...

     cd app_server_root/profile_name/bin
     startNode

  5. Use the console of the deployment manager to create and start appserver processes. Click...

     Servers | Application servers | Start

• Scenario 6: Install a cell of managed appservers and a Web server on one machine.

  Installing a Web server, such as IBM HTTP Server, on the same machine as the appserver provides more configuration options. Installing a Web server plug-in is required for the Web server to communicate with the server in the managed node. This type of installation can support either rigorous testing in a cell environment or production environments that do not require a firewall.

  

  1. Install WAS ND.

     Create a cell environment during the installation. The cell environment creates a deployment manager profile and an appserver profile that is federated to the deployment manager cell.

  2. Start the deployment manager using its First steps console or by running...

     cd app_server_root/profile_name/bin
     ./startManager

  3. Start the console of the deployment manager using its First steps console.

  4. Start the node agent process by running...

     cd app_server_root/profile_name/bin
     startNode

  5. Use the console of the deployment manager to create and start appserver processes. Click...

     Servers | Application servers | Start

  6. Install IBM HTTP Server or another supported Web server.

     While installing IBM HTTP Server, use its installation wizard to install the Web server plug-ins. After installing IBM HTTP Server, proceed to step 4.

  7. If you use another supported Web server or an existing installation of IBM HTTP Server, use the Plug-ins installation wizard to install the Web server plug-ins and configure the Web server. Because the Web server and the appserver are on the same machine, the Plug-ins installation wizard creates a Web server definition and you can skip step 4.

  8. Create a Web server definition using the administrative console. Click...

     Servers | Web servers | New

• Scenario 7: Install a cell of managed appservers on one machine and a Web server on a separate machine.

  In a typical production environment, a managed node in a cell communicates with a Web server on a separate (remote) machine through the Web server plug-in. An optional firewall can provide additional security for the appserver machine.

  

  1. Install WAS ND on Machine A.

     Create a cell environment during the installation. The cell environment creates a deployment manager profile and an appserver profile that is federated to the deployment manager cell

  2. Start the deployment manager using its First steps console or by running...

     cd app_server_root/profile_name/bin
     startManager

  3. Start the console of the deployment manager using its First steps console.

  4. Start the node agent process by running...

     cd app_server_root/profile_name/bin
     ./startNode

  5. Use the console of the deployment manager to create and start appserver processes. Click...

     Servers | Application servers | Start

  6. On Machine B, install IBM HTTP Server or another supported Web server.

     While installing IBM HTTP Server, use its installation wizard to install the Web server plug-ins.

  7. If you use another supported Web server or an existing installation of IBM HTTP Server, use the Plug-ins installation wizard to configure each additional Web server on Machine B. Installation of the Web server plug-ins creates a script...

     plugins_root/bin/configureWebServerName

     ...on Machine B.

  8. Copy the configureWebServerName script on Machine B to the directory...

     app_server_root/profile_name/bin

     ...on Machine A.

  9. Run the configureWebServerName script on Machine A to create a Web server definition in the console. You can then use the console to manage the Web server.

  10. On Machine A, propagate the plugin-cfg.xml file from the second appserver to the Web server using the console. Click...

      Servers | Web servers | WebServerName | Propagate Plug-in

      Web servers other than IBM HTTP Server require manual propagation.

• Scenario 8: Install a deployment manager on one machine, multiple managed appserver nodes on a second machine, and a Web server on a third machine.

  The primary advantage of a cell over a stand-alone appserver is its scalability. Managing a cell to keep it in proportion with workload levels is possible. In this scenario, managed nodes exist on Machine C. All of the managed nodes are federated into the same deployment manager. Depending on your needs, an appserver in each managed node could serve the same or different applications. Machine A and Machine C represent both types of scaling, vertical and horizontal scaling:

  • Vertical scaling creates multiple managed nodes on the same physical machine.

  • Horizontal scaling creates cell members on multiple physical machines.

  The managed nodes in this scenario communicate with the same Web server. However, an alternative strategy could have a dedicated Web server for each managed node.

  

  1. Install WAS Network Deploymenton Machine A.

     Create a deployment manager profile during the installation.

  2. Start the deployment manager using its First steps console or by running...

     cd app_server_root/profile_name/bin
     ./startManager

  3. Install WAS Network Deployment on Machine C.

     Create an appserver profile during the installation.

  4. On Machine C, start the first appserver using its First steps console or by running...

     cd app_server_root/profile_name/bin
     startServer server1

  5. On Machine C, create a second appserver profile using the Profile Management Tool.

  6. Start the second appserver using its First steps console or by running...

     cd app_server_root/profile_name/bin
     startServer server1

  7. On Machine A, add both appserver nodes to the cell using the console of the deployment manager. Click...

     System Administration | Nodes | Add Node

  8. On Machine B, install IBM HTTP Server or another supported Web server.

     While installing IBM HTTP Server, use its installation wizard to install the Web server plug-ins.

  9. If you use another supported Web server or an existing installation of IBM HTTP Server, use the Plug-ins installation wizard to configure each additional Web server on Machine B. Installation of the Web server plug-ins creates a script

     plugins_root/bin/configureWebServerName

     ...on Machine B.

  10. Copy the configureWebServerName script on Machine B to the directory...

      app_server_root/profile_name/bin

      ...on Machine A.

  11. Run the configureWebServerName script on Machine A to create a Web server definition in the console. You can then use the console to manage the Web server.

  12. On Machine A, propagate the plugin-cfg.xml file from the second appserver to the Web server using the administrative console. Click...

      Servers | Web servers | WebServerName | Propagate Plug-in

      Web servers other than IBM HTTP Server require manual propagation.

 

Results

Following this procedure results in reviewing common installation scenarios to find a possible match for the topology that you intend to install. Each high-level procedure shows the installation order for the components that comprise the topology.

 

What to do next

After determining a possible topology, follow the steps in the overall procedure.

One step not mentioned in any of these scenarios is to prepare the operating system for installation. Useful links to the installation procedures for each installable component are in the list of related topics.

---

 

Related information

Planning the installationInstalling the product and additional software
Preparing the operating system for product installation
Creating profiles through the graphical user interface
Installing IBM HTTP Server
Installing Web server plug-ins
startManager command
startServer command