Multi data center deployments#

Overview#

Multi-node clusters can be deployed in both Active/Active or Active/Standby configurations:

Configuration

Description

Active/Active

Active/Active configurations have all the unified nodes enabled for transaction processing.

In order to run an Active/Active configuration, the latency (RTT) between data centers must not exceed 20ms.

Active/Standby

Active/Standby configurations have only the unified nodes in the primary data center (the data center containing the unified node with the primary database) enabled for transaction processing.

Use an Active/Standby configuration for higher latencies.

Switch to an Active/Standby configuration#

To switch to an Active/Standby configuration, do the following on all unified nodes in the secondary data center (the data center not containing the unified node with the primary database):

  1. Log into platform:

    ssh platform@<ip_address>

  2. Set the worker count on the nodes in the secondary data center to zero:

    voss workers 0

    Setting the number of workers is persistent; that is, this setting will still apply after upgrades and system restart.

Setting web weights for an Active/Standby configuration#

For an Active/Standby configuration, the proxy server web weights should be set to the unified nodes on the primary data center, using the web weight add command:

The web weight specifies the routing and relative counts of the initial HTTP request from the web proxy to a unified node. The initial request could be a request such as a transaction or, for example, a GET request.

Consider the following web weights configuration:

172.0.0.158:443: 1
172.0.0.159:443: 1
172.0.0.161:443: 1
172.0.0.162:443: 1
173.0.0.163:443: 0
173.0.0.164:443: 0

This configuration means that the servers 173.0.0.163 and 173.0.0.164 serve as backup servers and requests are only routed to these if the other servers are not available.

While the other servers are available, an equal number of requests are routed to them in a round-robin manner.

Note

Refer to the Best Practices Guide for more information on deployment models and web weight settings.

Example:

Consider an example where:

Note

The examples below show system command output where the Phone Based Registration application is running.

  1. Primary data center has unified nodes with IP addresses and ports:

    • 172.0.0.158:443

    • 172.0.0.159:443

    • 172.0.0.161:443

    • 172.0.0.162:443

    A unified node typically shows the following output for the web weight list command:

    $ web weight list
Default service weights

 voss-deviceapi:
     phoneservices:
         172.0.0.158:8412: 1
     selfservice:
         172.0.0.158:5000: 1
     voss-deviceapi:
         172.0.0.158:9902: 1
     voss-portal:
         172.0.0.158:6001: 1

  2. Secondary data center has unified nodes with IP addresses and ports:

    • 173.0.0.163:443

    • 173.0.0.164:443

The defaults of the web weight list command run on the proxy servers is as follows:

  1. Primary data center proxy server:

$ web weight list
Default service weights

    phonebasedreg:
        phoneservices:
            172.0.0.158:443: 1
            172.0.0.159:443: 1
            172.0.0.161:443: 1
            172.0.0.162:443: 1
            173.0.0.163:443: 0
            173.0.0.164:443: 0
    voss-deviceapi:
        selfservice:
            172.0.0.158:443: 1
            172.0.0.159:443: 1
            172.0.0.161:443: 1
            172.0.0.162:443: 1
            173.0.0.163:443: 0
            173.0.0.164:443: 0
        voss-deviceapi:
            172.0.0.158:443: 1
            172.0.0.159:443: 1
            172.0.0.161:443: 1
            172.0.0.162:443: 1
            173.0.0.163:443: 0
            173.0.0.164:443: 0

  1. Secondary data center proxy server:

$ web weight list
Default service weights

    phonebasedreg:
        phoneservices:
            172.0.0.158:443: 0
            172.0.0.159:443: 0
            172.0.0.161:443: 0
            172.0.0.162:443: 0
            173.0.0.163:443: 1
            173.0.0.164:443: 1
    voss-deviceapi:
        selfservice:
            172.0.0.158:443: 0
            172.0.0.159:443: 0
            172.0.0.161:443: 0
            172.0.0.162:443: 0
            173.0.0.163:443: 1
            173.0.0.164:443: 1
        voss-deviceapi:
            172.0.0.158:443: 0
            172.0.0.159:443: 0
            172.0.0.161:443: 0
            172.0.0.162:443: 0
            173.0.0.163:443: 1
            173.0.0.164:443: 1

To ensure that the secondary data center is configured for a Standby mode, change the web weights to show userweights, as displayed in the output on the secondary data center proxy server below:

$ web weight list
Default service weights

    phonebasedreg:
        phoneservices:
            172.0.0.158:443: 0
            172.0.0.159:443: 0
            172.0.0.161:443: 0
            172.0.0.162:443: 0
            173.0.0.163:443: 1
            173.0.0.164:443: 1
    voss-deviceapi:
        selfservice:
            172.0.0.158:443: 0
            172.0.0.159:443: 0
            172.0.0.161:443: 0
            172.0.0.162:443: 0
            173.0.0.163:443: 1
            173.0.0.164:443: 1
        voss-deviceapi:
            172.0.0.158:443: 0
            172.0.0.159:443: 0
            172.0.0.161:443: 0
            172.0.0.162:443: 0
            173.0.0.163:443: 1
            173.0.0.164:443: 1

Customized service weights
    userweights:
        172.0.0.158:443: 1
        172.0.0.159:443: 1
        172.0.0.161:443: 1
        172.0.0.162:443: 1
        173.0.0.163:443: 0
        173.0.0.164:443: 0

The outcome is that the load balancing web weights have been changed to the unified nodes on the primary data center.