Task ciclo di vita

È necessaria una manutenzione regolare del ciclo di vita per mantenere il sito secondario sincronizzato con il sito primario. Durante l'intero ciclo di vita, sarà possibile eseguire uno switchover pianificato per cambiare il ruolo dei siti primari e secondari e rispondere alle operazioni impreviste o non pianificate.

Informazioni sulla replica di configurazione

Durante l'impostazione della riconfigurazione dinamica, è stata eseguita una replica iniziale del contenuto presente nei file system. È necessario ripetere regolarmente la replica del file system per mantenere aggiornato il sito secondario con il sito primario.

È possibile utilizzare gli stessi script creati durante l'impostazione di DR, Replicate the File System Artifacts to OCI, e pianificare la replica dei file system con le considerazioni riportate di seguito per ogni artifact.

• Replica delle Oracle home durante il ciclo di vita

  Questo è un artifact statico. Non cambia frequentemente, quindi non c'è bisogno di replicarlo regolarmente. Solo quando si esegue una modifica nella Oracle home, ad esempio l'attività di applicazione delle patch, è necessario replicarla.

• Replica della configurazione condivisa del dominio WebLogic durante il ciclo di vita

  Questo è un artifact dinamico. Tra le altre cose, contiene ASERVER_HOME, che è l'origine della verità della configurazione del dominio SOA, e APPLICATION_HOME, che viene aggiornato ogni volta che un'applicazione viene distribuita, non distribuita, aggiornata e così via.

  Si prevede che questa configurazione condivisa del dominio WebLogic venga modificata frequentemente. Pianificare una replica regolare di questo artifact, che dovrebbe essere più o meno frequente a seconda della frequenza con cui vengono apportate le modifiche alla configurazione nel sistema. Un altro approccio controllato consiste nell'eseguire una replica ogni volta che si esegue una modifica alla configurazione primaria.

• Replica della configurazione privata del dominio WebLogic durante il ciclo di vita

  Si tratta inoltre di un artifact dinamico, che contiene MSERVER_HOME e NM_HOME. Non si prevede che gli aggiornamenti frequenti nella home nodemanager vengano eseguiti dopo l'impostazione iniziale. Il contenuto di MSERVER_HOME verrà modificato con la frequenza ASERVER_HOME poiché contiene la cartella di dominio utilizzata dai server gestiti. Tuttavia, la maggior parte del relativo contenuto (ASERVER_HOME/config) viene aggiornata e scaricata dal file AdminServer all'avvio dei server gestiti e quando le modifiche alla configurazione vengono applicate utilizzando lo strumento di script WebLogic (WLST) o la console di amministrazione di Oracle WebLogic Server. Non è tanto importante replicare questo artifact quanto spesso la configurazione condivisa. La replica è obbligatoria solo quando le modifiche vengono eseguite ad altre cartelle in MSERVER_HOME (ad esempio, una modifica nella cartella MSERVER_HOME/bin).

• Replica della cartella runtime condivisa

  Se si memorizza un artifact di runtime in questa cartella, pianificare la replica in standby, in base alle esigenze aziendali.

  Anziché utilizzare il file system Oracle Cloud Infrastructure File Storage e replicarlo con rsync, è possibile utilizzare un accesso a Oracle Database File System (DBFS) per il contenuto runtime condiviso. In questo modo, il contenuto risiede nel database e viene replicato automaticamente nella parte secondaria con la replica di base di Oracle Data Guard. Vedere Informazioni su Oracle Database File System in Ulteriori informazioni per i dettagli sull'uso di DBFS.

La tabella seguente contiene un riepilogo dei suggerimenti per la replica degli artifact del file system durante il ciclo di vita.

Artifact	Contiene	Suggerimento
Oracle home	Home FMW, JDK, inventario	Replica solo su richiesta (ad esempio dopo l'applicazione di patch)
WebLogic Configurazione condivisa del dominio	ASERVER_HOME, applicazioni, piani di distribuzione, keystore	Pianificare la replica, potrebbe essere necessaria un'alta frequenza. La frequenza dipende dalla frequenza con cui vengono eseguite le modifiche alla configurazione nel sistema SOA.
WebLogic Configurazione privata dominio	MSERVER_HOMES, nodemanager config	Pianifica la replica. L'alta frequenza non è in genere necessaria.
Runtime condiviso	Artifact di runtime specifici del cliente (non JMS, non TLOGS)	Determinato dai requisiti. Se si tratta di un MOUNT DBFS, il contenuto viene replicato automaticamente da Oracle Data Guard.

Eseguire uno switchover

Uno switchover è un'operazione pianificata in cui un amministratore ripristina i ruoli dei due siti. Dopo uno switchover, il sistema primario diventa secondario e il sistema secondario diventa primario. L'esecuzione di uno switchover comporta tempi di inattività nel sito primario.

Prima di eseguire uno switchover in una configurazione DR ibrido SOA, propagare le modifiche di configurazione in sospeso. Assicurarsi che non vi siano modifiche replicate nel sito secondario in sospeso.

1. Disabilitare qualsiasi replica pianificata durante l'esecuzione dello switchover in quanto potrebbe non riuscire e interferire con l'operazione di switchover stessa.
2. Arrestare i sistemi Oracle HTTP Server nel sito principale.
3. Arrestare i server nel sito primario.
   Utilizzare la console o gli script del server di amministrazione WebLogic per arrestare i server WebLogic nel sito primario.

   Nota:

   Il server di amministrazione nel sito principale può rimanere attivo durante lo switchover. Tuttavia, si consiglia di arrestarlo quando il sito è in standby perché è previsto che la configurazione del dominio nel sito in standby venga sostituita dalla configurazione principale durante il ciclo di vita. Se il server di amministrazione è attivo, verrà eseguita con una configurazione non più valida.
4. Eseguire lo switchover del nome DNS frontend.

   Eseguire il push DNS richiesto nel server DNS che ospita i nomi utilizzati dal sistema o modificare la risoluzione dell'host del file nei client per puntare il nome virtuale frontend del sistema all'IP pubblico utilizzato dal load balancer nel sito secondario.

   Per gli scenari in cui il DNS viene utilizzato per la risoluzione front-end esterna (ad esempio, il DNS OCI o il DNS commerciale), puoi utilizzare un'API per eseguire il push della modifica. Per vedere un esempio che esegue il PUSH di questa modifica in un DNS OCI, andare a GitHub, ad esempio script.

   Tenere presente che il valore TTL della voce DNS influirà sull'RTO dello switchover: se il TTL è elevato (ad esempio, 20 minuti), la modifica DNS richiederà tale tempo per essere efficace nei client. L'utilizzo di valori TTL inferiori renderà questo metodo più rapido, ma ciò può causare un sovraccarico poiché i client avranno più spesso accesso al DNS anziché utilizzare nomi inseriti nella cache. Un buon approccio consiste nell'impostare temporaneamente il TTL su un valore basso (ad esempio, 1 minuto), prima della modifica del DNS. Quindi eseguire la modifica e una volta completata la procedura di switchover, ripristinare di nuovo il valore originale del TTL.

5. In qualità di utente oracle, utilizzare il broker Oracle Data Guard nell'host del database primario per eseguire lo switchover del database.
   È necessario disporre della password di sistema e del nome univoco del database primario.

   [oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
   DGMGRL> switchover to secondary_db_unqname

6. Se non sono già attivi, avviare i sistemi Oracle HTTP Server nel sito secondario (nuovo primario).
7. Avviare il server di amministrazione nel sito secondario (nuovo principale) oppure riavviare il server se è già stato avviato.
   L'avvio del server di amministrazione abilita le modifiche alla configurazione che sono state replicate mentre si trattava di un database in standby per renderle effettive.
8. Avviare i server gestiti secondari nel sito secondario (nuovo database primario).
   Utilizzare la console o gli script WebLogic per avviare i server gestiti secondari.

Eseguire un failover

Un'operazione di failover è in genere un'operazione non pianificata eseguita quando il sito primario diventa non disponibile. È possibile eseguire la transizione di un database in standby a un ruolo di database primario quando il database primario originale non riesce e non è possibile recuperarlo in modo tempestivo. Potrebbero verificarsi perdite di dati, a seconda che i database in standby primari e di destinazione fossero coerenti al momento dell'errore del database primario.

1. Propaga eventuali modifiche alla configurazione in sospeso.
   Per replicare le modifiche al sito secondario, vedere Replicate the File System Artifacts to OCI.
2. Disabilitare qualsiasi replica pianificata durante l'esecuzione dello switchover in quanto potrebbe non riuscire e interferire con l'operazione di switchover stessa.
3. Arrestare i sistemi Oracle HTTP Server nel sito principale.
4. Arrestare i server gestiti nel sito primario, se possibile.

   Utilizzare la console o gli script del server di amministrazione WebLogic per arrestare i server gestiti in primario.

5. Eseguire lo switchover del nome DNS frontend.

   Eseguire il push DNS richiesto nel server DNS che ospita i nomi utilizzati dal sistema o modificare la risoluzione dell'host del file nei client per puntare il nome virtuale frontend del sistema all'IP pubblico utilizzato dal load balancer nel sito secondario.

   Per gli scenari in cui viene utilizzato il DNS per la risoluzione front-end esterna (DNS OCI, DNS commerciale e così via), utilizzare l'API appropriata per eseguire il push della modifica. Per vedere un esempio che esegue il push di questa modifica in un DNS OCI, vai qui.

   Nota:

   il valore TTL della voce DNS influirà sull'RTO dello switchover. Se il TTL è elevato (ad esempio, 20 minuti), la modifica DNS richiederà tale tempo per essere efficace nei client. L'utilizzo di valori TTL inferiori renderà questo metodo più veloce; tuttavia, questo può causare un sovraccarico poiché i client colpiranno il DNS più frequentemente anziché utilizzare nomi inseriti nella cache. Un buon approccio consiste nell'impostare temporaneamente il TTL su un valore basso (ad esempio, 1 minuto), prima della modifica del DNS. Eseguire quindi la modifica e al termine della procedura di switchover ripristinare il valore originale del TTL.
6. Come utente oracle, utilizzare il broker Oracle Data Guard nell'host del database secondario per eseguire il failover.
   È necessario disporre della password di sistema e del nome univoco del database primario.

   [oracle@hydrdb1 ~]$ dgmgrl sys/your_sys_password@secondary_db_unqname
   DGMGRL> failover to secondary_db_unqname

7. Se non sono già attivi, avviare i sistemi Oracle HTTP Server nel sito secondario (nuovo primario).
8. Avviare il server di amministrazione nel sito secondario (nuovo principale) oppure riavviare il server se è già stato avviato.
   L'avvio del server di amministrazione abilita le modifiche alla configurazione che sono state replicate mentre si trattava di un database in standby per renderle effettive.
9. Avviare i server gestiti secondari nel sito secondario (nuovo database primario).
   Utilizzare la console o gli script WebLogic per avviare i server gestiti secondari.

Apri il secondario per la convalida

È possibile convalidare il sito in standby senza eseguire uno switchover completo convertendo il database in standby in database in standby snapshot. Ciò consente di avviare i server SOA secondari nel sito in standby e di verificare il sistema secondario. Qualsiasi modifica eseguita nel database del sito in standby mentre è in modalità standby snapshot verrà eliminata una volta convertita di nuovo in standby fisico. I dati principali non sono interessati dalle convalide del sito secondario.

Nota:

Questa operazione deve essere eseguita con cautela: se nel database sono presenti messaggi o composti in sospeso quando viene convertito in snapshot, i server SOA del sito in standby li elaboreranno all'avvio. Controllare che non vi siano azioni in sospeso nel database primario durante la conversione in standby snapshot. In caso contrario, rimuovere i record dalle tabelle SOA di runtime nel database di standby dopo la conversione nel database di standby snapshot e prima di avviare i server SOA del sito secondario. Fare riferimento alla sezione Rimozione di record dalle tabelle di runtime senza eliminare le tabelle per la procedura di convalida del sito in standby senza eseguire uno switchover.

1. In qualità di utente oracle, utilizzare il broker Oracle Data Guard nell'host DB primario e convertire il secondario in standby di snapshot.

   [oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
   DGMGRL> convert database secondary_db_unqname to snapshot standby
   

   Utilizzare il comando show configuration per verificare che la conversione sia stata eseguita correttamente.
2. Verificare che non siano presenti azioni in sospeso nell'ambiente secondario.
   Se nel database primario sono presenti azioni in sospeso (transazioni, messaggi) quando il database di standby viene convertito in snapshot, i server SOA secondari tenteranno di elaborarle quando start.You potrà utilizzare lo script di troncamento SOA per rimuovere i record dalle tabelle di runtime SOA nel database secondario per eseguire il cleanup dei dati di runtime prima di avviare i server secondari. Eseguire questa azione con ATTENZIONE. Non troncare le tabelle nel database primario. Vedere Rimozione di record dalle tabelle di runtime senza eliminare le tabelle.
3. Se non sono già attivi, avviare i sistemi Oracle HTTP Server nel sito secondario.
4. Avviare il server di amministrazione nel sito secondario.
5. Avviare i server gestiti secondari nel sito secondario.
   Utilizzare la console o gli script WebLogic per avviare i server gestiti secondari.
6. Convalidare il sito secondario.

   Poiché questo non è uno switchover e il sito primario è ancora attivo, il nome frontend virtuale verrà risolto nell'indirizzo IP del load balancer del sito primario, pertanto per impostazione predefinita qualsiasi accesso al browser verrà reindirizzato al sito primario attivo.

   Per accedere direttamente ai servizi SOA del sito secondario, è necessario aggiornare il file /etc/hosts in un client controllato (ad esempio, un laptop), impostare il nome front-end virtuale da risolvere nell'indirizzo IP del load balancer front-end del sito secondario ed eseguire qualsiasi convalida da questo client.

   Nota:

   Verificare che il client utilizzato per le convalide non acceda al sistema tramite un proxy HTTP, poiché è possibile che il proxy HTTP continui a risolvere il nome front-end virtuale con l'indirizzo IP del load balancer del sito primario indipendentemente dal nome presente nell'/etc/hosts del client.

   I client non Linux potrebbero richiedere la reimpostazione della cache DNS locale prima che un browser risolva l'indirizzo IP utilizzando la voce del file host personalizzata.

   Una volta convalidato il sito secondario, andare al passo successivo per ripristinare il ruolo di standby.

   Nota:

   La convalida del sito secondario potrebbe richiedere del tempo.
7. Arrestare i server gestiti e i server di amministrazione nel sito secondario.
   Utilizzare la console secondaria WebLogic per chiudere i server gestiti e il server di amministrazione nel sito secondario.
8. In qualità di utente oracle, utilizzare il broker Oracle Data Guard nell'host del database primary e convertire di nuovo il database secondario in standby fisico.
   È necessario disporre della password di sistema e del nome univoco del database primario.

   [oracle@dbhost1 ~]$ dgmgrl sys/your_sys_password@primary_db_unqname
       DGMGRL> convert database secondary_db_unqname to physical standby

   Utilizzare show configuration per verificare la conversione.
9. Ripristinare i file /etc/hosts aggiornati.
   Se sono stati aggiornati file /etc/hosts in un client in modo che punti al sito secondario per le convalide, ripristinare nuovamente il nome front-end virtuale in modo che punti di nuovo all'indirizzo IP front-end primario.

Nota:

ORA-01403: nessun dato trovato ORA-06512 errori

Durante la convalida del sito secondario come descritto in questa sezione (senza eseguire uno switchover completo, ovvero aprire il database in modalità standby istantanea) "ORA-01403: nessun dato trovato ORA-06512" può mostrare errori nei log dei server SOA in standby. Questi errori sono correlati al job di rimozione automatica SOA. Questi errori si verificano poiché i job nel database potrebbero avere dipendenze del ruolo DB (verranno definiti come abilitati solo quando il database si trova nel ruolo principale). Si tratta di un funzionamento previsto e desiderato che impedisce l'esecuzione dei job due volte (una volta nel database primario e una volta nel database in standby). Il job di rimozione automatica SOA viene definito con il ruolo principale, pertanto non viene visualizzato nella vista DBA_SCHEDULER_JOBS quando il database è in modalità standby istantanea. Il file database_role definito per ogni job può essere visualizzato nella vista DBA_SCHEDULER_JOB_ROLE. In sintesi, questi errori possono essere ignorati finché vengono visualizzati nel sistema in standby. Il job dello scheduler per la rimozione automatica SOA verrà eseguito sul database se e solo se l'istanza ne modifica il ruolo in PRIMARY.

Failover locale del server di amministrazione in OCI

È possibile avviare il server di amministrazione in un nodo diverso nello stesso sito quando si verifica un errore nell'host in cui il server di amministrazione era originariamente in esecuzione. Non è necessario passare completamente dal sistema all'altro sito.

Nota:

Questo task del ciclo di vita è applicabile solo quando i server di amministrazione WebLogic utilizzano un VIP per l'alta disponibilità locale e la cartella di configurazione del server di amministrazione (ASERVER_HOME) si trova in una posizione condivisa.

La procedura viene illustrata in Verifica del failover manuale del server di amministrazione. Ciò fornisce la protezione failover locale per il server di amministrazione. Tenere presente che questa operazione non è necessaria per i server gestiti che dispongono di una protezione High Availability locale basata sulla funzione Migrazione automatica dei servizi.

Se è necessario eseguire un failover del server di amministrazione su un altro host quando il database primario è in esecuzione nel sito OCI, è possibile seguire tale procedura. Tuttavia, è necessaria un'azione aggiuntiva relativa al passo "Eseguire la migrazione dell'indirizzo IP virtuale ADMINVHN nel secondo host".

Eseguire i passi riportati di seguito per scollegare il VIP dall'host SOA in cui era in esecuzione il server di amministrazione e collegarlo all'host SOA in cui è in corso lo spostamento dell'amministrazione (scollegare il VIP da SOAHOST1 e collegarlo a SOAHOST2 nel sito OCI).

1. Come utente root, eseguire i comandi seguenti in SOAHOST1 per rimuovere il VIP del server di amministrazione dall'interfaccia di rete.
   1. Arrestare il server di amministrazione se è ancora in esecuzione
   2. Confermare l'esecuzione del VIP.

      ip addr show dev ens3

   3. Rimuovere l'IP dall'interfaccia di rete.

      ip addr del 100.70.8.120/20 dev ens3

2. Scollegare il VIP del server di amministrazione da SOAHOST1 .
   1. Connettersi alla console OCI e selezionare l'area e il compartimento appropriati.
   2. Passare all'istanza di computazione. Fare clic su Compute, Instances, quindi fare clic su SOAHOST1.
   3. Fare clic su VNIC collegate, quindi selezionare la VNIC alla quale è allegato il VIP del server di amministrazione.
   4. Fare clic su Indirizzi IPv4 e modificare il VIP utilizzato dal server di amministrazione.
   5. Salvare l'indirizzo IP del VIP e il nome fqdn in una nota (ad esempio: 100.70.8.120, idrsoa-vip.midtiersubnet.hydrvcn.oraclevcn.com).
   6. Fare clic su Delete Private IP.
3. Associare il VIP del server di amministrazione a SOAHOST2.
   1. Passare all'istanza di computazione. Fare clic su Compute, Instances, quindi fare clic su SOAHOST2.
   2. Fare clic su VNIC collegate, quindi selezionare la VNIC alla quale è allegato il VIP del server di amministrazione.
   3. Fare clic su Assegna indirizzo IP privato secondario.
   4. Fare clic su Indirizzi IPv4, quindi su Assegna indirizzo IP privato secondario.
   5. Immettere i valori dell'indirizzo IP privato e del nome host utilizzati in precedenza. Ad esempio: 100.70.8.120 per l'IP e hydrsoa-vip come nome host.
4. Eseguire il login a SOAHOST2 come utente root, quindi eseguire i comandi seguenti per collegare il VIP del server di amministrazione all'interfaccia di rete.
   1. Verificare se l'interfaccia di rete è in esecuzione.

      ip addr show dev ens3

   2. Aggiungere il VIP del server di amministrazione all'interfaccia di rete.

      ip addr add 100.70.8.120/20 dev ens3 label ens3:1

5. Eseguire il resto dei passi come descritto in Verifica del failover manuale del server di amministrazione.