Replikationstechnologien
Es gibt mehrere Technologien zur Replikation von Dateisysteminhalten: Replikationstechnologien auf Speicherebene, Betriebssystemtools und andere produktspezifische Funktionen.
Die folgenden Technologien, die in OCI für die Dateisystemreplikation der Mid-Tier verfügbar sind, werden behandelt: OCI Block Volumes-Replikat und das OCI File Storage-Replikat (als Replikate auf Speicherebene), rsync (als Betriebssystemtool) und Database File System (DBFS), das ein datenbankspezifisches Feature von Oracle ist.
Die RTO- und RPO-Werte sind für jede Technologie unterschiedlich. Das RTO wird durch die Zeit bestimmt, die benötigt wird, um den Speicher zu aktivieren und für die Anwendungen zugänglich zu machen. Das RPO wird durch die Häufigkeit der Replikation bestimmt, die von jeder Technologie zugelassen wird.
OCI Block Volumes Replication
Wenn Sie die Replikation für ein Volume oder eine Volume-Gruppe aktivieren, beinhaltet der Prozess eine anfängliche Synchronisierung der Daten aus der Quelle mit dem Replikat. Nach Abschluss des ersten Synchronisierungsprozesses ist der Replikationsprozess kontinuierlich, wobei die typische Recovery Point Object-(RPO-)Zielrate für die regionsübergreifende Replikation weniger als 30 Minuten beträgt (das RPO kann jedoch je nach Änderungsrate der Daten auf dem Quell-Volume variieren).
Die Artefakte des Block-Volume-Replikats können nicht direkt gemountet werden. Um ein repliziertes Block-Volume zu mounten, müssen Sie die Aktivierung auf dem Replikat ausführen (oder das Volume-Gruppenreplikat, wenn es innerhalb einer Gruppe repliziert wird). Beim Aktivierungsprozess wird ein neues Volume durch Klonen des Replikats erstellt, das Sie als reguläres Block-Volume mounten können. Das RTO dieser Technologie steht in direktem Zusammenhang mit der Zeit, die für die Ausführung dieses Vorgangs erforderlich ist (in der Regel 5-10 Minuten, kann je nach Anzahl der Knoten variieren und wenn Sie die Aktionen parallel ausführen). In Failover-Situationen können diese Schritte zusätzlichen Betriebsaufwand verursachen und den gesamten RTO erhöhen. Bei einem geplanten Switchover können Sie diese Vorgänge jedoch ausführen, bevor Sie das primäre System stoppen, sodass keine Ausfallzeiten auftreten oder das gesamte RTO erhöht wird.
Für diese Replikation ist keine spezifische Konnektivität zwischen Quelle und Ziel erforderlich. Sie müssen jedoch in den Zuordnungen der Quell- und Zielregion für die Block-Volume-Replikation aufgeführt werden.
Hinweis:
OCI Block Volumes werden normalerweise privat verwendet: Jede Compute-Instanz hat Lese-/Schreibzugriff auf ihren eigenen Block-Volumes. Obwohl Sie ein Volume an mehrere Compute-Instanzen gleichzeitig anhängen können, ist eine zusätzliche clusterfähige Lösung erforderlich, um Datenbeschädigung durch unkontrollierte Lese-/Schreibvorgänge mit mehreren Instanz-Volume-Anhängen zu verhindern. Wenn also eine Anwendung Dateien zwischen Knoten gemeinsam verwenden muss, verwendet sie stattdessen ein OCI File Storage-Dateisystem, bei dem es sich um ein Netzwerkdateisystem handelt.
OCI File Storage-Replikation
Wenn Sie die Replikation für ein OCI File Storage-Dateisystem aktivieren, wählen Sie ein Zieldateisystem aus, und definieren Sie, wie oft die Daten repliziert werden. Die Replikationsfunktion erstellt einen speziellen Replikations-Snapshot im Quelldateisystem. Anschließend wird der Snapshot an das Ziel übertragen, das die neuen Daten in das Zieldateisystem schreibt. Der letzte abgeschlossene Replikations-Snapshot verblebt bis zum nächsten Intervall sowohl im Quell- als auch in Zieldateisystem. Im nächsten Intervall löscht der Replikationsprozess automatisch die alten Replikations-Snapshots und erstellt einen neuen. Der Replikationsprozess wird im angegebenen Intervall fortgesetzt, solange die Replikation gültig ist. Das minimale Replikationsintervall beträgt 15 Minuten, wodurch das minimale RPO für diese Technologie definiert wird.
Das Zieldateisystem ist ein Dateisystem, das noch nie exportiert wurde. Daher wird es als "zielfähig" markiert. Während die Replikation aktiviert ist, ist das Zieldateisystem schreibgeschützt und wird nur durch Replikation aktualisiert. Um ein repliziertes Dateisystem zu exportieren und einzuhängen, müssen Sie es klonen.
Anschließend können Sie das geklonte Dateisystem exportieren und mounten. Das RTO dieser Technologie steht in direktem Zusammenhang mit der Zeit, die für die Ausführung dieses Vorgangs erforderlich ist (normalerweise weniger als 5 Minuten zum Klonen, Exportieren und Mounten eines Dateisystems, kann jedoch je nach Anzahl der Knoten variieren und wenn Sie die Aktionen parallel ausführen). In Failover-Situationen können diese Schritte zusätzlichen Betriebsaufwand verursachen und den gesamten RTO erhöhen. Bei einem geplanten Switchover können Sie diese Vorgänge jedoch ausführen, bevor Sie das primäre System stoppen, sodass keine Ausfallzeiten auftreten oder das gesamte RTO erhöht wird.
Für diese Replikation ist keine spezifische Konnektivität zwischen primären und sekundären Sites erforderlich. Sie müssen sich jedoch in der Liste der empfohlenen Zielregionen für die OCI File Storage-(OCI FS-)Replikation befinden.
Informationen zum Remote Sync-Dienstprogramm (rsync)
Mit dem Utility rsync können Sie Dateien zwischen einem Host und einem Speicherlaufwerk sowie zwischen Hosts übertragen und synchronisieren, indem Sie die Änderungszeiten und die Dateigrößen vergleichen. Bei Verwendung mit SSH können Sie Dateien und Verzeichnisse zwischen zwei verschiedenen Systemen mit minimaler Netzwerkauslastung synchronisieren.
Um diese Technologie zu verwenden, sind Sie für das Erstellen und Ausführen der rsync-Skripte verantwortlich. Die Skripte müssen die entsprechenden rsync-Befehle verwenden, um die Mid-Tier-Ordner zu replizieren, z.B. die Konfigurations- oder Produktordner. Der RPO für diese Technologie hängt von der Häufigkeit der rsync-Replikatskripte ab.
Wenn Sie rsync als Replikationstechnologie verwenden, wird der Speicher bereits sowohl in der Primär- als auch in der Sekundärspeicher gemountet. Daher ist beim Switchover keine Zeit erforderlich, um den Speicher in der Sekundärspeicher zu mounten. Durch diese Technologie wird das RTO des Systems bei Switchovers oder Failover nicht erhöht.
Der Befehl rsync bietet nützliche Optionen zum Ausführen eines guten Kopiervorgangs. Beispiel: Die Option --exclude überspringt bestimmte Dateien und Ordner aus der Kopie. Mit dem Flag --delete können Sie eine genaue Kopie beibehalten, indem Sie die Dateien, die nicht mehr in der Quelle vorhanden sind, im Ziel löschen. Das Flag --checksum erzwingt einen vollständigen Prüfsummenvergleich für jede Datei auf beiden Systemen. Da rsync ein Betriebssystembefehl ist, können Sie Dateien und Ordner unabhängig davon kopieren, ob sie sich in einem Block-Volume, einem NFS-Mount befinden oder ob der zugrunde liegende Speicher zwischen Primär- und Standbyspeicher unterschiedlich ist.
Diese Technologie erfordert eine Netzwerkkonnektivität zwischen der primären und der sekundären Region, insbesondere zwischen dem Host, auf dem rsync-Befehle ausgeführt werden, und den Remotehosts, mit denen die Verbindung hergestellt wird. OCI hat sich im Laufe der Jahre weiterentwickelt und bietet direkte Kommunikation zwischen Regionen mit Remote-Peering und dynamischen Routinggateways. Dies ermöglicht die Kommunikation mit privaten IP-Adressen, ohne den Datenverkehr über das Internet oder über Ihr On-Premise-Netzwerk zu leiten. Dadurch ist die rsync-Lösung zuverlässig und sicher genug, um regionsübergreifend als gültiger Replikationsansatz verwendet zu werden.
Die rsync-Technologie ermöglicht Flexibilität bei der Implementierung, da der Benutzer für die Erstellung der rsync-Skripte verantwortlich ist. Sie können zwischen verschiedenen Ansätzen wählen:
- Peer-to-Peer
In diesem Modell erfolgt die Kopie direkt von jedem Host zu seinem Remote-Peer. Jeder Knoten verfügt über SSH-Konnektivität zu seinem Peer und verwendet
rsync-Befehle über SSH, um das Primärsystem zu replizieren. Dies ist einfach einzurichten und benötigt keine zusätzliche Hardware. Es ist jedoch eine Wartung auf vielen Knoten erforderlich, da Skripte nicht zentralisiert sind. Das heißt, große Cluster erhöhen die Komplexität der Lösung.
- Zentrale Staging Area
In diesem Modell fungiert ein Knoten als Koordinator. Es stellt eine Verbindung zu jedem Host her, der repliziert werden muss, und kopiert den Inhalt in eine gemeinsame Staging Area. Dieser Knoten koordiniert auch die Kopie von der Staging Area zu den Zielhosts. Bei diesem Ansatz werden die einzelnen Knoten aus dem Overhead der Kopien ausgelagert.
Datenbankdateisystem
dbfs_client als reguläres NFS-Dateisystem mounten.
Hinweis:
Das DBFS-Feature ist nicht verfügbar, wenn die Datenbank eine Oracle Autonomous Database ist.
Wenn Oracle Data Guard für die Datenbank konfiguriert ist, werden die DBFS-Inhalte in der Primärdatenbank automatisch in der Standbydatenbank repliziert. Alle Ordner oder Dateien, die Sie im DBFS-Ordner speichern, sind auf der sekundären Site verfügbar. Die sekundären Hosts können sie mounten, wenn die Datenbank im schreibgeschützten Modus geöffnet ist oder in den Snapshot-Standbymodus konvertiert wird.
Oracle empfiehlt jedoch nicht, die Mid-Tier-Artefakte (wie die Mid-Tier-Konfiguration oder die Produkte) direkt in einem DBFS-Mount zu speichern. Dadurch wird die Middle Tier von der DBFS-Infrastruktur abhängig (Datenbankclient, Datenbank, FUSE-Librarys usw.). Sie können einen DBFS-Mount als Zwischenspeicherordner verwenden, um eine Kopie des Ordners zu speichern, den Sie replizieren möchten.
Um diese Technologie nutzen zu können, müssen Sie Skripte erstellen und ausführen, um die Mid-Tier-Ordner (z. B. die Konfigurationsordner) in den und aus dem DBFS-Staging-Ordner zu kopieren. Der RPO für diese Technologie hängt von der Häufigkeit dieser Skripte ab.
Da der DBFS-Mount nicht direkt zum Speichern der Mid-Tier-Artefakte verwendet wird, ist der reale Speicher bereits sowohl in der Primär- als auch in der Standbydatenbank gemountet. Daher ist beim Switchover keine Zeit erforderlich, um den Speicher im Standby zu mounten. Durch diese Technologie wird das RTO des Systems bei Switchovers oder Failover nicht erhöht.
Diese Technologie erfordert den Datenbankclient auf den Mid-Tier-Hosts. Je nach Implementierung kann diese Methode auch SQL*net-Konnektivität zwischen den Hosts und den Remotedatenbanken für Datenbankvorgänge wie Rollenkonvertierungen erfordern.
