Abilitazione del failover automatico

Il monitoraggio dello stato del server osserva il modo in cui un server reagisce al carico operativo e tiene traccia dei suoi tempi di risposta alle richieste del client. Lo scopo di questo monitoraggio è la prevenzione di errori del server garantendo che il server disponga sempre di capacità sufficienti per eseguire le attività richieste. La maggior parte degli strumenti standard di monitoraggio dello stato supportano il monitoraggio remoto del server attraverso i protocolli HTTP e HTTPS.
casm173
Il monitoraggio dello stato del server osserva il modo in cui un server reagisce al carico operativo e tiene traccia dei suoi tempi di risposta alle richieste del client. Lo scopo di questo monitoraggio è la prevenzione di errori del server garantendo che il server disponga sempre di capacità sufficienti per eseguire le attività richieste. La maggior parte degli strumenti standard di monitoraggio dello stato supportano il monitoraggio remoto del server attraverso i protocolli HTTP e HTTPS.
La funzione di failover automatico di CA SDM visualizza le seguenti interfacce standard basate su HTTP:
  • Interfaccia di monitoraggio dello stato: interfaccia HTTP(S) per monitorare lo stato del server in background. Prende anche decisioni di failover affidabili per avviare il failover su un server di standby selezionato nel caso di un'interruzione della disponibilità del server in background o di impossibilità a eseguire le attività richieste.
  • Interfaccia di avvio del failover: interfaccia HTTP(S) per promuovere il server di standby selezionato come nuovo server in background senza causare alcuna interruzione del servizio.
Attenersi alla seguente procedura:
  1. Installare Apache Tomcat 8.5.43 sui server in background e su tutti i server di standby.
    Accertarsi che Tomcat utilizzi JRE 1.8 e che non utilizzi il numero di porta configurato per i componenti di CA SDM.
  2. (Facoltativo) Configurare SSL sui server Tomcat che sono stati installati. Per ulteriori informazioni sulla configurazione SSL, consultare Modalità di configurazione dell'autenticazione SSL.
  3. Accedere al server in background.
  4. Distribuire il servlet di stato. Completare le seguenti attività:
    1. Copiare il file HealthServlet.war dalla cartella $NX_ROOT/samples/HealthServlet alla cartella
      TOMCAT_HOME
      /webapps.
    2. Riavviare Tomcat.
    Il file HealthServlet.war viene distribuito nella cartella webapps. Per confermare la distribuzione, verificare che la cartella HealthServlet sia stata creata nella stessa cartella di webapps.
    Una volta completata correttamente la distribuzione, il servlet di stato è pronto a eseguire le verifiche dello stato. Ciò include il controllo dello stato di SLUMP e dei processi di CA SDM che sono definiti nel file health.xml. Il file health.xml si trova nella posizione seguente:
    TOMCAT_HOME/webapps/HealthServlet/WEB-INF/classes
  5. (Facoltativo) Personalizzare health.xml in base alle esigenze dell'organizzazione. Ad esempio, si desidera monitorare il processo webengine. Aggiungere il processo nel file health.xml con il nome tag corretto, come definito in CA SDM. Completare i seguenti passaggi per individuare il nome tag:
    1. Aprire i file pdm_startup.i e pdm_startup dalla directory $NX_ROOT/pdmconf.
    2. Cercare il processo che si desidera controllare in ambedue i file.
    3. Trovare il nome tag corrispondente facendo corrispondere le variabili in ambedue i file.
      Ad esempio, il processo webengine è definito nel file pdm_startup.i come indicato di seguito:
      #define WEBENGINE(_TAG,_HOST,_SLUMP_NAME,_DOMSRVR, _CFG, _WEBDIRECTOR, _RPC_NAME)
      Il processo webengine è definito nel file pdm_startup come indicato di seguito:
      WEBENGINE(webengine, $NX_LOCAL_HOST, web:local, domsrvr, $NX_ROOT/bopcfg/www/web.cfg, "", "rpc_srvr:%h")
      Dall'esempio possiamo scoprire che il nome tag per il processo webengine è webengine.
      Per creare un nuovo processo, il processo esistente viene disabilitato nel file pdm_startup e vengono aggiunte nuove voci. Accertarsi di cercare il nome tag nelle nuove voci di processo.
      Se si modifica health.xml, verificare che il file XML non presenti alcun errore e riavviare Tomcat in modo da applicare le modifiche apportate al file XML.
  6. Eseguire i passaggi 4 e 5 per tutti i server di standby.
  7. Configurare lo strumento di terze parti selezionato per monitorare lo stato del server in background a intervalli regolari. Per controllare lo stato, utilizzare l'URL HTTP seguente:
    http(s)://Background_server_name:port_number/HealthServlet/GetHealth
  8. Configurare lo strumento di terze parti selezionato per avviare una logica di failover quando lo stato del server in background peggiore. Si consiglia di configurare la logica di failover in modo da promuovere il server di standby come nuovo server in background. Utilizzare il servlet di failover seguente nella logica di failover:
    Si consiglia di configurare il servlet di failover su SSL con i privilegi di accesso concessi solo agli utenti predefiniti. Attenersi a questa raccomandazione in caso di configurazione di strumenti di terze parti per l'avvio del failover.
    http(s)://Standby_server_name:port_number/HealthServlet/FailoverServlet
    Il failover automatico è stato abilitato.
  9. Una volta completata correttamente la configurazione lo strumento di terze parti comincia a monitorare lo stato del server in background mediante l'URL del servlet di stato.
    • Ogni tipo di server ha il proprio insieme di processi. Se SLUMP e tutti i processi di CA SDM funzionano correttamente, lo strumento di terze parti riceve una risposta HTTP 200 dal server in background con un payload predefinito:
      AA-Server-Status: All OK! AA-Server-Role: BG
    • Se SLUMP o uno dei i processi di CA SDM (elencati in health.xml) smette di funzionare correttamente e non può riprendere la sua attività, lo strumento di terze parti riceve una risposta HTTP 503 dal server in background con un payload predefinito, come indicato di seguito:
      AA-Server-Status: NOT OK! AA-Server-Role: BG
  10. Se riceve la risposta HTTP 503, lo strumento di terze parti avvia automaticamente la logica di failover.