High Availability
Optimizer Hub has High Availability (HA) as a fundamental architectural principle in its design:
-
The system architecture prioritizes continuous update and service reliability.
-
Built-in redundancy at multiple levels ensures business continuity.
High Availability in Clusters
High Availability (HA) is guaranteed inside and between clusters.
Inside a Cluster
The nodes inside the Optimizer Hub service have failover built-in:
-
Automatic redistribution of workload when a node fails.
-
The system maintains full functionality even if individual nodes crash.
-
A seamless transition between nodes prevents service interruption.
Between Clusters
HA is also integrated in configurations with multiple clusters:
-
Clusters have health check endpoints to declare their readiness to accept traffic.
-
You can add a DNS-based load balancer or service mesh to route the requests to the nearest available cluster.
-
Custers can sync important information.
High Availability Configuration
Follow these recommendations to ensure High Availability (HA) of Optimizer Hub.
-
Install multiple instances of the Optimizer Hub service, for example, one per region of availability zone.
-
Front the Optimizer Hub service with either:
-
A DNS-based load balancer (i.e. Amazon Route 53)
-
Kubernetes service mesh (i.e. Istio)
-
See Configuring Optimizer Hub Host > Host for High Availability and Failover for more info.
-
-
Let the clients connect to the load balancer or service mesh.
-
Use the health check APIs to only route requests to instances that are ready to handle traffic.
-
Route the requests to the Optimizer Hub service that is nearest to the JVMs.
|
Note
|
Cloud Native Compiler artifacts are not synced. They can be easily regenerated without compromising application performance. |