Setting Up B2B Data Exchange for High Availability in an Active/Active Configuration

Setting Up B2B Data Exchange for High Availability in an Active/Active Configuration 2010 Informatica

Abstract This document explains how to install multiple copies of B2B Data Exchange on a single computer. To do this, use the installer to install multiple copies of B2B Data Exchange on the target computer. After the installations are complete, update the port configurations of the copies. Supported Versions B2B Data Exchange 9.0.1 Table of Contents Overview.... 2 Prerequisites.... 3 Configuration Checklist.... 3 B2B Data Exchange Server Cluster... 4 Shared File System.... 4 B2B Data Exchange Configuration Properties.... 5 PowerCenter Configuration.... 6 Fuse Message Broker.... 7 Setting up B2B Data Exchange Managed File Transfer... 7 B2B Data Exchange Operation Console Cluster... 8 B2B Data Exchange Operation Console Clustering Software.... 9 Sticky Sessions.... 10 Session Replication.... 15 Glossary.... 18 Overview This document contains the information needed to configure B2B Data Exchange 9.0.1 for high availability in an active/ active configuration. Two alternative configurations are discussed, the sticky session configuration and the session replication configuration. The document explains how to configure the following components: B2B Data Exchange Server B2B Data Exchange Operation Console It is assumed that the reader has general knowledge about the following topics: High availability Load balancing Failover 2

Prerequisites To configure the active/active high availability option, verify that your system meets the following conditions: A high availability database, such as Oracle Real Application Clusters, is installed. The document store is located in highly available shared storage that is accessible from all the B2B Data Exchange servers operation consoles and from PowerCenter, using the same directory path. A load balancer is installed, for example, Apache HTTP Server load balancer. The clocks on all B2B Data Exchange nodes are synchronized to within 30 seconds of each other. The cluster nodes are located in the same physical location. Geographically distributed nodes are not supported. Note: To guarantee proper operation of a B2B Data Exchange high availability cluster, it must have multiple active B2B Data Exchange Server nodes, and PowerCenter real-time workflows active and running. If your cluster does not meet these requirements, please contact Informatica Global Customer Support for setup instructions. Configuration Checklist This section presents a checklist for setting up the B2B Data Exchange high availability active/active configuration. We recommend following the checklist in order to set up the configuration easily. The following sections provide detailed instructions for implementing the steps.. Verify that all prerequisites have been met. Set up a shared file system: - Move the document store to the shared file system. - Update all file endpoints to use the shared file system. Configure the B2B Data Exchange Operation Console: - Edit the operation console configuration properties, located in the dx-configuration.properties file. - Set up the HTTP load-balancing tool. - Turn on the sticky session option. - Optionally, configure session replication. Configure the B2B Data Exchange Server: - Edit the server configuration properties, located in the dx-configuration.properties file. - If you use multiple PowerCenter gateways: edit the pwc.domain.gateway system property. - If you use batch workflows: ensure that the Web Services Hub URL system property refers to a clustered or loadbalanced URL, and not to a single hub. - Set up the cluster manager and monitoring. Configure the FUSE Message Broker: - Enable network connector. - Enable cluster discovery. Configure B2B Managed File Transfer (optional): - Edit the dx.endpoint.mft.inbox.path system property. - Edit the dx.mft.console.url system property. Configure PowerCenter: - Edit the PowerCenter Integration Service environment variable: DX_SERVER_URL. - Edit the JNDI connections. 3

B2B Data Exchange Server Cluster This section discusses the configuration changes that are required to enable active/active clustering of B2B Data Exchange Server. The following figure illustrates a sample B2B Data Exchange Server cluster configuration: The sample cluster consists of two B2B Data Exchange Server instances, a PowerCenter environment, and a shared file system. The optional Fuse Message Broker and Managed File Transfer components are installed on the same hosts as B2B Data Exchange Server by the installer. The figure shows the lines of communication between the components. The lines between the B2B Data Exchange Servers and the PowerCenter Grid represent the JMS, RMI, and Web Service message flows. The cluster configuration does not require that B2B Data Exchange Server is installed on each of the PowerCenter nodes. The location where B2B Data Exchange Server is installed has no impact on the configuration changes presented in this section of the document. Shared File System The following B2B Data Exchange components access files via the file system: Document Store Inbound File Endpoints Outbound File Endpoints Each component must use a shared file system location that is accessible to every B2B Data Exchange server. For example, when configuring an inbound file endpoint, the endpoint path must be located on a shared file system that is accessible to all servers. 4

Each system component can use a different shared file system as long as every server can access it using the exact same file path. Document Store The document store must be accessible by all the B2B Data Exchange Server instances. It must be located on a shared network drive. If you use the file-by-reference feature of the document store, the PowerCenter nodes that run workflows need to be able to access the shared file system using the same file references. Thus all B2B Data Exchange and PowerCenter nodes require access to the same file server using the same path. For example, /shared/storage_1/b2b Data Exchange/document_store/file_one.txt must point to the same file from all nodes. If a single instance of B2B Data Exchange Server is upgraded to a cluster environment, then the document store must be moved to a shared location. If the document store is already located in a shared location, or if it is accessible by all the nodes in the cluster, there is no need to move it. The Repository Utilities provide a command to move the document store to a new location. This command is called movedocumentstore and has the following syntax (in a single line): repoutil c movedocumentstore l <jdbc URL> -u <user name> -p <password> \ --docstore <new document store location> For more information about the Repository Utilities, see the B2B Data Exchange Administrator Guide. Note: Do not move the document store manually. It contains document references which must be updated. File Endpoints Inbound and outbound file endpoints all reference the file system. These references must point to a shared file system that all server instances can access, since all the servers use the endpoints. For more information about endpoints, see the B2B Data Exchange Operator Guide. Archive Service The B2B Data Exchange Archive Service does not absolutely require a shared file system, because the archive execution runs on a specific node and targets a specific B2B Data Exchange Server instance, using a remote RMI call. Nevertheless, you should use a shared file system for the Archive Service. This enables you to use the same archive specification files on each B2B Data Exchange Server instance. You can run multiple archive tasks in parallel on several B2B Data Exchange Server instances. Verify that there are no conflicts in the archiving criteria, such as multiple instances writing to the same archive file. For more information about archiving, see the B2B Data Exchange Administrator Guide B2B Data Exchange Configuration Properties The property file, dx-configuration.properties, must be the same for all the B2B Data Exchange Server and Operation Console installations. Otherwise, the different B2B Data Exchange instances cannot find each other. This file resides in the following locations: <B2B Data Exchange Installation>/conf/dx-configuration.properties <B2B Data Exchange Installation>/apache-tomcat-5.5.28/shared/classes/dx-configuration.properties The dx.cluster.name property must be the same in all the configuration files. You can replace the generated value with one that is easy to remember. 5

The operation console property dx.console.url must point to the load-balancing HTTP server behind which the clustered B2B Data Exchange Operation Console instances are running. Verify that the property dx.jdbc.maxpoolsize contains the total number of database connections for all servers in the cluster. Note: If a highly available database is used, then in most cases the JDBC URL needs to be changed to make efficient use of the database. For more information about configuring the JDBC URL, see the Progress DataDirect Connect for JDBC User's Guide. Note that B2B Data Exchange 9.0.1 uses DataDirect drivers, version 4.0.56. A configuration using an Oracle TNS file is not supported. PowerCenter Configuration You must configure the following PowerCenter components to work with the B2B Data Exchange high availability environment: PowerCenter Integration Service JMS Connection Factory (PowerCenter workflow level) JMS Transacted Mode PowerCenter Integration Services Update the environment variable DX_SERVER_URL for each process that runs the Integration Service for B2B Data Exchange workflows. This variable must list all the node addresses on which a B2B Data Exchange Server is running, using the following format: rmi://<host>:<port>[;rmi://<host>:<port>]*[;dx.timeout=<timeout>] [;dx.max.connections=<max connect>] In the above code fragment, <host> refers to the host name or IP address of the node running the B2B Data Exchange Server, and <port> refers to the port number at which the B2B Data Exchange Server is accessible. This value is set in the dx-configuration properties file (dx.rmi.port) The value of <port> is the port valued defined in dx-configuration.properties as dx.rmi.port. The value of <port> can be different for each entry, depending on the <host> in that entry. The dx.timeout property indicates the timeout value, in seconds, when connecting. The property is optional and has a default value of 30 seconds. The dx.max.connections property specifies how many times an existing connection can be re-used. This property is optional, with a default value of 100. Note: You must update each PowerCenter Integration Service process that runs a mapping or workflow for B2B Data Exchange. If you run multiple PowerCenter Integration Services processes that process different workflows, then you must update each PowerCenter Integration Service process. Update each PowerCenter Integration Service process for each node on which it runs. Some properties, such as the Java system properties, are node-dependent. JMS Connection Factory You must update the JNDI Provider URL of the JNDI connection factory. To do this, go to the PowerCenter Workflow Manager, click Connections > Application, and select the appropriate JNDI connection factory. Set the JNDI Provider URL property to a URL and group name as in the following example: discovery:(multicast://224.252.253.254:18162?group=<dx.cluster.name>) 6

JMS Transacted Mode Open the PowerCenter Workflow Manager and edit the sessions that contain a B2B Data Exchange JMS target. On the Mapping tab, verify that the JMS Transacted Mode property is configured to run in Transacted Mode. Fuse Message Broker You must update the configuration of the Fuse Message Broker so that the different instances can exchange JMS messages for processing and load balancing. Apply the changes to all the ActiveMQ configuration files. The following changes need to be made in the <B2B Data Exchange installation>/fuse-message-broker-5.3.0.4/conf/ activemq.xml file: Step Explanation Backup activemq.xml. Create a backup of the file activemq.xml, calling it activemq.xml.bak. Enable network connector. Enable discovery on default transport connector. Remove the XML comment tags around: <network connector name="default-nc" url="multicast://224.252.253.254:18162?group=dx.cluster.name"/> This code is located around lines 70-71 of the file. This code opens a socket that Message Broker uses to receive forwarded messages from other Message Broker instances. Comment out the line <transportconnector name= "openwire" url="tcp://0.0.0.0.18616"/> which is located around line 119. Remove the comments around line 121, which adds the same transport connector. The difference is that the latter connector has a discovery protocol enabled. Rename dx.cluster.name. Replace the text dx.cluster.name with the value that is used in dx-configuration.properties for the property dx.cluster.name. Note: Each step is marked with an "INFA change (cluster)" XML-comment in activemq.xml. Search for this string to find the proper locations. Setting up B2B Data Exchange Managed File Transfer If you use B2B Data Exchange Managed File Transfer, follow these steps to configure it for high availability: 1. Install B2B Data Exchange Managed File Transfer on all nodes in the cluster. 2. Start all B2B Data Exchange services on all nodes. 3. Set up the user configuration for all B2B Data Exchange Managed File Transfer services. For more information about the user configuration on multiple Versalex components, see the B2B Data Exchange Managed File Transfer User Guide. 4. Update the B2B Data Exchange system property dx.mft.console.url to reference the IP address or host name of the DX Operation Console. 5. The B2B Data Exchange system property endpoint.mft.inbox.path must reference a path that is accessible by all the B2B Data Exchange Server nodes using the same directory path. 7

B2B Data Exchange Operation Console Cluster This section describes the cluster configuration of the B2B Data Exchange Operation Console. It discusses the required configuration changes that are needed to enable clustering. The examples in this section use the Apache HTTP Server for load balancing the B2B Data Exchange Operation Console cluster. Apache HTTP Server is not a part of the B2B Data Exchange installation. You can use it, or any other loadbalancing software or hardware. You can download the Apache HTTP Server installation files from http://httpd.apache.org/download.cgi. For more information about the Apache setup, see the Apache documentation. In the remainder of this document we assume that you are using a newly-installed copy of the Apache HTTP Server. The following figure shows a sample B2B Data Exchange Operation Console high availability cluster configuration: The cluster consists of multiple browser clients, one Apache HTTP Server, and two Tomcat instances that run B2B Data Exchange Operation Console. Synchronize the clocks of all machines in the cluster to ensure proper handling of browser requests. 8

The browser requests are forwarded by the HTTP server to one of the Tomcat instances. This flow is shown in the following figure: The back-end machine that handles the request is determined by the Apache HTTP Server. It might differ from request to request, depending upon the configuration. The exact same version of the B2B Data Exchange Operation Console is installed on all the back-end machines. B2B Data Exchange Operation Console Clustering Software This section describes how to set up a proxy server for the B2B Data Exchange Operation Console to handle load balancing and failover in the session replication configuration. Load balancing software for the B2B Data Exchange Console acts as a proxy server for the browsers connecting to the operation console. The browsers see a single proxy server, and are unaware to which physical server they are actually connected. Use one or both of the following options to configure the load balancer: Sticky sessions Session replication for failover handling If you choose to use Apache HTTP Server for load balancing, use version 2.2.15 or higher. B2B Data Exchange Operation Console Configuration Properties The information presented in B2B Data Exchange Configuration Properties on page 5 is valid for the B2B Data Exchange Operation Console configuration properties as well. Follow these instructions when configuring the B2B Data Exchange Operation Console. 9

Sticky Sessions A sticky session is a session that is processed by a single server. The first browser request creates a session. Thereafter this session is processed exclusively by the server that created it. For example, if the request of Browser 1 is processed by Tomcat A, then Tomcat A processes all the remaining requests of Browser 1. The advantage of a sticky session is that it does not require multicast transmission to multiple destinations, and so does not generate additional network traffic. The disadvantage is that if a server fails, all the users that have sessions on that server are required to log in to a different one. The cluster does not transfer sessions from a failed node to an active one. Tomcat Configuration Changes for Sticky Sessions The following configuration changes need to be made in the file <B2B Data Exchange installation>/apache-tomcat-5.5.28/conf/ server.xml: Step Back up server.xml. Explanation Create a backup of the file server.xml and call it server.xml.bak. Enable AJP connector. Edit jvmroute value. Remove the XML comment markers around <connection port="18009" enablelookup="false" redirectport="18443" protocol="ajp/1.3"/>, which are located near lines 107 and 108. This opens a socket that is used by the Apache HTTP Server to forward requests. Change the value of the attribute jvmroute on the XML element Engine. The value should be the physical machine name, for example, dx_tomcat-a. The value jvmroute must be unique for each Tomcat instance, hence we use the machine name. Otherwise, the Apache HTTP Server would not be able to consistently route the requests (and sessions) to the correct machine. Note: Failure to edit jvmroute might cause unexpected results. Note: Each step is marked with an "INFA change cluster" XML-comment in server.xml. Search for this string to find the proper locations. 10

Apache HTTP Server Configuration Changes for Sticky Sessions The configuration changes for the Apache HTTP Server consist of the following steps: Step Include cluster configuration. Add the cluster configuration. Edit the cluster configuration. Explanation Edit the file <apache installation>/conf/httpd.conf and add Include conf/dx-gui-cluster.conf at the end. This Apache directive indicates that an additional configuration file must to be loaded. Copy the contents of the code section below into a new file called dx-gui-cluster.conf. This file must be placed under <apache installation>/conf/. Edit the copied code segment as follows: - Between the lines <Proxy balancer://dx-gui-cluster> and </Proxy>, delete the two lines beginning with BalancerMember. - Insert new lines, one for each Operation Console (Tomcat) server that is part of your cluster. Each line must have fields for a specific node (Tomcat instance), the machine name, and the jvmroute value set for that specific Tomcat instance, for example, Balancer-Member ajp://<operation console machine name>:18009 route=<jvmroute value as defined in web.xml> ## Load the proxy module, if is not loaded already <IfModule!proxy_module> LoadModule proxy_module modules/mod_proxy.so ## Load the http proxy protocol module, if it is not loaded already ## This module enables load balancing between nodes <IfModule!proxy_http_module> LoadModule proxy_http_module modules/mod_proxy_http.so ## Load the proxy balancer module, if it is not loaded already ## This module enables load balancing between nodes <IfModule!proxy_balancer_module> LoadModule proxy_balancer_module modules/mod_proxy_balancer.so ## Load the ajp proxy protocol module, if it is not loaded already ## This module enables the communication between Apache and Tomcat via AJP <IfModule!proxy_ajp_module> LoadModule proxy_ajp_module modules/mod_proxy_ajp.so ## Add an additional location to access the current load balancing configuration ## and statistics. Access is only allowed from localhost ## Only set the location if status module (mod_status) is loaded <IfModule status_module> <Location /balancer-manager> SetHandler balancer-manager Order Deny,Allow Deny from all Allow from 127.0.0.1 </Location> ## Configure the proxy for the B2B Data Exchange Operation Console instances ## Note that this is a static list, all the machines should be explicitly listed here ## The value for the attribute route must exactly match that which is ## used when configuring Tomcat <Proxy balancer://dx-gui-cluster> BalancerMember ajp://tomcat-a:18009 route=dxtomcat-a BalancerMember ajp://tomcat-b:18009 route=dxtomcat-b </Proxy> # Disable ProxyRequest as only the ProxyPass and ProxyPassReverse are used. # This prevents the server from processing requests from spammers (sending e-mails) 11

ProxyRequests Off ## Configure the forwarding of the request. ## Client browser must connect to <apache http server>:<port>/dx-console/ ## Note that it must be a single line ProxyPass /dx-console/ balancer://dx-gui-cluster/dx-console/ stickysession=jsessionid jsessionid ## Configure the return route from back-end to front ProxyPassReverse /dx-console/ balancer://dx-gui-cluster/dx-console/ Note: The URLs in the ProxyPass and ProxyPassReverse directives must end with a slash. If the slash is missing, routing to and from the back-end nodes might fail. Testing the Configuration Changes for Sticky Sessions To test the configuration, follow the steps presented in the table below. These steps assume that the Tomcat instances and the Apache HTTP Server are started. Perform the steps on the host that runs this server. Step Test back-end machines. Verify that the Balancer Manager works properly. Log in to the B2B Data Exchange Operation Console. Description Go directly to the B2B Data Exchange Operation Console on the back-end machines. Verify that the behavior in a clustered environment is the same as in a single-server environment. Verify that the login and logout are successful. Repeat this step for each back-end machine. Go to http://localhost:80/balancer-manager. This page shows the status of all the configured workers. After restarting Apache, it should show that all the workers are OK and that no data has been transmitted or received. Go to http://localhost:80/dx-console/. The B2B Data Exchange Operation Console login page should be displayed. Log in into the B2B Data Exchange Operation Console. Verify sticky session. Go back to the balancer manager page at http://localhost:80/balancer-manager. This page should show that all the requests have been forwarded to a single back-end machine. See Figure 1. 12

Step Log in to the B2B Data Exchange Operation Console 2. Verify sticky session 2. Description Go to http://localhost:80/dx-console/, using a different browser than before, and log in to the B2B Data Exchange Operation Console. Go back to the balancer manager page at http://localhost:80/balancer-manager. This page should show that all the requests have been forwarded to the other back-end machine. See Figure 2. 13

Figure 1. Load Balancer for Sticky Sessions 1 Figure 2. Load Balancer for Sticky Sessions 2 14

Session Replication Session replication ensures that each Tomcat instance has the same session information about a user, allowing for transparent failover in case an instance fails unexpectedly. The other instances can immediately take over the request without requiring the user to log in again. The disadvantage of session replication is that there increases network traffic, as the sessions need to be replicated on all the nodes. The user may encounter longer response times if the replication takes a long time. Tomcat Configuration Changes for Session Replication The configuration changes are identical for each of the Tomcat instances, except for one attribute or property value. The steps below are identical to the sticky session setup, but with one additional step. Make the following configuration changes in the file <B2B Data Exchange Installation>/apache-tomcat-5.5.28/conf/ server.xml: Step Back up server.xml. Explanation Create a backup of the file server.xml and call it server.xml.bak. Enable AJP connector. Edit jvmroute value. Remove the XML comment markers around <connection port="18009" enablelookup="false" redirectport="18443" protocol="ajp/1.3"/>, located around lines 107-108. This change opens a socket that Apache HTTP Server uses to forward the requests to. Change the value of the attribute jvmroute on the XML element Engine. The value should be the physical machine name, for example, dx_tomcat-a. The value jvmroute must be unique for each Tomcat instance, hence we use the machine name. Otherwise, the Apache HTTP Server would not be able to consistently route the requests (and sessions) to the correct machine. Note: Failure to edit jvmroute might cause unexpected results. Enable clustering To enable clustering of the Tomcat instances, remove the XML start and end comments around the cluster element. The complete cluster element is located between lines 304 and 342. Note: Each step is marked with an '"INFA change cluster" XML comment in the server.xml file. Search for this string to find the proper locations. Make the following changes in the file <B2B Data Exchange Installation>/apache-tomcat-5.5.287/conf/context.xml. Step Back up context.xml. Explanation Create a backup of the file context.xml and call it context.xml.bak. Comment out session manager. Comment out the line that defines the session manager <Manager pathname=""/>, around line 27. In a cluster with session replication, the sessions need to be persisted. Otherwise the sessions are not replicated throughout the cluster. 15

Apache HTTP Server Configuration Changes for Session Replication The configuration changes for the Apache HTTP Server consist of the following steps, which are identical to the sticky session configuration setup. Step Include the cluster configuration. Add the cluster configuration. Explanation Edit the file <apache installation>/conf/httpd.conf and add Include conf/dx-guicluster.conf at the end. This Apache directive tells the server to load an additional configuration file. Copy the contents of the code section below to a new file called dx-gui-cluster.conf. Store the file under <apache installation>/conf/. ## Load the proxy module, if is not loaded already <IfModule!proxy_module> LoadModule proxy_module modules/mod_proxy.so ## Load the http proxy protocol module, if it is not loaded already <IfModule!proxy_http_module> LoadModule proxy_http_module modules/mod_proxy_http.so ## Load the proxy balancer module, if it is not loaded already ## This module enables load balancing between nodes <IfModule!proxy_balancer_module> LoadModule proxy_balancer_module modules/mod_proxy_balancer.so ## Load the ajp proxy protocol module, if it is not loaded already ## This module enables the communication between Apache and Tomcat via AJP <IfModule!proxy_ajp_module> LoadModule proxy_ajp_module modules/mod_proxy_ajp.so ## Add an additional location to access the current load balancing configuration ## and statistics. Access is only allowed from localhost ## Only set the location if status module (mod_status) is loaded <IfModule status_module> <Location /balancer-manager> SetHandler balancer-manager Order Deny, Allow Deny from all Allow from 127.0.0.1 </Location> ## Configure the proxy for the B2B Data Exchange Operation Console instances ## Note that this is a static list, all the machines should be explicitly listed here ## The value for the attribute route must exactly match that which is ## used during the Tomcat configuration <Proxy balancer://dx-gui-cluster> BalancerMember ajp://tomcat-a:18009 route=dxtomcat-a BalancerMember ajp://tomcat-b:18009 route=dxtomcat-b </Proxy> # Disable ProxyRequest as only the ProxyPass and ProxyPassReverse are used. # This prevents the server from processing requests from spammers (sending e-mails) ProxyRequests Off ## Configure the forwarding of request. ## Client browser must connect to <apache http server>:<port>/dx-console/ ## Note that it must be a single line ProxyPass /dx-console/ balancer://dx-gui-cluster/dx-console/ ## Configure the return route from back-end to front ProxyPassReverse /dx-console/ balancer://dx-gui-cluster/dx-console/ 16

The URLs in the ProxyPass and ProxyPassReverse directives must end with a slash. Otherwise, the routing to and from the back-end nodes might fail. The only difference between the sticky session configuration and the session replication configuration is that the property stickysession is removed from the ProxyPass directive. Testing the Configuration Changes for Session Replication To test the configuration changes, perform the following the steps. The steps assume that the Tomcat instances and Apache HTTP Server are running. Perform the steps on the machine that runs Apache HTTP Server. Step Test the back-end machines. Test the Balancer Manager. Log in to the B2B Data Exchange Operation Console. Verify session replication and balancing. Description Go directly to the B2B Data Exchange Operation Console on the back-end machines. Verify that the behavior is identical to that of a single-server environment. Verify that the login and logout are successful. Repeat this step for each back-end machine. Go to http://localhost:80/balancer-manager. This page shows the status of all the configured workers. After re-starting the Apache HTTP Server, verify that the page shows that all the workers are OK and that no data has been transmitted or received. Go to http://localhost:80/dx-console/. The B2B Data Exchange Operation Console login page should appear. Log in to the B2B Data Exchange Operation Console. Go back to the balancer manager page at http://localhost:80/balancer-manager. This page should show that all the requests have been balanced between the different back-end machines. See Figure 3. Figure 3. Balance Manager - Session Replication 17

Glossary Active/active. A configuration where all nodes are active. In the event of a failure, the remaining active nodes assume responsibility for all processing tasks. Active/passive. The cluster includes an active node and one or more passive nodes. The passive nodes are used only if the active node fails. Only one node is active at a time. AJP. Apache Jservlet Protocol is a binary packet-oriented communication protocol used to reduce the communications overhead between a web server (Apache HTTP Server) and a servlet container (Apache Tomcat). Browser. The browser that connects to the cluster Operation Console server. Client. See Browser. Failover. The migration of a service, process, or task to another node when the original node becomes unavailable, for example, if the original node shuts down unexpectedly. Grid. An alias assigned to a group of nodes that run sessions and workflows. When you run a workflow on a grid, you improve scalability and performance by distributing session and command tasks to service processes running on nodes on the grid. Load balancer. Hardware or software that balances the incoming requests to different back-end machines or nodes. Recovery. The automatic or manual completion of tasks after an application service is interrupted. Resilience. The ability of services to tolerate transient failures, such as loss of connectivity to the database or network failures. Sticky session. A session is sticky if the same server processes all its requests, from first to last. Tomcat instance. The node that runs Tomcat with the B2B Data Exchange Operation Console. Worker. A worker represents a running instance of Tomcat. Authors Francis Henninger Senior Software Engineer Michael Lahav Senior Documentation Specialist, AlmondWeb Ltd. 18