PersistentVolume

Das PersistentVolume stellt den dauerhaften Speicher für die Datenbank bereit. Es ist ein clusterweites Objekt und gehört nicht zu einem Namespace.

Geplante Verwendung

Je Datenbankumgebung wird ein eigener Speicherbereich benötigt. Analog zur ETE-Installation kann dieser auf einer dedizierten iSCSI-LUN liegen. Portal, IQN, LUN, Dateisystem und Kapazität werden mit dem Clusterbetrieb abgestimmt.

Anforderungen

• ReadWriteOnce als erwarteter Zugriffsmodus,
• Filesystem als Volume-Modus,
• ausreichende Kapazität für Daten, Indizes und Wachstum,
• Retain als bevorzugte Reclaim Policy zum Schutz produktiver Daten,
• eindeutige Zuordnung zu INT oder PROD,
• dokumentierter Backup- und Restore-Weg unabhängig vom Volume.

Abgrenzung

Das PersistentVolume ersetzt kein Datenbank-Backup. Es erhält Daten über Pod-Neustarts hinweg, schützt aber nicht vor fehlerhaften Migrationen, logischen Datenfehlern oder einem Ausfall des Speichersystems.

Falls der Cluster dynamische Provisionierung über eine StorageClass bereitstellt, wird die manuelle PersistentVolume-Anlage durch dieses Verfahren ersetzt.

Erzeugung von LUN + PV

Die LUNs (je eines pro Umgebung) werden auf NAS3 unter dem Target rke02 erzeugt. Zunächst muss die erforderliche Größe ermittelt werden. Dazu prüfen wir in der PROD-Umgebung das Volume docker_bflies-classic_vol_mysql. Mit docker system df -v wird unter Local Volumes space usage eine Belegung von 1.809GB angezeigt. Die LUN sollte deshalb mindestens 2 GB groß sein. Für bflies-int verwenden wir rke02pv004 mit 3 GB.

apiVersion: v1
kind: PersistentVolume
metadata:
    name: pv-rke02-004
spec:
    capacity:
        storage: 3Gi # passend zur LUN
    volumeMode: Filesystem
    accessModes:
        - ReadWriteOnce
    persistentVolumeReclaimPolicy: Retain
    iscsi:
        targetPortal: "192.168.2.152:3260"
        iqn: "iqn.2004-04.com.qnap:ts-451plus:rke02"
        lun: 3 # entspricht rke02pv004
        fsType: ext4
        readOnly: false