Percona is highly scalable and requires underlying persistent storage to be equally scalable and performing. OpenEBS provides scalable storage for Percona for providing a simple and scalable RDS like solution for both On-Premise and cloud environments.
Advantages of using OpenEBS for Percona database:
- Storage is highly available. Data is replicated on to three different nodes, even across zones. Node upgrades, node failures will not result in unavailability of persistent data.
- For each database instance of Percona, a dedicated OpenEBS workload is allocated so that granular storage policies can be applied. OpenEBS storage controller can be tuned with resources such as memory, CPU and number/type of disks for optimal performance.
- Take backup of the Prometheus metrics periodically and back them up to S3 or any object storage so that restoration of the same metrics is possible to the same or any other Kubernetes cluster
As shown above, OpenEBS volumes need to be configured with three replicas for high availability. This configuration works fine when the nodes (hence the cStor pool) is deployed across Kubernetes zones.
If OpenEBS is not installed in your K8s cluster, this can done from here. If OpenEBS is already installed, go to the next step.
Connect to Director Online (Optional) : Connecting the Kubernetes cluster to Director Online provides good visibility of storage resources. Director Online has various support options for enterprise customers.
Configure cStor Pool
If cStor Pool is not configured in your OpenEBS cluster, this can be done from here. If cStor pool is already configured, go to the next step. Sample YAML named openebs-config.yaml for configuring cStor Pool is provided in the Configuration details below.
Create Storage Class
You must configure a StorageClass to provision cStor volume on cStor pool. StorageClass is the interface through which most of the OpenEBS storage policies are defined. In this solution we using a StorageClass to consume the cStor Pool which is created using external disks attached on the Nodes. Since Percona-MySQL is a deployment, it requires high availability of data at Storage level. So cStor volume
replicaCountis 3. Sample YAML named openebs-sc-disk.yamlto consume cStor pool with cStoveVolume Replica count as 3 is provided in the configuration details below.
Launch and test Percona:
Create a file called
percona-openebs-deployment.yamland add content from
percona-openebs-deployment.yamlgiven in the configuration details section. Run
kubectl apply -f percona-openebs-deployment.yamlto deploy Percona application. For more information, see Percona documentation. In other way, you can use stable Percona image with helm to deploy Percona in your cluster using the following command.
helm install --name my-release --set persistence.enabled=true,persistence.storageClass=openebs-cstor-disk stable/percona
Reference at openebs.ci
Sample YAML for running Percona-mysql using cStor are here
Post deployment Operations
Monitor OpenEBS Volume size
It is not seamless to increase the cStor volume size (refer to the roadmap item). Hence, it is recommended that sufficient size is allocated during the initial configuration. However, an alert can be setup for volume size threshold using Director Online.
Monitor cStor Pool size
As in most cases, cStor pool may not be dedicated to just Percona database alone. It is recommended to watch the pool capacity and add more disks to the pool before it hits 80% threshold. See cStorPool metrics.
Maintain volume replica quorum during node upgrades
cStor volume replicas need to be in quorum when applications are deployed as
deployment and cStor volume is configured to have
3 replicas. Node reboots may be common during Kubernetes upgrade. Maintain volume replica quorum in such instances. See here for more details.
#Use the following YAMLs to create a cStor Storage Pool. # and associated storage class. apiVersion: openebs.io/v1alpha1 kind: StoragePoolClaim metadata: name: cstor-disk spec: name: cstor-disk type: disk poolSpec: poolType: striped # NOTE - Appropriate disks need to be fetched using `kubectl get disks` # # `Disk` is a custom resource supported by OpenEBS with `node-disk-manager` # as the disk operator # Replace the following with actual disk CRs from your cluster `kubectl get disks` # Uncomment the below lines after updating the actual disk names. disks: diskList: # Replace the following with actual disk CRs from your cluster from `kubectl get disks` # - disk-184d99015253054c48c4aa3f17d137b1 # - disk-2f6bced7ba9b2be230ca5138fd0b07f1 # - disk-806d3e77dd2e38f188fdaf9c46020bdc # - disk-8b6fb58d0c4e0ff3ed74a5183556424d # - disk-bad1863742ce905e67978d082a721d61 # - disk-d172a48ad8b0fb536b9984609b7ee653
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: openebs-cstor-disk annotations: openebs.io/cas-type: cstor cas.openebs.io/config: | - name: StoragePoolClaim value: "cstor-disk" - name: ReplicaCount value: "3" provisioner: openebs.io/provisioner-iscsi reclaimPolicy: Delete
apiVersion: v1 kind: Pod metadata: name: percona labels: name: percona spec: securityContext: fsGroup: 999 containers: - resources: limits: cpu: 0.5 name: percona image: percona args: - "--ignore-db-dir" - "lost+found" env: - name: MYSQL_ROOT_PASSWORD value: k8sDem0 ports: - containerPort: 3306 name: percona volumeMounts: - mountPath: /var/lib/mysql name: demo-vol1 volumes: - name: demo-vol1 persistentVolumeClaim: claimName: demo-vol1-claim kind: PersistentVolumeClaim apiVersion: v1 metadata: name: demo-vol1-claim spec: storageClassName: openebs-cstor-disk accessModes: - ReadWriteOnce resources: requests: storage: 30G