Autoscaling

Autoscaling is designed to respond to the short-to-medium term trends in resource usage on your IBM Cloud® Databases for Elasticsearch deployment. When enabled, your deployment is checked at the interval you specify. If it is running short on resources, more resources are added to the deployment. To keep an eye on your resources, use the IBM Cloud® Monitoring integration, which provides metrics for memory, disk space, and disk I/O utilization.

You can set your deployment to autoscale disk, RAM, or both.

General Autoscaling parameters:

When to scale, based on usage over time.
By how much to scale, as a percentage of the resources per member.
How often to scale, measured either in seconds, minutes, or hours.
A hard limit on scaling, your deployment stops scaling at the limit.

Memory - Memory autoscaling is based on Disk I/O utilization to provide more memory for disk caching as your read/write load increases. The benefit is that additional memory might alleviate pressure on disk I/O by supporting more caching. Autoscaling configurations based on memory usage are currently not available.

Disk - Disk autoscaling can scale when either disk usage reaches a certain threshold, Disk I/O utilization reach a certain threshold, or both. (The "or" in the UI operates as an inclusive or, |, v.) The amount of IOPS available to your deployment increases with disk size at a ratio of 10 IOPS for each GB.

CPU and RAM autoscaling is not supported on Isolated Compute. Disk autoscaling is available. If you provisioned an isolated instance or switched over from a deployment with autoscaling, monitor your resources using IBM Cloud® Monitoring integration, which provides metrics for memory, disk space, and disk I/O utilization. To add resources to your instance, manually scale your deployment.

The resource numbers refer to each database node in a deployment. For example, there are three members in an Elasticsearch cluster and if the deployment is scaled with 10 GB of disk and 1 GB of RAM, that means each member gets 10 GB of disk and 1 GB of RAM. The total resources added to your deployment is 30 GB of disk and 3 GB of RAM.

Autoscaling considerations

Scaling your deployment up might cause your Elasticsearch to restart. If your scaled deployment needs to be moved to a host with more capacity, then the databases are restarted as part of the move.
Disk cannot be scaled down.
A few scaling operations can be more long running than others. Drastically increasing RAM or Disk can take longer than smaller increases to account for provisioning more underlying hardware resources.
Autoscaling operations are logged in IBM Cloud® Activity Tracker Event Routing.
Limits:
- Can't set anything to scale in an interval less than 60 seconds.
- Maximum Disk = 4 TB per member.
- Maximum RAM = 112 GB per member.
Autoscaling does not scale down deployments where disk or memory usage has shrunk. The RAM provisioned to your deployment remains for your future needs, or until you scale down your deployment manually. The disk provisioned to your deployment remains because disk cannot be scaled down.
If you need to add resources to your deployment occasionally or rarely, you can manually scale your deployment.
Elasticsearch is designed to balance work load across a cluster and can benefit from being horizontally scaled. If you are concerned about performance, check out Adding Elasticsearch Nodes.

Configuring Autoscaling in the CLI

You can get the autoscaling parameters for your deployment through the CLI by using the cdb deployment-autoscaling command.

ibmcloud cdb deployment-autoscaling <deployment name or CRN> member

To enable and set autoscaling parameters through the CLI, use a JSON object or file with the cdb deployment-autoscaling-set command.

ibmcloud cdb deployment-autoscaling-set <deployment name or CRN> member '{"autoscaling": { "memory": {"scalers": {"io_utilization": {"enabled": true, "over_period": "5m","above_percent": 90}},"rate": {"increase_percent": 10.0, "period_seconds": 300,"limit_mb_per_member": 125952,"units": "mb"}}}}'

Configuring Autoscaling in the API

You can get the autoscaling parameters for your deployment through the API by sending a GET request to the /deployments/{id}/groups/{group_id}/autoscaling endpoint.

curl -X GET -H "Authorization: Bearer $APIKEY" 'https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/groups/member/autoscaling'

To enable and set the autoscaling parameters for your deployment through the API, send a POST request to the endpoint. Enabling autoscaling works by setting the scalers (io_utilization or capacity) to true.

curl -X PATCH https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/groups/member/autoscaling -H 'Authorization: Bearer <>'
-H 'Content-Type: application/json'
-d '{"autoscaling": {
      "memory": {
        "scalers": {
          "io_utilization": {
            "enabled": true,
            "over_period": "5m",
            "above_percent": 90}
          },
          "limits": {
            "scale_increase_percent": 10.0,
            "scale_period_seconds": 30,
            "scale_maximum_mb": 125952,
            "units": "mb"
          }
      }
    }'

To disable autoscaling, send the PATCH request with the currently enabled scalers set to false. If all of them are set to false, then autoscaling is disabled on your deployment.