Configuring a Load Balancer for DataPower API Gateway
This articles covers the key pieces of information that needs to be passed on to the load balancer team to configure the load balancer of choice.
Please Note: DataPower Self Load balancing with the AIO module is not supported with API Connect v10.
The scenario we here is we have three DataPowers forming a single Gateway Service. Assumptions
- Default ports, 9443 for API Invocation Traffic and 3000 for Management Traffic.
- All instances are running with an identical number of cores and memory
- No non API Connect workload is running on these DataPowers
Load Balancer Algorithm
For both API Invocation Traffic and Management Traffic we would recommend the Least Connections algorithm. In the event there is an uneven distribution of non API Connect workloads I would recommend the Round Robin algorithm.
As each DataPower has the same resources and workload, least connections ensures that the requests are sent to fewest active connections, and so we can assume that this has the lowest workload.
Health Check endpoints
For the API Invocation Endpoint, the webapi-init-check endpoint must be used. E.g. https://apigw:9443/webapi-init-check. This will return a 200 response code with no payload when it is ready to serve APIs.
For the Management Traffic we recommend the GWD health check - https://apigw:3000/health. This will Return a 200 response code and a payload with the following text.
{"status":"ok"}
SSL
For the API Invocation Endpoint, it is recommended (not required) to use SSL Passthrough and control the presenter certificates in API Manager. If the customer wants to use MTLS in the future to protect their APIs this solution would not need to change
For Management interface it is recommend that MTLS is used to protect communication between the API Manager and DataPower. If MTLS is not used there is not authentication between the API Manager and DataPower. If MTLS is used the F5 is required to have SSL Passthrough enabled