WebSphere Network Deployment

WebSphere Network Deployment is the version that is needed for high-availability features such as clustering. WebSphere Application Server is for single-server only.
WebSphere Network Deployment topology Tips for installation

Verify that the clocks on the host machines are in sync, including all machines involved in the cluster such as WebSphere and database hosts. If the clocks are not in sync the installation will throw an error midway. Verify that /var has a lot of disk space. Be safe and give it at least 3GB. WebSphere installer needs to write to this partition during installation.

Overview of Installation

The WebSphere high-availability environment divides the duties of server administration (managed servers) and clustering (sharing of resources at runtime between applications). So during installation you configure a set of managed servers. After the managed servers are up and running you configure a cluster. Here are a few relevant terms: Deployment Manager - this process sits in front of all the servers and is used for ALL administration of a application server such as start/stop, environment variables, data sources, certificates, etc. If there is some administration of an application server to be done then you should go to the console tool and find the function there. The console tool is accessed at http:// host:9060/ibm/console. Cell - a group of managed nodes Node - a host machine that has one or more application servers running on it. In our case, we are running one application server on each host. Node Agent - this process sits in front of the application server and listens for requests from the deployment manager. So this agent is how all the remote administration of the application server occurs. Application server - same as always, it serves the IDMProv.war The installation overview is: 1. Install the first server and choose to install a Cell. When installation is finished you'll have a deployment manager and one node with an application server named "server1". 2. Install the second server, in our case on a second host machine. Choose a Custom profile and choose to add this node to the cell during installation by specifying the deployment manager host and port. 3. After second server installation finishes go to the console tool, under Servers/Applicaton servers, and create a new application server. This process actually creates the application server that you just installed and now it is a member of the cell! 4. To configure the cluster go to the console under Servers/Cluster and choose New to create the new cluster. 5. Add the servers into the cluster as cluster members located on different or same node. 6. Need to pass the engine ID to the application servers the same way as sys-configurationxmldata.xml(add it as a custom properties of JVM for the server). Need to set

com.novell.afw.wf.engine-id=myengineid.

7.

For cluster give cluster server1 Engine1 and server2 Engine2.

Configuring Session Failover on WebSphere Create a cluster. A Replication Domain will be created for you when you create a cluster or else create a new one. 3. For each server and member of the cluster you need to: 1. Go to Session Management 2. Enable Cookies 3. Choose the "Enable Cookies" link to go into configuration of cookie. 4. Set the cookie domain to: .novell.com 5. Go back up and choose Session Management/Distributed Environment Settings. 6. Click on the Memory-to-Memory replication Link. The option is probably greyed out by default. The reason is because you must go into these options and choose them explicitly in order for them to take effect even if you are keeping the defaults!! Without this step you'll get messages that say you've chosen memory-to-memory replication but have not chosen any options. 7. Keep the default settings and click Apply. 8. Now go back and Memory-to-Memory replication will be enabled and no longer greyed out. HINT! If you try to log in to UserApp and you keep getting thrown back to the login page the reason is because your URL does not have the domain you specified for cookies. That is, if you set cookies above to have .novell.com and you are hitting http://164.99.218.103:9080/IDMProv or http://silvercharm:9080/IDMProv, the IP address or short name for the host then try the fully qualified name of http://silvercharm.qalab.cam.novell.com:9080/IDMProv.
1. 2. To turn on logging of HTTP Session handling in WebSphere

Go to Application Servers/servername/Diagnostic and Trace/Runtime/Change Log Level Details. 2. Add: com.ibm.ws.webcontainer.httpsession.*=all Here are some messages to grep for in trace.log: Server1 down (look in server2 trace.log): (grep for "membership changed") [7/26/07 11:36:36:359 EDT] 00000025 DRSBuddyManag A CWWDR0007I: Replication instance group membership changed: sunfireCell01\sunfireNode01\server1 [7/26/07 11:36:36:367 EDT] 00000025 DRSBuddyManag A CWWDR0006I: Replication instance terminated : sunfireCell01\sunfireNode01\server1 Server1 rejoins cluster: (grep for "membership changed") [7/26/07 9:49:16:247 EDT] 00000026 DRSBuddyManag A CWWDR0007I: Replication instance group membership changed: sunfireCell01\sunfireNode01\server1 [7/26/07 9:49:16:260 EDT] 00000026 DRSBuddyManag A CWWDR0002I: Replication instance is active : sunfireCell01\sunfireNode01\server1 User hits server1 first time: (Grep for "setCookie" to locate the whole block which starts prior to setCookie) [7/26/07 11:33:50:813 EDT] 0000004e SessionContex 3 SessionContext.setCookie :0001mMnyDdaDRs0P9gL6QeYkjE2:3EOLVVQFFP
1.

Session is found on server2 for user begins with this sequence: [7/26/07 11:36:48:245 EDT] 0000005b SessionContex < SessionContext.getRequestedSessionIdFromCookie returning 0001mMnyDdaDRs0P9gL6QeYkjE2:3EOLVVQFFP Exit

1.2 Install MS SQL

Install MS SQL according to manufacturers instructions and create a database. Enable the database for UTF-8. Continue with the following steps to configure and deploy the IDM environment.

Add and configure the DB2 driver on WebSphere

1 Copy the sqljdbc.jar file to E:\IBM\WebSphere\AppServer\deploytool\itp\plugins\com.ibm.datatools.dbdefinition.sqlserver_2.0.0.v200803311827(for websphere7.0)on the machine hosting the WebSphere server.

1.4 Create JDBC Provider

1 Log in to the WebSphere administrators console as an admin user. 2 From the left panel, go to Resources > JDBC > JDBC Providers. 3 Select the scope at which applications can use the JDBC provider. For clusters, select Cell from the dropdown list, for example Cell=blazerCell01. 4 Click New to start the wizard to create a new JDBC provider. 5 In the Create a new JDBC provider screen, use the first dropdown list to select SQL Server as the Database Type. 6 Use the second dropdown list to select Microsoft SQL Server JDBC Driver as the Provider Type. 7 Use the third dropdown to select Connection pool data source as the Implementation type. Other types might also be used, but this is what we used for testing. Connection pool data source supports only 1-phase commit. So if you need two-phase commit, you must choose a different option. 8 Type a Name for the JDBC provider, for example MS SQL Server JDBC Driver. 9 Click Next to move to the Enter database class path information screen. 10 Provide the directory location for the sqljdbc.jar file and library path. 11 Leave everything else as the defaults and click Next to move to the Summary screen. 12 Review the Summary screen and click Finish.

1.5 Create a Data Source

1 Log in to the WebSphere administrators console as an admin user. 2 From the left panel, go to Resources > JDBC > Data sources. 3 In the Enter basic data source information screen, select the scope at which applications can use the data source. Choose Cell from the dropdown list, for example Cell=blazerCell01. 4 Click New to start the wizard to create a new data source. 5 For Data source name, enter the name that identifies the data source, for example MS SQLDataSource. This name is used only for administration. 6 For the JNDI name, enter a JNDI name for the data source, for example MS SQLJNDI. This name identifies the data source during configuration of the User Application deployment. NOTE: Remember to assign unique JNDI names within the same scope, or across different

resource types. 7 For the Component-managed authentication alias dropdown, you must first create a new J2C authentication alias. To create a new alias, click on the link just above the dropdown that says create a new J2C authentication alias. This action closes the data source wizard and displays the J2C authentication data page instead. 8 Click New to create a new alias. 9 For the alias name, enter a name to identify the alias, for example MS SQLAlias. 10 For the User ID, enter a username, for example sa, on the database server that has access to the database you will be connecting to on the MS SQL server. 11 For the Password, enter the password for the user you entered above. 12 For the Description, enter a description to describe the alias, for example MS SQL Alias . 13 Click OK to save the alias. 14 Once the component-managed authentication alias has been created, restart the data source wizard by using the left panel to navigate back to Resources > JDBC > Data sources. 15 Click New to start the wizard again for creating a data source. 16 Re-enter the Data source name and JNDI name, if needed. 17 Then in the Component-managed authentication alias dropdown, select the alias you just created, for example MyServerNode01/MS SQLAlias. 18 Choose to select an existing JDBC provider. 19 In the existing JDBC provider dropdown, select the JDBC provider you created earlier, for example MS SQL Universal JDBC Driver Provider. 20 Click Next to move to the Enter database specific properties for the data source screen. 21 For the database name, enter the name of the database on the MS SQL server that you are using for the User Application. This database should already be created, and the user specified in that alias should have been granted rights to the database.Click next to move to Setup security aliases screen. 22 Then in the Component-managed authentication alias dropdown, select the alias you just created, for example MyServerNode01/MS SQLAlias and for Mapping-Configuration alias select Default Principle Mapping and give created alias for Container managed authentication alias. 23 For the Server name, enter the name of the MS SQL server. 24 For the Port number, enter the port number on which the MS SQL server is running, for example 1433 25 Leave everything else as the defaults and click Next to move to the Summary screen. 26 Review the Summary screen and click Finish. 1. Check the newly created Data Source and Click Test Connection to verify the connectivity.

Add User Application configuration files and JVM system properties

1 Copy the sys-configuration-xmldata.xml file and the idmuserapp_logging.xml file to a directory, for example /UserAppConfigFiles, on the machine hosting the WebSphere server. 2 Set the path to these files in the JVM system properties. Log in to the WebSphere admin console as an admin user to do this. 3 From the left panel, go to Servers > Application Servers 4 Click on the server name in the server list (probably server1 if you only have one installed), for example server1. 5 In the list of settings on the right, go to Java and Process Management under Server Infrastructure. 6 Expand the link and select Process Definition. 7 Under the list of Additional Properties, select Java Virtual Machine. 8 Then select Custom Properties under the Additional Properties heading for the JVM page. 9 Click New to add a new JVM system property. a. For the Name, enter extend.local.config.dir.

b. For the Value, enter the directory, for example /UserAppConfigFiles, where you copied the sys-configuration-xmldata.xml file and the idmuserapp_logging.xml c. For the Description, enter a description for the property, for example path to sysconfigurationxmldata.xml. d. Click OK to save the property. 10 Click New to add another new JVM system property.

file.

a. For the Name, enter idmuserapp.logging.config.dir b. For the Value, enter the directory, for example /UserAppConfigFiles, where you copied the sys-configuration-xmldata.xml file and the idmuserapp_logging.xml file.
c. For the Description, enter a description for the property, for example path to sysconfigurationxmldata.xml i. Click OK to save the property.

Import the eDirectory trusted root to the WebSphere keystore

2 3 4 5 6 7. 8. 9. 1. Then, log in to the WebSphere administrators console as an admin user. From the left panel, go to Security > SSL certificate and key management Under the list of Related Items, select Key stores and certificates. Click on CellDefaultTrustStore. Now go to Additional Properties -> Signer Certificates. Click Add to import new signer certificate. Give an alias name in General Properties screen. Give the name with complete path of the ceritificate file(O=IDM-M2, OU=Organizational CA-1.der). Say apply and then save to save the configuration.

Installing the IBM HTTP SERVER (IHS) Procedure

1. 2. 3. 4. 5. 6.

7. 8. 9.

Launch the Installation wizard for IBM HTTP Server from the network deployement launchpad. Click Next to go to License screen. Verify the system prerequisite check and install the appropriate Service pack if it failed. Click next to go to the next screen. Specify the Product Installation Location and click next screen to go to Port Value Assignment screen. Specify the HTTP port and click next to move to Windows Service Definition screen. Choose different options to IBM HTTP Server and Administration according to your Scenario(for websphere cluster we have chosen both to run as windows service and Logon as local system account) click next to move to HTTP Administration Server Authentication screen. Create a userid and password to authenticate to the IBM HTTP server administration server using the websphere application server administrative console. Don't Install IBM HTTP Server plugin for IBM Application server with this installation we will install it separately. Click Next on Installation summary screen to start the installation.

Results The IBM HTTP Server is installed. Note: IBM HTTP server and Webserver Plugins are located on supplement disk (C1G2HML), this is required for install.

Installing the Webserver Plugins

For IBMHTTP server we can choose the option while installing IHS to install the plugins. The Plug-ins installation wizard installs the plug-in module, configures the Web server for communicating with the application server, and creates a Web server configuration definition in the application server(for which we need to run the script configurewebserver.bat or can use the ws console). Some topologies, such as the Web server on one machine and the application server on another machine, prevent the Plug-ins installation wizard from creating the Web server definition in the application server configuration on the remote machine. In such a case, the Plug-ins installation wizard creates a script that you can copy to the application server machine. Run the script to create the Web server configuration definition within the application server configuration. 1. Launch the installation wizard for webserver plugins from the Network Deployement launchpad. 2. Choose to view the Installation Roadmap or Getting Started guide for guidence. 3. Accept the license agreement in next screen and click next to move to System Prerequisite check screen. 4. Install appropriate service pack if the check fails and click next to move to Select the webserver screen. 5. Select the Webserver which you have installed and wish to configure for the purpose of handling application server requests. 6. Specify whether its installed on remote or local machine in the next screen. 7. Specify the directory where you wish to install the plugins in the next screen. 8. Specify the installation location of the websphere application server for which the webserver is being configured in the next screen. 9. Specify the Websphere Application server profile to configure with plugins installation (for cluster give the Manager profile ex.Dmgr01) in the next screen. 10. Specify the webserver configuration file(httpd.conf) and port to configure the web server definition in the next screen. This httpd.conf file has the configuration information for the web server at the end of this installation it is updated with the location of the plugin-cfg.xml and the plugin module, this plugin module reads the configuration details from pluincfg.xml and redirects the requests accordingly. 11. Give a name to the web server definition in the next screen. 12. Give the location where to create the plugin-cfg.xml file this file is an applicationcentric file has an application that is mapped to both Web server and application server definitions. Changes that you make to the plug-in using the administrative console persist to the plugin-cfg.xml file upon generation. the plug-in configuration file, which the WebSphere Application Server products

create and maintain, interacts with the binary module to provide information about the application server configuration to the Web server. The Web server uses the information to determine how to communicate with the application server, but to locate specific applications on the application server. 13. Click next on the summary screen to start installation.

Plugins installation will generate a file configurewebserver1.bat in C:\IBM\WebSphere\Plugins\bin copy this file to c:\IBM\WebSphere\AppServer\bin and execute configurewebserver1.bat to create a webserver definition. Web server configuration Plug-in configuration involves configuring the Web server to use the binary plug-in module that WebSphere Application Server provides. Plug-in configuration also includes updating the plug-in XML configuration file to reflect the current application server configuration. The binary module uses the XML file to help route Web client requests. After installing a supported Web server, you must install a binary plug-in module for the Web server. The plug-in module lets the Web server communicate with the application server. The Plugins installation wizard installs the Web server plug-in. The wizard configures the Web server. The wizard also creates a Web server definition in the configuration of the application server. The Plug-ins installation wizard uses the following files to configure a plug-in for the Web server that you select: The Web server configuration file on the Web server machine, such as the httpd.conf file for IBM HTTP Server. The binary Web server plug-in file that the Plug-ins installation Wizard installs on the Web server machine. The plug-in configuration file, plugin-cfg.xml, on the application server machine that you propagate (copy) to a Web server machine. The default (temporary) plug-in configuration file, plugin-cfg.xml, on the Web server machine. The configureweb_server_name script that you copy from the Web server machine to the application server machine. See the following descriptions of each file. Web server configuration file The Web server configuration file is installed as part of the Web server. The wizard must reconfigure the configuration file for a supported Web server. Configuration consists of adding directives that identify file locations of two files: The binary plug-in file The plugin-cfg.xml configuration file The binary Web server plug-in file See Web server plug-ins for a description of the binary plug-in module. An example of a binary plug-in module is the mod_ibm_app_server_http.dll file for IBM HTTP Server on the Windows platform. The binary plug-in file does not change. However, the configuration file for the binary plug-in is

an XML file. The application server changes the configuration file when certain changes to your WebSphere Application Server configuration occur. See Web server plug-in configuration service property for examples of when the file gets regenerated and when it does not. The binary module reads the XML file to adjust settings and to route requests to the application server. The plug-in configuration file, plugin-cfg.xml The plug-in configuration file is an XML file with settings that you can tune in the administrative console. The file lists all of the applications installed on the Web server definition. The binary module reads the XML file to adjust settings and to route requests to the application server. The stand-alone application server regenerates the plugin-cfg.xml file in the profile_root/config/cells/ cell_name/nodes/web_server_name_node/servers/web_server_name directory. Regeneration occurs whenever a change occurs in the application server configuration that affects deployed applications. The deployment manager regenerates the plugin-cfg.xml file in the profile_root/config/cells/cell_name/ nodes/node_name/servers/web_server_name directory whenever a change occurs in application server configuration that affects deployed applications on the managed node. After regeneration, propagate (copy) the file to the Web server machine. The binary plug-in then has access to the most current copy of its configuration file. The Web server plug-in configuration service automatically regenerates the plugin-cfg.xml file after certain events that change the configuration. The configuration service automatically propagates the plugin-cfg.xml file to an IBM HTTP Server machine when the file is regenerated. You must manually copy the file on other Web servers. See Web server plug-in configuration service property for more information. Default plug-in configuration file, plugin-cfg.xml The Plug-ins installation wizard creates the temporary plugin-cfg.xml file in the plugins_root/config/ web_server_name directory. The wizard creates the file for every remote installation scenario. The wizard creates the file at the same time that it installs the binary plug-in module for the Web server. The default file is a placeholder that you must replace with the plugin-cfg.xml file from the Web server definition on the application server. The default file is a replica of the file that the application server creates for a default stand-alone application server that has the samples installed. Run the configureweb_server_name script from the app_server_root/bin directory of the application server machine for a remote installation, or directly from the plugins_root/bin directory for a local installation. The script creates the Web server definition in the configuration files of the default profile. To configure a different profile than the default, edit the configureweb_server_name script. Use the profileName parameter to identify a different profile than the default. After the Web server definition is created, the Web server plug-in configuration service within the application server creates the first plugin-cfg.xml file in the Web server definition on the application server machine. If you install an application, create a virtual host, or do anything that changes the configuration, you must propagate the updated plugin-cfg.xml file from the application server machine to the Web server machine to replace the default file. The configureweb_server_name script for the Web server definition The Plug-ins installation wizard creates the configureweb_server_name script on the Web server machine in the plugins_root/bin directory. If one machine in a remote scenario is running under an operating system like AIX or Linux and the other machine is running under Windows, use the script created in the plugins_root/bin/crossPlatformScripts directory. The script is created for remote

installation scenarios only. Copy the script from the Web server machine to the app_server_root/bin directory on a remote application server machine. You do not have to copy the script on a local installation. Run the script to create a Web server definition in the configuration of the application server. When using the IBM HTTP Server, configure the IBM HTTP Administration Server also. The IBM HTTP Administration Server works with the administrative console to manage Web server definitions. Also, use the administrative console to update your Web server definition with remote Web server management options. Click Servers > Web servers > web_server_name to see configuration options. For example, click Remote Web server management to change such properties as: Host name Administrative port User ID Password Important: Always open a new command window before running this script. You can avoid a potential problem by doing so. The problem is a potential conflict between a shell environment variable, the WAS_USER_SCRIPT environment variable, and the actual default profile. The script always works against the default profile. However, if the WAS_USER_SCRIPT environment variable is set, a conflict arises as the script attempts to work on the profile identified by the variable. The variable is easy to set accidentally. Issue any command from the profile_root/bin directory of any profile and the variable is set to that profile. If you have more than one profile on your system, the potential exists that the default profile and the profile identified by the variable are different profiles. If so, a conflict occurs and the script might not create the Web server definition in the correct profile, or might not create the Web server definition at all. Reset the variable in either of two ways: Close the command window where the variable is set and open a new one. Change directories to the profile_root/bin directory of the default profile and source the setupCmdLine.sh script: Open a command prompt window. Change directories to the app_server_root\bin directory. Issue the setupCmdLine.bat command. Use the same command prompt window to start the update installer, as described in the appropriate procedure. If a Web server definition already exists for a stand-alone application server, running the script does not add a new Web server definition. Each stand-alone application server can have only one Web server definition. Note: The webserverNodeName value in the script is a concatenation of the nick name you have chosen for the web server and the suffix -node. It is automatically created during plug-in installation and cannot be changed. For example, if you named your web server myserver during plug-in installation, the value for the associated Web server definition created after you ran the script would be myservernode. You cannot use the administrative console of a stand-alone application server to add or delete a Web server definition. However, you can do both tasks using the administrative scripting interface: Add a Web server definition through the wsadmin facility using the configureweb_server_name script. The script uses a Java Command Language (Jacl) script named configureWebserverDefintion.jacl to create and configure the Web server definition. Delete a Web server definition using wsadmin commands. The Web server is named
1. 2. 3. 4.

webserver1 in the following example:

set webserverName webserver1 set webserverNodeSuffix _node set webserverNodeName $webserverName$webserverNodeSuffix $AdminConfig remove [$AdminConfig getid /Node:$webserverNodeName/ Server:$webserverName] $AdminConfig remove [$AdminConfig getid /Node:$webserverNodeName] $AdminConfig save

A managed node, on the other hand, can have multiple Web server definitions. The script creates a new Web server definition unless the Web server name is the same. Replacing the default plug-in configuration file with the file from the Web server definition (propagation) The default file uses fixed parameter values that might not match the parameter values in the actual file on the application server. The default file is a placeholder only. The file cannot reflect changes that occur in the application server configuration. The file also cannot reflect non-default values that might be in effect on the application server. The application server must have the following values in the actual plugin-cfg.xml file. If so, the default file can successfully configure the binary plug-in module. Then, the plug-in module can successfully communicate with the Web server and the application server. Suppose that the application server does not have the following values in the actual plugin-cfg.xml file. In that case, the default file configures the binary plug-in module incorrectly. The plug-in module can always communicate with the Web server. But with an improper configuration file, the plug-in module cannot communicate successfully with the application server. The following are fixed parameter values in the temporary plug-in configuration file. Virtual host name Default value: default_host This virtual host is configured to serve the DefaultApplication and the Sample applications. This value is probably the same as the value in the real plugin-cfg.xml file. However, suppose that you create another virtual host for serving applications and install the DefaultApplication on it. If so, the actual plugin-cfg.xml file is regenerated. The Web server cannot access the DefaultApplication. (The application includes the snoop servlet and the hitcount servlet.) To access applications on the new virtual host, propagate the real plugin-cfg.xml file. Propagation is copying the updated file from the application server machine to the Web server machine.

HTTP transport port Default value: 9080 The 9080 value is the default value for the HTTP transport port for the default_host virtual host. This value is probably the same as the value in the updated file. However, this value changes for every profile on the application server machine. The HTTP transport port value must be unique for every application server. To communicate over a different port, propagate the real plugin-cfg.xml file.

Web server listening port Default value: 80 The 80 value is the default value for the port that controls communication with the Web server.

However, each application server profile must have a unique port value to communicate to a Web server. The actual port value might be 81 or another number. To communicate over a different port, propagate the real plugin-cfg.xml file.

HTTPS transport port Default value: 9443 The 9443 value is the default value for the HTTPS (secure) transport port for the default_host virtual host. This value is probably the same as the value in the updated file. However, this value changes for every profile on the application server machine. The HTTPS transport port value must be unique for every application server. To communicate over a different secure port, propagate the real plugin-cfg.xml file.

Applications installed on the server1 application server All of the default servlets and applications are included in the default file, including the WSsamples application and the SamplesGallery application. The default file lists all of the default applications and samples. The list can be inaccurate. If you performed a custom installation and did not install the samples, for example, the list is inaccurate. To serve an application that you developed with the Web server, propagate the real plugincfg.xml file.

Deploy the IDM WAR file

1 Log in to the WebSphere administration console as an admin user. 2 From the left panel, go to Applications > New Application > New Enterprise Application. 3 Browse to the file location of the IDM War (for example, IDMProv.war). 4 Choose how to install the product according in the next screen. Then, click Next to move to the Select installation options screen. 6 Accept the defaults for this screen and click Next to move to the Map modules to servers screen. 7 Leave everything as the defaults for this screen and click Next to move to the Map resource references to resources screen. 8 For the authentication method, select the User default method check box. Then for the Authentication data entry dropdown, select the alias you created earlier, for example MyServerNode01/DB2AliasMyDB. 9 In the table below the authentication settings, find the module you are deploying. Under the column titled Target Resource JNDI Name click the browse button to specify a JNDI name. This should bring up a list of resources. Select the datasource that you created earlier and click the Apply button to get back to the Map resource references to resources screen, for example DB2DataSourceMyDB. 10. Select the target on which you wish to deploy the application 10 Select Next to go to the Map virtual hosts for Web modules. 11 Leave everything as the defaults for this screen and select Next to go to the Summary screen. 12 Select Finish to complete the deployment.

Access the User Application portal

For accessing the IDMProv application we will use the webserver's IP with configured

port(default=80). The application can also be accessed from the server ip's involved in cluster for server1 URL would be like <server1 ip:9081/IDMProv> and for server2 the URL would be <server2 ip:9082>. The web server will use only a single servers stream at a time it will get transffered to other server as soon as the other server is unavailable. For using this ip to access application we need to add the port and ip as host alias to the Default Host(Environment > Virtual Hosts > Default_Host > Host Aliases). Always add complete domain name for entering as Alias(ex: Cluster001.app.novell.com; port=9081) and use domain name into URL instead of IP for accessing application. After adding the host alias restart the cluster server once to make the alias effective.