Autoscaling

1: Scaling an entire database
2: Running KEDA ScaledObject autoscaler on OpenShift

The VerticaAutoscaler provides flexible scaling options, allowing you to scale specific subclusters or the entire database. You can scale a specific subcluster or a subset of subclusters by specifying a service name, or scale the entire database by leaving the service name empty, which scales across all nodes. This section explains two ways to scale the database. You can use the Horizontal Pod Autoscaler (HPA), which is a core Kubernetes feature that scales based on CPU and memory usage (it can also use custom metrics like Prometheus, but this often requires additional configuration), or KEDA’s ScaledObject for Prometheus-based scaling, which scales based on Prometheus metrics. For OpenShift, using KEDA’s ScaledObject is recommended due to HPA limitations in OpenShift. The following sections detail how to configure and deploy both autoscalers to scale an entire database, setup instructions for OpenShift environments, use cases, and best practices.

1 - Scaling an entire database

The autoscaler allows you to scale specific subclusters by providing a service name. If you need to scale the entire database and make scaling decisions based on all nodes, leave spec.serviceName empty.

Note

This is only supported when scalingGranularity is Subcluster.

In the following sections, we will reference the following VerticaDB:

apiVersion: vertica.com/v1
kind: VerticaDB
metadata:
  name: v-test
spec:
  communal:
    path: "path/to/communal-storage"
    endpoint: "path/to/communal-endpoint"
    credentialSecret: credentials-secret
  licenseSecret: license
  subclusters:
    - name: pri1
      size: 3
      type: primary
      serviceName: primary1
      resources:
        limits:
          cpu: "8"
        requests:
          cpu: "4"
    - name: sec1
      size: 3
      type: secondary
      serviceName: secondary1
      resources:
        limits:
          cpu: "8"
        requests:
          cpu: "4"

Horizontal Pod Autoscaler

apiVersion: vertica.com/v1beta1
kind: VerticaAutoscaler
metadata:
  name: v-scale
  verticaDBName: v-test
  scalingGranularity: Subcluster
  template:
    name: as
    size: 3
    serviceName: newsvc
    type: secondary 
  customAutoscaler:
    type: HPA
    hpa:
      minReplicas: 3
      maxReplicas: 12
      metrics:
        - metric:
            type: Pods
            pods:
              metric:
                name: vertica_sessions_running_total
              target:
                type: AverageValue
                averageValue: 50

spec.template serves as a blueprint for new subclusters added when scaling out.

Currently, the database consists of six nodes distributed across two subclusters and all of them will be used for calculating the metric value. If scaling is needed and target size - current size exceeds template.size, new subclusters will be added, each with its own dedicated service.

ScaledObject

apiVersion: vertica.com/v1
kind: VerticaAutoscaler
metadata:
  name: v-scale
spec:
  verticaDBName: v-test
  serviceName: primary1
  scalingGranularity: Subcluster
  customAutoscaler:
    type: ScaledObject
    scaledObject:
      minReplicas: 3
      maxReplicas: 12
      metrics:
      - name: vertica_sessions_running_total
        metricType: AverageValue
        prometheus:
          serverAddress: "http://prometheus-kube-prometheus-prometheus.prometheus.svc.cluster.local:9090"
          query: sum(vertica_sessions_running_counter{type="active", initiator="user", pod=~"v-test-.*"})
          threshold: 50

Note

pod=~"v-test-.*" selects all pods belonging to the database, as all pods share the vdb name as a prefix. This is particularly useful when there are multiple VerticaDBs in the same namespace and you do not want to scale one by mistake. If there is only one vdb in a namespace, you can omit it.

2 - Running KEDA ScaledObject autoscaler on OpenShift

The VerticaAutoscaler custom resource (CR) supports two types of autoscaler, Horizontal Pod Autoscaler (HPA) and ScaledObject. In OpenShift, HPA has limited support for scaling based on Prometheus metrics as it relies on the Prometheus adapter, which is challenging to install. For OpenShift environments, ScaledObject is the recommended autoscaler.

To set up VerticaAutoscaler with ScaledObject in Openshift:

On OperatorHub Marketplace locate and install Custom Metrics Autoscaler. This installs all the required custom resources.

Navigate to Installed Operators, and select Custom Metrics Autoscaler. From the list of APIs, select KedaController and create an instance. You can keep the default values and ensure that watchNamespace is empty.

Select YAML view to view the yaml file:

kind: KedaController
apiversion: keda.sh/v1alpha1
metadata:
  name: keda
  namespace: opensfhits-keda
spec:
  admissionWebhooks:
    logEncoder: console
    logLevel: info
  metricsServer:
    logLevel: '0'
  operator:
    logEncoder: console
    logLevel: info
 serviceAccount: null
 watchNamespace: ''

Next, deploy the VerticaAutoscaler CR with ScaledObject. For example:

apiVersion: vertica.com/v1
kind: VerticaAutoscaler
metadata:
  name: v-scale
spec:
  verticaDBName: v-test
  serviceName: primary1
  scalingGranularity: Pod
  customAutoscaler:
    type: ScaledObject
    scaledObject:
      minReplicas: 3
      maxReplicas: 12
      metrics:
      - name: vertica_sessions_running_total
        metricType: AverageValue
        prometheus:
          serverAddress: "http://prometheus-kube-prometheus-prometheus.prometheus.svc.cluster.local:9090"
          query: sum(vertica_sessions_running_counter{type="active", initiator="user", service="v-test-primary1"})
          threshold: 50