Architecture insights
At Cloud-IAM, Deployments are made High Availability, secure and robust in different manners. All the information about the Cloud-IAM can not be disclosed, but here some details of how Cloud-IAM works.
Cloud-IAM Architecture insight
The Cloud-IAM architecture is designed to guarantee the isolation of the deployments and avoid any neighborhood noise.
The Cloud-IAM Control Plane is composed of the Cloud-IAM Console, API and Database that stores the Cloud-IAM Customers, their Organization settings and the attached Deployment.
The Cloud-IAM Data Plane represents each of the deployments managed by Cloud-IAM. They are all self-sufficient and continue working properly even if the Cloud-IAM Control Plane is having issues.
The Control Plane triggers jobs that are executed via a pool of worker to interact with the Data Planes.
Deployment Architecture insight
Cloud-IAM deployments are deployed into their own network:
- Dedicated VPC on all availability zones of the region
- Fixed IP addresses for every inbound and outbound elements
- Network restriction for each zone
The architecture do not have any single point of failure. Every element is replicated at least once to properly handle every element failure or maintenance.
Inbound Load balancers are DNS load balanced with a Health check. Every Keycloak node is self sufficient. Databases are replicated with failover
Data transfer
Even if your deployment are kept isolated from others, they are part of our overall infrastructure. That's why some data might be gathered in our monitoring systems.
This is the case of the deployment logs, deployment usage metrics that are aggregated in France.
Database snapshot are located in the deployment region, but the deployment cold backup are stored in France.
Also note that all the control plane is being hosted in France. That includes the deployment settings, organization members, deployment third party resources, deployment custom extensions.
Deployment lifecycle
The deployment is automatically managed by Cloud-IAM and its status is reflected in the Cloud-IAM Console.
When the deployment is in a normal state, it is marked as RUNNING.
Through the API or the Console, the customer can interact with the deployment. Some actions such as managing custom extensions, setting environment variables, ... require to restart the Keycloak cluster. This is smoothly done through a rolling upgrade over all the nodes of the cluster.
During this period, the deployment is marked as STARTING. For the end-user point of view, the rolling upgrade is transparent. However, the deployment in the Cloud-IAM data plane system is frozen until it is RUNNING again. This is done to ensure the deployment changes are applied atomically.
If, for any reason, during a rolling upgrade, the process could not complete, the deployment is marked as ERROR. This happens for instance, when a custom extension is not properly packaged, with missing classes, ... In this case, the process is interrupted and the deployment is blocked in this state.
Please note that even in the ERROR state, the Keycloak cluster might still be available. Usually, only one node of the cluster is missing and this error is seamless for the end-user.
In such case, please contact the support so that the Cloud-IAM support team helps to diagnose and heals the deployment.
Rolling upgrade
The rolling upgrade phase is when a change is applied to the cluster. To keep the cluster alive during all the operation, the nodes are sequentially removed from the cluster, upgraded, then re introduced into the cluster.
This is the safest way to upgrade a cluster by minimizing the risk. However, during this period, the cluster will run simultaneously 2 versions of the Keycloak settings with some nodes that have been updated, and others that will.
Be aware of that and respect the backward compatibility principles so that the nodes can continue sharing the same information (in the attributes, cache, database, ...) and that the services depending on it continue working properly.