Having three DataPower gateways for HA is mandatory to establish a quorum. In version 5 of API Connect, the only component that required a quorum was the Developer Portal. Now, with versions v2018 and v10, all components (such as Cloud/API Manager, Gateway, Developer Portal, and Analytics) require a quorum for HA.
You can configure gateway clustering by grouping gateways together in an on-premises implementation, or you can spread them out across data centers, AZs, or within cloud implementations. The loss of a gateway in one data center will be picked up by another member of the cluster without any impact. This is all possible because of the quorum.
Briefly, we will discuss why gateway clustering is important. However, for additional details about how to set it up, please refer to the IBM Knowledge Center on this subject. It can be located at https://www.ibm.com/support/knowledgecenter/SSMNED_v10/com.ibm.apic.install.doc/tapic_install_datapower_gateway.html.
A properly setup gateway cluster provides you with the ability to scale your gateways to handle spikes in requests and meet predefined Service-Level Agreements (SLAs). When your gateways establish a quorum, a primary gateway is elected and the other two become secondary gateways. As requests are made (including OAuth token requests), the gateways synchronize. So, if the primary gateway goes down, the secondary gateway kicks in. When the primary gateway becomes available again, resynchronization will occur so that all gateways are available and up to date.
Figure 2.10 depicts a three-instance quorum where there is a primary gateway and two secondary gateways. The disks represent the synchronization of the runtime data:
Figure 2.10 – API gateways are scalable
Important Note
Remember that the gateway is the runtime. In the event that other cluster members experience an outage due to a lost quorum, as long as the gateway is still running, your API calls will be processed. You will have to encounter a loss in capability between the interaction of gateways to managers and analytics, but business processing will continue.
Before we move on to the other components of API Connect, there is one important aspect of the gateway that solution architects and developers should be aware of. In version 5 of API Connect, the gateway service was built using the existing DataPower multi-protocol gateway service With v10.0.1.5, an additional API gateway service was created that is built as an out-of-the-box native service. This new service is dramatically faster.
Important Note
The new gateway service is called the API Connect Gateway Service (apigw). It can increase performance by 10 times, and possibly even more, depending on your APIs. Version 5 customers should be aware that during the migration to version 10, you have the choice to convert to this new API Connect Gateway Service.
With API Connect version 10, there are two options to add gateways to your topology. You just learned about the API Connect Gateway Service, which is one of those options. The other option is called the Version 5 Compatibility (v5c) gateway. This gateway was also slightly modified to help improve performance, but it is primarily available to support existing version 5 APIs. If your company is migrating from version 5 and is not ready to move to the new API Connect Gateway Service, then you would utilize the v5c gateway instead.
However, there might be legitimate reasons not to move to the latest and faster gateway. There were changes in the API Connect Gateway Service that could hinder the way you code your APIs. While the version 5 to version 10 migration would convert as much as possible, certain custom code might not migrate successfully. So, for migration efforts from version 5 to version 10, you should clearly evaluate the ramifications of converting all of your APIs into the gateway service type. Coding changes of previously running APIs could lead to negative results, rendering your APIs useless.
Important Note
Another important consideration to bear in mind when migrating to version 10 is if you have created user-defined policies based on version 5. There are new methods of supporting user-defined policies, and you might have to update those in order for your APIs to continue using them.
You have just learned about the two types of gateways that are available. If you are new to API Connect version 10 and are not migrating to version 5, you should default to using the API Connect Gateway Service.
As mentioned earlier, the gateway will capture transactional information to route to the Analytics subsystem. The Analytics subsystem is the final of the four components that comprise API Connect. You will learn about it next.