Storage

An ArangoDB cluster relies heavily on fast persistent storage.The ArangoDB Kubernetes Operator uses PersistentVolumeClaims to deliverthe storage to Pods that need them.

Storage configuration

In the ArangoDeployment resource, one can specify the type of storageused by groups of servers using the spec.<group>.storageClassNamesetting.

This is an example of a Cluster deployment that stores its agent & dbserverdata on PersistentVolumes that use the my-local-ssd StorageClass

  1. apiVersion: "database.arangodb.com/v1alpha"
  2. kind: "ArangoDeployment"
  3. metadata:
  4.   name: "cluster-using-local-ssh"
  5. spec:
  6.   mode: Cluster
  7.   agents:
  8.     storageClassName: my-local-ssd
  9.   dbservers:
  10.     storageClassName: my-local-ssd

The amount of storage needed is configured using thespec.<group>.resources.requests.storage setting.

Note that configuring storage is done per group of servers.It is not possible to configure storage per individualserver.

This is an example of a Cluster deployment that requests volumes of 80GBfor every dbserver, resulting in a total storage capacity of 240GB (with 3 dbservers).

  1. apiVersion: "database.arangodb.com/v1alpha"
  2. kind: "ArangoDeployment"
  3. metadata:
  4.   name: "cluster-using-local-ssh"
  5. spec:
  6.   mode: Cluster
  7.   dbservers:
  8.     resources:
  9.       requests:
  10.         storage: 80Gi

Local storage

For optimal performance, ArangoDB should be configured with locally attachedSSD storage.

The easiest way to accomplish this is to deploy anArangoLocalStorage resource.The ArangoDB Storage Operator will use it to provide PersistentVolumes for you.

This is an example of an ArangoLocalStorage resource that will result inPersistentVolumes created on any node of the Kubernetes clusterunder the directory /mnt/big-ssd-disk.

  1. apiVersion: "storage.arangodb.com/v1alpha"
  2. kind: "ArangoLocalStorage"
  3. metadata:
  4.   name: "example-arangodb-storage"
  5. spec:
  6.   storageClass:
  7.     name: my-local-ssd
  8.   localPath:
  9.   - /mnt/big-ssd-disk

Note that using local storage required VolumeScheduling to be enabled in yourKubernetes cluster. ON Kubernetes 1.10 this is enabled by default, on version1.9 you have to enable it with a —feature-gate setting.

Manually creating PersistentVolumes

The alternative is to create PersistentVolumes manually, for all servers thatneed persistent storage (single, agents & dbservers).E.g. for a Cluster with 3 agents and 5 dbservers, you must create 8 volumes.

Note that each volume must have a capacity that is equal to or higher than thecapacity needed for each server.

To select the correct node, add a required node-affinity annotation as shownin the example below.

  1. apiVersion: v1
  2. kind: PersistentVolume
  3. metadata:
  4.   name: volume-agent-1
  5.   annotations:
  6.         "volume.alpha.kubernetes.io/node-affinity": '{
  7.             "requiredDuringSchedulingIgnoredDuringExecution": {
  8.                 "nodeSelectorTerms": [
  9.                     { "matchExpressions": [
  10.                         { "key": "kubernetes.io/hostname",
  11.                           "operator": "In",
  12.                           "values": ["node-1"]
  13.                         }
  14.                     ]}
  15.                  ]}
  16.               }'
  17. spec:
  18.   capacity:
  19.     storage: 100Gi
  20.   accessModes:
  21.   - ReadWriteOnce
  22.   persistentVolumeReclaimPolicy: Delete
  23.   storageClassName: local-ssd
  24.   local:
  25.     path: /mnt/disks/ssd1

For Kubernetes 1.9 and up, you should create a StorageClass which is configuredto bind volumes on their first use as shown in the example below.This ensures that the Kubernetes scheduler takes all constraints on a Podthat into consideration before binding the volume to a claim.

  1. kind: StorageClass
  2. apiVersion: storage.k8s.io/v1
  3. metadata:
  4.   name: local-ssd
  5. provisioner: kubernetes.io/no-provisioner
  6. volumeBindingMode: WaitForFirstConsumer