Load balancing in IBM API Connect

In the IBM® API Connect cloud, multiple Management servers and multiple Gateway servers can be used to achieve high availability or resilience. If multiple servers are used in a cloud, consider the following aspects of load balancing: API calls, the user interfaces, and communications between servers in the API Connect cloud.

Load balancing API calls

Inbound API calls can be load balanced by using the self-balancing capabilities of the DataPower® appliance, or by using an external load balancer of your choice.

To use the DataPower appliance for load balancing, you must supply an IP address or a host name that resolves to that IP address. The IP address must not be used for any existing machine and must be accessible to the consumers of your APIs. The IP address is used to automatically configure a standby group on DataPower. For more information, see Configuring the initial Gateway cluster and Standby controls.

If you are using an external load balancer, the cluster address that is specified in the Gateway Cluster settings pane in the API Manager cloud console must resolve to the load balancer. Also, the domain name that is specified for the Developer Portal and its subdomains must resolve to the load balancer. For more information, see Configuring the initial Gateway cluster. For information about which ports are used, see Firewall requirements.

Load balancing the user interfaces

If you have more than one Management server, you must use an external load balancer to provide load balancing for the user interfaces: cloud console, API Manager and Developer Portal. The cluster address that is specified in the Management Cluster settings pane in the API Manager cloud console must resolve to the load balancer. For more information, see Configuring the Management service

../com.ibm.apic.cmc.doc/create_node_mgmt_1.html. For information about which ports are used, see Firewall requirements.

Tip: You can call a health check API from your external load balancer to determine whether a specific Management server is up (ready to receive requests) or down (there is an issue with the server and it cannot receive requests). For more information, see Obtain health check data of Management servers by using REST API calls.

Load balancing the user interfaces for the Developer Portal

The load balancer must be configured to ensure that the HTTP Host header that arrives at the Developer Portal machine is set to the host name of the Developer Portal site.

Note: You can apply these principles to use a reverse proxy in front of the Developer Portal. However, you are not allowed to modify the Developer Portal URL in a reverse proxy, or modify the Host header. It must be a transparent proxy.

To check the health of a Developer Portal server, it is sufficient to configure a health check only on port 443. If there is a database problem on the server, the web server shuts down, so the load balancer needs to perform a health check only on port 443 of each portal server to decide where to route traffic.

Tip: You can call a simple health check API from your external load balancer to determine whether a specific Developer Portal site in a cluster is running. For more information, see Obtaining simple health check data of Developer Portal sites by using a REST API call.

In the following example:

Load Balancer hostname: balancer.myorg.com IP: 10.0.0.1
          AdvPortal1 hostname: adp1.myorg.com IP: 10.0.0.2
          AdvPortal2 hostname: adp2.myorg.com IP: 10.0.0.3
          AdvPortal3 hostname: adp3.myorg.com IP: 10.0.0.4
          Site1: developer.myorg.com
          Site2: special-developers.myorg.com

The DNS entries, developer.myorg.com and special-developer.myorg.com, are mapped to the IP address of the load balancer, 10.0.0.1. The mapped IP address sends the request to one of the following IP addresses while maintaining the HTTP Host header of the original request:

10.0.0.2
10.0.0.3
10.0.0.4

The HTTP Host header of the original request is either developer.myorg.com or special-developers.myorg.com, depending on what you have entered in your browser's address bar.

The URL that you enter in a browser to access the Developer Portal site must match the URL that is specified in the API Manager UI Catalog for the IBM Developer Portal.

If you are using datapower to proxy or load balance your Developer Portal, you must ensure that the variable Rewrite Host Names When Gatewaying in the Global HTTP options tab is set to FALSE. For more information, see Rewriting Host names in the DataPower user interface when you redirect.

CAUTION:

Rewriting the Developer Portal URL in the Gateway is not recommended. By rewriting the Developer Portal URL, links in the following emails will not work:

User activation emails
Password reset emails
Emails from the Developer Portal

External integration to authentication providers will not work because the Developer Portal will send the incorrect URL as the redirect_uri. In addition, loading resources such as files, js, and .css might not work.

Note: The Developer Portal listens only on ports 80 and 443. Port 80 redirects immediately to port 443 and uses the HTTPS protocol.

Rewriting `Host` names in the DataPower user interface when you redirect

To demultiplex, some protocols have distinct name-based elements that are separate from the URL. HTTP uses the Host header for this purpose; this functionality can be disabled.

To disable the functionality, you must search for Multi-Protocol Gateway, in the search bar that is located in the upper left of the screen. After you open the Multi-Protocol Gateway window, you can disable the functionality in the HTTP Options tab.

By disabling the functionality, the remote server receives a request that reflects the information as it arrived at the DataPower service. Disabling the functionality for web servers that issue redirects is preferred, as they depend on the Host header for the value of their redirect.

Note: By default, when a request is proxied by DataPower, DataPower does not propagate the original value that is receives from the Host header. DataPower rewrites to represent the final route. Disabling the functionality enables you to proxy the received header.

Supporting mutual TLS on the load balancer

Whether mutual TLS support is enabled on the load balancer effects how certificates are updated.

The standard configuration for a load balancer does not enable mutual TLS. When mutual TLS is not enabled, the external load balancer will terminate TLS on ingress (either anonymous or mutual), and connect to API Connect using anonymous (1-way) on egress. In this setup, certificates require updating only on the load balancer.

If mutual TLS is enabled between API Connect and the load balancer, then certificates on API Connect require updating (as well as the certificates on the load balancer). Depending on the load balancer configuration, either the identity store, trust store or both will require updating.

Load balancing communications between servers

Communications between multiple Gateway servers, between multiple Management servers, and between Management servers and Gateways servers within the same cloud are handled automatically in the cloud configuration. However, if your topology is complex, you might have to ensure that the necessary ports are open across firewalls. For information about which ports are used, see Firewall requirements.

You can use a load balancer to optimize internal communications between the Gateway servers and Management servers. A load balancer is typically used when you want to gain finer control over load distribution, particularly if your API Connect cloud spans two of more different geographical locations. For more information, see Using an internal load balancer to optimize internal communications.