Oracle Cloud Infrastructure-Dokumentation

Durch Full Stack Disaster Recovery ausgeführte Vorabprüfungen

Beim Full Stack Disaster Recovery werden Vorabprüfungen für Ressourcen wie DR-Schutzgruppen, DR-Pläne und DR-Planausführungen durchgeführt.

Vorabprüfungen für Compute-Instanzen

Full Stack DR führt zuerst die folgenden Speichervorabprüfungen für jede VM im primären DRPG durch. Full Stack DR prüft, ob:
  • Die Volume-Gruppenreplikation ist konfiguriert, oder das Backup ist mit einer Backup-Policy konfiguriert, und das regionsübergreifende Kopieren ist aktiviert.
  • In der Standbyregion ist ein Volume-Gruppenreplikat oder mindestens ein Volume-Gruppenbackup vorhanden. Es können auch mehrere Backups vorhanden sein, da Full Stack DR das letzte Volume-Gruppenbackup verwendet.
  • Alle Boot- und Block-Volumes der VMs der Mitglieder in einem DRPG werden der Volume-Gruppe hinzugefügt.
  • Volume-Gruppe enthält nur die Boot- und Block-Volumes, die an die VM der Mitglieder in einem DRPG angehängt sind.
  • Gibt an, ob der Benutzer versucht, gleitende Compute-Instanzen zu einer Standby-DR-Schutzgruppe hinzuzufügen. Dies ist nicht zulässig.

Vorabprüfungen für Dateisystem:

Full Stack DR führt zunächst die folgenden Vorabprüfungen für das Dateisystem aus:
  • Switchover/Failover/Start-Drill:
    • Validiert, ob sich das Quelldateisystem im Status Aktiv befindet und exportiert werden soll
    • Validiert, dass das Quelldateisystem keinen benutzerdefinierten Verschlüsselungsschlüssel enthalten darf
    • Validiert, dass der gesamte im Quelldateisystem vorhandene Export dem Zielmountziel als Teil der Dateisystem-Member-Eigenschaft zugeordnet ist und eindeutig sein muss (Duplizierung vermeiden)
    • Validiert, ob mindestens eine aktive Replikations-Policy im Quelldateisystem eingerichtet ist
    • Validiert, ob sich die Ziel-Availability-Domain der Dateisystem-Member-Eigenschaft in der Peerregion befindet
    • Validiert, dass sich alle Zielmountziele, die für Quelldateisystemexporte konfiguriert werden, in der Peerregion befinden und sich in derselben Availability-Domain wie die Ziel-Availability-Domain der Mitgliedseigenschaft befinden.
    • Validiert, ob sich das Zieldateisystem im Status Aktiv befindet und nicht exportiert sein soll
    • Validiert, dass mindestens ein Replikations-Snapshot im Zieldateisystem vorhanden sein muss
    • Validiert, ob für die Ziel-Mount-Ziele das korrekte TCP/UDP-Protokoll aktiviert ist. Siehe VCN-Sicherheitsregeln für File Storage konfigurieren.
    • Validiert die OCID in der Snapshot Policy des Ziel-Snapshots der Dateisystem-Member-Eigenschaft.
    • Validiert, ob die Ziel-Snapshot-Policy in der Eigenschaft des Dateisystemelements vorhanden ist und den Lebenszyklusstatus Aktiv aufweist.
    • Validiert, ob der Ziel-Vault und Zielverschlüsselungsschlüssel in der Dateisystem-Member-Eigenschaft vorhanden ist und den Lebenszyklusstatus Aktiv aufweist.
    • Validiert, ob der Zielverschlüsselungsschlüssel in der Eigenschaft des Dateisystemmitglieds ein symmetrischer AES-(Advanced Encryption Standard-)Verschlüsselungsschlüssel ist und einen Aktivierten Lebenszyklusstatus aufweist.
  • Drilldown stoppen
    • Validiert, ob das geklonte exportierte Dateisystem zur Bereinigung vorhanden ist
    • Validiert, ob die Exporte im geklonten exportierten Dateisystem zur Bereinigung vorhanden sind

Vorabprüfungen für Mount-/Unmount-Dateisystem auf Compute-Instanz:

Full Stack DR führt zunächst die folgenden Vorabprüfungen für das Mount-/Unmount-Dateisystem auf der Compute-Instanz aus:
  • Validierungen für Mount-/Unmount-Detail-Elementeigenschaft:
    • Mount-Details:
      • Validiert, ob das Mountziel der Mountdetails mit der Standbyregion übereinstimmt.
      • Stellt sicher, dass die Kombination aus Einhängepunkt und Export eindeutig ist (mehrere Einhängepunkte vermeiden).
    • Details zum Unmounten:
      • Validiert, ob das Mountziel der Details zum Aushängen mit der primären Region übereinstimmt.
      • Prüft, ob der Exportpfad im Mountziel der Details zum Aushängen vorhanden ist.
    • Validiert, ob für die verschiebbare/nicht verschiebbare Compute-Instanz und das Mountziel der Mountdetails das korrekte TCP/UDP-Protokoll aktiviert ist. Siehe VCN-Sicherheitsregeln für File Storage konfigurieren.
    • Validiert für eine verschiebbare/nicht verschiebbare Compute-Instanz. Entweder muss die primäre DR-Schutzgruppe das mountbare Dateisystem aufweisen, oder das Zielmountziel muss den richtigen Exportpfad zum Mounten aufweisen.
    • Hinweis

      Bei einem Failover wird die folgende Prüfung im Schritt Dateisystem - Auf Compute-Instanz mounten mit neu gestarteter Compute-Instanz ausgeführt, da die primäre Region nicht verfügbar ist

    • Validiert, ob für die Compute-Instanz das Compute Instance Run Command-Plug-in aktiviert ist.
    • Validiert, ob die Compute-Instanz über einen Root-Zugriff verfügt:
    • Validiert nur für das Linux-Betriebssystem, dass auf der Compute-Instanz nfs-client installiert ist. Informationen zur Installation von nfs-client auf Compute finden Sie unter Dateisysteme von Instanzen im UNIX-Stil mounten.
    • Stellen Sie nur für das Linux-Betriebssystem sicher, dass für /etc/fstab im linux-Betriebssystem Mountendetails mit der richtigen IP-Adresse des Mountziels/dem vollständig qualifizierten Domainnamen und dem Mount Point vorhanden sein sollen.
    • Prüfen Sie bei beiden Betriebssystemen, ob der Mount Point auf der Compute-Instanz vorhanden ist

Vorabprüfungen für Volume-Gruppen (Block Storage)

Full Stack DR führt zuerst die folgenden Vorabprüfungen für alle Volume-Gruppen aus, die dem primären DRPG hinzugefügt wurden. Full Stack DR prüft, ob:
  • Die Volume-Gruppe befindet sich im Status Available.
  • Für die Volume-Gruppe sind entweder Replikationen oder Backups in der Standbyregion konfiguriert. Wenn beide konfiguriert sind, verwendet Full Stack DR Replikate und ignoriert Backups.
  • Bei regionsinterner DR befinden sich alle Zielreplikate (Standby-)Regionen nicht in derselben Availability-Domain (AD).
  • Das Replikat in der Standbyregion weist den Status Available auf. Wenn Backups verwendet werden, ist mindestens ein Backup vorhanden und ist Available.
  • Die Liste der Volumes in der Quell-Volume-Gruppe stimmt mit der Liste der Volumes im Replikat oder Backup der Standbyregion überein.
  • Die Zielbackup-Policy ist eine gültige Backup-Policy.
  • Der Vault und der Verschlüsselungsschlüssel, die unter Gemeinsamer Zielschlüssel angegeben werden, sind beide gültig.
  • Der im Allgemeinen Zielschlüssel bereitgestellte Vault hat den Lebenszyklusstatus Aktiv.
  • Der im gemeinsamen Zielschlüssel angegebene Verschlüsselungsschlüssel hat den Lebenszyklusstatus Aktiviert
  • Das Quell-Volume, der Ziel-Vault und der Verschlüsselungsschlüssel, die unter Verschlüsselungsschlüsselzuordnungen von Quell-Volume zu Ziel angegeben werden, sind alle gültig.
  • Sie können entweder Gemeinsamer Zielschlüssel oder Verschlüsselungsschlüssel Quell-Volume zu Ziel Zuordnungen angeben. Beide Elementeigenschaften können nicht angegeben werden.

Vorabprüfungen für Block-Volume für nicht bewegliche Compute-Instanzen

Full Stack DR führt zunächst die folgenden Vorabprüfungen für das Block-Volume für nicht bewegliche Compute-Instanzen aus:

Wenn die Compute-Instanz einem DRPG mit der Rolle Primär als Mitglied hinzugefügt wird, führen Sie die folgenden Validierungen für jede Block-Volume-ID aus, die in der Liste der neuen Elementeigenschaften angegeben wird:
  • Die Block-Volume-ID muss eine gültige OCID eines Block-Volumes sein.
  • Das Block-Volume darf keine Duplikate in den Member-Eigenschaften derselben Compute-Instanz enthalten.
  • Block-Volume muss bereits an die Compute-Instanz angehängt sein.
  • Das Block-Volume muss Teil eines Volume-Gruppenmitglieds des DRPG sein.
  • Wenn in den Anhangsdetails eine Referenzinstanz-ID für Volume-Anhang angegeben ist, muss diese Instanz Mitglied der Standby-DR-Schutzgruppe sein, und die Block-Volume-ID muss in ihren Mitgliedseigenschaften hinzugefügt werden.
  • Wenn die Referenzinstanz-ID des Volume-Anhangs nicht in den Anhangsdetails angegeben ist, muss für nur eine Compute-Instanz im Standby-DRPG eine Elementeigenschaft mit dieser Block-Volume-ID definiert sein.
  • Die definierten Einhängepunkte müssen eindeutig sein.
Wenn die Compute-Instanz einem DRPG mit der Rolle Standby als Mitglied hinzugefügt wird, führen Sie die folgenden Validierungen für jede Block-Volume-ID aus, die in der Liste der neuen Elementeigenschaften angegeben ist:
  • Die Block-Volume-ID muss eine gültige OCID eines Block-Volumes sein.
  • Das Block-Volume darf keine Duplikate in den Member-Eigenschaften derselben Compute-Instanz enthalten.
  • Das Block-Volume muss aus dem Bereich des primären DRPG stammen.
  • Das Block-Volume muss Teil eines Volume-Gruppenmitglieds des primären DRPG sein.
  • Die Ziel-/Ziel-AD der Volume-Gruppe (wo das Backup oder Replikat aktiviert wird) muss mit der AD dieser Standby-Compute-Instanz übereinstimmen.
  • Wenn in den Anhangsdetails eine Referenzinstanz-ID des Volume-Anhangs angegeben ist, muss diese Peerinstanz Mitglied des primären DRPG sein, und das Block-Volume muss an sie angehängt werden.
  • Wenn die Referenzinstanz-ID des Volume-Anhangs nicht in den Anhangsdetails angegeben ist, muss das Block-Volume nur an eine Compute-Instanz im primären DRPG angehängt sein.
  • Die von Ihnen definierten Einhängepunkte müssen eindeutig sein.
  • Es dürfen keine zwei Block-Volumes zum Anhängen mit demselben Gerätepfad konfiguriert werden.
  • Wenn der Anhang Gerätepfade verwendet, dürfen die Gerätepfade nicht verwendet werden.
  • Wenn ein Block-Volume so konfiguriert ist, dass es an mehrere Compute-Instanzen angehängt wird, muss der Anhang über einen gemeinsam nutzbaren Zugriff verfügen.

Vorabprüfungen für Objektspeicher mit Switchover und Failover

Full Stack DR führt die folgenden Vorabprüfungen für den Objektspeicher aus:

  • Switchover:

    • Object Storage-Bucket - Vorabprüfung "Replikation löschen (primär)"

      • Validiert, ob der Quell-Bucket vorhanden ist.

      • Validiert, ob die Replikations-Policy vorhanden ist.

      • Validiert, ob sich die Replikations-Policy in der Peerregion befinden sollte.

    • Objektspeicher-Bucket - Vorabprüfung für Reverse Replication (Standby) einrichten

      • Validiert, ob der Ziel-Bucket vorhanden ist

      • Validiert, ob der Quell-Bucket vorhanden ist

  • Failover:

    • Object Storage-Bucket - Vorabprüfung "Replikation löschen (primär)"

      • Validiert, ob sich der Quell-Bucket im Status Aktiv befindet.

      • Validiert, ob die Replikations-Policy vorhanden ist.

      • Validiert, ob sich die Replikations-Policy in der Peerregion befinden sollte.

      • Validiert, ob sich der Ziel-Bucket im Status Aktiv befindet.

    • Objektspeicher-Bucket - Vorabprüfung für Reverse Replication (Standby) einrichten (bei Fehler fortsetzen)

      • Validiert, ob der Ziel-Bucket vorhanden ist.
      • Validiert, ob der Quell-Bucket vorhanden ist.

Vorabprüfungen für Database (Oracle Base Database Service, Oracle Exadata Database Service on Dedicated Infrastructure, Oracle Exadata Database Service on Exascale-Infrastruktur, Oracle Exadata Database Service on Cloud@Customer)

Full Stack DR führt die folgenden Vorabprüfungen aus, wenn ein Datenbankmitglied (Oracle BaseDatabase Service, Oracle Exadata Database Service on Dedicated Infrastructure, Oracle Exadata Database Service on Exascale-Infrastruktur, Oracle Exadata Database Service on Cloud@Customer) Teil des DRPG ist. Full Stack DR prüft, ob:
  • Datenbank-Member-Eigenschaften sind nicht leer oder null, und der Secret Vault-Speicherort des Kennworts ist Teil der Datenbank-Member-Eigenschaften.
  • Sie können auf den Secret Vault zugreifen, in dem das Datenbankkennwort gespeichert ist und die Peerdatenbank den Status Available aufweist.
  • Für Datenbank und Peerdatenbanken ist Data Guard aktiviert, und sie sind Data Guard-Peers voneinander.
  • Datenbank und Peerdatenbank haben die richtigen Data Guard-Rollen.
  • Datenbank und Peerdatenbank sind Teil der beiden zugeordneten DR-Schutzgruppen, die Bestandteil der Konfiguration sind. Die Primärdatenbank ist Teil der primären DR-Schutzgruppe, und die Standbydatenbank gehört zur Standby-DR-Schutzgruppe.

Vorabprüfungen für Oracle Autonomous Database Serverless

Full Stack DR führt die folgenden Vorabprüfungen aus, wenn ein Autonomous Database Serverless-Mitglied Teil des DRPG ist. Full Stack DR prüft, ob:
  • Autonome Datenbankelementeigenschaften sind nicht leer oder null.
  • Die autonome Primärdatenbank hat keine leere Standbydatenbankliste.
  • Die autonome Standby-Datenbank befindet sich nicht in derselben Region wie die Primärdatenbankregion und ist kein lokaler Peer.
  • Die autonome Datenbank und die autonome Peerdatenbank gehören zu den beiden verknüpften DR-Schutzgruppen, die Bestandteil der Konfiguration sind.
  • Remote Data Guard ist konfiguriert.
  • Die Remote-Peer-Datenbank gehört zum Remote-DRPG.
  • Der Lebenszyklusstatus der Primärdatenbank ist AVAILABLE.

    Bei Switchover-Vorprüfungen führt Full Stack DR die folgenden zusätzlichen Validierungen in der Standbydatenbank aus: Prüft, ob die Remote-Peer-Standbydatenbank den korrekten Status (STANDBY) aufweist.

  • Wenn der Vault und der in Zielverschlüsselungsschlüssel angegebene Verschlüsselungsschlüssel gültig sind.
  • Die Vault-ID in Zielverschlüsselungsschlüssel hat den Lebenszyklusstatus Aktiv.
  • Die Verschlüsselungs-ID im Zielverschlüsselungsschlüssel hat den Lebenszyklusstatus Aktiviert.

Vorabprüfungen für autonome Oracle-Containerdatenbank

Full Stack DR führt die folgenden Vorabprüfungen aus, wenn ein Member einer autonomen Containerdatenbank Teil des DRPG ist. Full Stack DR prüft, ob:
  • Member-Eigenschaften der autonomen Containerdatenbank sind nicht leer oder Null.
  • Die autonome Primärcontainerdatenbank enthält keine leere Standbydatenbankliste.
  • Die autonome Datenbank und die autonome Peerdatenbank sind Teil der beiden verknüpften DR-Schutzgruppen, die Teil der Konfiguration sind.
  • Remote Data Guard ist konfiguriert.
  • Remote-Peer-Datenbank gehört zum Remote-DRPG.
  • Der Lebenszyklusstatus der autonomen Primär- und Standbycontainerdatenbank lautet AVAILABLE.

    Bei Switchover-Vorprüfungen führt Full Stack DR die folgenden zusätzlichen Validierungen in der Standbydatenbank aus: Prüft, ob die Remote-Peer-Standbydatenbank den korrekten Status (STANDBY) aufweist.

Vorabprüfungen für Kubernetes-Engine (OKE)

Full Stack DR führt die folgenden Vorabprüfungen für die Kubernetes-Engine (OKE) aus.

Primäres Cluster
  1. Prüft die Verbindung zum primären Cluster.
  2. Prüft, ob das Backup älter als einen Tag ist.
  3. Lädt das Backuplog herunter und druckt es.
  4. Validiert, ob der Lebenszyklusstatus des primären OKE-Clusters "Aktiv" lautet.
  5. Validiert, ob der Namespace und der Bucket in den Eigenschaften des primären Elements vorhanden und gültig sind.
  6. Validiert, ob der Backupzeitplan in den Eigenschaften des primären Elements im RFC 5545-Format vorliegt.
    • Validiert für den nicht unterstützten Regelteil.
    • Validiert den Bereich für jedes Regelteil.
  7. Validiert die Load-Balancer-Zuordnung in primären Elementeigenschaften für die folgenden Constraints.
    • SourceLoadBalancerId und DestinationLoadBalancerId haben OCIDs von LOADBALANCER.
    • Load-Balancer-Zuordnung muss eindeutig sein.
      • A-B, C-B -> Nicht zulässig
      • A-B, A-D -> Nicht zulässig
        Hinweis

        Beispiel: Wenn sich zwei Load Balancer in der primären Region befinden (z.B. load_balancer_A and load_balancer_C). In der Standbyregion gibt es ein weiteres Set aus zwei Load Balancern (z.B. load_balancer_B and load_balancer_D). Wenn Sie also ein OKE-Cluster als Mitglied hinzufügen, müssen Sie die Eigenschaft für Load-Balancer-Zuordnungen hinzufügen. In dieser Zuordnung sind nur die folgenden Zuordnungen zulässig: 
        load_balancer_A <--> load_balancer_B & load_balancer_C <--> load_balancer_D 
or load_balancer_C <--> load_balancer_B & load_balancer_A <--> load_balancer_D
        . Die folgenden Zuordnungen sind jedoch nicht zulässig, da load_balancer_B in beiden Zuordnungen als Ziel-Load Balancer festgelegt ist: 
        load_balancer_A <--> load_balancer_B & load_balancer_C <--> load_balancer_B
  8. Validiert die Network Load Balancer-Zuordnung in primären Member-Eigenschaften für die folgenden Constraints.
    • SourceNetworkLoadBalancerId und DestinationNetworkLoadBalancerId haben OCIDs von NETWORKLOADBALANCER.
    • Die Network Load Balancer-Zuordnung muss eindeutig sein.
      • A-B, C-B -> Nicht zulässig
      • A-B, A-D -> Nicht zulässig
        Hinweis

        Beispiel: Wenn sich zwei Network Load Balancer in der primären Region befinden (z.B. network_load_balancer_A and network_load_balancer_C). In der Standbyregion gibt es ein weiteres Set aus zwei Network Load Balancern (z.B. network_load_balancer_B and network_load_balancer_D). Wenn Sie also ein OKE-Cluster als Member hinzufügen, müssen Sie die Mappings-Eigenschaft für den Network Load Balancer hinzufügen. In dieser Zuordnung sind nur die folgenden Zuordnungen zulässig: 
        network_load_balancer_A <--> network_load_balancer_B & network_load_balancer_C <--> network_load_balancer_D 
or network_load_balancer_C <--> network_load_balancer_B & network_load_balancer_A <--> network_load_balancer_D
  9. Validiert die Vault-Zuordnung in primären Elementeigenschaften für die folgenden Constraints.
    • SourceVaultId und DestinationVaultId haben OCIDs von VAULT.
    • Vault-Zuordnung muss eindeutig sein.
      • A-B, C-B -> Nicht erlaubt.
      • A-B, A-D -> Nicht zulässig.
        Hinweis

        Beispiel: Wenn sich ein Set aus zwei Vaults in der primären Region befindet (z.B. vault_A and vault_C). In der Standbyregion gibt es ein weiteres Set aus zwei Vaults (z.B. vault_B and vault_D). Wenn Sie also ein OKE-Cluster als Member hinzufügen, müssen Sie die Eigenschaft "Vault-Mappings" hinzufügen. In dieser Zuordnung sind nur die folgenden Zuordnungen zulässig: 
        vault_A  <--> vault_B & vault_C <--> vault_D 
or vault_C <--> vault_B & vault_A <--> vault_D
  10. Validiert, dass die Peer-Cluster-ID und der Backupspeicherort in den Eigenschaften des primären Elements nicht leer sind.
  11. Validiert den Jump-Host in primären Elementeigenschaften für die folgenden Constraints.
    • Die DR-Schutzgruppe muss eine Compute-Instanz mit derselben OCID wie der Jump-Host enthalten.
    • Jump-Host muss eine nicht verschiebbare Compute-Instanz sein.
    • Der Lebenszyklusstatus des Jump-Hosts muss RUNNING lauten.
  12. Validiert die Peercluster-ID in primären Member-Eigenschaften für die folgenden Constraints.
    • Validiert, ob die Peer-DR-Schutzgruppe ein Cluster mit der Peercluster-ID aufweist.
    • Validiert, dass das Member-Cluster selbst nicht als Peer-Cluster hinzugefügt wird.
    • Validiert, dass das in Member-Eigenschaften angegebene Peercluster nicht als Peercluster für das andere OKE-Cluster in der DR-Schutzgruppe hinzugefügt wird.
  13. Validiert die Knotenpools im OKE-Cluster der primären Region für die folgenden Constraints.
    • Validiert, dass die Knotenanzahl in allen Knotenpools mindestens eines ist.
    • Validiert, dass in allen Knotenpools mindestens ein aktiver Knoten vorhanden ist.
    • Beispiel: Wenn zwei Knotenpools vorhanden sind, hat ein Knoten keinen aktiven Knoten, ein anderer jedoch einen aktiven Knoten, würde dies zu einer Ausnahme führen.
  14. Validiert die Quell-Load-Balancer-ID in primären Elementeigenschaften für die folgenden Constraints.
    • Lebenszyklus muss aktiv sein.
    • Load Balancer kann nur ein regionales Subnetz aufweisen.
  15. Validiert die Load-Balancer-ID des Quellnetzwerks in primären Member-Eigenschaften für die folgenden Constraints.
    • Lebenszyklus muss aktiv sein.
    • Network Load Balancer darf nur ein regionales Subnetz aufweisen.
  16. Validiert, ob die Quell-Vault-ID in den Eigenschaften des primären Elements "Aktiv" lautet.
  17. Validiert die Konfiguration des verwalteten Knotenpools in den Eigenschaften des primären Elements für die folgenden Constraints.
    • Elementtyp muss "Verwaltet" lauten.
    • Der Lebenszyklus muss aktiv sein.
    • Die Summe der Knotenanzahl ("Maximum" in der Konfiguration von verwalteten Knoten oder die vorhandene Knotenanzahl, je nachdem, welcher Wert größer ist) für alle Knotenpools im Cluster darf das Limit nicht überschreiten.
  18. Validiert die Konfiguration des virtuellen Knotenpools in den Eigenschaften des primären Elements für die folgenden Constraints.
    • Elementtyp muss VIRTUAL sein.
    • Der Lebenszyklus muss aktiv sein.
    • Die Summe der Knotenanzahl ("Maximum" in der Konfiguration virtueller Knoten oder die vorhandene Knotenanzahl, je nachdem, welcher Wert größer ist) für alle Knotenpools im Cluster darf das Limit nicht überschreiten.

Standbycluster

  1. Prüft, ob der bzw. die Namespace(s) Teil des Backups ist/sind.
  2. Prüft, ob alle in persistenten Volumes referenzierten Block-Volumes Teil der DR-Schutzgruppe sind.
  3. Prüft, ob alle Dateisysteme/Mount-Ziele, die in persistenten Volumes referenziert werden, Teil der DR-Schutzgruppe sind.
  4. Prüft, ob alle in der Ingress-Klasse referenzierten Load Balancer Teil der DR-Schutzgruppe sind.
  5. Prüft, ob alle in secretproviderclasses referenzierten Vaults Teil der DR-Schutzgruppe sind.
  6. Prüft, ob die benutzerdefinierten Ressourcendefinitionen mit der Standbyclusterversion kompatibel sind.
  7. Validiert, ob der Lebenszyklusstatus des Standby-OKE-Clusters "Aktiv" lautet.
  8. Validiert, dass die Peer-Cluster-ID und der Backupspeicherort in den Standby-Member-Eigenschaften nicht leer sein dürfen.
  9. Validiert den Jump-Host in Standby-Member-Eigenschaften für die folgenden Constraints.
    • Die DR-Schutzgruppe muss eine Compute-Instanz mit derselben OCID wie der Jump-Host enthalten.
    • Jump-Host muss eine nicht verschiebbare Compute-Instanz sein.
    • Der Lebenszyklusstatus des Jump-Hosts muss RUNNING lauten.
  10. Validiert die Peer-Cluster-ID in Standby-Member-Eigenschaften für die folgenden Constraints.
    • Validiert, ob die Peer-DR-Schutzgruppe ein Cluster mit einer Peercluster-ID aufweist.
    • Validiert, dass das Member-Cluster selbst nicht als Peer-Cluster hinzugefügt wird.
    • Validiert, dass das in Member-Eigenschaften angegebene Peercluster nicht als Peercluster für ein anderes OKE-Cluster in der DR-Schutzgruppe hinzugefügt wird.
  11. Validiert die Ziel-Load-Balancer-ID in primären Member-Eigenschaften für die folgenden Constraints.
    • Lebenszyklus muss aktiv sein.
    • Load Balancer kann nur ein regionales Subnetz aufweisen.
  12. Validiert die Ziel-Network Load Balancer-ID in primären Member-Eigenschaften für die folgenden Constraints.
    • Lebenszyklus muss aktiv sein.
    • Network Load Balancer darf nur ein regionales Subnetz aufweisen.
    • Validiert, dass die Ziel-Vault-ID in den Eigenschaften des primären Elements "Aktiv" ist.
  13. Validiert die Konfiguration des verwalteten Knotenpools in Standby-Member-Eigenschaften für die folgenden Constraints.
    • Elementtyp muss "Verwaltet" lauten.
    • Lebenszyklus muss aktiv sein.
    • Die Summe der Knotenanzahl ("Maximum" in der Konfiguration von verwalteten Knoten oder die vorhandene Knotenanzahl, je nachdem, welcher Wert größer ist) für alle Knotenpools im Cluster darf das Limit nicht überschreiten.
  14. Validiert die Konfiguration des virtuellen Knotenpools in Standby-Member-Eigenschaften für die folgenden Constraints.
    • Elementtyp muss VIRTUAL sein.
    • Lebenszyklus muss aktiv sein.
    • Die Summe der Knotenanzahl ("Maximum" in der Konfiguration virtueller Knoten oder die vorhandene Knotenanzahl, je nachdem, welcher Wert größer ist) für alle Knotenpools im Cluster darf das Limit nicht überschreiten.
  15. Validiert die Knotenpools im OKE-Cluster der Standbyregion auf die folgenden Constraints.
    • Validiert, dass die Knotenanzahl in allen Knotenpools mindestens eines ist.
    • Validiert, dass in allen Knotenpools mindestens ein aktiver Knoten vorhanden ist.
  16. Validiert, dass der Zielclusterknotenpool mindestens einen Knoten in jeder AD aufweisen muss, auf dem FSS/Block wiederhergestellt wird.
  17. Validiert die securityList- und NSG-Regeln, die in der Subnetz-/Netzwerksicherheitsgruppe der im Cluster bereitgestellten Knotenpools und virtuellen Knotenpools definiert sind, indem sichergestellt wird, dass die folgenden Regeln festgelegt sind.
    • Regeln für zustandsbehafteten Ingress
      • TCP-Ports 111, 2048, 2049 und 2050 und
      • UDP-Ports 111 und 2048
    • Regeln für zustandsbehafteten Egress
      • TCP-Quellports 111, 2048, 2049 und 2050 und
      • UDP-Quellport 111.
        Hinweis

        Die Validierung ist nur anwendbar, wenn das OKE-Cluster PV oder PVC für das Dateisystem enthält. Full Stack DR prüft nur die folgenden Szenarios:
        • Szenario A: Mountziel und Instanz befinden sich in unterschiedlichen Subnetzen (empfohlen).
        • Szenario B: Mountziel und Instanz befinden sich im selben Subnetz.
          Full Stack DR prüft die folgenden Szenarios nicht:
          • Szenario C: Das Mountziel und die Instanz verwenden die TLS-Verschlüsselung bei der Übertragung.
          • Szenario D: Das Mountziel verwendet LDAP zur Autorisierung.

Vorabprüfungen für MySQL HeatWave-DB-System

Full Stack DR führt die folgenden Vorabprüfungen für das MySQL-DB-System aus:

  • Switchover:
    • Validiert, ob die Lebenszyklusstatus von primären und Standby-MySQL HeatWave-DB-Systemen den Status Aktiv aufweisen.
    • Validiert, ob das Ziel-DB-System in der Peer-DR-Schutzgruppe als Member vorhanden ist. Außerdem verfügt es über die Ziel-DB-Systemeigenschaft, die mit der primären MySQL-DB-System-OCID übereinstimmt.
    • Validiert, ob das primäre MySQL-DB-System im Lesen/Schreiben-Modus ist.
    • Validiert, ob sich das Ziel-DB-System MySQL im Schreibgeschützten-Modus befindet.
    • Validiert, ob das primäre MySQL-DB-System-Vault Secret, das für Admin- und Replikationsbenutzer bereitgestellt wird, den Status Verfügbar aufweist.
    • Validiert, ob das für Admin- und Replikationsbenutzer bereitgestellte DB-System-Vault Secret des Standby-MySQL im Status Verfügbar ist.
    • Validiert, ob ein aktiver Kanal zwischen dem primären DB-System MySQL und dem Ziel-DB-System MySQL vorhanden ist.
      Hinweis

      Bei einem Fehler zeigt Full Stack DR eine Warnung an.
    • Validiert die Konnektivität zwischen der Containerinstanz und den DB-Knoten MySQL.
    • Validiert, ob die GTID-Ausführung sowohl für Primär- als auch für Ziel-DB-Systeme vorhanden ist.
  • Failover:
    • Validiert, ob der Lebenszyklusstatus des Standby-DB-Systems MySQL den Status Aktiv aufweist.
    • Validiert, ob das Ziel-DB-System in der Peer-DR-Schutzgruppe als Member vorhanden ist. Außerdem verfügt es über die Ziel-DB-Systemeigenschaft, die mit der primären MySQL-DB-System-OCID übereinstimmt.
    • Validiert, ob sich das Ziel-DB-System MySQL im Lesen-Modus befindet.
    • Validiert, ob das für Admin- und Replikationsbenutzer bereitgestellte DB-System-Vault Secret des Standby-MySQL im Status Verfügbar ist.
    • Validiert, ob ein aktiver Kanal zwischen dem primären DB-System MySQL und dem Ziel-DB-System MySQL vorhanden ist.
    • Validiert die Konnektivität zwischen der Containerinstanz und beiden DB-Knoten MySQL.
    • Validiert, ob die GTID-Ausführung sowohl für das primäre als auch für das Ziel-DB-System vorhanden ist.
  • Drill starten:
    • Validiert, ob der Lebenszyklusstatus des MySQL-DB-Systems für das Primär- und das Standby-DB-System den Status Aktiv aufweist.
    • Validiert, ob das Ziel-DB-System in der Peer-DR-Schutzgruppe als Member vorhanden ist. Außerdem verfügt es über die Ziel-DB-Systemeigenschaft, die mit der primären MySQL-DB-System-OCID übereinstimmt.
    • Validiert, ob sich das primäre MySQL-DB-System im Lese-/Schreibmodus befindet.
    • Validiert, ob sich das DB-System MySQL des Ziels im Lesemodus befindet.
    • Validiert, ob das Backup im wiederherzustellenden DB-System MySQL des Ziels vorhanden ist.
    • Validiert, ob ein aktiver Kanal zwischen dem primären DB-System MySQL und dem Ziel-DB-System MySQL vorhanden ist.
  • Aufgliederung stoppen:

    Validiert, ob die wiederhergestellte MySQL-DB in der Peerregion vorhanden ist, um bereinigt zu werden.

Übergeordnetes Thema: Referenz