Implementare rsync con una posizione intermedia centrale

Questa implementazione utilizza la tecnologia rsync e segue il modello in base a una posizione intermedia centrale. In questo modello, esiste un nodo host bastion che funge da coordinatore. Si connette a ogni host che deve essere replicato e copia il contenuto in una posizione intermedia comune.

I vantaggi dell'implementazione di rsync con una posizione di staging centrale sono:

• Si tratta di una soluzione di uso generale applicabile a qualsiasi livello intermedio, quindi se hai più sistemi, puoi utilizzare lo stesso approccio in tutti loro.
• Non dipende dal tipo di storage di base; è valido per la replica degli artifact di file che risiedono nei volumi a blocchi, in NFS e così via.
• Lo storage può rimanere installato nei nodi secondari. Pertanto, non richiede passaggi aggiuntivi per collegare o montare lo storage nel secondario in ogni operazione di switchover o failover.
• Rispetto all'implementazione peer-to-peer, la manutenzione è più semplice, poiché esiste un nodo centrale per l'esecuzione degli script.

Di seguito sono riportate le considerazioni per l'implementazione di rsync con una posizione intermedia centrale.

• È 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.
• Questo modello richiede un host e uno storage aggiuntivi per la posizione intermedia centrale.

Analogamente al modello peer-to-peer, gli script rsync possono utilizzare un modello pull o push. Nel modello "pull", lo script copia i file dal nodo remoto al nodo locale. Nel modello "push", lo script copia il file dal nodo locale al nodo remoto. Oracle consiglia di utilizzare un modello pull per recuperare il contenuto dagli host primari, in quanto scarica i nodi primari dal sovraccarico delle copie.

Imposta replica per rsync con area intermedia centrale

Per implementare rsync con una posizione intermedia centrale, è necessario quanto riportato di seguito.

• Host bastion con connettività SSH a tutti gli host (sia primari che secondari).
• Cartella intermedia nell'host bastion, con spazio sufficiente per memorizzare i contenuti del file system di livello intermedio replicati.
• Script che utilizzano rsync per copiare gli artifact di file di livello intermedio da e in questa cartella intermedia. Gli script rsync possono saltare determinate cartelle dalla copia (come file di lock, log, file temporanei e così via).
• 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 periodica di questi script.
• Meccanismo per modificare la direzione della replica dopo uno switchover o un failover. Questo meccanismo può essere un controllo dinamico che identifica il ruolo del sito, o una modifica manuale dopo uno switchover o un failover (ad esempio, disabilitazione e abilitazione degli script appropriati).

Questo documento presenta due diversi esempi di implementazione di questo modello:

• Esempio 1: utilizzare gli script Oracle Fusion Middleware Disaster Recovery Guide
• Esempio 2: utilizzo del framework WLS-HYDR

Esempio 1: utilizzare gli script di Oracle Fusion Middleware Disaster Recovery Guide

Nota

Questo esempio si applica a qualsiasi sistema di livello intermedio. A titolo di riferimento, utilizza gli script forniti dal manuale Oracle Fusion Middleware Disaster Recovery Guide per eseguire la replica di livello intermedio per un sistema DR Oracle WebLogic: rsync_for_WLS.sh e rsync_copy_and_validate.sh. Tuttavia, questi script sono generalmente applicabili e offrono sufficiente flessibilità per sincronizzare gli artifact del file system di livello intermedio in OCI.

Il manuale Oracle Fusion Middleware Disaster Recovery Guide fornisce gli script rsync per eseguire copie remote in un sistema di livello intermedio. Questi script sono validi per qualsiasi modello rsync. Questo esempio mostra come utilizzarli per il modello di area intermedia centrale. Questa implementazione utilizza le operazioni pull in due fasi:

• Un host bastion estrae i contenuti da tutti gli host principali e li memorizza nell'area intermedia centrale.
• Quindi, tutti i nodi secondari eseguono un'operazione di pull per raccogliere il contenuto dallo staging centrale.

Per impostare la replica di livello intermedio con questi script, vedere Replicating the Primary File Systems to the Secondary Site nel manuale Oracle Fusion Middleware Disaster Recovery Guide, la sezione Rsync Replication Approach e, in particolare, i passi Using a Staging Location.

Descrizione dell'illustrazione repliche-rsync-scripts.png

replica-rsync-scripts-oracle.zip

Esempio 2: utilizzo del framework WLS-HYDR

Nota

Questo esempio si applica a un sistema Oracle WebLogic Server. Utilizza il modulo di replica del framework WLS-HYDR, ma si applica a qualsiasi ambiente DR di Oracle WebLogic Server, indipendentemente dal fatto che sia stato creato con il framework WLS-HYDR o meno.

In questo modello, un nodo host centrale funge da coordinatore totale, eseguendo operazioni pull e push. Si connette a ogni host che deve essere replicato e copia il contenuto in una posizione intermedia comune. Questo nodo coordina anche la copia dalla posizione intermedia agli host di destinazione. Questo approccio scarica i singoli nodi dal sovraccarico delle copie.

La struttura WLS-HYDR utilizza questo approccio per la copia iniziale durante l'impostazione di DR. Quindi, è possibile riutilizzare il modulo di replica del framework per ripetere il pull e il push periodicamente. Fare riferimento a Scopri di più in questo playbook per i collegamenti al framework WLS-HYDR e ad altre risorse.

Il nodo bastion esegue la replica in due passi:

• Operazione pull, in cui si connette agli host primari e copia il contenuto del file system in una cartella intermedia nell'host bastion.
• Operazione push, in cui il contenuto viene copiato dalla cartella intermedia del bastion in tutti gli host secondari.

Un nodo centrale esegue tutte le operazioni, quindi la pianificazione, i log, la manutenzione e così via sono centralizzati su quel nodo. Quando il sistema ha molti nodi, questo è più efficiente rispetto al modello peer-to-peer o all'esempio precedente.

Descrizione dell'illustrazione replica-wls-hydr-framework.png

replica-wls-hydr-framework-oracle.zip

Se è stata utilizzata la struttura WLS-HYDR per la creazione del sistema secondario, l'host bastion è già pronto per eseguire la replica. In caso contrario, è possibile configurarlo a questo punto. Per configurare la replica, effettuare le operazioni riportate di seguito.

1. Preparare il bastione.

   Se è stata utilizzata la struttura WLS-HYDR per la creazione del sistema secondario, l'host bastion è già pronto per eseguire la replica. In caso contrario, controllare il README nel repository GitHub del framework WLS-HYDR per preparare un bastion host.

2. Esaminare i file di configurazione WLS-HYDR.
   Verificare che i file di configurazione WLS-HYDR (replication.properties, oci.env e prem.env) contengano le informazioni corrette per il sistema in uso.
3. Eseguire il modulo di replica WLS-HYDR.
   È possibile utilizzare il modulo di replica del framework per sincronizzare tutti gli elementi (dominio e prodotti Oracle WebLogic Server) oppure sincronizzare questi elementi in modo indipendente. In tutti i casi, la sincronizzazione completa consiste in due operazioni: un'operazione pull, per recuperare il contenuto dal primario e un'operazione push, per copiare il contenuto nel secondario.

   Nota

   Eseguire sempre l'operazione PULL prima di PUSH. In caso contrario, non verrà eseguita la push dell'ultima versione del contenuto.
   1. Per sincronizzare tutto il contenuto:
      • Per estrarre tutto il contenuto dagli host primari all'area intermedia dell'host bastion:

        WLS-HYDR_BASE/lib/DataReplication.py pull

      • Per eseguire il PUSH di tutti i contenuti dall'area intermedia dell'host bastion agli host secondari:

        WLS-HYDR_BASE/lib/DataReplication.py push

   2. Per sincronizzare i solo artifact dei prodotti, eseguire le operazioni riportate di seguito.
      • Per estrarre i prodotti dagli host principali all'area intermedia dell'host bastion:

        WLS-HYDR_BASE/lib/DataReplication.py pull -d products

      • Per eseguire il push dei prodotti dall'area intermedia dell'host bastion agli host secondari:

        WLS-HYDR_BASE/lib/DataReplication.py push -d products

   3. Per sincronizzare solo la configurazione (dominio WebLogic).
      • Per recuperare la configurazione dagli host primari all'area intermedia dell'host bastion, eseguire questa operazione Pull:

        WLS-HYDR_BASE/lib/DataReplication.py pull -d private_config

      • Per copiare la configurazione dall'area intermedia dell'host bastion agli host secondari, eseguire questa operazione push:

        WLS-HYDR_BASE/lib/DataReplication.py push -d private_config

   4. Per i casi in cui è presente una cartella configurazione condivisa (dominio Oracle WebLogic condiviso in un file system OCI File Storage):
      • Per recuperare la configurazione condivisa dagli host primari all'area intermedia dell'host bastion, eseguire questa operazione Pull:

        WLS-HYDR_BASE/lib/DataReplication.py pull -d shared_config

      • Per copiare la configurazione condivisa dall'area intermedia dell'host bastion agli host secondari, eseguire questa operazione push:

        WLS-HYDR_BASE/lib/DataReplication.py push -d shared_config

4. Preparare le sostituzioni delle stringhe di connessione al database.
   Le normali operazioni di pull e push WLS-HYDR che copiano la configurazione WebLogic saltano il file tnsnames.ora dalle copie, quindi non è necessario aggiornare il file tnsnames.ora in ogni replica successiva.

   Tuttavia, l'approccio è diverso quando il database è un Autonomous Database. Per connettersi a un database autonomo, la cartella di amministrazione TNS contiene anche un keystore e file del truststore, diversi per i database primari e in standby.

   La tabella riportata di seguito riassume le modalità di gestione delle informazioni di connessione al database in ogni scenario.

   Tipo di database	Script di sostituzione e passi di download	Utilizzo
   Oracle Base Database Service o Oracle Exadata Database Service	Lo script per la gestione di tnsnames.ora è incluso nel modulo di replica del framework WLS-HYDR.	Assicurarsi che la sezione JDBC nel file replication.properties contenga i dati corretti. Questa operazione viene eseguita nel bastion ed esegue il pull, l'aggiornamento e il push del file tnsnames.ora. Per eseguire l'operazione completa: WLS-HYDR/lib/DataReplication.py tnsnames Non è necessario eseguire alcuna operazione a meno che non si eseguano modifiche a tnsnames.ora (ad esempio, aggiungendo un alias).
   Autonomous Database	fmwadb_switch_db_conn.sh 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.	Questo script deve essere eseguito su tutti gli host di livello intermedio in standby. Deve essere eseguito prima di avviare i server WebLogic in standby per un'operazione di convalida, switchover o failover. Sostituisce la cartella di amministrazione TNS utilizzata da WebLogic con quella fornita come input. Inoltre, aggiorna le proprietà della password del wallet nelle origini dati. Sintassi per eseguire lo script: 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.

Convalida replica per rsync con area intermedia centrale

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 nel sito secondario, non è necessario collegare o installare alcun volume. L'unica azione che potrebbe essere necessaria è assicurarsi che contenga la versione più recente del contenuto è la seguente.

1. Eseguire una replica.
   Eseguire gli script per replicare l'ultima versione del contenuto.
2. Disabilitare le repliche pianificate.
   Al termine dell'ultima replica, disabilitare tutti gli script di replica. In caso contrario potrebbe interferire con la procedura di switchover, failover o di convalida. Sarà possibile abilitare nuovamente gli script dopo l'operazione, nella direzione appropriata.
3. Sostituire le informazioni specifiche del sito negli host di livello intermedio secondari.
   Se gli artifact del file system che si sta replicando contengono informazioni specifiche del sito, assicurarsi che la copia non ne esegua l'override o che venga aggiornata dopo la replica.

   Suggerimento

   Ad esempio, gli script rsync del manuale Oracle Fusion Middleware Disaster Recovery Guide e del modulo di replica WLS-HYDR saltano il file tnsnames.ora dalla copia, quindi non è necessario modificarlo dopo ogni replica.

   Se il sistema utilizza Oracle Autonomous Database, ripristinare la cartella wallet necessaria nel secondario per connettersi al database dell'area secondaria. È possibile utilizzare lo script di sostituzione fmwadb_switch_db_conn.sh in tutti gli host di livello intermedio in standby. Richiede, come input, il percorso in cui si trova il wallet originale secondario e la password del wallet.

È quindi possibile eseguire i passi aggiuntivi necessari per convalidare il sistema.

Esegui replica continua per rsync con posizione area intermedia centrale

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

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

• Utilizzare il sistema operativo crontab o un altro strumento di pianificazione per eseguire periodicamente gli script di replica. Ad esempio, quando si utilizzano gli script rsync forniti dalla guida di disaster recovery, attenersi alla procedura descritta nella sezione Scheduling Ongoing Replication With Rsync Scripts del manuale Oracle Fusion Middleware Disaster Recovery Guide. Fare riferimento a Esplora di più in questo playbook per i collegamenti a queste e altre risorse. Per la frequenza di replica, attenersi alle linee guida descritte in Artifact file di livello intermedio in precedenza in questo playbook.
• Mantieni 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 quando si convalida il sito in standby o durante le procedure di switchover o failover.
• Gestire le informazioni specifiche di ciascun sito 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 del wallet quando si esegue un aggiornamento nel wallet. In questo modo, verrà ripristinato correttamente nello switchover e nei failover successivi.
• Dopo uno switchover o un failover, invertire la direzione della replica. Dipende dall'implementazione specifica. Questo può essere fatto utilizzando un controllo dinamico che identifica chi è il sito attivo, o con una modifica manuale dopo uno switchover o failover, disabilitando e abilitando gli script appropriati.

  Suggerimento

  • Quando si utilizzano gli script rsync forniti dalla guida DR (esempio 1), assicurarsi di creare uno script equivalente per eseguire la replica nella direzione opposta. Nel crontab o nello strumento programmato, abilitare solo gli script appropriati per il ruolo effettivo.
  • Quando si utilizza il WLS-HYDR (esempio 2), modificare il ruolo del primario nel framework WLS-HYDR, in modo che le repliche successive vadano nell'altra direzione. Per questo, modificare WLS-HYRDR/lib/DataReplication.py e cambiare da questi:

    if True:
           PRIMARY = PREM 
           STANDBY = OCI
          	 else:
    	        PRIMARY = OCI
                   STANDBY = PREM

    in quanto segue:

    if False:
    	        PRIMARY = PREM
                    STANDBY = OCI
           	else:
                    PRIMARY = OCI
                    STANDBY = PREM