Implementare la replica di Oracle Database File System (DBFS)

Questa implementazione consiste nel copiare il contenuto di livello intermedio in una cartella DBFS e fare affidamento su Oracle Data Guard per replicarlo nel sito secondario. I contenuti di livello intermedio non risiedono direttamente su DBFS, perché ciò renderebbe il livello intermedio dipendente dall'infrastruttura DBFS (database, librerie FUSE, punti di accesso e così via). L'accesso DBFS è solo una cartella intermedia per memorizzare una copia del contenuto.

Qualsiasi replica in standby implica due passi in questo modello: dalla cartella di origine del database primario all'accesso DBFS intermedio e quindi, nel sito secondario, dall'accesso DBFS alla cartella di destinazione dello standby. Le copie intermedie vengono eseguite utilizzando rsync. Poiché si tratta di una copia rsync a bassa latenza e locale, alcuni dei problemi che si verificano in un'operazione di copia rsync remota vengono evitati con questo modello.

Nota

Questo metodo non è supportato con Oracle Autonomous Database, che non consente connessioni DBFS.

Descrizione dell'illustrazione repliche-mid-tier-dbfs.png

replica-dbfs-mid-tier-oracle.zip

I vantaggi dell'implementazione della replica di livello intermedio con DBFS sono:

• Questo metodo sfrutta la robustezza della replica di Oracle Data Guard.
• Lo storage di livello intermedio reale può rimanere montato nei nodi secondari. Non sono disponibili passi aggiuntivi per collegare o installare lo storage nel secondario in ogni operazione di switchover o failover.

Di seguito sono riportate alcune considerazioni per l'implementazione della replica di livello intermedio con DBFS.

• Questo metodo richiede un Oracle Database con Oracle Data Guard.
• Gli host di livello intermedio richiedono che il client Oracle Database esegua il MOUNT del DBFS.
• L'uso di DBFS per la replica ha implicazioni dal punto di vista dell'impostazione, dello storage del database e del ciclo di vita. Richiede un'installazione del client Oracle Database negli host di livello intermedio, una certa manutenzione del database (per pulire, comprimere e ridurre lo storage delle tabelle) e una buona comprensione del funzionamento dei punti di accesso DBFS.
• È possibile eseguire il MOUNT delle directory DBFS solo se il database è aperto. Quando Oracle Data Guard non è un Active Data Guard, il database di standby è in stato MOUNT. Pertanto, per accedere all'accesso DBFS nel sito secondario, è necessario convertire il database in standby snapshot. Quando si utilizza Active Data Guard, è possibile eseguire il MOUNT del file system per le letture e non è necessario eseguire la transizione a uno snapshot.
• Non è consigliabile utilizzare DBFS come soluzione generica per replicare tutti gli artifact (in particolare i file runtime) in standby. L'uso di DBFS per replicare i file binari è un overkill. Tuttavia, questo approccio è adatto per replicare alcuni artifact, come la configurazione, quando altri metodi come la replica dello storage o rsync non soddisfano le esigenze del sistema.
• È responsabilità dell'utente creare gli script personalizzati per ciascun ambiente ed eseguirli periodicamente.
• È responsabilità dell'utente implementare un modo per invertire la direzione della replica.

Imposta replica per file system di database

Questa implementazione utilizza la tecnologia rsync e segue il modello peer-to-peer. In questo modello, la copia viene eseguita direttamente tra gli host peer di livello intermedio. Ogni nodo dispone della connettività SSH al peer e utilizza i comandi rsync su SSH per replicare gli artifact del file di livello intermedio primario.

Per implementare la replica di livello intermedio con DBFS, è necessario quanto riportato di seguito.

• Installazione di un client Oracle Database sugli host di livello intermedio che eseguono la copia, sia nel database primario che in quello secondario.
• File system DBFS creato nel database.
• MOUNT DBFS negli host di livello intermedio che eseguono le copie, sia nel database primario che in quello secondario. Questo attiva il file system DBFS del database. Questo file system può essere attivato in più host, poiché DBFS è un file system condivisibile.
• Script che copiano gli artifact di file di livello intermedio nell'accesso DBFS nel sito primario.
• Script che copiano gli artifact di file di livello intermedio dall'accesso DBFS alle cartelle nel sito secondario. A seconda dell'implementazione, questo metodo potrebbe richiedere la connettività SQL*net tra gli host di livello intermedio e il database remoto per le operazioni del database, ad esempio le conversioni dei ruoli.
• Un modo per gestire le informazioni specifiche del sito, escludendo tali informazioni dalla copia o aggiornandole con le informazioni appropriate dopo la replica.
• Pianificare l'esecuzione continua di questi script.
• Meccanismo per modificare la direzione della replica dopo uno switchover o un failover.

Esempio 1: utilizzare DBFS per replicare il dominio Oracle WebLogic

Nota

L'esempio riportato di seguito si applica ai sistemi Oracle WebLogic. È possibile utilizzarlo come riferimento per copiare altre cartelle del sistema di livello intermedio tramite DBFS, ma questo particolare esempio utilizza uno script che replica la cartella di dominio dell'amministratore WebLogic sul secondario tramite DBFS.

Questo esempio mostra come replicare la cartella del dominio dell'host di amministrazione WebLogic tramite DBFS. Il contenuto che si trova all'esterno della cartella del dominio, nonché il contenuto di altri host, non è incluso in questo esempio. La cartella del dominio non risiede direttamente in DBFS; l'accesso DBFS è solo una cartella intermedia in cui memorizzare una copia della cartella del dominio.

In questo esempio viene fornito uno script per eseguire queste azioni, che devono essere eseguite periodicamente nei siti primari e in standby. Questo script copia la cartella del dominio di amministrazione WebLogic, saltando alcuni elementi quali i file tmp, .lck, .state e tnsnames.ora. La procedura consiste di quanto segue:

• Quando lo script viene eseguito sull'host di amministrazione WebLogic del sito primario, lo script copia la cartella del dominio WebLogic nella cartella DBFS.
• I file copiati nel DBFS, così come vengono memorizzati nel database, vengono trasferiti automaticamente al database di standby tramite Oracle Data Guard.
• Quando lo script viene eseguito sull'host di amministrazione WebLogic del sito secondario:
  • Lo script converte il database di standby in uno standby snapshot.
  • Successivamente, esegue il MOUNT del file system DBFS dal database di standby.
  • La cartella del dominio replicato è ora disponibile in questa cartella DBFS. Lo script lo copia dall'accesso DBFS alla cartella del dominio reale.
  • Infine, lo script converte di nuovo il database in standby in standby fisico.
• In caso di modifica del ruolo, lo script adatta automaticamente l'esecuzione al nuovo ruolo. Raccoglie il ruolo effettivo del sito controllando il ruolo del database.

Questo script replica solo la cartella del dominio dell'host di amministrazione WebLogic. Il contenuto della cartella DOMAIN_HOME/config viene copiato automaticamente in tutti gli altri nodi che fanno parte del dominio WebLogic all'avvio dei server gestiti. I file esterni a questa cartella e i file posizionati su altri host non vengono replicati e devono essere sincronizzati separatamente.

Per le operazioni di distribuzione dell'applicazione, utilizzare l'opzione di distribuzione Carica file nella console di amministrazione WebLogic. In questo modo, i file distribuiti vengono posizionati nella directory di caricamento del server di amministrazione ($DOMAIN_HOME/servers/admin_server_name/upload) e lo script di replica di configurazione li sincronizzerà nel sito in standby.

In questo esempio viene fornito un altro script per installare il client DB e configurare un accesso DBFS negli host di livello intermedio. L'immagine è un esempio di sistema Oracle WebLogic Server per OCI con replica DBFS.

Descrizione dell'illustrazione wls-dbfs-replication.png

wls-dbfs-replication-oracle.zip

Per usare il metodo DBFS per replicare il dominio WebLogic, eseguire le operazioni riportate di seguito.

1. Consente la connettività SQL*net tra gli host di amministrazione e i database remoti.
   Oracle consiglia di utilizzare il peering remoto con il gateway di instradamento dinamico. Lo script richiede questa connettività per eseguire le operazioni del database, ad esempio le conversioni dei ruoli. Quando lo script viene eseguito nel sito con ruolo di standby, converte il database di standby in uno standby snapshot per eseguire il MOUNT dell'accesso DBFS.
2. Scaricare gli script.
   Questo documento fornisce script per configurare il MOUNT DBFS e per automatizzare la replica.
   1. Andare al repository Oracle MAA in GitHub. Fare riferimento alla sezione Esplora altri in questo playbook.
   2. Scaricare tutti gli script nella directory app_dr_common.
   3. Scaricare tutti gli script nella directory wls_mp_dr.
   4. Copiarli negli host di amministrazione primari e secondari, in una posizione non replicata.
   5. Gli script effettuano chiamate tra loro. Copiare gli script di entrambe le directory e collocarli nella stessa cartella. Assicurarsi che l'utente oracle disponga dell'autorizzazione di esecuzione.
3. Configurare l'accesso DBFS negli host di amministrazione primario e secondario.

   Nota

   Se si dispone già di un accesso DBFS, è possibile saltare questo passo. Ad esempio, alcuni stack Marketplace SOA sono dotati di un accesso DBFS pronto all'uso.
   Configurare l'accesso DBFS negli host di amministrazione WebLogic primari e secondari. Richiede il client del database e alcuni pacchetti del sistema operativo sull'host di amministrazione WebLogic. Attenersi alla procedura riportata di seguito in ogni host di amministrazione.
   1. Scaricare il client DB dalla consegna elettronica e caricarlo nell'host di livello intermedio (NON installarlo ancora). Cercare Oracle Database Client e selezionare solo il client del database. Fare clic su Continua, quindi selezionare la versione del programma di installazione (non l'immagine finale).

      Nota

      Assicurarsi di scaricare la versione del programma di installazione, non l'installazione basata su immagini. Si consiglia di utilizzare la versione più recente.
      Ad esempio, scaricare il file 982064-01.zip per Oracle Database Client 19.3.0.0.0 per Linux x86-64, 1,1 GB e caricarlo in /u01/install/V982064-01.zip su tutti gli host di livello intermedio.

      NON installarlo ancora.

   2. Individuare lo script dbfs_dr_setup_root.sh nella cartella app_dr_common.
      Questo script esegue i task per preparare l'accesso DBFS nell'host. Installa il client di database e i pacchetti del sistema operativo necessari, configura l'utente e lo schema DBFS nel database, attiva il file system DBFS e crea un file system cron, quindi il file system DBFS viene attivato al boot host.
   3. Eseguire lo script come utente root.
      La sintassi è la seguente:

      ./dbfs_dr_setup_root.sh  local_db_scan_name db_port  local_PDB_service pdb_sys_password path_to_dbclient_installer

      Come parametri di input, fornire i dati di connessione utilizzati per connettersi al database locale utilizzato da WLS: fornire i dati di connessione PDB primaria quando vengono eseguiti nell'host di amministrazione del sito primario e fornire i dati di connessione PDB secondari quando vengono eseguiti nell'host di amministrazione secondario.

      Nota

      Il database di standby deve essere in modalità standby snapshot per eseguire questo script nell'host di amministrazione secondario.
      Nell'esempio seguente viene eseguito l'host di amministrazione di livello intermedio principale. Deve essere una singola riga ed è necessario fornire i valori PDB primari e la password:

      ./dbfs_dr_setup_root.sh  drdba-scan.wlsdrvcnlon1ad2.wlsdrvcnlon1.oraclevcn.com 1521 mypdbservice.example.com  mypassword   /u01/install/V982064-01.zip

      Nell'esempio seguente viene eseguito l'host di amministrazione di livello intermedio secondario. Deve essere una singola riga ed è necessario fornire i valori PDB primari e la password:

      ./dbfs_dr_setup_root.sh  drdbb-scan.wlsdrvcnfra1ad2.wlsdrvcnfra1.oraclevcn.com 1521 mypdbservice.example.com  mypassword   /u01/install/V982064-01.zip

      Come risultato dell'esecuzione di questo script, si ottiene quanto segue:

      Artifact	Valore	Descrizione
      Home client database	/u01/app/oracle/client	Lo script installa il software client del database nell'host. Inoltre, utilizza yum per installare i pacchetti richiesti.
      Utente database	Nome: dbfsuser Password: uguale a sys	Utente nel database PDB per DBFS.
      Tablespace DBFS	tbsdbfs	Tablespace nel PDB per l'accesso DBFS.
      Cartella DBFS	dbfsdir	La cartella DBFS nella tablespace.
      Una cartella nell'host di livello intermedio	DOMAIN_HOME/dbfs	Contiene il wallet che memorizza l'utente, la password e altri artifact (tnsnames.ora, sqlnet.ora) richiesti dal client di database per eseguire il MOUNT del DBFS nell'host.
      Script nell'host di livello intermedio	DOMAIN_HOME/dbfs/dbfsMount.sh	Script per il MOUNT del file system DBFS nell'host. Questo script viene aggiunto a cron al reboot, quindi viene eseguito al reboot del sistema.
      Punto di attivazione nell'host di livello intermedio	/u02/data/dbfs_root	Il file system DBFS viene attivato nel punto di attivazione /u02/data/dbfs_root come cartella dbfsdir.

      È possibile eseguire di nuovo lo script, ma si riceveranno avvertenze perché alcuni elementi sono già stati creati (utente DB, tablespace e così via). Questi messaggi possono essere ignorati.

   4. Verificare che l'accesso DBFS sia presente nell'host di amministrazione di livello intermedio.

      [root@ prefix-wls-1]# df -h | grep dbfs
      dbfs-@PDB1:/     32G  248K   32G   1% /u02/data/dbfs_root
      [root@ prefix-wls-1]# ls /u02/data/dbfs_root
      dbfsdir

      Questo file system DBFS viene utilizzato come file system di assistenza per memorizzare una copia della configurazione del dominio del sito principale.
4. Preparare lo script di replica.
   Questo documento fornisce uno script di riferimento per questa implementazione, lo script config_replica.sh.
   1. Nell'host di amministrazione Oracle WebLogic primario aprire lo script config_replica.sh. Modificare le sezioni dei parametri personalizzabili.
      Assicurarsi di fornire le variabili appropriate per il database primario. Nella proprietà DR_METHOD utilizzare DBFS.
   2. Fai lo stesso nell'host di amministrazione Oracle WebLogic secondario. Assicurarsi di fornire le variabili appropriate per il secondario.
5. Eseguire lo script di replica.
   1. Come utente oracle, eseguire lo script config_replica.sh nell'host di amministrazione Oracle WebLogic primario.
      Lo script verificherà il ruolo del sito corrente e copierà la configurazione del dominio dal dominio Oracle WebLogic Server primario all'accesso DBFS.
   2. Monitorare l'esecuzione e controllare eventuali errori.
   3. Una volta completato, eseguire lo script config_replica.sh nell'host Oracle WebLogic Administration Server del sito secondario.
      Assicurarsi di utilizzare i valori appropriati nei parametri personalizzati. Lo script verificherà il ruolo del database. Poiché si tratta del database in standby, la configurazione del dominio verrà copiata dal file system dell'area intermedia secondaria al dominio Oracle WebLogic Server secondario.

   Nota

   Questo script deve sempre essere eseguito sia in database primario che in standby per eseguire una replica completa: prima sul database primario per copiare il dominio nella cartella DBFS, quindi sullo standby per copiare il dominio dal DBFS alla cartella del dominio. La frequenza dipende dalla frequenza di esecuzione delle modifiche alla configurazione nel dominio Oracle WebLogic Server.

Convalida replica per file system di database

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).

In questa implementazione, lo storage è sempre disponibile in standby; non è necessario collegare o montare alcun volume. L'unica azione necessaria è assicurarsi che contenga la versione più recente del contenuto.

Per utilizzare i contenuti replicati in standby, eseguire le operazioni riportate di seguito.

1. Eseguire una replica.
   Eseguire gli script di replica per rendere disponibile il contenuto più recente nel sistema secondario.
2. Disabilitare le repliche pianificate.
   Al termine dell'ultima replica, disabilitare uno script di replica. In caso contrario potrebbe interferire con la procedura di switchover, failover o di convalida. Lo si abiliterà nuovamente dopo l'operazione, nella direzione appropriata.

Esegui replica continua per file system di database

Eseguire periodicamente lo script di replica per mantenere sincronizzato il dominio secondario con quello primario.

Seguire questi suggerimenti quando si utilizza rsync dagli host di livello intermedio:

• Utilizzare il crontab del sistema operativo o un altro strumento di pianificazione per pianificare la replica. Deve consentire agli script di completare la replica. In caso contrario, i job successivi potrebbero sovrapporsi.
• Mantenere i processi di livello intermedio arrestati nel sito in standby. Se i server sono attivi nel sito in standby durante la replica delle modifiche, le modifiche diventeranno effettive al successivo avvio. Avviarli solo durante la convalida del sito in standby o durante la procedura di switchover o failover.
• Gestire le informazioni specifiche di ciascun sito e tenerle aggiornate. Ad esempio, saltare il file tnsnames.ora dalla copia in modo che ogni sistema disponga dei relativi dettagli di connettività. Se si esegue una modifica nel file tnsnames.ora nel file primario (ad esempio, aggiungendo un nuovo alias), aggiornare manualmente il file tnsnames.ora nel file secondario.
• Dopo uno switchover o un failover, invertire la direzione della replica. Dipende dall'implementazione specifica. Gli script possono utilizzare un controllo dinamico per identificare chi è il sito attivo oppure è possibile eseguire una modifica manuale dopo uno switchover o un failover (ad esempio, disabilitando e abilitando gli script appropriati). Nell'esempio fornito, lo script config_replica.sh adatta automaticamente l'esecuzione al ruolo effettivo del sito controllando il ruolo del database locale.