Update resources

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.