Open ExchangeOne of the recommendations when deploying InterSystems Technologies for production is to set up High Availability. The recommended API Manager for these InterSystems Technologies is the InterSystems API Manager (IAM). IAM (essentially Kong Gateway) has multiple deployment topologies.
If you are looking for high availability you could use:
a) Kong Traditional Mode: Multiple Node Clusters
b) Hybrid Mode
c) DB-less Mode
Before we break them down let's first understand the out of the box deployment that is provided by InterSystems: Installing IAM Version 3.10.
Kong Traditional Mode
This is the Kong Traditional Mode: Single Node Cluster. If you haven't yet, go over the great article by @Guillaume Rongier : IAM (InterSystems API Manager), Zero to Hero which does a great job explaining how to get IAM up and working with InterSystems IRIS.
The Kong Traditional Mode Single Node Cluster is the only currently supported IAM deployment option via IKO at this time, check out the docs for deploying that here.
Note that in the YAML of Guillaume's article (section 2.4.4 of the article or 3.4.4 of the attached OpenExchange Application's GitHub Repository's README) , we have 3 containers:
- iam-migrations (an initialization of the empty postgres database)
- iam (IAM itself!)
- db (the postgres database)
In Traditional Mode all configuration is done via the IAM container and all requests are sent to this container as well.
This can be scaled up so we are less reliant on a single IAM container:
It is very simple, you just add another IAM section! So if you are working on just one YAML you could have:
- iam-migrations
- iam1
- iam2
- db
Note that if you are working on just one YAML you must make sure you give IAM1 different ports than IAM2.
Ideally, you would like for the database (including the migrations bootstrap) and each Kong node to be running on independent servers. In this case the ports would not be a problem, but you would have to make sure to change the KONG_PG_HOST environment variable to point to the host the database is running on.
Now you have High Availability, though this is Active/Active as opposed to the IRIS/HealthConnect Active/Passive Mirroring. You can go ahead and set up any configuration on either IAM1 or IAM2 and since they share a database the other will be updated and store the same information.
.png)
If you would like independent databases you would have to have 2 individual single node clusters. Note that Kong does not have an option to "mirror" databases such as IRIS so you would need to create a pipeline to automate the configuration (or configure everything twice, or get rid of the DB entirely - see DB-less Mode). In the above diagram provided by Kong, we see that they would have just had 3 IAMs instead of 2. You would also want to add a load balancer as well as a health check probe on each IAM node, with the environment variable KONG_STATUS_LISTEN: 0.0.0.0:8100.
A significant advantage to the Traditional Mode is:
Traditional mode is the only deployment topology that supports plugins that require a database, like rate limiting with the cluster strategy, or OAuth2.
But it comes with downsides as well:
- When running in traditional mode, every Kong Gateway node runs as both a Control Plane (CP) and Data Plane (DP). This means that if any of your nodes are compromised, the entire running gateway configuration is compromised.
- If you’re running Kong Gateway Enterprise with Kong Manager, request throughput may be reduced on nodes running Kong Manager due to expensive calculations being run to render analytics data and graphs.
The following modes solve these issues.
Kong Hybrid Mode
Hybrid Mode splits what we previously referred to as the IAM container into two: the Control Plane (CP) and the Data Plane (DP).
The CP is where the administration of Kong is hosted, such as the Kong Manager (this is the "management portal" of Kong, by default accessed on port 8002 or 8445). The control plane is connected to the database and sends its configuration out to the DPs. The DPs do not have any of the responsibility for managing Kong, only for implementing the configurations. All client API requests via Kong are sent directly to the DPs without going through the CP (this is the routes, by default at port 8000 or 8443). This resolves the downsides introduced by Traditional Mode Multi Node Clusters. An imperfect InterSystems analogy to Hybrid Mode is that of ECP. The client interacts with the fast running DP who's only purpose is to serve the application, while we leave everything else, such as management, and rendering of data and graphs to the CP.
.png)
Have a look at what the Control and Data Plane YAMLs look like below.
- Deployment flexibility: Users can deploy groups of Data Planes in different data centers, geographies, or zones without needing a local clustered database for each DP group.
- Increased reliability: The availability of the database doesn’t affect the availability of the Data Planes. Each DP caches the latest configuration it received from the Control Plane on local disk storage, so if CP nodes are down, the DP nodes keep functioning.
- While the CP is down, DP nodes constantly try to reestablish communication.
- DP nodes can be restarted while the CP is down, and still proxy traffic normally.
- Traffic reduction: Drastically reduces the amount of traffic to and from the database, since only CP nodes need a direct connection to the database.
- Increased security: If one of the DP nodes is compromised, an attacker won’t be able to affect other nodes in the Kong Gateway cluster.
- Ease of management: Admins only need to interact with the CP nodes to control and monitor the status of the entire Kong Gateway cluster.
DB-less mode
The third and final Kong Gateway Deployment Topology available is DB-less mode. There is no database because all of the configuration is done declaratively in a YAML, and the application runs ephemerally (with no persistent storage).
.png)
This of course comes with the following downsides:
- The Admin API is read only.
- Any plugin that stores information in the database, like rate limiting (cluster mode), doesn’t fully function.
But there is upsides as well:
- Reduced number of dependencies: no need to manage a database installation if the entire setup for your use case fits in memory.
- Your configuration is always in a known state. There is no intermediate state between creating a Service and a Route using the Admin API.
- DB-less mode is a good fit for automation in CI/CD scenarios. Configuration for entities can be kept in a single source of truth managed via a Git repository.
Note that this time the YAML has no database, and hence no iam-migrations either.
And of course we would need the declarative configuration of Kong. See an example YAML of this below.
To summarize, there are three deployment topologies you can use for IAM to achieve HA, each with its advantages and disadvantages. I encourage you to check out the attached Open Exchange Application which takes you through deploying these topologies one by one.
