Documentazione di Oracle Cloud Infrastructure

Controlli preliminari eseguiti da Full Stack Disaster Recovery

Full Stack Disaster Recovery esegue controlli preliminari per risorse quali i gruppi di protezione DR, i piani DR e le esecuzioni dei piani DR.

Controlli preliminari per l'istanza di computazione

Full Stack DR esegue innanzitutto i controlli preliminari di storage riportati di seguito per ogni VM presente nel DRPG primario. Full Stack DR verifica che:
  • La replica del gruppo di volumi è configurata oppure il backup è configurato con un criterio di backup e la copia tra più aree è abilitata.
  • Nella standby region esiste una replica del gruppo di volumi o almeno un backup del gruppo di volumi. Possono inoltre esistere più backup poiché Full Stack DR utilizza il backup più recente del gruppo di volumi.
  • Tutti i volumi di avvio e a blocchi delle VM dei membri in un DRPG vengono aggiunti al gruppo di volumi.
  • Il gruppo di volumi contiene solo i volumi di avvio e a blocchi collegati alla VM dei membri in un DRPG.
  • Indica se l'utente sta tentando di aggiungere lo spostamento delle istanze di computazione a un gruppo di protezione DR in standby, operazione non consentita.

Controlli preliminari per il file system:

Full Stack DR esegue innanzitutto i seguenti controlli preliminari per il file system:
  • Switchover/Failover/Start Drill:
    • Verifica che il file system di origine sia in stato Attivo e che debba essere esportato
    • Verifica che il file system di origine non debba avere una chiave di cifratura personalizzata
    • Verifica che tutta l'esportazione presente nel file system di origine sia mappata alla destinazione di accesso di destinazione come parte della proprietà del membro del file system e che debba essere univoca (evitare la duplicazione)
    • Verifica la presenza di almeno un'impostazione dei criteri di replica attiva nel file system di origine
    • Verifica che la proprietà del membro del file system dominio di disponibilità di destinazione si trovi nell'area peer
    • Verifica che tutte le destinazioni di accesso di destinazione configurate per le esportazioni del file system di origine si trovino nell'area peer e si trovino nello stesso dominio di disponibilità della proprietà membro dominio di disponibilità di destinazione.
    • Verifica che il file system di destinazione sia in stato Attivo e che sia un file system non esportato
    • Verifica la presenza di almeno uno snapshot di replica nel file system di destinazione
    • Verifica che le destinazioni di accesso di destinazione dispongano dell'abilitazione del protocollo TCP/UDP corretta. Vedere Configurazione delle regole di sicurezza VCN per lo storage dei file.
    • Convalida l'OCID nel criterio snapshot di destinazione della proprietà del membro del file system.
    • Verifica che il criterio dello snapshot di destinazione nella proprietà del membro del file system esista e abbia uno stato del ciclo di vita Attivo.
    • Verifica che il vault di destinazione e la chiave di cifratura di destinazione nella proprietà del membro del file system esista e abbia uno stato del ciclo di vita Attivo.
    • Verifica che la chiave di cifratura della destinazione nella proprietà del membro del file system sia una chiave di cifratura AES (Advanced Encryption Standard) simmetrica e disponga dello stato del ciclo di vita Enabled.
  • Stop Drill
    • Verifica la presenza del file system esportato duplicato per il cleanup
    • Verifica la presenza delle esportazioni nel file system esportato duplicato per il cleanup

Controlli preliminari per l'installazione/disinstallazione del file system nell'istanza di computazione:

Full Stack DR esegue innanzitutto i controlli preliminari riportati di seguito per il file system di installazione/disinstallazione nell'istanza di computazione.
  • Convalide per la proprietà del membro dettaglio MOUNT/UNMOUNT:
    • Dettagli del montaggio:
      • Verifica che la destinazione di accesso dei dettagli di accesso corrisponda alla standby region.
      • Verifica che la combinazione di punto di montaggio ed esportazione sia univoca (evitare il montaggio multiplo sullo stesso punto di montaggio).
    • Dettagli disattivazione:
      • Verifica che la destinazione di accesso dei dettagli di disinstallazione corrisponda all'area primaria.
      • Verifica la presenza del percorso di esportazione nella destinazione di accesso dei dettagli di disinstallazione.
    • Verifica che l'istanza di computazione mobile/non mobile e la destinazione di accesso dei dettagli di accesso abbiano l'abilitazione del protocollo TCP/UDP corretta. Vedere Configurazione delle regole di sicurezza VCN per lo storage dei file.
    • Convalida l'istanza di computazione mobile/non mobile. Il gruppo di protezione DR primario deve disporre del file system attivabile o della destinazione di accesso di destinazione deve disporre del percorso di esportazione corretto per l'accesso.
    • Nota

      Per un failover, il controllo riportato di seguito viene eseguito nel passo File system - Esegui MOUNT su istanza di computazione con l'istanza di computazione appena avviata a causa dell'indisponibilità dell'area primaria

    • Verifica che il plugin Comando di esecuzione istanza di computazione sia abilitato per l'istanza di computazione.
    • Verifica che l'istanza di computazione disponga di un accesso root:
    • Solo per il sistema operativo Linux, verifica che nell'istanza di computazione sia installato nfs-client. Per informazioni su come installare nfs-client in Compute, vedere Attivazione dei file system da istanze di stile UNIX.
    • Solo per il sistema operativo Linux, verificare che /etc/fstab nel sistema operativo linux abbia dettagli di MOUNT presenti con l'indirizzo IP della destinazione di MOUNT corretto/Nome dominio completamente qualificato e punto di accesso.
    • Per entrambi i sistemi operativi, verificare che il punto di accesso sia presente nell'istanza di computazione

Controlli preliminari per i gruppi di volumi (storage a blocchi)

Full Stack DR esegue innanzitutto i controlli preliminari seguenti per tutti i gruppi di volumi aggiunti al DRPG principale. Full Stack DR verifica che:
  • Il gruppo di volumi è in stato Available.
  • Il gruppo di volumi dispone di repliche o backup configurati nella standby region. Se entrambi sono configurati, Full Stack DR utilizza le repliche e ignora i backup.
  • Per la riconfigurazione dinamica intraregionale, qualsiasi replica dell'area di destinazione (in standby) non si trova nello stesso dominio di disponibilità (AD).
  • La replica nella standby region è in stato Available o, se vengono utilizzati i backup, almeno un backup esiste ed è Available.
  • La lista dei volumi nel gruppo di volumi di origine corrisponde alla lista dei volumi nella replica o nel backup della standby region.
  • Il criterio di backup della destinazione è un criterio di backup valido.
  • Il vault e la chiave di cifratura forniti nella Chiave di destinazione comune sono entrambi validi.
  • Il vault fornito nella chiave di destinazione comune ha uno stato del ciclo di vita Attivo.
  • La chiave di cifratura fornita nella chiave di destinazione comune dispone di uno stato del ciclo di vita Abilitato
  • Il volume di origine, il vault di destinazione e la chiave di cifratura forniti nei Mapping delle chiavi di cifratura da volume di origine a destinazione sono tutti validi.
  • È stata fornita la chiave di destinazione comune o la chiave di cifratura da volume di origine a destinazione mapping. Non è possibile fornire entrambe le proprietà membro.

Controlli preliminari per il volume a blocchi per le istanze di computazione non mobili

Full Stack DR esegue innanzitutto i controlli preliminari riportati di seguito per il volume a blocchi per le istanze di computazione non mobili.

Se l'istanza di computazione viene aggiunta come membro a un DRPG con il ruolo Principale, eseguire le convalide riportate di seguito per ogni ID volume a blocchi fornito nella nuova lista di proprietà dei membri.
  • L'ID volume a blocchi deve essere un OCID valido di un volume a blocchi.
  • Il volume a blocchi non deve avere duplicati nelle proprietà membro della stessa istanza di computazione.
  • Il volume a blocchi deve essere già collegato all'istanza di computazione.
  • Il volume a blocchi deve far parte di un membro del gruppo di volumi del DRPG.
  • Se nei dettagli del collegamento viene fornito un ID istanza di riferimento collegamento volume, tale istanza deve essere membro del gruppo di protezione DR in standby e l'ID volume a blocchi deve essere aggiunto nelle relative proprietà membro.
  • Se l'ID istanza di riferimento collegamento volume non viene fornito nei dettagli del collegamento, solo un'istanza di computazione nel DRPG in standby deve avere una proprietà membro definita con questo ID volume a blocchi.
  • I punti di attivazione definiti devono essere univoci.
Se l'istanza di computazione viene aggiunta come membro a un DRPG con il ruolo In standby, eseguire le convalide riportate di seguito per ogni ID volume a blocchi fornito nella nuova lista di proprietà dei membri.
  • L'ID volume a blocchi deve essere un OCID valido di un volume a blocchi.
  • Il volume a blocchi non deve avere duplicati nelle proprietà membro della stessa istanza di computazione.
  • Il volume a blocchi deve provenire dall'area del DRPG primario.
  • Il volume a blocchi deve far parte di un membro del gruppo di volumi del DRPG primario.
  • L'AD di destinazione/destinazione del gruppo di volumi (in cui verrà attivato il backup o la replica) deve corrispondere all'AD di questa istanza di computazione in standby.
  • Se nei dettagli del collegamento viene fornito un ID istanza di riferimento collegamento volume, l'istanza peer deve essere un membro del DRPG primario e il volume a blocchi deve essere collegato ad esso.
  • Se nei dettagli del collegamento non viene fornito l'ID istanza di riferimento collegamento volume, solo un'istanza di computazione nel DRPG primario deve disporre del volume a blocchi collegato.
  • I punti di attivazione definiti devono essere univoci.
  • Non è necessario configurare due volumi a blocchi per il collegamento utilizzando uno stesso percorso dispositivo.
  • Se l'allegato utilizza i percorsi dispositivo, i percorsi dispositivo non devono essere in uso.
  • Se un volume a blocchi è configurato per essere collegato a più istanze di computazione, il collegamento deve disporre di un accesso condivisibile.

Controlli preliminari per lo storage degli oggetti con switchover e failover

Full Stack DR esegue i seguenti controlli preliminari per lo storage degli oggetti:

  • Scambia:

    • Bucket di storage degli oggetti - Controllo preliminare Elimina replica (principale)

      • Convalida la presenza del bucket di origine.

      • Verifica la presenza del criterio di replica.

      • Verifica che il criterio di replica si trovi nell'area peer.

    • Bucket di storage degli oggetti - Controllo preliminare impostazione della replica inversa (in standby)

      • Verifica la presenza del bucket di destinazione

      • Convalida la presenza del bucket di origine

  • Failover:

    • Bucket di storage degli oggetti - Controllo preliminare Elimina replica (principale)

      • Verifica che lo stato del bucket di origine sia Attivo.

      • Verifica la presenza del criterio di replica.

      • Verifica che il criterio di replica si trovi nell'area peer.

      • Verifica che lo stato del bucket di destinazione sia Attivo.

    • Bucket di storage degli oggetti - Imposta replica inversa (in standby) - Controllo preliminare (continua in caso di errore)

      • Convalida la presenza del bucket di destinazione.
      • Convalida la presenza del bucket di origine.

Controlli preliminari per il database (Oracle Base Database Service, Oracle Exadata Database Service on Dedicated Infrastructure, Oracle Exadata Database Service on Exascale Infrastructure, Oracle Exadata Database Service on Cloud@Customer)

Full Stack DR esegue i seguenti controlli preliminari se un membro del database (Oracle BaseDatabase Service, Oracle Exadata Database Service on Dedicated Infrastructure, Oracle Exadata Database Service on Exascale Infrastructure, Oracle Exadata Database Service on Cloud@Customer) fa parte del DRPG. Full Stack DR verifica che:
  • Le proprietà dei membri del database non sono vuote o nulle e la posizione del vault segreto password fa parte delle proprietà dei membri del database.
  • È possibile accedere al vault segreto in cui viene memorizzata la password del database e il database peer è in stato Available.
  • Il database e il database peer hanno Data Guard abilitato e sono peer di Data Guard l'uno dell'altro.
  • Il database e il database peer dispongono dei ruoli Data Guard corretti.
  • Il database e il database peer fanno parte dei due gruppi di protezione DR associati che fanno parte della configurazione. Il database primario fa parte del gruppo di protezione DR primario e il database di standby fa parte del gruppo di protezione DR in standby.

Controlli preliminari per Oracle Autonomous Database Serverless

Full Stack DR esegue i controlli preliminari riportati di seguito se un membro Serverless di Autonomous Database fa parte del DRPG. Full Stack DR verifica che:
  • Le proprietà dei membri di Autonomous Database non sono vuote o nulle.
  • L'Autonomous Database primario non dispone di una lista di database di standby vuota.
  • L'Autonomous Database di standby non si trova nella stessa area dell'area del database primario e non è un peer locale.
  • Autonomous Database e Autonomous Database peer fanno parte dei due gruppi di protezione DR associati che fanno parte della configurazione.
  • Remote Data Guard è configurato.
  • Il database peer remoto appartiene al DRPG remoto.
  • Lo stato del ciclo di vita del database primario è AVAILABLE.

    Per i controlli preliminari dello switchover, Full Stack DR esegue le seguenti convalide aggiuntive nel database di standby: verifica che lo stato del database di standby peer remoto sia corretto (STANDBY).

  • Se il vault e la chiave di cifratura forniti nella chiave di cifratura di destinazione sono validi.
  • L'ID vault nella chiave di cifratura della destinazione ha lo stato del ciclo di vita Attivo.
  • Lo stato del ciclo di vita dell'ID di cifratura nella chiave di cifratura della destinazione è Abilitato.

Controlli preliminari per Oracle Autonomous Container Database

Full Stack DR esegue i controlli preliminari riportati di seguito se un membro di Autonomous Container Database fa parte del DRPG. Full Stack DR verifica che:
  • Le proprietà dei membri di Autonomous Container Database non sono vuote o nulle.
  • L'Autonomous Container Database primario non dispone di una lista di database di standby vuota.
  • Autonomous Database e Autonomous Database peer fanno parte dei due gruppi di protezione DR associati che fanno parte della configurazione.
  • Data Guard remoto è configurato.
  • Il database peer remoto appartiene al DRPG remoto.
  • Gli stati del ciclo di vita dell'Autonomous Container Database primario e di standby sono AVAILABLE.

    Per i controlli preliminari dello switchover, Full Stack DR esegue le seguenti convalide aggiuntive nel database di standby: verifica che lo stato del database di standby peer remoto sia corretto (STANDBY).

Controlli preliminari per Kubernetes Engine (OKE)

Full Stack DR esegue i controlli preliminari riportati di seguito per Kubernetes Engine (OKE).

Cluster primario
  1. Controlla la connessione al cluster primario.
  2. Verifica se il backup è più vecchio di un giorno.
  3. Scarica e stampa il log di backup.
  4. Verifica che lo stato del ciclo di vita del cluster OKE primario sia Attivo.
  5. Verifica che lo spazio di nomi e il bucket nelle proprietà dei membri principali esistano e siano validi.
  6. Verifica che la pianificazione del backup nelle proprietà dei membri principali sia nel formato RFC 5545.
    • Convalida la parte della regola non supportata.
    • Convalida l'intervallo per ogni parte della regola.
  7. Convalida il mapping del load balancer nelle proprietà dei membri principali per i vincoli riportati di seguito.
    • SourceLoadBalancerId e DestinationLoadBalancerId hanno OCID di LOADBALANCER.
    • Il mapping del load balancer deve essere univoco.
      • A-B, C-B -> Non consentito
      • A-B, A-D -> Non consentito
        Nota

        Ad esempio, se nell'area primaria si dispone di un set di due load balancer, ad esempio load_balancer_A and load_balancer_C. Hai un altro set di due load balancer nella standby region (ad esempio, load_balancer_B and load_balancer_D). Pertanto, durante l'aggiunta di un cluster OKE come membro, è necessario aggiungere la proprietà dei mapping del load balancer. In questa mappa è consentito solo il mapping seguente: 
        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
        . Tuttavia, i mapping riportati di seguito non sono consentiti poiché load_balancer_B è impostato come load balancer di destinazione in entrambi i mapping. 
        load_balancer_A <--> load_balancer_B & load_balancer_C <--> load_balancer_B
  8. Convalida il mapping del load balancer di rete nelle proprietà dei membri principali per i vincoli riportati di seguito.
    • SourceNetworkLoadBalancerId e DestinationNetworkLoadBalancerId dispongono di OCID di NETWORKLOADBALANCER.
    • Il mapping del load balancer di rete deve essere univoco.
      • A-B, C-B -> Non consentito
      • A-B, A-D -> Non consentito
        Nota

        Ad esempio, se nell'area primaria si dispone di un set di due load balancer di rete, ad esempio network_load_balancer_A and network_load_balancer_C. Hai un altro set di due load balancer di rete nella standby region (ad esempio, network_load_balancer_B and network_load_balancer_D). Pertanto, durante l'aggiunta di un cluster OKE come membro, è necessario aggiungere la proprietà dei mapping del load balancer di rete. In questa mappa è consentito solo il mapping seguente: 
        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. Convalida il mapping del vault nelle proprietà dei membri principali per i vincoli riportati di seguito.
    • SourceVaultId e DestinationVaultId dispongono di OCID VAULT.
    • Il mapping del vault deve essere univoco.
      • A-B, C-B -> Non consentito.
      • A-B, A-D -> Non consentito.
        Nota

        Ad esempio, se nell'area primaria si dispone di un set di due vault, ad esempio vault_A and vault_C. Hai un altro set di due vault nella standby region (ad esempio, vault_B and vault_D). Pertanto, durante l'aggiunta di un cluster OKE come membro, è necessario aggiungere la proprietà dei mapping del vault. In questa mappa è consentito solo il mapping seguente: 
        vault_A  <--> vault_B & vault_C <--> vault_D 
or vault_C <--> vault_B & vault_A <--> vault_D
  10. Verifica che l'ID cluster peer e la posizione di backup nelle proprietà del membro primario non siano vuoti.
  11. Convalida l'host Jump nelle proprietà dei membri principali per i vincoli riportati di seguito.
    • Il gruppo di protezione DR deve contenere un'istanza di computazione con lo stesso OCID dell'host di accesso.
    • L'host Jump deve essere un'istanza di computazione non mobile.
    • Lo stato del ciclo di vita dell'host Jump deve essere RUNNING.
  12. Convalida l'ID cluster peer nelle proprietà dei membri principali per i vincoli riportati di seguito.
    • Verifica che il gruppo di protezione DR peer disponga di un cluster con ID cluster peer.
    • Convalida che il cluster membro stesso non sia stato aggiunto come cluster peer.
    • Verifica che il cluster peer fornito nelle proprietà dei membri non venga aggiunto come cluster peer per l'altro cluster OKE nel gruppo di protezione DR.
  13. Convalida i pool di nodi nel cluster OKE dell'area principale per i vincoli riportati di seguito.
    • Verifica che il conteggio dei nodi in tutti i pool di nodi sia almeno uno.
    • Verifica la presenza di almeno un nodo attivo in tutti i pool di nodi.
    • Esempio: se sono presenti due pool di nodi, un nodo non dispone tuttavia di alcun nodo attivo, un altro ha un nodo attivo, ciò comporterebbe un'eccezione.
  14. Convalida l'ID load balancer di origine nelle proprietà dei membri principali per i vincoli riportati di seguito.
    • Il ciclo di vita deve essere attivo.
    • Il load balancer può avere solo una subnet regionale.
  15. Convalida l'ID load balancer di rete di origine nelle proprietà dei membri principali per i vincoli riportati di seguito.
    • Il ciclo di vita deve essere attivo.
    • Il load balancer di rete può avere solo una subnet regionale.
  16. Verifica che l'ID del vault di origine nelle proprietà dei membri principali sia attivo.
  17. Convalida la configurazione del pool di nodi gestiti nelle proprietà dei membri principali per i vincoli riportati di seguito.
    • Il tipo di membro deve essere MANAGED.
    • Il ciclo di vita deve essere ACTIVE.
    • La somma del conteggio dei nodi ('massimo' nella configurazione dei nodi gestiti o del conteggio dei nodi esistente, a seconda di quale delle due è maggiore) per tutti i pool di nodi nel cluster non deve superare il limite.
  18. Convalida la configurazione del pool di nodi virtuali nelle proprietà dei membri principali per i vincoli riportati di seguito.
    • Il tipo di membro deve essere VIRTUAL.
    • Il ciclo di vita deve essere ACTIVE.
    • La somma del conteggio dei nodi ('massimo' nella configurazione dei nodi virtuali o del conteggio dei nodi esistente, a seconda di quale delle due è maggiore) per tutti i pool di nodi nel cluster non deve superare il limite.

Cluster in standby

  1. Verifica se lo spazio o gli spazi di nomi fanno parte del backup.
  2. Verifica se tutti i volumi a blocchi a cui viene fatto riferimento nei volumi persistenti fanno parte del gruppo di protezione DR.
  3. Verifica se tutti i file system/destinazioni di MOUNT a cui si fa riferimento nei volumi persistenti fanno parte del gruppo di protezione DR.
  4. Verifica se tutti i load balancer a cui viene fatto riferimento nella classe di entrata fanno parte del gruppo di protezione DR.
  5. Verifica se tutti i vault a cui viene fatto riferimento in secretproviderclasses fanno parte del gruppo di protezione DR.
  6. Verifica se le definizioni delle risorse personalizzate sono compatibili con la versione del cluster in standby.
  7. Verifica che lo stato del ciclo di vita del cluster OKE in standby sia attivo.
  8. Verifica che l'ID cluster peer e la posizione di backup nelle proprietà dei membri in standby non siano vuoti.
  9. Convalida l'host Jump nelle proprietà dei membri in standby per i vincoli riportati di seguito.
    • Il gruppo di protezione DR deve contenere un'istanza di computazione con lo stesso OCID dell'host di accesso.
    • L'host Jump deve essere un'istanza di computazione non mobile.
    • Lo stato del ciclo di vita dell'host Jump deve essere RUNNING.
  10. Convalida l'ID cluster peer nelle proprietà dei membri in standby per i vincoli riportati di seguito.
    • Verifica che il gruppo di protezione DR peer disponga di un cluster con ID cluster peer.
    • Verifica che il cluster membro stesso non venga aggiunto come cluster peer.
    • Verifica che il cluster peer fornito nelle proprietà dei membri non venga aggiunto come cluster peer per un altro cluster OKE nel gruppo di protezione DR.
  11. Convalida l'ID load balancer di destinazione nelle proprietà dei membri principali per i vincoli riportati di seguito.
    • Il ciclo di vita deve essere attivo.
    • Il load balancer può avere solo una subnet regionale.
  12. Convalida l'ID load balancer di rete di destinazione nelle proprietà dei membri principali per i vincoli riportati di seguito.
    • Il ciclo di vita deve essere attivo.
    • Il load balancer di rete può avere solo una subnet regionale.
    • Verifica che l'ID del vault di destinazione nelle proprietà dei membri principali sia attivo.
  13. Convalida la configurazione del pool di nodi gestiti nelle proprietà dei membri in standby per i vincoli riportati di seguito.
    • Il tipo di membro deve essere MANAGED.
    • Il ciclo di vita deve essere attivo.
    • La somma del conteggio dei nodi ('massimo' nella configurazione dei nodi gestiti o del conteggio dei nodi esistente, a seconda di quale delle due è maggiore) per tutti i pool di nodi nel cluster non deve superare il limite.
  14. Convalida la configurazione del pool di nodi virtuali nelle proprietà dei membri in standby per i vincoli riportati di seguito.
    • Il tipo di membro deve essere VIRTUAL.
    • Il ciclo di vita deve essere attivo.
    • La somma del conteggio dei nodi ('massimo' nella configurazione dei nodi virtuali o del conteggio dei nodi esistente, a seconda di quale delle due è maggiore) per tutti i pool di nodi nel cluster non deve superare il limite.
  15. Convalida i pool di nodi nel cluster OKE della standby region per i vincoli riportati di seguito.
    • Verifica che il conteggio dei nodi in tutti i pool di nodi sia almeno uno.
    • Verifica la presenza di almeno un nodo attivo in tutti i pool di nodi.
  16. Verifica che il pool di nodi del cluster di destinazione debba disporre di almeno un nodo in ogni dominio AD in cui verrà ripristinato FSS/blocco.
  17. Convalida le regole securityList e NSG definite nel gruppo di sicurezza subnet/rete dei pool di nodi e dei pool di nodi virtuali forniti nel cluster assicurandosi che siano impostate le regole riportate di seguito.
    • Regole di entrata con conservazione dello stato
      • le porte TCP 111, 2048, 2049 e 2050, e
      • Porte UDP 111 e 2048
    • Regole di uscita con conservazione dello stato
      • le porte di origine TCP 111, 2048, 2049 e 2050, e
      • Porta di origine UDP 111.
        Nota

        La convalida è applicabile solo se il cluster OKE dispone di PV o PVC per il file system. Full Stack DR verifica solo i seguenti scenari:
        • Scenario A: la destinazione e l'istanza di accesso si trovano in subnet diverse (consigliato).
        • Scenario B: la destinazione e l'istanza di accesso si trovano nella stessa subnet.
          Full Stack DR non verifica i seguenti scenari:
          • Scenario C: la destinazione di accesso e l'istanza utilizzano la cifratura in transito TLS.
          • Scenario D: la destinazione di accesso utilizza LDAP per l'autorizzazione.

Controlli preliminari per il sistema DB MySQL HeatWave

Full Stack DR esegue i seguenti controlli preliminari per il sistema DB MySQL:

  • Switchover:
    • Verifica che gli stati del ciclo di vita dei sistemi DB MySQL HeatWave primari e in standby siano in stato Attivo.
    • Convalida la presenza del sistema DB di destinazione nel gruppo di protezione DR peer come membro, che dispone anche della proprietà del sistema DB di destinazione corrispondente all'OCID del sistema DB MySQL primario.
    • Verifica che il sistema DB primario MySQL sia in modalità Lettura/Scrittura.
    • Verifica che il sistema DB MySQL di destinazione sia in modalità Sola lettura.
    • Verifica che il segreto vault del sistema DB MySQL primario fornito per l'utente Admin e Replication sia in stato Disponibile.
    • Verifica che il segreto vault del sistema DB MySQL in standby fornito per l'utente Admin e Replication sia in stato Disponibile.
    • Convalida la presenza di un canale attivo tra il sistema DB MySQL primario e il sistema DB MySQL di destinazione.
      Nota

      In caso di guasto, Full Stack DR visualizza un'avvertenza.
    • Convalida la connettività tra l'istanza del contenitore e entrambi i nodi DB MySQL.
    • Verifica che l'esecuzione GTID sia presente sia per i sistemi DB primari che per quelli di destinazione.
  • Failover :
    • Verifica che lo stato del ciclo di vita del sistema DB MySQL in standby sia Attivo.
    • Convalida la presenza del sistema DB di destinazione nel gruppo di protezione DR peer come membro, che dispone anche della proprietà del sistema DB di destinazione corrispondente all'OCID del sistema DB MySQL primario.
    • Verifica che il sistema DB MySQL di destinazione sia in modalità Lettura.
    • Verifica che il segreto vault del sistema DB MySQL in standby fornito per l'utente Admin e Replication sia in stato Disponibile.
    • Convalida la presenza di un canale attivo tra il sistema DB MySQL primario e i sistemi DB MySQL di destinazione.
    • Convalida la connettività tra l'istanza del contenitore ed entrambi i nodi DB MySQL.
    • Convalida la presenza dell'esecuzione GTID sia per i sistemi DB primari che per quelli di destinazione.
  • Startdrill:
    • Verifica che lo stato del ciclo di vita del sistema DB MySQL per il sistema DB primario e in standby sia in stato Attivo.
    • Convalida la presenza del sistema DB di destinazione nel gruppo di protezione DR peer come membro, che dispone anche della proprietà del sistema DB di destinazione che corrisponde all'OCID del sistema DB MySQL primario.
    • Verifica che il sistema DB MySQL primario sia in modalità di lettura/scrittura.
    • Verifica che il sistema DB MySQL di destinazione sia in modalità lettura.
    • Verifica che il backup sia presente nel sistema DB MySQL di destinazione da ripristinare.
    • Convalida la presenza di un canale attivo tra il sistema DB MySQL primario e i sistemi DB MySQL di destinazione.
  • Interrompi drilling:

    Convalida la presenza del database MySQL ripristinato nell'area peer per il cleanup.

Argomento padre: riferimento