Implementa la replica rsync peer-to-peer

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.

I vantaggi dell'implementazione della replica peer-to-peer rsync sono i seguenti:

• 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.
• Non ha bisogno di hardware aggiuntivo, come un host centrale o uno storage.
• 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.

Le considerazioni per l'implementazione del peer-to-peer rsync sono le seguenti:

• È 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.
• Richiede la manutenzione su molti nodi poiché gli script non sono centralizzati, quindi la soluzione è più complessa in cluster di grandi dimensioni.

Gli script rsync peer-to-peer 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 i file dal nodo locale al nodo remoto. Quando gli script rsync vengono eseguiti sui nodi con il ruolo standby, eseguono un'operazione "pull" per recuperare il contenuto dal database primario. Quando gli script rsync vengono eseguiti sui nodi con il ruolo primario, eseguono un'operazione push per copiare il contenuto nei nodi secondari. Oracle consiglia il modello pull per il peer-to-peer. In questo modo, gli script rsync utilizzano meno risorse degli host del sistema primario, poiché tutte le operazioni della copia (ad esempio, il confronto checksum della copia) vengono eseguite nei nodi secondari.

Impostare la replica per il peer-to-peer rsync

Per implementare il modello peer-to-peer rsync è necessario quanto riportato di seguito.

• Consentire la connettività SSH tra gli host e i relativi host peer.
• Creare script che utilizzano rsync per copiare gli artifact di file di livello intermedio dagli host primario a quello secondario. Gli script rsync possono saltare determinate cartelle dalla copia (ad esempio file di lock, log, file temporanei e così via)
• Implementare 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).

Esempio 1: utilizzare gli script rsync di Oracle Fusion Middleware Disaster Recovery Guide per la replica peer-to-peer

Nota

Questo esempio si applica a qualsiasi sistema di livello intermedio. Utilizza gli script forniti dal manuale Oracle Fusion Middleware Disaster Recovery Guide per eseguire la replica di livello intermedio per un sistema DR WebLogic: rsync_for_WLS.sh e rsync_copy_and_validate.sh. Tuttavia, questi script sono generalmente applicabili e offrono sufficiente flessibilità per sincronizzare qualsiasi artifact di file di livello intermedio in OCI. Fare riferimento a Esplora altro per i collegamenti a queste e altre risorse.

In questo esempio, ogni host nel sito secondario stabilisce una connessione con il nodo primario peer ed esegue un pull del contenuto. 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 Peer-to-Peer.

Descrizione dell'illustrazione dr-scripts-peer-peer.png

dr-scripts-peer-peer-oracle.zip

Convalida replica per peer-to-peer rsync

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.

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

Esegui replica continua per peer-to-peer rsync

Eseguire periodicamente gli 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 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 dal manuale Oracle Fusion Middleware Disaster Recovery Guide, attenersi alla procedura descritta nella sezione Scheduling Ongoing Replication With Rsync Scripts. Fare riferimento a Esplora di più in questo playbook per i collegamenti a queste e altre risorse. Per la frequenza di replica, seguire le linee guida descritte in Artifact file di livello intermedio all'inizio di 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. Ad esempio, con gli script rsync forniti dal manuale Oracle Fusion Middleware Disaster Recovery Guide, assicurarsi di creare gli script equivalenti per eseguire la replica nell'altra direzione. Nel file crontab o nello strumento schedulato, abilitare solo gli script appropriati per il ruolo effettivo.