Question & Answer
Question
What are the high availability requirements for components in an API Connect architecture ?
Answer
On Demand Consulting
Author: Uday Pilai
Overview
This article describes the high availability requirements for components in an API Connect architecture. Intended Audience
Infrastructure architects responsible for building highly available API Connect environments.
Key components requires High Availability
Management Service Scalability & Load Balancing
- Management Servers are added to the Management Service to provide scalability:
- The Management Service will receive requests from a number of users:
- Other API Connect components such as the Developer Toolkit DataPower and Developer Portals Servers? Users of the user interfaces (API Developer/API Product Managers/Operation Lead/ App Developer)

?
?The Management Service controls two types of data:
?API Configuration Data (Users API and Plans) - At any time only one Management server (the Primary) is allowed to write the data. The other servers (Secondary) maintain a complete local cache for performance and high availability (HA) reasons.
?API Analytics Data (API usage and performance) - All of the data that is written to the Analytics system is replicated asynchronously on the back-end server. When Analytics data is sent from a DataPower service or MicroGateway service to a Management server that data is balanced across the available Management servers. If there are two or more Management servers in the Management Service at least two of the Management servers hold each Analytics data record for redundancy purposes.
?If a server fails the others keep running as normal and the whole system can still be used as before.
?Under the covers one of the management servers is designated as the primary while the others are secondary.
?If the primary is the one that dies one of the others will pick up the responsibility of being primary.
Analytics High Availability
- The analytics engine and data is hosted on the management servers
- If you have two management servers there is a copy of the analytics data on both servers.
- If one goes down you still have access to all the data.
- If you have more than two management servers there is a sharding model where each index stores a copy on two different servers.
- The analytics engine manages the copies of data and ensures the same data is always displayed as long as one of the copies is available.
- The DataPower service can use the internal load balancer in DataPower
- The address that is specified in the?DataPower Service is the virtual IP.
- You only need to specify a unique load balancer group number
- This capability is enabled by the DataPower Application Optimization feature.
- If you use a mixture of physical and virtual appliances the?load?balancing configuration might not use the full capabilities of the physical appliance.
- The DataPower servers can also use an external load balancer for API calls
- The address that is specified in the?DataPower Service window must resolve to the load balancer

?
- If a server fails using internal load balancing the in-flight resource calls fail but any subsequent ones will be routed to the gateways that are still up
- For external load balancing behavior will depend the external load balancer configuration
- Developer Portal Servers are clustered together to provide scalability. The clustering is configured on the individual Developer Portal Servers and NOT the Cloud Console.
- An external load balancer is always required for the Developer Portal when High Availability / Scalability requirements exist.
- There are two components/users that will access the Developer Portal:
- Management Service - The Cloud Management Console with the Management Console only accepts a single endpoint for the Developer Portal and this should correspond to the load balancer endpoint.
- User Interface Access ? access to the developer portal should have a common entry point via a load balancer

- The Developer Portal holds its own data for a Drupal Content Management System. This data is replicated to all nodes within the service.
- The Developer Portal requires at least 3 nodes for High Availability ? as a majority of the nodes must always be functioning ? e.g. 66% with 2 out of 3 working.
- If multi-datacenter topologies are considered then 3 data centers are recommend where DC 1 and 2 have the same number of nodes and DC 3? has at least 1. This means that a majority is always possible even on a single data center failure.
- If nodes are shutdown gracefully (e.g. during a scheduled maintenance window then the remaining nodes (even if they are in a minority) will continue to function.
A Collective is an administrative domain for a collection of Collective Members
Collective controller is a control point for a collective. The controller holds information about collective members. A collective controller exposes a REST-based interface. A collective can be configured with one or more collective controllers depending on the scalability and high availability requirements.
Collective member is a server in a Liberty collective. An API Connect collective member host is responsible for a number of Node Runtimes; one for each deployed application. A collective member shares information about itself with the collective controllers in the same collective. This information includes network location security information and operational status.
Admin clients are any other software processes that connect to a collective controller to query information about the collective and its membership or perform operations.

?
An external load balancer is always required to balance the traffic across the available instances of the Application.
Was this topic helpful?
Document Information
Modified date:
08 December 2018
UID
ibm10773007