Planning your deployment topology and profiles

When you install on VMware, API Connect provides a choice of deployment configurations for capacity and high availability (HA). These configurations are named ‘deployment profiles’ and there are several pre-defined profiles to choose from.

High availability versus disaster recovery

High availability focuses on minimizing the loss of service that is experienced by users during a hardware or software failure. Disaster recovery (DR) focuses on the procedures for recovering a system after a catastrophic hardware, software, or operator failure. Consider the following two metrics:
Recovery Time Objective (RTO)
The RTO is the time that it is acceptable for a system to be unavailable after a disaster.
Recovery Point Objective (RPO)
DR solutions are usually based on restoring from a backup. This means that the system can only be recovered to the state it was in when the last backup was taken, and not to the state it was in at the instant the disaster occurred. The RPO measures how far back in time the recovery point is, and therefore how much new data is lost. An RPO of zero would assert that no data is lost, but such a solution is often a compromise against the cost and performance of the system.

To achieve high availability in your API Connect VMware deployment, the three replica deployment profiles should be used, where each API Connect component is distributed across three virtual machines (VMs). However, this topology requires a low network latency between the VMs that is often unachievable between geographically separated data centers. To overcome this limitation, API Connect provides a two data center deployment solution that has both a low Recovery Time Objective (RTO), and a low Recovery Point Objective (RPO).

Deployment options

API Connect is composed of three components: Management, Portal, and Analytics, and the DataPower Gateway supporting program, see API Connect components. Each of these components includes a set of deployment profiles to cover different capacity and availability requirements.
Note: Throughout this document, the management, portal, and analytics components, and the gateway supporting program are also referred to as subsystems.
The naming convention of the deployment profiles is nAxcB.mC where:
  • nA indicates the number (A) of VMs (nodes) that are deployed to support the profile. The term node is used to refer to a VM instance (n1 means one node, n3 means three nodes).
  • cB indicates the minimum number of virtual cores (B) required on the VM to deploy the profile.
  • mC indicates the minimum amount of memory (C) in GB required by the profile on the VM.
API Connect components have two profile types: one replica and three replica:
  • The one replica profile is a single node profile and is also known as the n1 profile. It consists of a single VM for each component. This deployment type is recommended for development or testing where high availability is not a requirement.
  • The three replica profiles consist of a cluster of three VMs for each component. This profile is also referred to as the n3 profile. Each VM runs a replica of the component's microservices, and if a VM fails, the replicas on the other two VMs continue serving requests.
The available profiles for the management, portal, and analytics components are:
  • Management

    n1xc4.m16, n3xc4.m16.

  • Portal

    n1xc2.m8, n1xc4.m16, n1xc8.m16, n3xc3.m8, n3xc4.m8, n3xc8.m16.

  • Analytics

    n1xc2.m16, n1xc4.m32, n1xc6.m48, n3xc4.m16, n3xc4.m32, n3xc6.m48, n3xc8.m64.

For information about gateway CPU and memory, refer to Deploying the OVA on a VMware hypervisor in the appropriate version of the DataPower documentation.

Additional points:
  • Deployment profiles do not have to be the same for each component. For example, you can have a three replica deployment of the management component that is configured with a one replica deployment of the portal component.
  • It is possible to change the deployment profile of an existing installation, but all endpoints in your deployment must remain the same. This means that you should use a load-balancer or logical DNS records when you do the initial one replica deployment. For example, if you installed a one replica deployment and used the portal VM hostname as the portal management registration endpoint, this endpoint cannot change when you move it to a three replica deployment. For more information, see Changing deployment profiles on VMware. If you want to change the deployment profile and the endpoints, you can use the form factor migration procedure: Migrating from v10 to v10 on a different form factor.
  • Multiple portal, analytics, and gateway component instances can be added with either configuration. For example, you can have a one replica management component that is configured with two portal services: a three replica portal component, and a one replica portal component.

Two data center disaster recovery

API Connect deployments can operate across two data centers in an active/warm-standby configuration. Each data center has a complete API Connect installation. The active data center processes all user operations. The warm-standby data center does not process user operations but maintains its management and portal component databases in synchronization with the active data center. If a failure occurs at the active data center, the warm-standby data center can become active with a manual failover operation. For more information on the two data center disaster recovery configuration, see: Two data center warm-standby deployment strategy on VMware.