Setting up of a highly available HTTP Server

Set up and administer highly available IBM® HTTP Server for i instances using the IBM Web Administration for i interface.

All required programs (HTTP Server, WebSphere®, Servlets, Net.Data®, and Clustering support) must already be installed on all nodes. See Highly available HTTP Server for more information.

Step 1 - Configure the IBM i Cluster

For each node, configure your cluster. See Configuring clusters for more information. Then continue to step 2.

Step 2 - Configure IP addresses

For each IBM i node in the cluster that a highly available Web server will be running on, configure the IP address that the Web server will be using. This can be done using the CFGTCP CL command. You should configure one IP address for each unique Web server. Each Web server is configured to a dedicated TCP/IP line interface. When using the Network Dispatcher model or comparable IP director with either HAModel IPTakeoverWithDispatcher of PurePeer model, the IP Line interface should be typed *VIRTUALIP. See TCP/IP for more information.

  1. Start the Web Administration for i interface.
  2. Click the Manage tab.
  3. Click the HTTP Servers subtab.
  4. Select your HTTP Server from the Server list.
  5. Select the context you want to work with from the Server area list.
  6. Expand Server Properties.
  7. Click General Server Configuration.
  8. Click the General Settings tab in the form.
  9. Click Add under the Server IP addresses and ports to listen on table.
    Note: Directive HotBackup will be set to off and ignored if currently configured for your HTTP Server.
    You may want to perform the next steps on one IBM i server and copy (for example using FTP or NetServer) the HTTP Server configuration and instance files to each IBM i server where the highly available HTTP Server will be running in the cluster. The files that must be copied are:
    • /www/server_name/conf/server_name.conf
    • /QSYS.LIB/QUSRSYS.LIB/QATMINSTC.FILE/instance_name.MBR
  10. Add the IP address the highly available Web server will be running on.
  11. Click OK.
  12. Continue to step 3.

Step 3- Configure the highly available HTTP Server

  1. Start the Web Administration for i interface.
  2. Click the Manage tab.
  3. Click the HTTP Servers subtab.
  4. Select your HTTP Server from the Server list.
  5. Select the context you want to work with from the Server area list.
  6. Expand Server Properties.
  7. Click System Resources.
  8. Click the Highly Available Server tab in the form.
  9. Specify one specific server IP address to listen on.
  10. Click Enable HTTP server to be highly available.
  11. Select a highly available model.
    Note: If you are implementing the primary/backup with network dispatcher model or the peer model, configure the network dispatcher according to the existing cluster nodes and the configured Web server.
  12. Optional: Click Enable highly available CGI program.
  13. Enter your liveness monitor settings. The LMUrlCheck directive is required. The other LM directives have defaults.
  14. Click OK.
  15. Continue to step 4.

Step 4- Start the highly available HTTP Server

Start your highly available HTTP Server.

  1. Start a 5250 session on the IBM i server that will contain a highly available HTTP Server instance.
  2. Use STRTCPSVR CL command on the appropriate node.
  3. Continue to step 5.
Note: In the case of the primary/backup model, the first highly available server to be started will automatically assume the role of the primary. The second highly available server to be started will automatically assume the role of the backup.

Step 5- Manage your highly available HTTP Server

Use the ENDTCPSVR CL command on the appropriate node or use the IBM Simple Cluster Management interfaces to stop or end your highly available HTTP Server. In the case of primary/backup model depending on which server you are ending this may or may not force a fail over. Ending the primary server with a backup server running will force a fail over from primary to backup to occur. Ending the backup will only affect the backup server. Ending the primary server with no backup will end the primary server. In the case of PurePeer model only the server you are ending will be affected as any other peer servers will continue to process client requests.

Note: In the case of primary/backup model, it is possible to determine which highly available Web server is the primary or backup server. The QBATCH subsystem will have a job running named QZHBEXPG on the primary node only. For the client data it is suggested that you set up a method to automatically publish static files to each Web server. Static files include HTML and highly available CGI programs.