After the cluster is created and running, we may need to adjust the resource configuration of the OBServer node, such as CPU, memory, and storage volumes. This article introduces the resource configuration that can be modified and the specific operations.
Scale up: Modify CPU and memory resources
Note
Only cluster of the `standalone` or `service` mode supports this operation.
Assuming that we have created a single-node standalone cluster with a resource specification of 2C+10G. The configuration in YAML format is as follows:
observer:
# ...
resource:
cpu: 2
memory: 10Gi
# ...
If you find that the resources are insufficient after running for a period of time and need to be expanded, you can directly modify this part of the configuration. For example, in the following YAML fragment, we have expanded the resource specification of the OBServer to 4C+16G.
observer:
# ...
resource:
cpu: 4
memory: 16Gi
# ...
Upon modifying the YAML, apply it to the Kubernetes cluster. ob-operator will then perform the cluster's scale-up expansion. Once the OBCluster transitions back to a running state, the expansion is complete.
kubectl apply -f obcluster.yaml
kubectl get obcluster -w
NAME STATUS AGE
test scale up obzone xxx
test scale up obzone xxx
...
test running xxx
Dynamically expand PVC
Note
This operation requires that the storage class used by the cluster supports the `AllowVolumeExpansion` feature.
Assuming that we have deployed an OBCluster, the storage configuration is shown in the following YAML fragment:
observer:
# ...
storage:
dataStorage:
storageClass: my-storage
size: 50Gi
redoLogStorage:
storageClass: my-storage
size: 50Gi
logStorage:
storageClass: my-storage
size: 20Gi
# ...
To expand the mounted volume, increase the size value in the YAML fragment and apply the changes via kubectl. ob-operator will handle the PVC expansion. Note that size can only be increased.
After modification, the configuration is as follows:
observer:
# ...
storage:
dataStorage:
storageClass: my-storage
size: 60Gi
redoLogStorage:
storageClass: my-storage
size: 60Gi
logStorage:
storageClass: my-storage
size: 30Gi
# ...
kubectl apply -f obcluster.yaml
kubectl get obcluster -w
NAME STATUS AGE
test expand pvc xxx
test expand pvc xxx
...
test running xxx
Modify the storage class for running cluster
If you need to change the storage class of the running cluster, you can modify the storage class in the OBCluster YAML configuration and apply the changes via kubectl. ob-operator will handle the migration one server by one server.
Assuming that we have deployed an OBCluster, the storage configuration is shown in the following YAML fragment:
observer:
# ...
storage:
dataStorage:
storageClass: my-storage
size: 60Gi
redoLogStorage:
storageClass: my-storage
size: 60Gi
logStorage:
storageClass: my-storage
size: 30Gi
# ...
To change the storage class, modify the storageClass value in the YAML fragment and apply the changes via kubectl. What value should be modified to depends on the actual situation. In the following example, we change the storage class to new-storage.
After modification, the configuration is as follows:
observer:
# ...
storage:
dataStorage:
storageClass: new-storage
size: 60Gi
redoLogStorage:
storageClass: new-storage
size: 60Gi
logStorage:
storageClass: new-storage
size: 30Gi
# ...
In order to ensure the stability of the cluster, ob-operator will roll out the migration one server by one server. Only after a server is successfully migrated will the next server be migrated. The migration process will not affect the cluster's overall availability, but it may affect the cluster's performance. Therefore, it is recommended to perform this operation during off-peak hours.