Implementa OCI File Storage Replication

Questa implementazione utilizza la funzione di replica Oracle Cloud Infrastructure File Storage, che fornisce una replica tra più aree automatizzata per i file system OCI File Storage.

Di seguito sono riportati i vantaggi dell'implementazione della replica OCI File Storage.

• Non è necessario creare ed eseguire script periodicamente, come in altri casi di replica. Una volta impostata, la replica viene eseguita automaticamente da Oracle Cloud Infrastructure.
• Si tratta di una soluzione di uso generale applicabile a qualsiasi file system OCI File Storage attivato da qualsiasi sistema di livello intermedio. Se si dispone di più sistemi che utilizzano OCI File Storage, è possibile utilizzare lo stesso approccio in tutti i sistemi.
• Le informazioni sul file system replicato sono una copia esatta del file system primario; tutti i file del file system vengono replicati.

Di seguito sono riportate le considerazioni sull'implementazione di OCI File Storage.

• Richiede la procedura per eseguire il MOUNT dello storage di file OCI replicato nel sistema secondario. Non è possibile attivare direttamente i file system di destinazione; è necessario prima clonarli e quindi attivare il file system clonato. Tuttavia, puoi superare questa complessità utilizzando il servizio OCI Full Stack Disaster Recovery per automatizzare questi passaggi nelle operazioni di switchover, failover e convalida.
• Questa tecnologia potrebbe non essere sufficiente per molti sistemi. Se il sistema dispone di più tipi di storage (ad esempio, volumi a blocchi), sarà necessario utilizzare una tecnologia di replica diversa.

Impostare la replica per OCI File Storage

Per implementare la replica di OCI File Storage, sono necessari i passi riportati di seguito.

• Utilizzare OCI Console per creare i file system OCI di destinazione nel sito secondario.
• Abilitare la replica nei file system OCI primari, puntando al file system OCI di destinazione appropriato.
• Connettersi agli host di livello intermedio dell'area secondaria e disattivare il file system che verrà replicato da quello primario.
• Utilizzando l'interfaccia utente di OCI Console, scollegare ed eliminare i file system OCI che verranno replicati dal database primario.
• Implementare un modo per gestire le informazioni specifiche del sito aggiornandole con le informazioni appropriate dopo la replica.

Esempio 1: utilizzare la replica dello storage di file OCI per replicare la configurazione e il runtime di livello intermedio

Nota

Questo esempio si applica a qualsiasi sistema di livello intermedio. Come riferimento, utilizza un sistema Oracle WebLogic Server che segue le procedure ottimali di Oracle Fusion Middleware Enterprise Deployment Guide. Questo sistema dispone di due file system OCI File Storage: uno per la configurazione condivisa (dominio di amministrazione WebLogic, keystore e così via) e l'altro per i dati di runtime. Tuttavia, puoi seguire gli stessi passi per replicare qualsiasi file system OCI File Storage di livello intermedio.

Per impostare la replica tra più aree per i file system Storage di file OCI, eseguire le operazioni riportate di seguito.

1. Eseguire il backup delle informazioni specifiche per ciascun sito.
   Il file system può contenere file con informazioni specifiche per ciascun sito, ad esempio stringhe di connessione ai database o ai server LDAP. Quando si utilizza la replica OCI File Storage, il file system replicato è una copia esatta del file primario. Non è possibile saltare file o cartelle specifici dalla replica. Quindi, è necessario gestire queste differenze adattando le informazioni su ogni sito. Esistono diversi approcci:

   • È possibile eseguire una ricerca e una sostituzione di stringhe nei file con informazioni specifiche del sito.
   • È possibile eseguire il backup di queste informazioni prima della replica e ripristinarle successivamente.

   A questo punto, prima di abilitare la replica, identificare ed eseguire il backup di qualsiasi file con informazioni specifiche del sito nei volumi a blocchi replicati. Eseguire la copia di backup in una posizione non sotto il volume a blocchi replicato; in caso contrario, verrà eseguito l'override della copia.

   Suggerimento

   Esempio di Oracle WebLogic

   Ad esempio, quando si replica un file system che contiene un dominio WebLogic, sono disponibili file con informazioni per la connessione al database. Queste informazioni si trovano nella cartella di amministrazione TNS. Controllare la proprietà tns_admin nelle origini dati WebLogic per identificare la cartella. Questo documento fornisce script per gestire questo problema, seguendo l'approccio appropriato a seconda dello scenario:

   • Se il sistema si connette a Oracle Base Database Service o Oracle Exadata Database Service, è possibile aggiornare la stringa di connessione al database nel file tnsnames.ora del sistema di livello intermedio secondario durante le operazioni di switchover e failover. Questo documento fornisce uno script di esempio.
   • Se il sistema si connette a un Autonomous Database, la cartella di amministrazione TNS contiene più artifact (un truststore e un keystore). Sono diversi nel database primario e in standby e non possono essere aggiornati con una semplice sostituzione di stringhe. Questo documento fornisce uno script che ripristina la copia di backup della cartella TNS.

   A questo punto, è sufficiente eseguire un backup delle informazioni sulla cartella TNS.

2. Identificare le informazioni dei file system OCI File Storage sul sito principale.
   • Per i file system OCI File Storage che verranno replicati, identificare i nomi, le destinazioni di accesso, le esportazioni e i punti di accesso degli host di livello intermedio principali.
   • Andare alla Console OCI, selezionare l'area principale, quindi scegliere il compartimento.
   • Passare a Storage, Storage di file, quindi File system e identificare i file system.
   • Salvare il nome, l'esportazione, la destinazione di MOUNT e l'AD in cui si trovano.

   Identificare l'host che esegue l'installazione delle esportazioni e dei punti di attivazione controllando il file /etc/fstab degli host.

   Suggerimento

   Esempio di Oracle WebLogic

   Ad esempio, in un sistema Oracle WebLogic Server che segue Enterprise Deployment Guide:

   File system OCI	Destinazione di accesso	Percorso di esportazione	DC	Host e punti di accesso
   configFS	mt1_region1	/exports/configFS	AD1	apphost1, /u01/oracle/config apphost2, /u01/oracle/config
   runtimeFS	mt1_region1	/exports/runtimeFS	AD1	apphost1, /u01/oracle/runtime apphost2,/u01/oracle/runtime

3. Identificare le informazioni dei file system OCI File Storage sul sito secondario.
   Ripetere i passaggi descritti nel passaggio precedente per raccogliere le stesse informazioni sul sito secondario.

   Suggerimento

   Esempio di Oracle WebLogic

   Ad esempio, in un sistema WebLogic che segue Enterprise Deployment Guide:

   File system OCI	Destinazione di accesso	Percorso di esportazione	DC	Host e punti di accesso
   configFS	mt1_region2	/exports/configFS	AD1	apphost1, /u01/oracle/config apphost2, /u01/oracle/config
   runtimeFS	mt1_region2	/exports/runtimeFS	AD1	apphost1, /u01/oracle/runtime apphost2, /u01/oracle/runtime

4. Disattivare i file system OCI File Storage originali dagli host di livello intermedio secondari.
   Per ciascun host di livello intermedio nel secondario, disattivare i file system che verranno replicati dal database primario. Ad esempio:

   [opc@host ~]$ sudo umount  /u01/oracle/config
   [opc@host ~]$ sudo umount  /u01/oracle/runtime

   Accertarsi che non siano in esecuzione processi oracle; in caso contrario, la disinstallazione non riuscirà. Ripetere questi passi in tutti i nodi di livello intermedio nel secondario.

   Non rimuovere le voci dal file /etc/fstab per queste attivazioni. Se si utilizzano sempre gli stessi valori per la destinazione di accesso e i nomi di esportazione per il file system replicato, le voci saranno valide durante l'intero ciclo di vita.

5. Eliminare o rinominare i file system OCI File Storage originali nel sistema secondario.
   Solo un file system che non è mai stato esportato può essere impostato come file system di destinazione per la replica archiviazione di file OCI. Pertanto, i file system originali montati sugli host di livello intermedio secondari non possono essere utilizzati come destinazione di replica. Non verranno più utilizzati; eliminarli ora (o rinominarli ed eliminarli in seguito), rimuovendo l'esportazione e terminando il file system.

   Nota

   NON eliminare le destinazioni di accesso. Verranno utilizzati per esportare i file system replicati.
6. Abilitare la replica nei file system primari.
   Nel database primario, abilitare la replica per ogni file system OCI File Storage che deve essere replicato.
   1. Andare alla Console OCI, selezionare l'area principale e scegliere il compartimento.
   2. Selezionare Memorizzazione, Storage di file, quindi File system.
   3. Fare clic sul nome del file system, andare a Repliche e fare clic su Crea replica.
      Fornire un nome per la replica.
   4. Selezionare Crea nuovo file system di destinazione e fornire i dettagli riportati di seguito.
      • Nome: il nome della replica del file system che verrà creata nell'area secondaria. Utilizzare un nome che lo identifichi chiaramente come replica, ad esempio configFS_replica.
      • Area target: l'area del sistema secondario.
      • Dominio di disponibilità: dominio di disponibilità per il file system di destinazione. Deve essere uguale alla destinazione di accesso che la esporterà.
      • Compartimento: il compartimento per il file system di destinazione.
      • Intervallo in minuti che determina la frequenza di replica dei dati.

   Nota

   In alternativa, è possibile creare i file system di destinazione in anticipo in modalità secondaria e fornire l'OCID qui.
7. Se necessario, preparare gli script per sostituire le informazioni specifiche di ciascun sito.

   Questa azione si applica solo quando il file system Memorizzazione file OCI contiene informazioni specifiche per ciascun sito. Altrimenti, non è richiesta alcuna azione.

   Creare script per sostituire le informazioni del sito locale, in base ai requisiti specifici (ad esempio, eseguire una ricerca e sostituire o ripristinare una copia di backup dei dati specifici del sito). Assicurarsi di memorizzare questi script in una cartella NON replicata.

   IMPORTANTE. A questo punto non eseguire gli script. Lo script verrà utilizzato la prossima volta che viene eseguita una convalida, uno switchover o un failover.

   Suggerimento

   Esempio di Oracle WebLogic

   Ad esempio, quando si replica un file system che contiene un dominio Oracle WebLogic. Durante uno switchover o un failover, è necessario eseguire un'operazione di sostituzione nella configurazione replicata per puntare al database locale. Questo documento fornisce alcuni script di esempio per automatizzare questa sostituzione.

   Tipo di database	Script di sostituzione e passi di download	Prepara passi
   Oracle Base Database Service o Oracle Exadata Database Service	replacement_script_BVmodel.sh Vai al repository di Oracle MAA in GitHub all'indirizzo https://github.com/oracle-samples/maa Scaricare tutti gli script nella directory wls_mp_dr. Lo script si trova nella cartella wls_mp_dr/Block_Volume_Replica_Method Copiare in tutti gli host di livello intermedio.	Questo script sostituisce le stringhe di connessione al database. Pulisce anche i file di stato dei server WebLogic (.lck e .state) per un avvio pulito. Modificarlo e personalizzarlo in ogni host con i valori appropriati, fornendo i valori locali e remoti per il database in ogni sito. Si noti che i valori sono diversi a seconda del sito. Quando lo si personalizza negli host site1, i valori "LOCAL" si riferiscono ai valori di site1 e i valori "REMOTE" si riferiscono ai valori di site2. Quando si personalizza lo script negli host site2, i valori "LOCAL" fanno riferimento ai valori site2 e "REMOTE" a site1. Andare al repository MAA Oracle in GitHub https://github.com/oracle-samples/maa Scaricare tutti gli script nella directory app_dr_common. Scaricare tutti gli script nella directory fmw-wls-with-adb-dr. Copiare in tutti gli host di livello intermedio. Gli script fanno chiamate l'uno all'altro. Inserire tutti gli script di entrambe le directory nella stessa cartella.
   Oracle Autonomous Database	fmwadb_switch_db_conn.sh Vai al repository Oracle MAA in GitHub https://github.com/oracle-samples/maa Scaricare tutti gli script nella directory app_dr_common. Scaricare tutti gli script nella directory fmw-wls-with-adb-dr. Copiare in tutti gli host di livello intermedio. Gli script fanno chiamate l'uno all'altro. Inserire tutti gli script di entrambe le directory nella stessa cartella.	Questo script sostituisce la cartella di amministrazione TNS utilizzata da Oracle WebLogic Server con quella fornita come input. Inoltre, aggiorna le proprietà della password del wallet nelle origini dati. Non è necessario modificare lo script. I valori della cartella e della password verranno passati come input. Per eseguire uno script, procedere come segue. ./fmwadb_switch_db_conn.sh WALLET_DIR WALLET_PASSWORD Dove WALLET_DIR è una cartella che contiene i file tnsnames.ora, keystore e truststore per connettersi al database locale. Assicurarsi che la cartella WALLET_DIR non venga sostituita nella replica. Non eseguire lo script in questo momento.

La replica del file system OCI è ora pronta.

Convalida replica per OCI File Storage

In un'operazione di switchover o failover, le informazioni replicate devono essere disponibili e utilizzabili nel sito in standby prima dell'avvio dei processi. Questa operazione è necessaria anche quando si convalida il sistema secondario (aprendo il database di standby in modalità snapshot).

Per rendere disponibili e utilizzabili i file system OCI File Storage replicati nel sistema in standby, eseguire le azioni riportate di seguito per ogni file system.

Eseguire le operazioni riportate di seguito per utilizzare i file system replicati in standby.

1. Creare una clone del file system di destinazione.
   Non è possibile attivare direttamente un file system di destinazione, è necessario prima duplicarlo.
   1. In secondario, passare a Memorizzazione, Storage di file, quindi a File system.
   2. Fare clic sul nome del file system di destinazione.
   3. Nella sezione Replica di Informazioni sul file system, fare clic sul collegamento del nome Destinazione di replica.
   4. Fare clic sul collegamento del nome dell'ultimo snapshot.
   5. Fare clic su Duplica per creare un file system normale da questa istantanea.
   6. Modificare i dettagli per fornire un nome per la copia.
      Per garantire la coerenza, utilizzare lo stesso nome usato in Primary, ad esempio configFS.
2. Creare un'esportazione per il file system clonato.
   1. Nel file system clonato andare a Esporta.
   2. Selezionare la destinazione di accesso nella destinazione secondaria.
   3. Selezionare il nome dell'esportazione.
      Per facilitare la gestione dello switchover, utilizzare lo stesso nome dell'esportazione nel database primario. Ad esempio: /exports/configFS.
3. Attivare il file system dagli host in standby.
   1. Se si utilizza sempre lo stesso nome di esportazione e la stessa destinazione di accesso per il file system, la voce nel file /etc/fstab per l'accesso non cambia durante il ciclo di vita.
   2. Se non si utilizza lo stesso nome di esportazione e la stessa destinazione di accesso per il file system, è necessario modificare il file /etc/fstab e la voce in ogni switchover, failover e convalida.
      Di seguito è riportato un esempio della voce /etc/fstab.

      10.1.80.131:/exports/configFS    /u01/oracle/config  nfs  defaults,nofail,nosuid,resvport 0 0

   3. Quando il file /etc/fstab contiene la voce di attivazione appropriata, attivare il file system nell'host.
      Ad esempio:

      [opc@host opc]# sudo mount -a

   4. Ripetere l'operazione in tutti gli host in standby che eseguono il MOUNT del file system.
4. Eseguire lo script di sostituzione su tutti gli host di livello intermedio in standby per sostituire le informazioni specifiche del sito negli host di livello intermedio secondari.

   Suggerimento

   Esempio di Oracle WebLogic

   Ad esempio, in un file system che contiene il dominio Oracle WebLogic, aggiornare le informazioni di connessione al database per puntare al database locale eseguendo lo script di sostituzione su tutti gli host di livello intermedio in standby.

   • Se il sistema utilizza Oracle Base Database Service o Oracle Exadata Database Service, lo script è replacement_script_BVmodel.sh. Assicurarsi che utilizzi i valori appropriati.
   • Se il sistema utilizza Oracle Autonomous Database, lo script è fmwadb_switch_db_conn.sh. Richiede, come input, il percorso in cui si trova il wallet originale secondario e la password del wallet.
5. Eseguire il cleanup dei file di lock dei server.

   Il file system replicato può contenere file di lock del processo di livello intermedio, poiché la replica viene eseguita mentre i processi primari sono attivi. Prima di avviare i processi secondari, potrebbe essere necessario eseguire il cleanup di questi file. In caso contrario, possono impedire l'avvio dei processi di livello intermedio.

   Suggerimento

   Esempio di Oracle WebLogic

   Ad esempio, in un file system che contiene un dominio Oracle WebLogic possono essere presenti file .lck, .pid o .state nelle cartelle ${DOMAIN_HOME}/servers/*/data/nodemanager riportate dal database primario. Assicurarsi che questi file vengano puliti prima di tentare di avviare Node Manager e i server. Ad esempio:

   rm -f ${DOMAIN_HOME}/servers/*/data/nodemanager/*.lck
   rm -f ${DOMAIN_HOME}/servers/*/data/nodemanager/*.state
   rm -f ${DOMAIN_HOME}/servers/*/data/nodemanager/*.pid

   È possibile includere questa azione negli script di sostituzione o come passo precedente nell'avvio di Oracle WebLogic.

6. Quando l'operazione di switchover o failover è terminata, è necessario disinstallare ed eliminare i file system di OCI File Storage nel sito con il ruolo di standby. Eseguire le operazioni riportate di seguito per tornare al ruolo in standby.
   Questa operazione è necessaria anche quando è stata completata una convalida nel sito in standby (aprendo il database in standby in modalità snapshot) e si desidera ripristinarlo al ruolo in standby.
   1. Disattivare il file system di archiviazione di file OCI nel sito in standby replicato dal database primario.
      Ad esempio:

      [opc@host opc]# sudo umount /u01/oracle/config

   2. Eliminare i file system non attivati.
      Arrestare i file system disinstallati nel sito in standby. Non sono più utilizzati.

Esegui replica continua per OCI File Storage

Seguire questi suggerimenti per la replica in corso quando si utilizza questa implementazione.

• OCI esegue automaticamente la replica OCI File Storage in background. L'unica cosa che devi fare durante il ciclo di vita è assicurarsi che i file system OCI File Storage del database primario abbiano la replica abilitata.
• Prendi in considerazione l'utilizzo di OCI Full Stack Disaster Recovery per automatizzare le attività di switchover e failover. Offre la possibilità di eseguire un piano di switchover o failover con un solo clic utilizzando OCI Console. È molto utile semplificare l'esecuzione dei task correlati alla replica di archiviazione di file OCI.
• La funzione di replica è complementare alla funzione snapshot, non una sostituzione. Assicurarsi di allegare un criterio snapshot anche per i file system di OCI File Storage. Ciò fornirà la protezione dei dati oltre alla replica tra più aree, consentendo di ripristinare un file system in un point-in-time.
• Gestire le informazioni specifiche di ciascun sito e tenerle aggiornate. Ad esempio, se il file system contiene una cartella con gli artifact per connettersi a un Autonomous Database, gestire una copia di backup di questa cartella. Assicurarsi di aggiornare il backup della cartella quando si esegue un aggiornamento nel wallet. In questo modo, verrà ripristinato correttamente nello switchover e nei failover successivi.
• After a switchover or a failover operation, cleanup the unused file systems and change the replica direction. Queste azioni sono necessarie per invertire la direzione della replica:
  1. Disabilitare la replica precedente dal precedente database primario ed eseguire il cleanup (eliminazione) dei file system di destinazione non utilizzati nel nuovo database primario.
  2. Abilitare la replica nei file system OCI File Storage del nuovo database primario.
  3. Eliminare i file system non utilizzati nel nuovo standby.