Multiple data center deployment strategies

Strategies for deploying API Connect on VMware across multiple data centers.

If you want to deploy API Connect across multiple data centers, then several options are available and are detailed in this topic.

Note:

You can install the subsystems that make up an API Connect deployment in different data centers, but it is not recommended to split a single API Connect subsystem across data centers. For example, if you are deploying a three replica analytics subsystem, then all analytics subsystem VMs (replicas) must run in the same data center. Splitting a three replica deployment across data centers is only supported when the network latency between the data centers is less than 10 ms.

For the gateway service, if TMS is required and an external OAuth provider cannot be used, then the gateways can be located in different data centers if network latency between data centers is less than 30 ms.

Remote gateway deployment

To provide high availability for your published APIs, you can deploy one or more gateway services in different data centers, and register them with the management subsystem in your main data center. If your main data center has an outage, then your remote gateways continue to process calls to your published APIs.

Remote gateway deployment is the simplest way to take advantage of multiple data centers. The main disadvantage is that you cannot update any published APIs during the main data center outage (because your management subsystem is in the main data center).

Cold-standby deployment

In a cold-standby deployment, API Connect is installed and running in your main data center. In your cold-standby data center, API Connect is ready to be installed and has access to the API Connect backup files from your main data center.

If your main data center has an outage, then you install API Connect in your cold-standby data center, and restore your most recent subsystem database backups to your cold-standby deployment.

Requirements for cold-standby configuration:
  • The API Connect deployment in the cold-standby data center must use the same deployment profile as the main data center.
  • The API Connect network endpoints that you define in your main data center must be valid in your cold-standby data center.

    For example, if the network endpoint for your Cloud Manager UI is cloud-admin.apicinstall.example.com, this endpoint must route correctly to the management subsystem you install in your cold-standby data center.

    Every network endpoint that you configure during API Connect installation and configuration in your main data center must be valid in your cold-standby data center.

  • Ensure that subsystem backups are regularly copied from your main data center to your cold-standby. Backups must include both your project directory and your subsystem database backups. See Backing up and restoring on VMware.
The steps for failing over to your cold-standby data center are:
  1. Install API Connect in your cold-standby data center.
  2. Restore your API Connect subsystem database backups.
  3. Update network routing so that user traffic is directed to your cold-standby data center.
Steps 1 and 2 are essentially the same as the disaster recovery steps to restore API Connect, see Management subsystem disaster recovery.

The advantage of the cold-standby deployment over the remote gateway deployment is that your full API Connect deployment is available in the cold-standby site. Management and portal subsystem users can update APIs and view analytics data while your main site is unavailable.

Warm-standby deployment

In the warm-standby deployment, the management and portal subsystems continually replicate their databases to a warm-standby API Connect deployment in a separate data center.

The advantage of the warm-standby deployment over cold-standby is that the failover process is faster, and the management and portal databases in the warm-standby site are fully up to date. With the cold-standby strategy, your management and portal databases are only as recent as the last backup you took from your main site.

The disadvantage of the warm-standby deployment is that it adds extra complexity to the API Connect installation process, and all ongoing maintenance procedures such as upgrade. Use the warm-standby deployment strategy only when the following are essential requirements:
  • Minimal management and portal subsystem downtime.
  • No management and portal data loss, when restoration of data from the last backup that was taken of your active site is not sufficient.
Requirements for warm-standby configuration:
  • The API Connect deployment in the warm-standby data center must use the same deployment profile as the main data center.
  • The API Connect network endpoints that you define in your main data center must be valid in your warm-standby data center.

    For example, if the network endpoint for your Cloud Manager UI is cloud-admin.apicinstall.example.com, this endpoint must route correctly to the management subsystem you install in your warm-standby data center.

    Every network endpoint that you configure during API Connect installation and configuration in your main data center must be valid in your warm-standby data center.

The warm-standby deployment configuration is referred to in this documentation as two data center disaster recovery (2DCDR). For more information about 2DCDR, see Two data center warm-standby deployment strategy on VMware.