Enabling high performance peering for DataPower API Gateway on Kubernetes

Enabling high performance peering on DataPower API Gateway deployments optimizes API transaction performance.

About this task

You can configure DataPower API Gateways to have dedicated gateway-peering objects for the API Connect Gateway Service, subscription data, and rate-limit data. By default, the gateway service is configured to share a single gateway-peering object for all three. In some scenarios, use of a single object can impact API performance. Enabling of high performance peering is highly recommended.

High performance peering is available in API Connect Version 2018.4.1.7 and later.

Use the procedure in this topic to reconfigure an existing API Connect deployment to enable high performance peering.

Important: Enabling high performance peering on an existing deployment requires an outage to API transaction processing during configuration.

If you are upgrading the Gateway from Version 2018.4.1.6 to version 2018.4.1.7 or later, complete the upgrade first and then use the instructions in this topic to reconfigure peering. For upgrade instructions, see Upgrading API Connect in a Kubernetes environment.
If you are deploying DataPower API Connect externally to Kubernetes, such as part of a physical or virtual DataPower appliance, do not use this topic. Instead, follow the configuration instructions in Sample configuration for multiple peering objects on gateway services external to Kubernetes

It is important that all gateway instances are down at the same time, in order for dynamic reconfiguration to take place. In this case, dynamic reconfiguration is achieved by scaling down gateway services, using apicup to install, then scaling up the gateway services. To review the DataPower Gateway dynamic reconfiguration process, see Dynamically re-registering and reconfiguring a Gateway service in a Kubernetes deployment.

Procedure

Set the high performance peering option in the apicup gateway configuration.
```
apicup subsys set gwy enable-high-performance-peering="true"
```
You must run apicup in the same project directory as where the gateway was originally configured using apicup.

Obtain the name of the StatefulSet, and scale the cluster down to a single gateway.

kubectl get statefulset
kubectl scale statefulset r600e4a32ef-dynamic-gateway-service  --replicas=1

Use apicup to redeploy the gateway pod.
```
apicup subsys install gwy
```

Optional: Log in to the DataPower CLI and use the

show
gateway-peering-status

status to confirm that multiple gateway-peering objects have been configured.

Confirm that the status shows separate entries for API Connect Gateway Service (gwd), API Gateway rate limit (rate-limit), and API Gateway subscriptions (subs). For example:


idg# sw apiconnect
idg[apiconnect]# config
Global configuration mode
idg[apiconnect](config)# show gateway-peering-status

 Address       Configuration name Pending updates Replication offset Link status Primary
 ------------- ------------------ --------------- ------------------ ----------- -------
 192.168.0.127 gwd                0               0                  ok          yes
 192.168.0.127 rate-limit         0               0                  ok          yes
 192.168.0.127 subs               0               0                  ok          yes

When the first gateway pod is marked ready, scale the StatefulSet to the original number of gateways. For example:
```
kubectl scale statefulset r600e4a32ef-dynamic-gateway-service  --replicas=3
```
Be sure to scale up the same StatefulSet that you scaled down in Step 2.
Wait for management server heartbeat to detect that reconfiguration is required.

Heart beat processing usually detects the need for reconfiguration within 5 minutes, but the process may take a few more minutes to begin. When the show api-collection command returns data, the reconfiguration has begun. The length of time to required to reach completion depends on the number of catalogs, products, APIs, subscriptions, etc.