Define wether the database node is installed.
Is set to false in ReadyNow Orchestrator only mode, using values-disable-compiler.yaml
Optional Database Pod Configuration
For versions older than 1.10, Code Cache uses a relational database pod to cache information. In 1.10, the default and recommended store for Code Cache is blob storage.
|
Note
|
Using a database is no longer recommended. We advise to use scalable blob storage provided by your cloud system, without persistent volumes. See Installing Optimizer Hub on Kubernetes > Configure the blob storage. |
If you still need to use the database pod to store Code Cache information, follow the instructions below.
Enabling the Database
codeCache:
storageType: sqldb
cleaner:
enabled: true
targetSize: 0
interval: PT1M
storage:
offloadReadOperations: false
writeBehindStorageMethod: true
db:
enabled: true
schemaRecreateRegularCheck: true
nodeSelector:
role: opthubinfra
Configuring the Database
| Option | Description | Default |
|---|---|---|
db.enabled |
true |
|
dbschema.auto-recreate.enabled |
If enabled, automatically recovers from database pod restarts with loss of schema. If you have a database and this database is not using a persistence volume, this setting must be set to true, otherwise you need a manual interaction if the pod is restored. |
false |
Setting Up Persistent Storage
By default, Optimizer Hub pods allocate data directories on the root disk or in an emptyDir volume, both residing in the pod’s ephemeral storage. If the pod dies, all data is lost and has to be regenerated after restart.
You can move the pods' data directories to persistent volumes, so the data survives pod crashes, restarts and even scale down/up events. Furthermore, this allows you to lower the local storage sizing of target Kubernetes worker nodes, since large data directories are stored in separate volumes outside of these worker nodes.
When you use persistent volumes, you create 2 additional Kubernetes objects per pod:
-
persistentVolumeClaim(PVC), whose name is derived from parent pod -
persistentVolume(PV), which is allocated automatically by chosen the storage class and has an auto-generated name.
PV and PVC objects lifecycles are separate from other Optimizer Hub Kubernetes objects. When you uninstall Optimizer Hub using the helm chart, these objects remain in cluster for as long as the installation namespace exists. Removal of namespace or manual deletion of PVCs within the namespace automatically removes their associated PVs from the Kubernetes cluster as well.
You can configure persistent volumes for the db and builtinStorage components. The configuration is the same for both components. Your target Kubernetes cluster needs to have at least one storage class configured. By default, Optimizer Hub uses the default configured storage class.
|
Note
|
If you are using AWS EBS Storage for your persistent storage, use gp3 volumes instead of gp2 volumes. gp2 volumes have limited IOPS which can affect Optimizer Hub performance. Additional configuration info for AWS S3 Storage is available here. |
|
Note
|
If you are using Azure Blob Storage, please check "Installing Optimizer Hub on Azure" for additional settings. |
Configuration with Custom Resources Values
Example pod sizing with 10GiB for root volume and 100GiB for data volume:
db:
resources:
requests:
cpu: "5"
memory: "20Gi"
ephemeral-storage: "10Gi"
limits:
cpu: "5"
memory: "20Gi"
ephemeral-storage: "10Gi"
persistentDataVolume:
enabled: true
size: "100Gi"
If you want to use recommended sizing of pods, you still need to explicitly override the default size of the ephemeral storage. This is in order to not waste resources and increase pod schedulability on smaller sized nodes.
db:
resources:
requests:
ephemeral-storage: "10Gi"
limits:
ephemeral-storage: "10Gi"
persistentDataVolume:
enabled: true
size: "100Gi"