Containerized environments

OpenText™ Analytics Database supports containerized environments that conform to the performance requirements for vioperf and vcpuperf.

As the database extends support and deployment in containerized environments including Kubernetes, we cannot test and certify all possible configurations. However, OpenText makes an effort to ensure the success of its customers on recent versions of supported operating systems for the x86_64 architecture.

The database tests containers running on Docker. When the underlying hardware, OS, and container are configured correctly, the database system performs well. In some circumstances, there is a minor performance difference for queries made against a cold- or partially-populated depot when accessing communal storage.

The database support contract covers database products only. If you choose to run the database on a container configuration and experience an issue that might not be caused by database products, the support team might ask you to reproduce the issue in a different environment or engage with the support resources for your containerization technology.

For guidelines on how to provision and size your Kubernetes resources for database deployments, see Recommendations for Sizing Vertica Nodes and Clusters in the Knowledge Base.

VerticaDB operator and OpenText™ Analytics Database server version support

The VerticaDB operator supports database server versions 11.0.0 and higher.

For more information about downloading images, version details, creating custom images, and the security vulnerability policy, see images.

Container orchestration version support

Communal storage support

Containerized OpenText™ Analytics Database on Kubernetes supports the following public and private cloud providers:

• Amazon Web Services S3

• S3-compatible storage, such as MinIO

• Google Cloud Storage

• Azure Blob Storage

• Hadoop File Storage

Managed Kubernetes services support

OpenText™ Analytics Database supports the following managed Kubernetes services:

• Amazon Elastic Kubernetes Service (EKS)

• Google Kubernetes Engine (GKE)

• Azure Kubernetes Service (AKS)

Multi-AZ database deployment on Amazon EKS

Running Kubernetes pods across multiple availability zones (AZs) ensures your database stays available and resilient. If one data center experiences an outage, your pods can continue running from another zone, so your services remain available. This is an important best practice for production deployments.

You can create a multi-AZ database cluster on Amazon EKS by creating nodes in a particular AZ and specifying the desired subnet while configuring your managed node group or self-managed nodes. When nodes are available, use pod affinity and anti-affinity configuration to constrain them to be scheduled on nodes in the chosen AZ.

Example 1: Subclusters in different AZs

Configure a multi-AZ database cluster with subclusters in different AZs. In this example, subcluster sc1 runs in AZ1 and sc2 runs in AZ2.

• Database cluster with 2 subclusters (sc1 and sc2)
• Each subcluster has 3 nodes
• All nodes of subcluster sc1 are in AZ1 (us-east-1d) and sc2 are in AZ2 (us-east-1f)

Prerequisites

• EKS cluster is configured and VerticaDB operator is installed.
• 6 compute nodes (3 each in AZ1 (us-east-1d) and AZ2 (us-east-1f)) are created and available for scheduling database pods.

VerticaDB Custom Resource

Create the following VerticaDB CR to enforce scheduling of pods in desired AZs:

apiVersion: vertica.com/v1
kind: VerticaDB
metadata:
  name: vertica-k8s
spec:
  communal:
    path: "s3://bucket-name/key-name"
    endpoint: "https://path/to/s3-endpoint"
    credentialSecret: k8s-creds
  licenseSecret: vertica-license
  image: opentext/vertica-k8s:version
  subclusters:
  - name: sc1
    serviceName: k8s-svc
    size: 3
    affinity:
      # to schedule the pod on nodes with subnet in desired zone (us-east-1d)
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: topology.kubernetes.io/zone
              operator: In
              values:
              - us-east-1d
      # to avoid scheduling on nodes with vertica already installed
      podAntiAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: app.kubernetes.io/name
              operator: In
              values:
              - vertica
          topologyKey: "kubernetes.io/hostname"
  - name: sc2
    size: 3
    serviceName: k8s-svc
    affinity:
      # to schedule the pod on nodes with subnet in desired zone (us-east-1f)
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: topology.kubernetes.io/zone
              operator: In
              values:
              - us-east-1f
      # to avoid scheduling on nodes with vertica already installed
      podAntiAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: app.kubernetes.io/name
              operator: In
              values:
              - vertica
          topologyKey: "kubernetes.io/hostname"

nodeSelectorTerms:
- matchExpressions:
  - key: topology.kubernetes.io/zone
    operator: In
    values:
    - us-east-1a
    - us-east-1b

Example 2: Nodes distributed across multiple AZs

Configure a multi-AZ database cluster with nodes distributed across multiple AZs. In this example, each subcluster has nodes spread across three different AZs.

• Database cluster with 2 subclusters (sc1 and sc2)
• Each subcluster has 3 nodes
• All nodes in each subcluster are spread across AZ1 (us-east-1d), AZ2 (us-east-1e), and AZ3 (us-east-1f)

Prerequisites

• EKS cluster is configured and VerticaDB operator is installed.
• 6 compute nodes (2 each in AZ1 (us-east-1d), AZ2 (us-east-1e), and AZ3 (us-east-1f)) are created and available for scheduling database pods.
• Add a label to each node to map subclusters to nodes across different availability zones. For example, use the label subcluster-group with values such as group1 and group2 as shown in the following table:

VerticaDB Custom Resource

Create the following VerticaDB CR to enforce scheduling of pods in desired AZs:

apiVersion: vertica.com/v1
kind: VerticaDB
metadata:
  name: vertica-k8s
spec:
  communal:
    path: "s3://bucket-name/key-name"
    endpoint: "https://path/to/s3-endpoint"
    credentialSecret: k8s-creds
  licenseSecret: vertica-license
  image: opentext/vertica-k8s:version
  subclusters:
  - name: sc1
    serviceName: k8s-svc
    size: 3
    affinity:
      # to deploy on nodes with label subcluster-group=group1
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: subcluster-group
              operator: In
              values:
              - group1
      # to avoid deploying on nodes with vertica already installed
      podAntiAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: app.kubernetes.io/name
              operator: In
              values:
              - vertica
          topologyKey: "kubernetes.io/hostname"
  - name: sc2
    size: 3
    serviceName: k8s-svc
    affinity:
      # to deploy on nodes with label subcluster-group=group2
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: subcluster-group
              operator: In
              values:
              - group2
      # to avoid deploying on nodes with vertica already installed
      podAntiAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: app.kubernetes.io/name
              operator: In
              values:
              - vertica
          topologyKey: "kubernetes.io/hostname"

Cluster management platform support

OpenText™ Analytics Database supports the VerticaDB operator and database in Kubernetes environment on Red Hat OpenShift versions 4.8 and higher.