Übersicht über die Replikation

Nachdem Sie eine Dateifreigabe erstellt haben, können Sie die Replizierung einrichten.

Wenn eine Replikatfreigabe erstellt wird, enthält das erste Replikat die Daten der gesamten Freigabe. Danach werden nur noch die Änderungen hinzugefügt, die nach der letzten Replikation aufgetreten sind.

Sie können eine Replikatfreigabe in einer anderen Zone derselben Region erstellen. Sie können auch ein Replikat in einer anderen Region derselben Region erstellen, wenn Sie über eine weitere VPC in der Zielregion verfügen. Die regionsübergreifende Replikation wird nicht unterstützt.

Wenn Sie Ihre Replikatdateifreigabe in einer anderen Zone derselben Region erstellen, übernimmt die Replikatfreigabe den Verschlüsselungstyp und den Schlüssel aus der Quellendateifreigabe. Die Verschlüsselung kann nicht geändert werden.

Wenn Sie Ihre Dateifreigabe in eine andere Region replizieren, muss das Replikat dem Verschlüsselungstyp der Quellenfreigabe entsprechen. Sie übernimmt jedoch nicht die Verschlüsselung von der Quelle. Mit anderen Worten: Wenn die Quellenfreigabe mit providerverwalteten Schlüsseln verschlüsselt ist, muss das Replikat auch über providerverwaltete Verschlüsselung verfügen. Wenn die Quellenfreigabe mit einem vom Kunden verwalteten Schlüssel verschlüsselt wird, muss die Replik auch mit einem vom Kunden verwalteten Schlüssel verschlüsselt werden. Es muss jedoch nicht derselbe Schlüssel sein. Wenn Sie das Replikat erstellen, geben Sie den CRN des zu verwendenden Schlüssels an.

Basierend auf dem Replikationszeitplan extrahiert der Service Daten aus der Quellendateifreigabe in die Replikatdateifreigabe. Sie können auswählen, wie häufig Änderungen der Quellenfreigabe mit der Replikatfreigabe synchronisiert werden sollen. Sie können einen stündlichen, täglichen, wöchentlichen oder monatlichen Replikationsplan angeben. Die Wiederholungen müssen im Abstand von mindestens 15 Minuten erfolgen.

Während Sie keine Snapshots einer Replikatfreigabe manuell oder programmgesteuert erstellen können, werden die Snapshots der Ursprungsfreigabe bei der nächsten geplanten Synchronisierung in die Replikatfreigabe kopiert. Wenn eine Quellfreigabe mit Snapshots repliziert wird, werden die entsprechenden Replikatfreigabe-Snapshots mit vom System generierten Namen erstellt, anstatt die Namen der Quellfreigabe-Snapshots zu übernehmen. Da replizierte Snapshots die Fingerprint-ID der Quelle gemeinsam haben, können Sie den Fingerprint verwenden, um die Snapshots zu korrelieren.

Wenn Sie regionsübergreifend replizieren, überschreiten die Daten VPC-Grenzen. Sowohl VPCs als auch Dateifreigaben müssen demselben Konto angehören und Sie müssen Service-to-Service-Berechtigungen zwischen den Dateiservices der beiden Regionen einrichten. Die Daten werden während der Übertragung verschlüsselt, während sie zwischen Dateifreigaben verschoben werden. Die Gebühren für die Datenübertragung zwischen den beiden Dateifreigaben werden mit einem Pauschalbetrag in GB-Schritten berechnet. Die Gebühren basieren auf dem Datenvolumen, das während des gesamten Abrechnungszeitraums übertragen wurde.

Wenn Sie Daten über Regionen hinweg replizieren, sollten Sie die lokalen Gesetze zur Datenaufbewahrung berücksichtigen, da das Verschieben von Daten über Grenzen hinweg rechtliche Folgen haben kann.

Bei der Replikation handelt es sich um eine asynchrone Operation, die nicht sofort ausgeführt wird. Sie können die Informationen zur Replikationssynchronisation verwenden, um die Dauer des Replikationsprozesses und die Übertragungsrate anzuzeigen. Durch die Überprüfung der Informationen zur Replikationssynchronisation können Sie Ihren Replikationszeitplan anpassen und Ihre Kosten auf die Häufigkeit abwägen, mit der die Daten auf dem Replikat aktualisiert werden müssen. Durch Anzeigen der Jobprotokolle und der Übertragungsraten können Sie auch ermitteln, ob die Größe der zu übertragenden Daten in das Replikationsfenster passt.

Damit die Replikation abgeschlossen werden kann, muss genügend ungenutzte Kapazität in Ihrer Dateifreigabe vorhanden sein. Während des Replikationsprozesses werden neue Daten von der Quelle auf das Replikationsvolume kopiert. Die alten Daten werden nicht sofort überschrieben, sondern nach Abschluss des Kopiervorgangs entfernt. Wenn Ihre Freigabe beispielsweise zu 95 % ausgelastet ist und die Änderungsrate 10 % beträgt, kann es sein, dass die Replik nicht genug Platz hat, um die Änderungen zu speichern. Wenn das Replikat nicht über genügend Speicherplatz verfügt, um die Aktualisierungen zu speichern, schlägt der Replikationsprozess fehl. Sie können die Dateifreigabekapazität in der Konsole überwachen und Warnungen für die Nutzung konfigurieren. Weitere Informationen finden Sie in Metriken für File Storage for VPC überwachen.

Die Daten in der Replikatfreigabe sind schreibgeschützt. Sie können auf zwei Arten Lese- und Schreibzugriff auf die Daten erhalten:

• Failover zum Replikationsstandort- Die Lese-/Schreibvorgänge von der Quelldateifreigabe werden angehalten und eine endgültige Kopie der Dateifreigabedaten wird auf die Replikationsfreigabe gezogen. Auf die Replikatfreigabe kann lesend und schreibend zugegriffen werden, und es wird eine umgekehrte Replikationsbeziehung hergestellt. Die ursprüngliche Quellendateifreigabe wird jetzt zur Replikatfreigabe und ist schreibgeschützt. Der Dienst beginnt dann, Daten aus der neuen Quelldatei-Freigabe zu ziehen.

  Wenn eine Quelldateifreigabe kompromittiert ist, sind Replikatfreigaben eine gute Möglichkeit, den Betrieb wiederherzustellen. Ein Failover auf eine gemeinsam genutzte Replikatressource stellt sicher, dass Ihre Services nicht unterbrochen werden.

  Wenn Sie den Failover einleiten, können Sie angeben, was mit der Replikationsbeziehung geschieht, wenn der Failover-Prozess das Zeitlimit überschreitet oder fehlschlägt. Diese Option wird häufig verwendet, wenn Sie eine Zeitvorgabe haben, wie lange Ihre Dateifreigabe offline sein darf. Sie müssen angeben, was geschehen soll, wenn die Operation das Zeitlimit überschreitet oder wenn die Replikation aufgrund des ursprünglichen Standorts fehlschlägt, der vermindert oder nicht verfügbar ist.

  • Wenn der Quellenstandort aufgrund einer geplanten Wartung nicht verfügbar ist, haben Sie die Möglichkeit, die Replikationsbeziehung beizubehalten. Die Replikation wird wie geplant fortgesetzt, wenn der ursprüngliche Quellenstandort wieder betriebsbereit ist.
  • In einer Disaster-Recovery-Situation können Sie auswählen, dass die Datenträger aufgeteilt werden, damit die gemeinsam genutzte Replikatressource so bald wie möglich online geschaltet wird. In diesem Fall ist jedoch möglicherweise nicht die neueste Datei verfügbar und Sie müssen den Status in Ihrer Anwendung möglicherweise manuell abgleichen. Da die Replikationsbeziehung getrennt wird, müssen Sie die Replikation erneut einrichten, wenn der ursprüngliche Standort wieder betriebsbereit wird.

• Replikationsbeziehung entfernen-In diesem Fall teilen Sie die beiden gemeinsam genutzten Ressourcen auf und erstellen zwei unabhängige Dateifreigaben. Beide Freigaben sind Schreib-/Lesezugriff und Daten werden zwischen den beiden nicht mehr synchronisiert. In der API wird dieser Vorgang als Replikationsvorgang split bezeichnet. Das Entfernen der Replikatbeziehung ist permanent. Sie kann nicht zwischen den beiden gemeinsam genutzten Ressourcen wiederhergestellt werden. Sie können jedoch neue Replikate in derselben Zone oder in anderen Zonen derselben Region erstellen.

Das Entfernen der Replikationsbeziehung oder das Failover auf das Replikat findet nicht statt, wenn eine andere Operation für die Quellen-oder Replikatdateifreigabe ausgeführt wird. (Ein Beispiel für eine solche Operation ist das Erweitern der Dateifreigabegröße.) Der Split- oder Failover-Vorgang bleibt so lange in der Schwebe, bis der andere Vorgang abgeschlossen ist.

Anwendungsfälle

Sie können die Replikation verwenden, um Probleme bei der Wiederherstellung nach einem Katastrophenfall zu beheben. Die Replikation geht auf diese Szenarien ein:

• Disaster-Recovery nach einem Anwendungsfehler.

  In diesem Szenario schlägt die Anwendung fehl, die Sie ausführen. Die Daten sind nicht betroffen, aber die Anwendung ist nicht betriebsbereit. Sie können einen Failover ausführen, bei dem die Daten in den Wartemodus versetzt und an eine andere Zone gesendet werden. Die virtuellen Serverinstanzen in dieser Zone können so konfiguriert werden, dass sie das Ausführen der Anwendung übernehmen, während die primären Server repariert werden.

• Disaster Recovery aufgrund eines Ausfalls der IBM Cloud Infrastruktur.

  In diesem Szenario wird die Verfügbarkeitszone IBM Cloud, in der Ihre Anwendung ausgeführt wird, unbrauchbar. Sie müssen Ihre Anwendung am Replikationsort so schnell wie möglich starten und die replizierten Daten des letzten Replikationsereignisses verwenden. Sie können den Failover mit der Option split einleiten, damit der Replikatdatenträger unabhängig wird. Die Replikation wurde gestoppt.

• Die regelmäßige Wartung Ihrer Anwendungen vereinfachen.

  Mit der Replikation können Sie bestimmte Verwaltungstasks wie Upgrades mit höherer Verfügbarkeit vereinfachen. Migrieren Sie Daten zwischen zwei Zonen, in denen möglicherweise unterschiedliche Versionen des Anwendungscodes ausgeführt werden. Die unabhängige Ausführung in zwei Umgebungen ermöglicht mehr Flexibilität in Ihrem Bereitstellungsprozess.

• Datenmigration oder geografische Erweiterung.

  Sie können die Replikation verwenden, um Daten ohne großen Aufwand zwischen zwei MZR-Regionen zu migrieren. Nach der Replikation Ihrer Daten können Sie die Replikationsbeziehung entfernen und Ihre Replikatdateifreigabe wird mit Ihren Daten verfügbar, die unabhängig in der neuen Region verwendet werden können.

Nächste Schritte

1. Erstellen Sie eine Replikat-Dateifreigabe in der Konsole, über die Befehlszeilenschnittstelle, mit der API oder Terraform.

   Wenn Sie eine Replikation zwischen verschiedenen Regionen einrichten möchten, müssen Sie zunächst Service-zu-Service-Autorisierungen zwischen den Dateidiensten der beiden VPCs einrichten.

   Wenn Sie eine Replikatfreigabe in einer anderen Region erstellen möchten, in der Sie eine andere KMS-Lösung verwenden, richten Sie Service-zu-Service-Autorisierungen zwischen dem Dateiservice und dem Ziel-KMS ein.

2. Überprüfen Sie, ob die Replikation funktioniert, indem Sie den Replikationsstatus und die Informationen zur Replikationssynchronisation überprüfen. Das System fragt den letzten Synchronisationsstatus alle 15 Minuten ab.

3. Replikatdateifreigabe verwenden-Wenn die primäre Dateifreigabe fehlschlägt oder aus irgendeinem Grund nicht mehr verfügbar ist, können Sie ein Failover auf die Replikatdateifreigabe durchführen. Wenn Sie den Failover durchführen, wird die Replikatfreigabe zur neuen primären Dateifreigabe mit Lese-und Schreibberechtigung.

4. Starten Sie die Replikation mit der ursprünglichen Dateifreigabe wie geplant erneut, wenn sie wieder online ist. In diesem Fall können Sie die Replikatsite weiterhin als primäre Site verwenden oder auf die ursprüngliche Site zurücksetzen.