How Do I Set Up the Data Centers in Hot Standby Mode Using Composite Operation?
This use case explains how to set up data centers in hot standby mode. When you want to set up the data centers simultaneously, you can use this method.
The data centers are set up in hot standby mode using the REST APIs. You can find the REST API in the swagger file APIGatewayDataManagement.json located at SAG_Root/IntegrationServer/instances/default/packages/WmAPIGateway/resources/apigatewayservices.
For example, assume that you have two data centers DC 1 and DC 2 in the following landscape:
Data Center Name | Host Name | Region |
DC 1 | uk.myhost.com | United Kingdom |
DC 2 | us.myhost.com | United States |
To set up the data centers in hot standby mode
1. Configuring data centers.
Configure and establish connection between DC 1 and DC 2 data centers in a single step rather than configuring the listener and ring separately using the PUT/rest/apigateway/dataspace/configure REST API. You can invoke this REST API on any one of the data centers (DC 1 or DC 2).
Request: PUT http://uk.myhost.com:5555/rest/apigateway/dataspace/configure.
Sample payload for DC 1 is as follows:
{
"local":
{
"host": "uk.myhost.com",
"syncPort": 4440
},
"remotes":
[
{
"host": "us.myhost.com",
"port": 5555,
"syncPort": 4440,
"userName": "Administrator",
"password": "manage"
}
]
}
Ensure that the local section in the payload contains the details of the data center on which you invoke the REST API. You must have the Manage general administration configurations functional privilege for the API Gateway instance running on the data center to authenticate the unit level operations that are performed simultaneously. If you have multiple API Gateway instances clustered in a data center and when you use load balancer for high availability between the API Gateway instances, then you have to provide the load balancer URL as host in the payload.
HTTP response appears as follows:
{
"local":
{
"host": "uk.myhost.com",
"syncPort": 4440
},
"remotes":
[
{
"host": "us.myhost.com",
"port": 5555,
"syncPort": 4440,
"userName": "Administrator",
"password": "manage"
}
]
}
On successful configuration, the response status code displays as 200 and you can see the corresponding log entry in the Server Logs.
2. Securing the Remote Procedure Call (gRPC) channel.
This is optional. You update the configuration only when you want to secure the gRPC channel. In Cross-DC support, the communication between data centers happens through gRPC channel. Securing the gRPC channel prevents data leaks and cyber attacks. You can secure the gRPC channel of all the data centers by updating the configuration with keystore and truststore information. The gRPC channel is secured by configuring keystore and truststore with self-signed or CA signed certificates. Make sure that you have configured keystore and truststore in the API Gateway instance running on the data center for which you want to secure the gRPC channel. For information about configuring keystore and truststore, see Keystore and Truststore section in webMethods API Gateway User's Guide. This configuration can be updated on any one of the data centers (DC 1 or DC 2) by invoking the PUT/rest/apigateway/dataspace/configure REST API with keystore and truststore details to secure the gRPC channel.
Request: PUT http://uk.myhost.com:5555/rest/apigateway/dataspace/configure.
Sample payload for DC 1 that uses SSL certificate is as follows:
{
"local": {
"host": "uk.myhost.com",
"syncPort": 4440,
"keyStoreAlias":"UK_Key",
"keyAlias":"Key_Alias_UK",
"trustStoreAlias":"Trustpackage",
"insecureTrustManager": true
},
"remotes": [
{
"host": "us.myhost.com",
"port": 5555,
"syncPort": 4440,
"userName": "Administrator",
"password": "manage",
"keyStoreAlias":"US_Key",
"keyAlias":"Key_Alias_US",
"trustStoreAlias":"Trustpackage",
"insecureTrustManager": true
}
]
}
HTTP response appears as follows:
{
"local": {
"host": "uk.myhost.com",
"syncPort": 4440,
"keyStoreAlias":"UK_Key",
"keyAlias":"Key_Alias_UK",
"trustStoreAlias":"Trustpackage",
"insecureTrustManager": true
},
"remotes": [
{
"host": "us.myhost.com",
"port": 5555,
"syncPort": 4440,
"userName": "Administrator",
"password": "manage",
"keyStoreAlias":"US_Key",
"keyAlias":"Key_Alias_US",
"trustStoreAlias":"Trustpackage",
"insecureTrustManager": true
}
]
}
Note:
If you have configured the truststore using CA signed certificate, then in the payload, set "insecureTrustManager": false.
On successful configuration, the response status code displays as 200 and you can see the corresponding log entry in the Server Logs.
3. Configuring data centers to use HTTPS port.
This is optional. You update the configuration, if the API Gateway instances running on the data center use HTTPS port. By default, API Gateway is available on a HTTP port. You can also make API Gateway available on an external HTTPS port to establish a secure connection. If you make API Gateway available on a HTTPS port, then you must update the configuration with the HTTPS port details. Make sure you have added and enabled the HTTPS port in the API Gateway instance running on the data center. You must also make sure that you have configured the listener specific credentials to the added port. For information about adding HTTPS port, see Adding an HTTPS Port section in webMethods API Gateway User's Guide. This configuration can be updated on any one of the data centers (DC 1 or DC 2) by invoking the PUT/rest/apigateway/dataspace/configure REST API with HTTPS port details to secure the ports.
Request: PUT https://uk.myhost.com:2503/rest/apigateway/dataspace/configure.
Sample payload for DC 1 is as follows:
{
"local": {
"host": "uk.myhost.com",
"port":2503,
"isHttps": true,
"syncPort": 4440,
"keyStoreAlias":"UK_Key",
"keyAlias":"Key_Alias_UK",
"trustStoreAlias":"Trustpackage",
"insecureTrustManager": true
},
"remotes":
[
{
"host": "us.myhost.com",
"port": 2505,
"isHttps": true,
"syncPort": 4440,
"userName": "Administrator",
"password": "manage",
"keyStoreAlias":"US_Key",
"keyAlias":"Key_Alias_US",
"trustStoreAlias":"Trustpackage",
"insecureTrustManager": true
}
]
}
HTTP response appears as follows:
{
"local": {
"host": "uk.myhost.com",
"port": 2503,
"isHttps": true,
"syncPort": 4440,
"keyStoreAlias": "UK_Key",
"keyAlias": "Key_Alias_UK",
"trustStoreAlias": "Trustpackage",
"insecureTrustManager": true
},
"remotes": [
{
"host": "us.myhost.com",
"port": 2505,
"isHttps": true,
"syncPort": 4440,
"userName": "Administrator",
"password": "manage",
"keyStoreAlias": "US_Key",
"keyAlias": "Key_Alias_US",
"trustStoreAlias": "Trustpackage",
"insecureTrustManager": true
}
]
}
On successful configuration, the response status code appears as 200 and you can see the corresponding log entry in the Server Logs.
4. Activating data centers in hot standby mode.
Data centers can be activated in two different ways. You can activate each data center separately by invoking the PUT/rest/apigateway/dataspace/activate REST API from each data center or activate all the data centers in this mode at a time by invoking the PUT/rest/apigateway/dataspace/activateAll?mode= STANDBY REST API once on any one of the data centers.
Activating individual data centers.
Activate DC 1 and DC 2 separately using the PUT/rest/apigateway/dataspace/activate REST API.
Request: PUT https://uk.myhost.com:2503/rest/apigateway/dataspace/activate.
Sample payload for DC1 is as follows:
{
"mode": "STANDBY"
}
HTTP response appears as follows:
{
"mode": "STANDBY"
}
Note:
Similarly, you can activate DC 2 data center by invoking the PUT/rest/apigateway/dataspace/activate REST API with the respective payloads.
On successful activation, the response status code appears as 200 and you can see the corresponding log entry in the Server Logs.
Activating multiple data centers.
Activate DC 1 and DC 2 data centers in a single step using the PUT/rest/apigateway/dataspace/activateAll?mode= STANDBY REST API on any one of the data centers (DC 1 or DC 2)
Request: PUT https://uk.myhost.com:2503/rest/apigateway/dataspace/activateAll?mode= STANDBY.
Sample payload is as follows:
{
"local": {
"host": "uk.myhost.com",
"port":2503,
"isHttps": true,
"syncPort": 4440,
"keyStoreAlias":"UK_Key",
"keyAlias":"Key_Alias_UK",
"trustStoreAlias":"Trustpackage",
"insecureTrustManager": true
},
"remotes":
[
{
"host": "us.myhost.com",
"port": 2505,
"isHttps": true,
"syncPort": 4440,
"userName": "Administrator",
"password": "manage",
"keyStoreAlias":"US_Key",
"keyAlias":"Key_Alias_US",
"trustStoreAlias":"Trustpackage",
"insecureTrustManager": true
}
]
}
HTTP response appears as follows:
{
"local": {
"host": "uk.myhost.com",
"port":2503,
"isHttps": true,
"syncPort": 4440,
"keyStoreAlias":"UK_Key",
"keyAlias":"Key_Alias_UK",
"trustStoreAlias":"Trustpackage",
"insecureTrustManager": true
},
"remotes":
[
{
"host": "us.myhost.com",
"port": 2505,
"isHttps": true,
"syncPort": 4440,
"userName": "Administrator",
"password": "manage",
"keyStoreAlias":"US_Key",
"keyAlias":"Key_Alias_US",
"trustStoreAlias":"Trustpackage",
"insecureTrustManager": true
}
]
}
On successful activation, the response status code displays as 200 and you can see the corresponding log entry in the Server Logs.
Note:
When DC 1 fails, you have to reconfigure the load balancer with DC 2 details, so that DC 2 handles the client request. When DC 1 is restored back, it gets added to the ring automatically as a standby data center. DC 2 continues to handle the client requests.
If you want to replace any one of the data centers (DC 1 or DC 2) with a new data center (for example, DC 3) in hot standby mode, you have to bring down either DC 1 or DC 2 to standalone mode. For example, if you bring down DC 2 to standalone mode, then you can reconfigure the setup with DC 1 and DC 3 in hot standby mode.