Optimizer Hub Architecture Overview
Table of Contents
Optimizer Hub is shipped as a Helm chart and a set of docker images to be deployed into a Kubernetes cluster. The Helm chart deploys different components based on the use case.
Architecture Overview
Full Installation
In a full installation, all Optimizer Hub components are available and gateway, compile-broker, and cache are scaled when needed.
Remarks:
-
The Management Gateway component is optional, as it depends on your use case. See Management Gateway Parameters for more info.
-
All services use one pod, except Cache uses two pods by default.
Deployment Overview
With the default AWS setup (values-aws.yaml), the setup is divided into three node types (four if you also want to use the optional monitoring stack). Each node has a role label used to set the affinity for the nodes. If you set up your cluster on AWS EKS using the Azul-provided cluster config file, nodes are created with these labels.
|
Note
|
Make sure that the instances on which you run your Optimizer Hub on have enough CPU to handle your requests. For example, for AWS m5.2xlarge instances can be used, and on Google Cloud Platform c2-standard-8 instances. |
The nodes in a Optimizer Hub instance are as follows:
-
Compile Broker - Performs JIT compilations.
-
AWS node type:
role=opthubserver -
System Requirements: CPU 8, RAM 32GB, HDD 100GB
-
-
Cache - Stores information about the JVM that the compiler needs to perform compilations.
-
AWS node type:
role=opthubcache -
System Requirements: CPU 8, RAM 32GB, HDD 100GB
-
There is one pod per Cache node. To scale up, create more replicas.
-
-
Infrastructure - Provides supporting functionality.
-
AWS node type:
role=opthubinfra -
System Requirements: CPU 8, RAM 32GB, HDD 100GB. Make sure the disk connection is fast (use SSD) and that the storage volume is persistent between runs.
-
The pods included in this node are:
-
db
-
gateway
-
storage
-
-