Containerized: Scaling an entire database

Mon, 01 Jan 0001 00:00:00 +0000

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.

Containerized: Running KEDA ScaledObject autoscaler on OpenShift

Mon, 01 Jan 0001 00:00:00 +0000

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

OpenText Analytics Database 26.2.x – Autoscaling

Containerized: Scaling an entire database

Note

Horizontal Pod Autoscaler

ScaledObject

Note

Containerized: Running KEDA ScaledObject autoscaler on OpenShift