How Do I Set Up the Data Centers in Active-Active Mode Using Basic Operation?
This use case explains how to set up the data centers in the active-active mode. When you want to set up the data centers at a unit level, you can use this method.
The data centers are set up in active-active 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 three data centers DC 1, DC 2, and DC 3 in the following landscape:
Data Center Name | Host Name | Region |
DC 1 | uk.myhost.com | United Kingdom |
DC 2 | us.myhost.com | United States |
DC 3 | in.myhost.com | India |
In general, the active-active mode can accommodate any number of data centers.
To set up the data centers in active-active mode
1. Configuring listener.
Configure the listener on all the data centers (DC 1, DC 2, and DC 3) using the PUT/rest/apigateway/dataspace/listener REST API.
Request: PUT http://uk.myhost.com:5555/rest/apigateway/dataspace/listener.
Sample payload for the DC 1 is as follows:
{
"listener": {
"nodeName": "ecb1308f-22ac-4877-aba9-471a31a834e6",
"host": "uk.myhost.com",
"port": 4440
},
}
The system assigns unique node name for each data center. You must know the node name to configure the data centers as listener and to establish a ring. If you are unaware of the node names, invoke the GET/rest/apigateway/dataspace REST API on that data center whose node name you want to know. 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, you have to provide the load balancer URL as host in the payload.
HTTP response appears as follows:
{
"listener": {
"nodeName": "ecb1308f-22ac-4877-aba9-471a31a834e6",
"host": "uk.myhost.com",
"port": 4440
},
}
}
Note:
Similarly, you can configure the listener on DC 2 and DC 3 by invoking the PUT/rest/apigateway/dataspace/listener REST API with the respective payload.
On successful configuration, the response status code displays as 200 and you can see the corresponding log entry in the Server Logs.
2. Establishing ring.
Establish a fully connected network, where all the data centers are inter-connected and forms a ring using the PUT/rest/apigateway/dataspace/ring REST API. You must invoke this REST API on all the data centers (DC 1, DC 2, and DC 3).
Request: PUT http://uk.myhost.com:5555/rest/apigateway/dataspace/ring.
Sample payload for DC 1 is as follows:
{
"ring": [
{
"nodeName": "a04609a0-ca13-44db-98e1-f988ba18fbb4",
"host": "us.myhost.com",
"port": 4440
},
{
"nodeName": "4820681b-f2fd-42d7-bccd-cf580ea8bf1c",
"host": "in.myhost.com",
"port": 4440
}
]
}
Note:
When you configure the ring from one data center, you have to provide the details of other associated data centers with which you want to establish the ring configuration in the payload. For example, when you establish the ring configuration from DC 1, you have to specify the DC 2 and DC 3 details in the payload. Similarly, when you establish the ring configuration from DC 2, you have to specify the DC 3 and DC 1 details in the payload. Likewise, when you establish the ring configuration from DC 3, you have to specify the DC 2 and DC 1 details in the payload.
HTTP response appears as follows:
{
"ring": [
{
"nodeName": "a04609a0-ca13-44db-98e1-f988ba18fbb4",
"host": "us.myhost.com",
"port": 4440
},
{
"nodeName": "4820681b-f2fd-42d7-bccd-cf580ea8bf1c",
"host": "in.myhost.com",
"port": 4440
}
]
}
Note:
Similarly, you can configure the ring on DC 2 and DC 3 by invoking the PUT/rest/apigateway/dataspace/ring REST API with the respective payload.
On successful configuration, the response status code displays as 200 and you can see the corresponding log entry in the Server Logs.
3. 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. You have to update the listener configuration with keystore and truststore details using this
PUT/rest/apigateway/dataspace/listener REST API with keystore and truststore details on all the data centers DC 1, DC 2, and DC 3 to secure the gRPC channel.
Request: PUT http://uk.myhost.com:5555/rest/apigateway/dataspace/listener.
Sample payload for DC 1 that uses SSL certificate is as follows:
{
"keyStoreAlias":"UK_Key",
"keyAlias":"Key_Alias_UK",
"trustStoreAlias":"Trustpackage"
"listener": {
"nodeName": "ecb1308f-22ac-4877-aba9-471a31a834e6",
"host": "uk.myhost.com",
"port": 4440
},
"insecureTrustManager": false
}
HTTP response appears as follows:
{
"keyStoreAlias":"UK_Key",
"keyAlias":"Key_Alias_UK",
"trustStoreAlias":"Trustpackage"
"listener": {
"nodeName": "ecb1308f-22ac-4877-aba9-471a31a834e6",
"host": "uk.myhost.com",
"port": 4440
},
"insecureTrustManager": false,
"$resourceID": "listener"
}
Note:
If you have configured the truststore using CA signed certificate, then in the payload, set
"insecureTrustManager": false.
Invoke the
PUT/rest/apigateway/dataspace/listener REST API on DC 2 and DC 3. Provide a similar payload for DC 2 and DC 3.
On successful configuration, the response status code displays as 200 and you can see the corresponding log entry in the Server Logs.
Important:
Whenever you update the listener configuration, make sure you update the ring configuration in all the associated data centers using the PUT/rest/apigateway/dataspace/ring REST API. For example, if you update the listener configuration on DC 1, you have to update the ring configuration on DC 2 and DC 3.
4. Activating data centers in active-active 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= ACTIVE_RING REST API once on any one of the data centers.
Activating individual data centers.
Activate DC 1, DC 2, and DC 3 separately using the PUT/rest/apigateway/dataspace/activate REST API.
Request: PUT http://uk.myhost.com:5555/rest/apigateway/dataspace/activate.
Sample payload for DC 1 is as follows:
{
"mode": "ACTIVE_RING"
}
HTTP response appears as follows:
{
"mode": "ACTIVE_RING"
}
Note:
Similarly, you can activate DC 2 and DC 3 data centers by invoking the PUT/rest/apigateway/dataspace/activate REST API with the respective payloads.
On successful activation, the response status code displays as 200 and you can see the corresponding log entry in the Server Logs.
Activating multiple data centers.
Activate DC 1, DC 2, and DC 3 data centers in a single step using the PUT/rest/apigateway/dataspace/activateAll?mode= ACTIVE_RING REST API in any one of the data centers.
Request: PUT http://uk.myhost.com:5555/rest/apigateway/dataspace/activateAll?mode= ACTIVE_RING.
Sample payload for DC 1 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",
"syncPort": 4440,
"userName": "Administrator",
"password": "manage",
"keyStoreAlias":"US_Key",
"keyAlias":"Key_Alias_US",
"trustStoreAlias":"Trustpackage",
"insecureTrustManager": true
},
{
"host": "in.myhost.com",
"syncPort": 4440,
"userName": "Administrator",
"password": "manage",
"keyStoreAlias":"IN_Key",
"keyAlias":"Key_Alias_IN",
"trustStoreAlias":"Trustpackage",
"insecureTrustManager": true
}
]
}
HTTP response appears as follows:
{
"mode": "ACTIVE_RING",
"local": {
"host": "uk.myhost.com",
"syncPort": 4440,
"keyStoreAlias": "UK_Key",
"keyAlias": "Key_Alias_inchn",
"trustStoreAlias": "Trustpackage",
"insecureTrustManager": true
},
"remotes": [
{
"host": "us.myhost.com",
"syncPort": 4440,
"userName": "Administrator",
"password": "manage",
"keyStoreAlias": "US_Key",
"keyAlias": "Key_Alias_US",
"trustStoreAlias": "Trustpackage",
"insecureTrustManager": true
},
{
"host": "in.myhost.com",
"syncPort": 4440,
"userName": "Administrator",
"password": "manage",
"keyStoreAlias":"IN_Key",
"keyAlias":"Key_Alias_IN",
"trustStoreAlias":"Trustpackage",
"insecureTrustManager": true
}
],
"acknowledged": true
}
On successful activation, the response status code displays as 200 and you can see the corresponding log entry in the Server Logs.
You can validate whether the data center is activated in the respective mode by reading the current configuration of the data center using the
GET/rest/apigateway/dataspace REST API. For more information, see
How Do I Read the Current Configuration of the Data Center?Note:
In active-active, if any one of the data center (DC 1 or DC 2 or DC 3) goes down, then that data center is removed from the ring. When the same data center is restored back, then that data center gets added to the ring automatically. If you want to add one more new data center (DC 4) to the ring, then you have to update the configuration with DC 4.