1. Esegui il provisioning e distribuisci una soluzione di massima disponibilità per PeopleSoft su Oracle Cloud
  2. Failover e recupero sito

Failover e recupero sito

È necessario un failover del sito se l'infrastruttura ha subito un evento non pianificato che rende il sito primario non disponibile e completamente inaccessibile per un periodo di tempo che avrà un impatto negativo sull'attività. In questo scenario, lo standby assume il ruolo primario.

Un sito principale può diventare non disponibile per una serie di motivi, tra cui, a titolo esemplificativo ma non esaustivo, i seguenti:

  • Problemi che potrebbero impedire l'avvio delle istanze di database primarie, ad esempio un supporto guasto o danneggiato, un aggiornamento del sistema operativo o del firmware difettoso
  • Errore dell'infrastruttura, ad esempio un'interruzione completa del sistema di alimentazione o raffreddamento all'interno dell'infrastruttura dell'area OCI
  • Completamento degli errori di rete
  • Disastri naturali come terremoti, incendi e inondazioni

Mentre gli eventi non pianificati sono rari, possono e possono verificarsi.

Esegui failover sito

Poiché un vero failover comporta interruzioni del funzionamento e può comportare una piccola perdita di dati, eseguire il TEST del failover del sito in un ambiente TEST.
Nell'esempio seguente vengono utilizzati i nomi del nostro ambiente di test per il database primario in Ashburn (CDBHCM_iad1dx) e il database in standby in Phoenix (CDBHCM_phx5s).
  1. Forzare l'arresto di tutte le istanze di database Oracle Real Application Clusters (Oracle RAC) sul database primario.

    Nota

    Non eseguire questo test in un ambiente di produzione. 
    $ srvctl stop database -db CDBHCM_iad1dx -stopoption
        abort
    Da questo momento in poi, si presume che il nostro primario (simulato) sia completamente non disponibile. Renderemo la nostra regione secondaria il nostro nuovo sito primario.

    I seguenti passaggi utilizzano la nostra implementazione del test e tutti i passaggi vengono eseguiti nel sito secondario (nuovo primario).

  2. Nel sito secondario, eseguire il login a uno qualsiasi di Oracle Exadata Database Service on Dedicated Infrastructure domUs, diventare l'utente del sistema operativo oracle e richiamare l'interfaccia della riga di comando del broker Data Guard.
    • Nodo: un Oracle Exadata Database Service on Dedicated Infrastructure domU
    • Utente: oracle
    $ dgmgrl sys/sys password
DGMGRL> show configuration lag

Configuration - fsc

  Protection Mode: MaxPerformance
  Members:
  CDBHCM_iad1dx  - Primary database
    Error: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
  CDBHCM_phx5s - Physical standby database 
                    Transport Lag:      0 seconds (computed 18 seconds ago)
                    Apply Lag:          0 seconds (computed 18 seconds ago)

Fast-Start Failover:  Disabled

Configuration Status:
ERROR   (status updated 0 seconds ago)
    Notate l'errore.
  3. Eseguire un failover utilizzando l'interfaccia della riga di comando del broker Oracle Data Guard.
    • Nodo: un Oracle Exadata Database Service on Dedicated Infrastructure domU nel sito secondario
    • Utente: oracle
    DGMGRL> failover to CDBHCM_phx5s
  4. Se i livelli intermedi primari (incluso il file system condiviso) sono ancora intatti, eseguire manualmente un comando rsync "forzato" dal sito principale non riuscito al sito DR.

    È possibile che l'applicazione e i livelli Web siano ancora funzionali, ma i processi dello scheduler di applicazioni e processi inizieranno a non riuscire nel tentativo di connettersi al database non riuscito. In questo modo lo script rsync interromperà l'esecuzione di rsync.

    • Nodo: un livello intermedio, sede principale non riuscita
    • Utente: psadm2
    1. Eseguire rsync forzato. Nella directory degli script è disponibile uno script rsync_psft.sh di esempio.
      Se lo script rsync è disabilitato, il parametro -f richiederà di continuare con un valore rsync forzato. Un rsync forzato non consulterà il database per determinare il ruolo del sito, quindi eseguirà l'rsync richiesto.

      Nota

      Questa operazione deve essere eseguita solo durante l'aggiornamento finale durante il failover di un sito. Viene registrata l'opzione FORCE. 
      $ rsync_psft.sh path to file system/parameter file -f
      Di seguito sono riportati alcuni esempi. 
      $ rsync_psft.sh $SCRIPT_DIR/fs1 -f
    2. Monitorare il log del processo rsync per verificare che il processo sia stato completato correttamente.
  5. Se l'errore del sito è stato completato e non è possibile eseguire un processo rsync finale, disabilitare rsync nel nuovo database primario eseguendo lo script disable_psft_rsync.sh.
    • Nodo: un livello intermedio, nuovo sito principale
    • Utente: psadm2
    disable_psft_rsync.sh
  6. Se è stato configurato il supporto di Active Data Guard durante la configurazione dei database server primari e in standby, assicurarsi che il servizio Active Data Guard per PeopleSoft (PSQUERY) sia stato avviato sul nuovo database primario.
    • Nodo: un Oracle Exadata Database Service on Dedicated Infrastructure domU nel sito secondario
    • Utente: oracle
    $ srvctl status service -db CDBHCM_phx5s -s PSQUERY
Service PSQUERY is running on instance(s) CDBHCM1,CDBHCM2
    Questo servizio deve essere in esecuzione su tutte le istanze di Oracle Real Application Clusters (Oracle RAC).

    Nota

    Questo servizio deve essere avviato prima di avviare lo scheduler dei processi. In caso contrario, lo scheduler dei processi non riuscirà all'avvio.
  7. Verificare che i servizi di database basati sui ruoli siano attivi sul nuovo database primario.
    • Sito: sito 2
    • Nodo: tutti i Oracle Exadata Database Service on Dedicated Infrastructure domUs
    • Utente: oracle
    Ad esempio, eseguire il comando seguente su ogni domU che ospita un'istanza di database Oracle RAC PeopleSoft: 
    $ srvctl status service -db CDBHCM_phx5s -s HR92U033_BATCH
Service HR92U033_BATCH is running on instance(s) CDBHCM1,CDBHCM2
$ srvctl status service -db CDBHCM_phx5s -s HR92U033_ONLINE
Service HR92U033_ONLINE is running on instance(s) CDBHCM1,CDBHCM2
    Questo servizio deve essere in esecuzione su tutte le istanze Oracle RAC.
  8. Avviare i domini Application Server e Process Scheduler.
    • Sito: sito 2
    • Nodo: istanze di computazione del server dello scheduler di applicazioni e processi
    • Utente: psadm2
    1. Eseguire il login alle istanze di computazione che ospitano gli Application Server PeopleSoft e lo scheduler dei processi e diventare psadm2.
      Utilizzare lo script startPSFTAPP.sh dalla directory Wrapper in GitHub.
      $ startPSFTAPP.sh
    2. Monitorare l'avvio.
      È possibile utilizzare la query dai domini Application and Process Scheduler di PeopleSoft.
      col service_name format a20
select a.inst_id,a.instance_name,b.service_name, count(*)
from gv$instance a, gv$session b
where a.inst_id = b.inst_id
and service_name not like 'SYS%'
group by a.inst_id,a.instance_name,b.service_name
order by 1

SQL> /

   INST_ID INSTANCE_NAME    SERVICE_NAME          COUNT(*)
---------- ---------------- ------------------- ----------
         1 CDBHCM1          CDBHCM_phx5s                 2
SQL> /

   INST_ID INSTANCE_NAME    SERVICE_NAME          COUNT(*)
---------- ---------------- ------------------- ----------
         1 CDBHCM1          CDBHCM_phx5s                2
         1 CDBHCM1          HR92U033_BATCH               8
         1 CDBHCM1          HR92U033_ONLINE             52
         2 CDBHCM2          HR92U033_BATCH               7
         2 CDBHCM2          HR92U033_ONLINE             50
  9. Se non si è verificato un errore completo del sito, come descritto nel Passo 5, andare al passo successivo. Se si è verificato un errore completo del sito, è necessario eseguire di nuovo lo script disable_psft_rsync.sh, in quanto lo script startPSTAPP.sh abiliterà rsync.

    Nota

    In un evento di errore effettivo in cui il sito principale viene perso o diventa inaccessibile, sarà necessario condurre una valutazione dell'ambito e dell'impatto. Ecco alcuni elementi da considerare:

    • Possibile perdita di dati del database
    • Artifact del file system mancanti (report, log, file in entrata e in uscita e così via)

    A seconda dell'indisponibilità, è possibile recuperare o meno tutte le transazioni di cui è stato eseguito il commit nel database primario originale. Se possibile, chiedi agli utenti di verificare le ultime transazioni su cui stavano lavorando.

    È probabile che mancheranno gli artifact del file system, dall'output scritto o trasmesso quando l'accesso al file primario originale cessa. Utilizzare il log del report nel database per identificare gli artifact del file system creati vicino al momento dell'indisponibilità, quindi determinare le operazioni da eseguire, caso per caso, per i file mancanti o incompleti.

  10. Avviare i servizi Web.
    • Sito: sito 2
    • Nodo: tutte le istanze di calcolo del server Web PIA (Internet Architecture) PeopleSoft
    • Utente: psadm2
    Se Coherence*Web è configurato, il cluster cache verrà avviato prima su tutte le istanze di computazione che ospitano i server Web PIA, quindi sui server Web PIA. In questo esempio, viene utilizzato uno script per avviare entrambi nell'ordine corretto.
    1. Eseguire il login ai server Web PIA e diventare psadm2.
    2. Utilizzando lo script da startPSFTAPP.sh, avviare i server Web.
      $ startPSFTWEB.sh
  11. Controllare il load balancer.
    • Sito: area sito 2
    • Nodo: OCI Console
    • Utente: amministratore della tenancy
    1. Eseguire il login a OCI Console e modificare l'area in base al nuovo primario.
    2. Selezionare Networking, quindi Load Balancer dal menu principale.
    3. Selezionare il compartimento appropriato.
    4. Fare clic su Set backend, quindi su Backend.
      Ogni backend deve mostrare OK. Potrebbero essere necessari alcuni minuti dopo l'avvio di ciascun server Web PIA.

Reintegra il primario non riuscito come nuovo standby

Dovrai proteggere il tuo nuovo ambiente di produzione con uno standby. In teoria, potrai ripristinare il database primario non riuscito come nuovo database in standby ripristinando sia il database che i file system.

Ricrea un'istanza del vecchio database primario come database in standby

Oracle Data Guard impedirà l'apertura del vecchio database primario quando viene reso nuovamente disponibile dopo un errore del sito primario. Qualsiasi tentativo di avviare il database in genere non riuscirà, con messaggi scritti nell'alert log che indicano che è necessario eseguire il ripristino. Se Flashback Database è stato abilitato in questo database prima dell'errore, è possibile ricreare un'istanza del database primario precedente come nuovo database di standby.

Eseguire le operazioni riportate di seguito per ripristinare il database primario precedente come standby della produzione corrente.

  1. Eseguire il login a uno dei domUs che ospitano il vecchio database primario e avviare il database:
    $ srvctl start database -db CDBHCM_phx5s
  2. Eseguire il login all'interfaccia della riga di comando del broker Data Guard nella nuova area primaria e visualizzare la configurazione.
    Si noti l'errore ORA-16661 in grassetto di seguito.
    $ dgmgrl sys/sys password
DGMGRL> show configuration
configuration - fsc

  Protection Mode: MaxPerformance
  Members:
  CDBHCM_iad1dx - Primary database
    CDBHCM_phx5s  - Physical standby database (disabled)
      ORA-16661: the standby database needs to be reinstated

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 12 seconds ago)
  3. Reintegrare lo standby.
    DGMGRL> REINSTATE DATABASE CDBHCM_phx5s;

    Nota

    Il processo di recupero del database non riuscito e l'avvio di un database in standby valido potrebbero richiedere del tempo per il completamento.
  4. Utilizzare l'interfaccia della riga di comando del broker Data Guard per controllare lo stato dell'ambiente.
    Di seguito sono riportati alcuni esempi. 
    DGMGRL> show configuration lag

Configuration - fsc

  Protection Mode: MaxPerformance
  Members:
  CDBHCM_iad1dx - Primary database
    CDBHCM_phx5s  - Physical standby database 
                    Transport Lag:      0 seconds (computed 1 second ago)
                    Apply Lag:          0 seconds (computed 1 second ago)

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 35 seconds ago)

    Il database reintegrato ora funge da database in standby, proteggendo il database primario e disponibile per lo switchover e il failover.

    Se è stato configurato il supporto di Active Data Guard quando sono stati configurati i database server primari e in standby, il servizio Active Data Guard per PeopleSoft (PSQUERY) può essere riposizionato dal database primario al database in standby.

Reintegra i livelli medi principali precedenti come standby

Reintegra i vecchi livelli intermedi primari in base all'evento di failover.
  1. Se i vecchi server di livello intermedio primari sono rimasti disponibili mentre si è verificato l'evento di failover del database, è necessario aver eseguito un valore rsync forzato finale dal sito primario non riuscito al database in standby al momento dell'errore, quindi la direzione inversa dei processi rsync allo stesso modo di quando si esegue uno switchover.

    È possibile che l'applicazione e i livelli Web siano ancora funzionali, ma i processi dello scheduler di applicazioni e processi inizieranno a non riuscire nel tentativo di connettersi al database non riuscito. Ciò causerà l'arresto dell'esecuzione di rsync da parte dello script rsync.

    1. Se i livelli intermedi primari, incluso il file system condiviso, sono ancora intatti, eseguire manualmente una sincronizzazione "forzata" dal sito primario non riuscito al sito DR.
      Se lo script rsync è disabilitato, il parametro -f richiederà di continuare con un valore rsync forzato. Un rsync forzato non consulta il database per determinare il ruolo del sito, quindi eseguirà il rsync richiesto.

      Nota

      Questa operazione deve essere eseguita solo durante l'aggiornamento finale durante il failover di un sito. L'utilizzo dell'opzione FORCE verrà registrato.
      Lo script di esempio può essere utilizzato nella directory degli script rsync_psft.sh, come utente psadm2: 
      $ rsync_psft.sh path to file system/parameter file -f
      Di seguito sono riportati alcuni esempi. 
      $ rsync_psft.sh $SCRIPT_DIR/fs1 -f
    2. Monitorare il log del processo rsync per verificare che il processo sia stato completato correttamente.
  2. Se il vecchio sito primario è completamente inaccessibile anche per rsync, eseguire le operazioni riportate di seguito.
    1. Disabilitare gli script rsync nel nuovo sito principale con disable_psft_rsync.sh per tutti i file system replicati.
    2. Se è possibile riprendere l'attività sui livelli intermedi originali in un secondo momento, riabilitare gli script rsync e consentirne il recupero.
  3. Se è necessario ricostruire i livelli intermedi, seguire i processi descritti in precedenza.