Creating Persistent Volume(s) (PVs) and Persistent Volume Claim(s) (PVCs) for Domino Containers

Mindwatering Incorporated

Author: Tripp W Black

Created: 07/14 at 02:43 PM

 

Category:
Domino Installs, RH OpenShift
Software Installation
Storage

Task:


Create persistent storage for HCL Domino container.
If setting up dynamic (on demand) PV creation with NFS; there is a separate version of this document.

Step 1: Create the storage PV(s):
If the production server has low utilization, create one PersistentVolume /local.
If the production server has high utilization, create multiple PersistentVolumes:
/local/notesdata
/local/translog
/local/NIF
/local/FT
/local/DAOS

Storage Types Notes:
- Use local storage, NFS, or iSCSI, and others. NFS and GlusterFS are two very popular implementations with K8s variants.
- NFS (notesdata), NIF, and FT require fast storage of random (often 4k) I/O operations
- Translog requires low latency small 4k write operations continuously
- DAOS is written in 32K sequential read/write operations, read many times, and written once/few
- For smaller Domino installations, one PV (/local) with a back-end 15k speed SAS disk is sufficient, and with a 1 GB network connection (if not shared w/many Pods) or a 10 GB network connection shared for 1 to 3 hosts.

PV Sizing:
For a smaller server that services a smaller community, one /local PVC and PV is sufficient.
For a larger/busier server, create multiple PVCs each for each function. (e.g. /local/notesdata, local/NIF, local/FT, local/DAOS ...). Each PV will be the types delivering the performance needs above.

PVC/PV ReadWriteOnce Considerations:
- The creation of each PersistentVolumeClaim (PVC) requires a PersistentVolume (PV) to already exist of that storage type (speed and size, for example), Domino is NOT a micro server - it uses ReadWriteOnce PVCs.
- A ReadWriteOnce PVC can only bind to a ReadWriteOnce PV, in that Domino's RWO PVC cannot share a PV that has RWM PVCs. OKD and OCP4 do not allow it.
- Once the first PVC binds to a PV, the PV is bound/taken until that PVC (e.g. Domino server/app) is destroyed and the storage reclaimed.
- If there are separate binding locations (e.g. /local/notesdata, local/NIF, and local/FT, they will each be a PVC, each needing each a PV.
- To keep the mapping of PVCs to their "parent" PVs, use a strick naming convention. e.g. mwdom01-local-path-pvc and mwdom01-local-path-pv

PVC Creation Notes:
- To map to the PV, update the PVC to use the same storageClassName to its "parent" PV. Size the PV the a little larger than the PVC being created. The PV and PVC are 1 to 1, not 1 PV to many PVCs, as Domino's use of ReadWriteOnce exclusivity binds one pod/container to one back-end PV.
- If using the HCL ConfigMap and auto-config deployment K8s scripts, the number of PVCs for each domino server will be 1 or 5.


Step 2: Create the Domino PVC:
Note:
- Update the namespace, the name, and the storageClassName. The storageClassName is the glue that maps which PVC is applied to which PV(s).

$ vi ~/mwdom01-pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mwdom01-local-path-pvc
  namespace: mwdom
spec:
  storageClassName: mwdom01-local-sc
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 24Gi


- Login, and create the PVC:
$ oc login -u mwadminid <host>
<enter password>

$ oc apply -f mwdom01-pvc.yaml
<confirmed created successfully>

Note:
- Confirm the PVC moves from pending and finds a suitable PV.


previous page

×