Usage of Mediator in a Cluster Environment

Usage of Mediator in a Cluster Environment

1. INTRODUCTION

2. PRE-REQUISITE

3. CONFIGURATIONS

     3.1 Cluster Configuration in Mediator

     3.2 Load Balancer configuration in Mediator (as Optional)

     3.3 Virtual Service Creation

     3.4 Consumer Application Creation

4. DEPLOY A VIRTUAL SERVICE INTO MEDIATOR

5. DEPLOY A CONSUMER APPLICATION INTO MEDIATOR

6. VERIFY CLUSTER DEPLOYMENT OF A VIRTUAL SERVICE

7. VERIFY CLUSTER DEPLOYMENT OF A CONSUMER APPLICATION

8. EXECUTION  OF VIRTUAL SERVICE RUNTIME INVOCATION USING SOAPUI

9. VERIFY RUNTIME METRICS IN CENTRASITE

10.TROUBLESHOOTING

 

1. INTRODUCTION

This tutorial will explain the usage and configuration of the Mediator Runtime Cluster Scenario using CentraSite and Mediator. Multiple instances of Mediator can be clustered together to provide scalability of mediation.

A load balancer can also be placed in front of the clustered Mediator instances to properly distribute the request messages. Each node is an instance of Mediator running on an instance of Integration Server.

When we configure each node of the system to communicate with the same CentraSite server, we create a cluster. A cluster is a group of nodes that monitors the same virtual service and sends events and metrics

triggered by that virtual service to CentraSite.

 

2. PRE-REQUISITE

  1. Target should be created with the deployment endpoint of any one of the clustered node 
    e.g. http://<hostname>:5555/ws/mediator.integration:Deployer or optionally, you can also use Load Balancer URL like http://hostname:8081/ws/mediator.integration:Deployer pointing to the load balancer.

 

      2.Terracotta server should be started

    • Go to <Installation Directory>\Terracotta\server\bin and execute start-tc-server.bat to start the TC server.

 

    3. Load Balancer (e.g. Apache) should be started (as Optional)

In this article Apache 2.2 (Ms Windows version) is used as a Load Balancer.

Step 1: Go to <<Apache Software Foundation_home>>\Apache2.2\conf and edit httpd.conf file and provide the following values (in the screen shot marked as green), then save it.

 

    4. Setup JDBC connection pool in IS

Ensure that a JDBC connection pool is defined in Integration Server which can be used by Mediator.

SQL component

Step 1: Login to IS admin page and go to Settings > JDBC pools > Create a new Pool Alias definition.

Step 2: Click Create a new Pool Alias definition link and provide the following details.

  • Alias Name : Name for the connection pool. The name can include any characters that are valid for a file name in your operating system. Ex. “OracleMongo102ClusteringAlias
  • Alias Description : Description for the pool. Ex. “For clustering to an Oracle database
  • Associated Driver Alias : Database driver to use. Ex. “DataDirect Connect JDBC Oracle Driver
  • Database URL : URL for the database server. Sample URL formats for the DataDirect Connect JDBC driver are displayed. Ex. “jdbc:wm:oracle://XX.XX.XX.XX:1521;SID=XX
  • User ID and Password : Oracle DB user name and password credentials.
  • Minimum Connections : Minimum number of connections the pool must keep open at all times. Ex. “3
  • Maximum Connections : Maximum number of connections the pools can have open at one time. Ex. “6
  • Available Connections Warning Threshold “0%
  • Waiting Thread Threshold Count “0
  • Idle Timeout : Idle Timeout Period of time, in milliseconds, the pool can keep an unused connection open. After the specified period of time, the pool closes unused connections that are not needed
    to satisfy the Minimum connections value. Ex. “3000” milliseconds

Then click “Test Connection” button and save the settings. Now, JDBC pool alias has created and you can use it in step.

 

3. CONFIGURATIONS

3.1 Cluster Configuration in Mediator

Step 1:  Go to Functional Alias Definitions > ISInternal  > Edit

  • ISInternal : This will be used for the Scheduled tasks, client certificate mappings, run-time data for pub.storage services, audit log of guaranteed delivery transactions, 
    trigger joins, and configuration and runtime data for OAuth.

 

Step 2: Select OracleMongo102ClusteringAlias from the list which is created in prerequisites 4.

 

Step 3: Go to Functional Alias Definitions > Xref > Edit

 

Step 4: Select OracleMongo102ClusteringAlias from the list which is created in prerequisites 4.

 

Step 5: Restart the Mediator. Now, the DB configuration for clustering is ready to use.

Step 6: After restart, need to configure cluster by selecting Settings > Clustering > Edit Cluster Settings and provide the following values.

  • Cluster Name as “MediatorCluster
  • Session Timeout as “60
  • Terracotta Server Array URLs as “<hostname>:portnumber” Ex. vmmed961bvt02w:9510

 

Step 7: Save the settings and restart the Mediator. After restart, you should be able to see the list of cluster nodes details from the below screenshot. Now, the cluster setup is ready to use.

 

3.2 Load Balancer configuration in Mediator (as Optional)

Clustering in Mediator requires a load balancer. When a service is deployed to a cluster, the node that performs the deployment sends the load balancer URL as the new endpoint to CentraSite as part of

its virtual service status message.CentraSite stores this load balancer URL endpoint in the registry/repository. Since all of the nodes in the cluster use the same load balancer URL, CentraSite accepts messages

from any node in the cluster as if they came from a single instance of Mediator. A load balancer URL consists of a host name (or IP address) and port number of the load balancer

as follows: http://hostname :portnumber or http://IP-address :portnumber

Note: You can also configure the load balancer URL to use the HTTPS protocol.

To configure the load balancer URLs,

Step 1: In the Navigation panel, select Solutions > Mediator > Administration > General.

Step 2: On the Mediator Configuration screen, click Edit.

Under HTTP Config, set the parameters as follows:

    • Load Balancer URL (HTTP): The primary HTTP load balancer URL and port number to use. For the URL, specify either the IP address or host name of the load balancer with the port number 
      Eg: http://IP-address :portnumber (or) http://hostname :portnumber
    • Load Balancer URL (HTTPS): This is optional. The primary HTTPS load balancer URL and port number to use. For the URL, you can specify either the IP address or host name of the load balancer with the port number 
      Eg: https://IP-address :portnumber (or) https://hostname :portnumber

      Note: If specified, all the virtual services hosted in Mediator (and exposed on HTTPS) will use   this value

Step 3: Click Save.

 

3.3 Virtual Service Creation

Step 1:  Login to BusinessUI (http ://< hostname>:53307/BusinessUI/). Click Create Asset link.

Step 2: In the create asset page, provide the following values.

  • Name as “MyService1
  • Select the Type as “Service
  • Organization as “DefaultOrganization
  • Select the URL option and value as http://<hostname>:<port>/ws/EchoWS?wsdl and Click the Next button.

Step 3:  Click “Save” button to save the service.

Step 4: Once the service created, it will go to the service details page.

Step 5: To virtualize the service, click Virtualize icon and give the Virtual Alias name as “MyVirtualService1”, End Point as http://127.0.0.1:5555/ws/EchoWS.EchoWSHttpEndpoint and click the Next button.

 

Step 6: In the next step,

a. Select Policy Actions > Policy Enforcement > Logging and Monitoring > Log Invocation, then Drag and Drop to Enforce layout area.

b. Click the Configuration icon and select the following values from the list and click ‘Ok’ button to save the configuration.

  1. Payloads (Request and Response) pertaining to the configured Virtual Service.
    1. Request Payload: Below is the sample request payload
      <?xml version='1.0' encoding='utf-8'?>
           <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/xmlns:axis="http://ws.apache.org/axis2">
                   <soapenv:Body> <axis:sayHello><axis:name>Mediator!</axis:name></axis:sayHello>
                   </soapenv:Body>
            </soapenv:Envelope>
    2. Response Payload: Response payloads looks like the below
      <?xml version='1.0' encoding='utf-8'?>
      <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
            <soapenv:Body><ns:sayHelloResponsexmlns:ns="http://ws.apache.org/axis2"><ns:return>Hello wM Mediator!</ns:return></ns:sayHelloResponse>
            </soapenv:Body>
      </soapenv:Envelope>
       
  2. Log Generation Frequency (Always/Success/Failure)
  • Always: Logs all the successful and failure transaction events.
  • Success: Logs only the successful transaction events.
  • Failure: Logs only the failed transaction events

                    3. Select one or more destination in Send Log Data

  • CentraSite: Logs the transaction events for a virtual service in CentraSite. If you choose this destination, you should configure the SNMP server configuration in Mediator. For details, 
    refer to the Configuration of destinations section.
  • Local Log: Logs the transaction events in the server log of the Integration Server on which Mediator is running. If you choose this destination, you should configure the IS logging 
    configuration in IS Admin for Mediator. For details, refer to the Configuration of destinations section.
    a. Info: logs the error-level, warning-level, and informational-level alerts.
    b. Warn: logs the error-level and warning-level alerts.
    c. Error: logs only error-level alerts.
        Note: The Integration Server Administrator's logging level for Mediator should match the logging level specified for this action (go to Settings > Logging > Server Logger).
        Please refer section 5 Enabling Local Log (in Mediator part)
  • SNMP: Logs the transaction events using 3rd party SNMP server.
  • Email: Sends the transaction events to an SMTP email server, which sends them to the email address (es) you specified. If you choose this destination, you should configure 
    the Email Configuration in Mediator admin pages.
  • Audit Log: Logs only transaction events to the configured database and the flat file. If you choose database destination, you should configure the Database pool in IS. 
  • EDA: Mediator can use EDA to log the transaction events to a database or default EDA endpoint. If you choose this destination, you should configure the EDA Configuration in Mediator admin pages.

3.4 Consumer Application Creation

Step 1: Go to Asset Catalog > Browse in CentraSite

Step 2: Click AddAsset… button and provide the following values.

  • Select Type as “Application” from dropdown list.
  • Name as “ConsumerApp1
  • Organization as “Default Organization” and Save it.

Step 3: In the consumer application details page, select Identification Tab > IPV4 Address and provide the IP range like From as 10.60.34.121 and To as 10.60.34.124, Save it.


4. DEPLOY A VIRTUAL SERVICE INTO MEDIATOR

Step 1: After virtualization, do the following to deploy the virtual alias

  • Click the Publish icon
  • Select the target (MediatorBVTClusterTarget)
  • Click the Publish button and “MyVirtualService1” (Virtual Alias) will be published into the Mediator.

Step 2: Once Virtual Alias created, it will go to the service details page. Now, the virtual service is ready to use.

5. DEPLOY A CONSUMER APPLICATION INTO MEDIATOR

Step 1:

    • Go to Virtual Service details page. Ex. Virtual Service name is MyVirtualService1
    • Select Consumer tab.
    • Click Add Application... button.
    • From the popup wizard, select consumer application "ConsumerApp1"
    • Click Ok button.

Step 2:

  • Go to Virtual Service details page. Ex. Virtual Service name is MyVirtualService1
  • Select Deployment tab.
  • Click Deploybutton.
  • From the popup wizard, select the target like "MediatorBVTClusterTarget"
  • Click Ok button.

Step 3: Now, Consumer application is deployed successfully and ready to use.

 

6. VERIFY CLUSTER DEPLOYMENT OF A VIRTUAL SERVICE

Step 1: Login to Mediator admin page http://<hostname:port>/WmMediator. Ex. http://vmmed951bvt02w.eur.ad.sag:5555/WmMediator/

Step 2: Click Services to see the deployed virtual services in the cluster nodes.

Mediator node-1

Mediator Node2

7. VERIFY CLUSTER DEPLOYMENT OF A CONSUMER APPLICATION

Step 1: Login to Mediator admin page http://<hostname:port>/WmMediator. Ex. http://vmmed961bvt02w.eur.ad.sag:5555/WmMediator/

Step 2: Click Consumers to see the deployed consumer applications in the cluster nodes.

Mediator node-1

Mediator node-2

 

8. EXECUTION  OF VIRTUAL SERVICE RUNTIME INVOCATION USING SOAPUI

Invoke the Virtual service which is deployed among the clustered nodes. The aggregated metrics should be collected in the configured CentraSite in the next step.

Step1 : Using SOAPUI client, invoke the virtual service 8 times (for success counts) e.g http://vmmed961bvt02w.eur.ad.sag:5555/ws/MyVirtualService1?wsdl where the VS running in clustered Mediator node1.

Step2 : Using SOAPUI client, invoke the virtual service 6 times (for failure counts) e.g http://vmmed961bvt02w.eur.ad.sag:5555/ws/MyVirtualService1?wsdl where the VS running in clustered Mediator node1.

Step3 : Using SOAPUI client, invoke the virtual service 6 times (for success counts) e.g http://vmmed961bvt03w.eur.ad.sag:5555/ws/MyVirtualService1?wsdl where the VS running in clustered Mediator node2.

Step4 : Using SOAPUI client, invoke the virtual service 4 times (for failure counts) e.g  http://vmmed961bvt03w.eur.ad.sag:5555/ws/MyVirtualService1?wsdl where the VS running in clustered Mediator node2.

9. VERIFY RUNTIME METRICS IN CENTRASITE

Step 1: Go to the Virtual Service details. e.g. MyVirtualService1

Step 2: Click Advanced Information > Runtime Metrics and provide the following values for Filters.

  • Target as “MediatorTarget
  • Date Range as “Last 12 hours” (as optional)
  • Displayed Interval as “3h” (as optional)

Step3: From the above filters, it gives the below runtime metrics results.

  • Clustered Mediator Node1 success counts are 8 + Clustered Mediator Node2 success counts are 6. The total success counts(metrics) observed should be 14.
  • Clustered Mediator Node1 failure counts are 6 + Clustered Mediator Node2 failure counts is 4. The total failure counts (metrics) observed should be 10.

 

10.TROUBLESHOOTING

S.No
Exception
Message Description
Possible Cause/Solution
1.

In the Mediator server log you may see the below exception

Initial cause was org.terracotta.license.LicenseException; Shutting down server. com.softwareag.osgi.is.launcher.ISLauncher.

License key file <SAG_HOME>\common\conf\terracotta-license.key does not exist or cannot be read

Make sure the TC license is applied properly or placed in the location as expected by the TC

2.

In the Mediator server log you may see the below exception

Initial cause was java.lang.RuntimeException: com.tc.config.schema.setup.ConfigurationSetupException: Shutting down server. com.softwareag.osgi.is.launcher.ISLauncher

Integration Server could not initialize the cache manager. Stopping Integration Server initialization. Use the server log and error log to diagnose and correct the problem. Make sure the terracotta server is running or accessible.
3.

In the Mediator server log you may see the below exception

Initial cause was java.lang.RuntimeException: com.tc.config.schema.setup.ConfigurationSetupException: Shutting down server. com.softwareag.osgi.is.launcher.ISLauncher

Integration Server could not initialize the cache manager. Stopping Integration Server initialization. Use the server log and error log to diagnose and correct the problem. Make sure the port number of terracotta server is correct or not

 

Click here to download PDF version of this tutorial.