Replikation auf Anwendungsebene
Beobachtung
Einige Anwendungen replizieren ihre Daten bereits selbst. Dazu gehören insbesondere CloudNativePG und Garage. Werden deren Persistent Volumes zusätzlich über DRBD repliziert, werden dieselben Daten sowohl auf Anwendungs- als auch auf Blockebene vervielfältigt.
Anwendungsreplikation
|
v
Mehrere Anwendungsinstanzen
|
v
Mehrere Persistent Volumes
|
v
Zusätzliche DRBD-Replikation
|
v
Weitere physische Datenkopien
Erkenntnis
Mehrfache Replikation erhöht den Speicherverbrauch, die Schreiblast und den Netzwerkverkehr. Außerdem entstehen zusätzliche Abhängigkeiten zwischen der von der Anwendung verwalteten Replikation und der darunterliegenden Blockreplikation.
Ein repliziertes Volume verbessert die Verfügbarkeit nicht automatisch, wenn die Anwendung bereits mehrere eigenständige Datenkopien verwaltet. Entscheidend ist, ob die zusätzliche Blockreplikation ein konkretes Ausfallszenario absichert, das durch die Anwendungsreplikation nicht bereits abgedeckt ist.
Konsequenz
Anwendungen mit eigener Replikation verwenden bevorzugt die StorageClass linstor-local. Diese stellt lokalen LINSTOR-Storage ohne DRBD-Layer bereit.
Typische Kandidaten sind:
-
CloudNativePG
-
Garage
-
Verteilte Cache- oder Datenbankdienste
-
Anwendungen mit eigener Replikations- und Wiederherstellungslogik
DRBD-basierte StorageClasses werden gezielt für Anwendungen eingesetzt, die keine eigene Datenreplikation bereitstellen und bei denen ein Node-Ausfall ansonsten zum Verlust der Verfügbarkeit führen würde.
Die Wahl der StorageClass erfolgt anhand der Anwendungseigenschaften:
Anwendung repliziert selbst
-> linstor-local
-> linstor-local-nvme bei erhöhtem IO-Bedarf
Anwendung repliziert nicht selbst
-> linstor-r02
-> linstor-r03 für besonders kritische Daten
-> jeweilige NVMe-Variante bei erhöhtem IO-Bedarf
Die Replikation wird damit nicht pauschal auf alle Persistent Volumes angewendet, sondern gezielt nach Verfügbarkeitsanforderung und Betriebsmodell ausgewählt.