Che cos'è il cluster Expressway e come funziona

Introduzione

In questo documento viene descritto come i cluster di Expressway sono progettati per estendere la resilienza e la capacità di un'installazione di Expressway.  

Premesse

Capacità. Il cluster Expressway può aumentare la capacità di una distribuzione Expressway di un fattore massimo di quattro, rispetto a una singola distribuzione Expressway. I peer Expressway in un cluster condividono l'utilizzo della larghezza di banda, nonché routing, zona, FindMe e altre configurazioni.

Resilienza. Il cluster Expressway può fornire ridondanza mentre un Expressway è in modalità manutenzione o nel caso in cui diventi inaccessibile a causa di un'interruzione della rete o dell'alimentazione o per altri motivi. Gli endpoint possono eseguire la registrazione a qualsiasi peer in un cluster. Se gli endpoint perdono la connessione con il peer iniziale, possono registrarsi nuovamente con un altro endpoint nel cluster.

Specifiche

Un'Expressway può far parte di un cluster composto da un massimo di sei Expressway. Quando si crea un cluster, viene nominato un peer come principale, dal quale la relativa configurazione viene replicata negli altri peer. Ogni peer Expressway nel cluster deve avere le stesse funzionalità di routing. Se qualsiasi peer Expressway può instradare una chiamata a una destinazione, si presuppone che tutti i peer Expressway nel cluster possano instradare una chiamata a tale destinazione.

Capacità

Dopo quattro peer non si verifica alcun aumento di capacità. In un cluster a sei peer, ad esempio, la quinta e la sesta Expressways non aggiungono ulteriore capacità di chiamata al cluster. La resilienza è migliorata con i peer in più, ma non con la capacità.

• Per le macchine virtuali di piccole dimensioni (VM), il cluster è destinato solo alla ridondanza e non alla scalabilità e non consente di ottenere guadagni di capacità dal cluster.
• La capacità basata sulla configurazione cluster a 4 peer è illustrata nell'immagine seguente:

Elementi importanti della pagina

Requisiti

• Conoscenze base di Secure Shell (SSH)
• Un cluster deve contenere solo nodi Expressway-C o solo nodi Expressway-E.
• Tutti i peer devono utilizzare la stessa versione del software.
• Tutti i peer utilizzano una piattaforma hardware, un accessorio o una macchina virtuale (VM) con funzionalità equivalenti.
• Expressway supporta un ritardo di andata e ritorno fino a 80 ms.
• La modalità H323 è attivata su ciascun peer.
• In tutti i peer è installato lo stesso insieme di chiavi di opzione, con le eccezioni seguenti:

• Per Video Control Server (VCS): Licenze di chiamata trasversali e non trasversali
• Per Expressway: Sessioni Rich Media
• Per Expressway: Licenze per la registrazione di sistemi desktop e per sistemi room

Tutte le altre chiavi di licenza devono essere identiche in ogni peer.

• Tra i peer del cluster non deve essere presente NAT (Network Address Translation).

Nota: Se Expressway-E utilizza un controller NIC (Network Interface Controller) singolo, deve utilizzare l'IP pubblico. Se Expressway-E utilizza una doppia NIC, è necessario utilizzare l'interfaccia interna per creare il cluster.

• È necessario configurare l'indirizzo IP, il DNS (Domain Name Service) e il protocollo NTP (Network Time Protocol). 

Connessioni e porte cluster

Configurazioni

Crea nuovo cluster

1. Aprire l'interfaccia Web di Expressway.
2. Selezionare Sistema > Clustering.
3. Immettere i valori successivi:

Nota: È necessario creare un cluster di un peer (primario) e riavviare il primario prima di aggiungere altri peer. È possibile aggiungere altri peer dopo aver stabilito un cluster di uno.

Primario configurazione: 1

Versione IP cluster: Scegliere IPv4 o IPv6 in base allo schema dell'indirizzo di rete.

Opzioni modalità di verifica TLS: Permissivo (impostazione predefinita) o Applica.

       Permissivo significa che i peer non convalidano i certificati degli altri peer quando vengono stabilite le connessioni TLS (Transport Layer Security) interne al cluster.

       L'imposizione è più sicura, ma richiede che ogni peer disponga di un certificato valido e che l'Autorità di certificazione (CA) sia considerata attendibile da tutti gli altri peer.

Indirizzo peer 1: Immettere l'indirizzo di Expressway (peer primario). Se la modalità di verifica TLS è impostata su Applica, è necessario immettere un nome di dominio completo (FQDN) corrispondente al nome comune (CN) del soggetto o a un nome alternativo del soggetto (SAN) nel certificato del peer.

4. Selezionare Salva.
5. Riavviare il server.
6. Passare a Manutenzione > Opzioni di riavvio, quindi selezionare Riavvia e confermare OK.
7. Verificare che il certificato sia valido, come illustrato nell'immagine seguente:

Aggiungi altri peer al cluster

 

Per aggiungere un peer aggiuntivo, eseguire la procedura seguente:

1. Passare a Sistema > Clustering in Expressway principale.
2. Nel primo campo vuoto immettere l'indirizzo del nuovo peer di Expressway.
3. Selezionare Salva.
4. Il peer 1 deve indicare Questo sistema. Il nuovo peer deve indicare Sconosciuto e quindi con un aggiornamento deve indicare Non riuscito perché non è stato ancora aggiunto completamente al cluster.
5. Passare a Sistema > Clustering su uno dei peer subordinati già presenti nel cluster e modificare i campi successivi:
   
   
   
   
6. Ripetere il passaggio precedente per ogni peer subordinato già presente nel cluster.
7. Selezionare Salva.
8. Expressway genera un avviso di errore di comunicazione del cluster. L'allarme scompare dopo il riavvio richiesto.
9. Riavviare Expressway.
10. Dopo il riavvio, attendere circa 2 minuti. Questa è la frequenza con cui la configurazione viene copiata dal server primario.
11. Convalidare lo stato del database cluster.
    
    
12. Verificare che la configurazione sia replicata in un peer subordinato.

Applica verifica TLS

Attenzione: Prima di procedere, verificare che le SAN dei certificati contengano gli FQDN presenti nei campi dell'indirizzo Peer N. Prima di procedere, è necessario visualizzare messaggi di stato verdi per il clustering e il certificato accanto a ogni campo indirizzo.  

1. Sul peer primario impostare la modalità di verifica TLS su Enforce.

Attenzione: Viene visualizzato un avviso se i certificati non sono validi e impedisce al cluster di funzionare correttamente nella modalità di verifica TLS applicata.

2. La nuova modalità di verifica TLS viene replicata in tutto il cluster.
3. Verificare che la modalità di verifica TLS sia ora Imponi l'uno sull'altro peer.
4. Selezionare Salva e riavviare il peer primario.
5. Dopo che il peer primario è tornato in linea, riavviare ogni peer uno alla volta.
6. Attendere che il cluster venga stabilizzato e verificare che lo stato Clustering e Certificato sia verde per tutti i peer.

Modificare il peer primario

Nota: È possibile eseguire questo processo anche se il peer primario corrente non è accessibile.

1. Nel nuovo Expressway primario, passare a Sistema > Clustering.
2. Dal menu a discesa Configuration primary (Configurazione principale), selezionare il numero ID della voce peer This system (Questo sistema).
3. Selezionare Salva.

Nota: Durante l'esecuzione di questo processo, ignorare gli avvisi in Expressway che segnalano mancata corrispondenza del cluster primario o errori di replica cluster.

4. In tutti gli altri peer di Expressway, iniziare con il vecchio peer primario (se ancora accessibile).
5. Passare a Sistema > Clustering.
6. Dal menu a discesa Configurazione principale selezionare il numero ID della nuova Expressway principale.
7. Selezionare Salva.
8. Confermare che la modifica al database primario di configurazione è stata accettata, passare a Sistema > Clustering e aggiornare la pagina.
9. Se Expressways non ha accettato la modifica, ripetere la stessa procedura.
10. Verificare che lo stato del database cluster sia Attivo.

Cambia cluster per utilizzare FQDN

Nota: Durante l'esecuzione di questa procedura, le comunicazioni tra peer sono temporaneamente compromesse, pertanto si prevede che gli allarmi persistano fino al completamento delle modifiche e fino a quando il cluster concorda i nuovi indirizzi.

1. Accedere a tutti i peer del cluster e selezionare Sistema > Clustering.
2. Scegliere l'indirizzo peer da modificare. si consiglia di iniziare con un indirizzo peer 1.
3. Per ogni peer del cluster eseguire la procedura seguente:
4. Modificare il campo Indirizzo peer scelto dall'indirizzo IP nel relativo FQDN.
5. Selezionare Salva.
6. Passare al peer identificato dall'indirizzo peer modificato e riavviare il server.
7. Attendere la risoluzione di eventuali avvisi temporanei del cluster.
8. Scegliere l'indirizzo peer successivo da modificare, quindi ripetere i passaggi da 3 a 7.
9. Ripetere questa procedura fino a modificare tutti gli indirizzi dei peer e riavviare tutti i peer.

Mapping indirizzi cluster per Expressway-E

Per implementazioni sicure come ad esempio Mobile e Remote Access (MRA), ogni peer Expressway-E deve disporre di un certificato con una SAN che contenga il relativo FQDN pubblico. L'FQDN è mappato nel DNS pubblico all'indirizzo IP pubblico di Expressway-E.

Nota: Se si desidera semplicemente inserire in un cluster i peer Cisco Expressway-E e non è necessaria la verifica TLS tra di essi, è possibile creare il cluster con gli indirizzi IP privati dei nodi. Non è necessario Mapping indirizzi cluster.

I mapping di indirizzi del cluster sono coppie FQDN:IP condivise nel cluster, una coppia per ogni peer. I peer consultano la tabella di mapping prima di eseguire query su DNS e, se trovano una corrispondenza, non eseguono query su DNS.

Se si sceglie di applicare TLS, i peer devono anche leggere i nomi dal campo SAN dei rispettivi certificati e verificare ogni nome sul lato FQDN del mapping.

È consigliabile immettere i mapping nel peer primario. I mapping di indirizzi vengono replicati in modo dinamico nel cluster. Per configurare Mapping indirizzi, eseguire la procedura seguente:

1. Passare a Sistema > Clustering nel peer primario e modificare l'elenco a discesa Mapping indirizzi cluster abilitato in Attivo (il valore predefinito è Disattivato). Vengono visualizzati i campi Mapping indirizzi cluster.
2. Modificare i mapping in modo che gli FQDN pubblici dei peer Expressway-E corrispondano agli indirizzi IP delle schede NIC interne.
3. Selezionare Salva.

Attenzione: Non provare a utilizzare il DNS pubblico per mappare gli FQDN pubblici dei peer ai relativi indirizzi IP privati. Questa azione può interrompere la connettività esterna.  

Cluster con NIC singola

Se si desidera che i peer Expressway-E di un cluster verifichino le rispettive identità tramite certificati, è possibile consentire loro di utilizzare il DNS per risolvere gli FQDN dei peer del cluster nei relativi indirizzi IP pubblici. Questo è un modo perfettamente accettabile per formare un cluster se i nodi Expressway-E hanno:

• Una sola NIC
• Nessun NAT statico configurato
• Indirizzi IP di routing

Risoluzione dei problemi

Cosa attiva un ripristino di fabbrica?

Se si cancellano tutti i campi dell'indirizzo del peer dalla pagina Clustering e si salva la configurazione, Expressway per impostazione predefinita esegue il ripristino automatico al successivo riavvio. Ciò significa che tutte le configurazioni vengono eliminate, ad eccezione della configurazione di rete di base per l'interfaccia LAN1 (Local Area Network 1), che include tutte le configurazioni eseguite dopo la cancellazione dei campi e il successivo riavvio.

Suggerimento: Se è necessario evitare la reimpostazione di fabbrica, ripristinare i campi dell'indirizzo peer del cluster. Sostituire gli indirizzi peer originali nello stesso ordine, quindi salvare la configurazione per cancellare il banner.

Il ripristino in fabbrica viene attivato automaticamente al riavvio del peer per rimuovere i dati riservati e la configurazione del cluster. Il ripristino cancella tutte le configurazioni ad eccezione delle informazioni di rete di base successive:

Nota: Se si utilizza l'opzione con due schede NIC, tenere presente che qualsiasi configurazione LAN2 viene rimossa completamente dal reset.

• Indirizzi IP · Account e password di amministrazione e root
• chiavi SSH
• Tasti opzione
• Accesso HTTPS (Hypertext Transfer Protocol Secure) abilitato
• Accesso SSH abilitato

Nota: Dalla versione X12.6 il ripristino del factory rimuove il certificato server, la chiave privata associata e le impostazioni dell'archivio di attendibilità CA dal peer. Nelle versioni precedenti del software Expressway queste impostazioni vengono mantenute.

Errore di ripristino in fabbrica

Il ripristino in fabbrica può avere esito negativo. Questo problema può verificarsi se Expressway è una nuova appliance di virtualizzazione aperta (OAV) installata e non è stata aggiornata. 

Per risolvere questo problema, seguire una delle opzioni seguenti:

• Aggiornare tutti i nodi alla stessa versione software con il file tar.gz. Al termine del processo di aggiornamento, riavviare il server, quindi attivare il programma di ripristino.
• Caricare il file tar.gz direttamente nella cartella di ripristino con WinSCP (/mnt/harddisk/factory-reset/). Quindi, riavviare per avviare il reset di fabbrica o eseguire il reset di fabbrica dalla CLI.

Nota: Assicurarsi di eseguire i backup corretti prima di un aggiornamento, di una modifica del certificato o di un avviso di ripristino in fabbrica.

Riavvia sequenza

Se è necessario riavviare il cluster o un peer, eseguire la procedura seguente:

1. Riavviare il peer primario e attendere che sia accessibile tramite interfaccia Web.
2. Convalidare lo stato di replica del cluster sul server primario e lo stato di tutti i peer. Attendere alcuni minuti, aggiornare occasionalmente le interfacce Web del peer.
3. Riavviare gli altri peer, se necessario, uno alla volta. Ogni volta, attendere alcuni minuti dopo l'accesso e convalidare lo stato della replica.

Nota: Potrebbe essere necessario attendere circa 5 minuti dopo aver apportato modifiche al cluster prima che i peer di Expressway segnalino lo stato di operazione riuscita.

Avvisi e avvisi

Gli allarmi degli errori del cluster sono visualizzati nel formato: Errore di replica cluster: (dettagli) è richiesta la sincronizzazione manuale della configurazione, di seguito sono riportati alcuni esempi:

• Errore di replica cluster: è necessaria la sincronizzazione manuale della configurazione.
• Errore di replica cluster: impossibile trovare il file di configurazione peer primario o del subordinato. è necessaria la sincronizzazione manuale della configurazione.
• Errore di replica cluster: ID primario di configurazione incoerente. È necessaria la sincronizzazione manuale della configurazione.
• Errore di replica cluster: la configurazione del peer è in conflitto con la configurazione del server primario. è necessaria la sincronizzazione manuale della configurazione.

Se un'Expressway subordinata segnala l'avviso menzionato, eseguire la procedura seguente:

1. Accedere come amministratore su un'interfaccia SSH o CLI.
2. Eseguire il comando successivo: xcommand ForceConfigUpdate

Nota: Assicurarsi di eseguire i backup corretti prima di un aggiornamento, di una modifica del certificato o di un avviso di ripristino in fabbrica.

3. Con questo comando viene eliminata la configurazione Expressway subordinata, quindi viene forzato l'aggiornamento della relativa configurazione da Expressway primario.

Se il problema persiste, potrebbe essere correlato alla chiave di crittografia per peer cluster. Generalmente si verifica quando i peer vengono aggiornati nell'ordine errato e i peer subordinati non vengono sincronizzati con il peer primario. Se xcommand forceconfigupdate non funziona, eseguire la procedura seguente:

1. Accedere al peer primario e verificare che si trovi in uno stato valido.
2. Verificare che nella configurazione del cluster il peer sia indicato come primario.
3. Aggiornare di nuovo il database primario, utilizzando lo stesso pacchetto utilizzato in origine per l'aggiornamento.

L'avviso di replica viene cancellato dopo l'aggiornamento e il riavvio del peer primario. Questo in genere accade entro dieci minuti dal riavvio, ma potrebbe richiedere fino a venti minuti dopo il riavvio.

Allarmi comuni

Configurazione cluster non valida: La modalità H.323 deve essere attivata - il clustering utilizza le comunicazioni H.323 tra peer.

Per cancellare questo allarme e assicurarsi che la modalità H.323 sia attiva, selezionare Configurazione > Protocolli > H.323.

Errore del database Expressway: Contattare il rappresentante del supporto Cisco.

Per risolvere questo tipo di allarme, procedere come segue:

1. Acquisire un'istantanea del sistema e fornirla al rappresentante del supporto.
2. Rimuovere Expressway dal cluster.
3. Ripristinare il database di Expressway da un backup eseguito in precedenza su Expressway.
4. Aggiungere di nuovo Expressway al cluster.

Un secondo metodo è possibile se il database non viene ripristinato:

1. Crea un'istantanea del sistema e forniscila al Technical Assistance Center (TAC).
2. Rimuovere Expressway dal cluster.
3. Accedere come utente root ed eseguire il comando successivo clusterdb_dies_and_purge_data.sh.
4. Ripristinare il database di Expressway da un backup eseguito in precedenza su Expressway.
5. Aggiungere di nuovo Expressway al cluster. 

Nota: Assicurarsi di eseguire i backup corretti prima di un aggiornamento, di una modifica del certificato o di un avviso di ripristino in fabbrica.

Attenzione: clusterdb_dies_and_purge_data.sh è pericoloso quanto sembra. Utilizzare questa opzione come ultima risorsa.

Problemi correlati alle chiavi di sistema

Nota: Le informazioni seguenti si applicano alla versione X14 in poi.

Impossibile aggiornare i file di chiave. Gli allarmi vengono generati in Expressways in uno scenario a nodo singolo.

Seguire la procedura seguente per risolvere questo tipo di allarme:

1. Accedere come amministratore dalla CLI (disponibile per impostazione predefinita su SSH e tramite la porta seriale sulle versioni hardware).
2. Eseguire il comando successivo: xCommand ForceSystemKeyUpdate.

Impossibile aggiornare i file di chiave. Gli avvisi vengono generati in Expressways in uno scenario cluster.

Seguire la procedura seguente per risolvere questo tipo di allarme:

1. Accedere al nodo come amministratore dalla CLI (disponibile per impostazione predefinita tramite SSH e tramite la porta seriale sulle versioni hardware) dove questo allarme non viene generato.
2. Eseguire il comando successivo: xCommand ForceSystemKeyUpdate.

Dettagli log

Come per qualsiasi altro accesso a Expressway, è possibile abilitare i registri di diagnostica con i dump TCP.

In uno stato normale, la sincronizzazione del database sul nodo master viene visualizzata nei log come output successivo:

2020-07-21T15:16:50.321-05:00 expc01 replication: UTCTime="2020-07-21 20:16:50,321" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(270)" Detail="Starting synchronisation"
2020-07-21T15:16:50.330-05:00 expc01 replication: UTCTime="2020-07-21 20:16:50,330" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationutils(750)" AlternateIPAddresses="[u'(10.15.13.15 expc01)', u'(10.15.13.16 expc02)']" ConfigurationMasterIndex="0" LocalPeerIndex="0" 
2020-07-21T15:16:50.433-05:00 expc01 replication: UTCTime="2020-07-21 20:16:50,433" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(257)" Detail="This peer is the cluster master, local configuration has already been replicated to the other peers"
2020-07-21T15:16:50.437-05:00 expc01 replication: UTCTime="2020-07-21 20:16:50,437" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(336)" Detail="Synchronisation completed successfully"

Dal punto di vista del nodo peer viene visualizzato come output successivo:

2020-07-21T15:16:46.900-05:00 expc02 replication: UTCTime="2020-07-21 20:16:46,899" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(270)" Detail="Starting synchronisation"
2020-07-21T15:16:46.908-05:00 expc02 replication: UTCTime="2020-07-21 20:16:46,908" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationutils(750)" AlternateIPAddresses="[u'(10.15.13.15 expc01)', u'(10.15.13.16 expc02)']" ConfigurationMasterIndex="0" LocalPeerIndex="1" 
2020-07-21T15:16:46.947-05:00 expc02 replication: UTCTime="2020-07-21 20:16:46,946" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(254)" Detail="This peer is not the cluster master, local configuration is already up to date"
2020-07-21T15:16:46.950-05:00 expc02 replication: UTCTime="2020-07-21 20:16:46,950" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(336)" Detail="Synchronisation completed successfully"

Nell'output successivo viene visualizzata una disconnessione peer:

2020-08-12T14:57:43.353-05:00 expc01 UTCTime="2020-08-12 19:57:43,353" Module="developer.clusterdb.cdb" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.159.0>" Detail="Processed mnesia_down event from accessible node" Node="clusterdb@expc02.apolo.local"
2020-08-12T14:57:43.354-05:00 expc01 UTCTime="2020-08-12 19:57:43,353" Module="developer.clusterdb.cdb" Level="ERROR" Node="clusterdb@expc01.apolo.local" PID="<0.159.0>" Detail="Inconsistent Database" Context="from mnesia system - mnesia down" Node="clusterdb@expc02.apolo.local"
2020-08-12T14:57:43.354-05:00 expc01 UTCTime="2020-08-12 19:57:43,354" Module="developer.clusterdb.cdb" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.159.0>" Detail="Connecting database on mnesia running_partitioned_network event" Node="clusterdb@expc02.apolo.local"
2020-08-12T14:57:43.354-05:00 expc01 UTCTime="2020-08-12 19:57:43,354" Module="developer.clusterdb.cdb" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.14215.425>" Detail="Ready to perform node connection transaction" Node="clusterdb@expc02.apolo.local"
2020-08-12T14:57:43.354-05:00 expc01 UTCTime="2020-08-12 19:57:43,354" Module="developer.clusterdb.cdb" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.14215.425>" Detail="Running node connection transaction" Node="clusterdb@expc02.apolo.local"
2020-08-12T14:57:43.354-05:00 expc01 UTCTime="2020-08-12 19:57:43,354" Module="developer.clusterdb.synchronise" Level="WARN" Node="clusterdb@expc01.apolo.local" PID="<0.14215.425>" Detail="Failed connecting to node" Node="clusterdb@expc02.apolo.local" Reason="{ badrpc, { EXIT, { aborted, { noproc, { gen_server, call, [ kernel_safe_sup, { start_child, { dets_sup, { dets_sup, start_link,  }, permanent, 1000, supervisor, [ dets_sup ] } }, infinity ] } } } } }"
2020-08-12T14:57:43.524-05:00 expc01 alarm: Level="WARN" Event="Alarm Raised" Id="20006" UUID="0f96695e-d954-4f6f-85c1-2ef1eae6f764" Severity="warning" Detail="Cluster database communication failure: The database is unable to replicate with one or more of the cluster peers" UTCTime="2020-08-12 19:57:43,524"
2020-08-12T14:57:43.771-05:00 expc01 alarm: Level="WARN" Event="Alarm Raised" Id="20004" UUID="3bca6888-f622-11df-93be-07cc953d7b99" Severity="warning" Detail="Cluster communication failure: The system is unable to communicate with one or more of the cluster peers" UTCTime="2020-08-12 19:57:43,771"

2020-08-12T14:57:53.872-05:00 expc01 tvcs: UTCTime="2020-08-12 19:57:53,871" Module="network.h323" Level="INFO":  Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS SCI  SeqNum=52319 Retransmit=True"
2020-08-12T14:57:54.872-05:00 expc01 tvcs: UTCTime="2020-08-12 19:57:54,871" Module="network.h323" Level="INFO":  Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS LRQ  SeqNum=52320 Retransmit=True"
2020-08-12T14:57:56.872-05:00 expc01 tvcs: UTCTime="2020-08-12 19:57:56,871" Module="network.h323" Level="INFO":  Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS LRQ  SeqNum=52320 Retransmit=True"
2020-08-12T14:57:57.871-05:00 expc01 tvcs: UTCTime="2020-08-12 19:57:57,871" Module="network.h323" Level="INFO":  Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS SCI  SeqNum=52319 Retransmit=True"
2020-08-12T14:57:58.871-05:00 expc01 tvcs: Event="External Server Communications Failure" Reason="gatekeeper timed out" Service="NeighbourGatekeeper" Detail="name:10.15.13.16:1719" Level="1" UTCTime="2020-08-12 19:57:58,871"
2020-08-12T14:57:58.871-05:00 expc01 tvcs: UTCTime="2020-08-12 19:57:58,871" Module="network.h323" Level="INFO":  Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS LRQ  SeqNum=52320 Timeout=True"
2020-08-12T14:57:59.601-05:00 expc01 UTCTime="2020-08-12 19:57:59,601" Module="developer.clusterdb.peernameresolver" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.145.0>" Detail="Triggering forced peer update of peers which failed DNS and queueing next run" Queue-Time-ms="300000"
2020-08-12T14:58:01.871-05:00 expc01 tvcs: UTCTime="2020-08-12 19:58:01,871" Module="network.h323" Level="INFO":  Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS SCI  SeqNum=52319 Timeout=True"

La modifica in TLS Enforcement sul nodo Master viene mostrata nell'output successivo:

2020-08-12T15:13:24.970-05:00 expc01 UTCTime="2020-08-12 20:13:24,969" Module="developer.cdbtable.cdb.clusterConfiguration" Level="DEBUG" Node="clusterdb@expc01.apolo.local" PID="<0.345.0>" Detail="Inserting into table" TableName="clusterConfiguration"
2020-08-12T15:13:24.976-05:00 expc01 UTCTime="2020-08-12 20:13:24,975" Event="System Configuration Changed" Node="clusterdb@expc01.apolo.local" PID="<0.345.0>" Detail="xconfiguration clusterConfiguration tls_verify - changed from: Permissive to: Enforcing"
2020-08-12T15:13:24.976-05:00 expc01 httpd[15060]: web: Event="System Configuration Changed" Detail="configuration/cluster/tls_verify - changed from: 'Permissive' to: 'Enforcing'" Src-ip="10.15.13.30" Src-port="53155" User="admin" Level="1" UTCTime="2020-08-12 20:13:24" 
2020-08-12T15:13:24.979-05:00 expc01 management: UTCTime="2020-08-12 20:13:24,978" Module="developer.management.databasemanager" Level="INFO" CodeLocation="databasemanager(312)" Detail="Cluster configuration change detected"
2020-08-12T15:13:24.980-05:00 expc01 UTCTime="2020-08-12 20:13:24,980" Module="developer.cdbtable.cdb.clusterConfiguration" Level="DEBUG" Node="clusterdb@expc01.apolo.local" PID="<0.345.0>" Detail="Inserting into table" TableName="clusterConfiguration"
2020-08-12T15:13:24.986-05:00 expc01 management: UTCTime="2020-08-12 20:13:24,986" Module="developer.management.databasemanager" Level="INFO" CodeLocation="databasemanager(405)" Detail="TLS Verify change status" Startup="False" New="True"
2020-08-12T15:13:25.022-05:00 expc01 UTCTime="2020-08-12 20:13:25,022" Event="System Configuration Changed" Node="clusterdb@expc01.apolo.local" PID="<0.557.0>" Detail="xconfiguration alternatesConfiguration - Changed"
2020-08-12T15:13:25.022-05:00 expc01 UTCTime="2020-08-12 20:13:25,022" Module="developer.clusterdb.peernameresolver" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.145.0>" Detail="Notifying databasemanager (Management Framework)"
2020-08-12T15:13:25.022-05:00 expc01 UTCTime="2020-08-12 20:13:25,022" Module="developer.clusterdb.alternatesmanager" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.142.0>" Detail="alternate peer changed info recieved"
2020-08-12T15:13:25.031-05:00 expc01 UTCTime="2020-08-12 20:13:25,031" Event="System Configuration Changed" Node="clusterdb@expc01.apolo.local" PID="<0.557.0>" Detail="xconfiguration alternatesConfiguration - Changed" 
2020-08-12T15:13:25.192-05:00 expc01 management: UTCTime="2020-08-12 20:13:25,192" Module="developer.diagnostics.alarmmanager" Level="INFO" CodeLocation="alarmmanager(173)" Detail="Raising alarm" UUID="e2b8e3d1-b731-4d7d-b606-4682a8f0c2e6" Parameters="null"
2020-08-12T15:13:25.195-05:00 expc01 management: Level="WARN" Event="Alarm Raised" Id="20007" UUID="e2b8e3d1-b731-4d7d-b606-4682a8f0c2e6" Severity="warning" Detail="Restart required: Cluster configuration has been changed, however a restart is required for this to take effect" UTCTime="2020-08-12 20:13:25,194"

Dal punto di vista del nodo Peer viene visualizzato nell'output successivo:

2020-08-12T15:13:24.976-05:00 expc02 UTCTime="2020-08-12 20:13:24,976" Event="System Configuration Changed" Node="clusterdb@expc02.apolo.local" PID="<0.390.0>" Detail="xconfiguration clusterConfiguration tls_verify - changed from: Permissive to: Enforcing"
2020-08-12T15:13:24.979-05:00 expc02 management: UTCTime="2020-08-12 20:13:24,978" Module="developer.management.databasemanager" Level="INFO" CodeLocation="databasemanager(312)" Detail="Cluster configuration change detected"
2020-08-12T15:13:24.982-05:00 expc02 management: UTCTime="2020-08-12 20:13:24,982" Module="developer.management.databasemanager" Level="INFO" CodeLocation="databasemanager(405)" Detail="TLS Verify change status" Startup="False" New="True"
2020-08-12T15:13:25.040-05:00 expc02 UTCTime="2020-08-12 20:13:25,040" Module="developer.clusterdb.peernameresolver" Level="INFO" Node="clusterdb@expc02.apolo.local" PID="<0.136.0>" Detail="Notifying databasemanager (Management Framework)"
2020-08-12T15:13:25.040-05:00 expc02 UTCTime="2020-08-12 20:13:25,040" Module="developer.clusterdb.alternatesmanager" Level="INFO" Node="clusterdb@expc02.apolo.local" PID="<0.143.0>" Detail="alternate peer changed info recieved"
2020-08-12T15:13:25.041-05:00 expc02 UTCTime="2020-08-12 20:13:25,041" Event="System Configuration Changed" Node="clusterdb@expc02.apolo.local" PID="<0.543.0>" Detail="xconfiguration alternatesConfiguration - Changed"
2020-08-12T15:13:25.042-05:00 expc02 UTCTime="2020-08-12 20:13:25,042" Event="System Configuration Changed" Node="clusterdb@expc02.apolo.local" PID="<0.543.0>" Detail="xconfiguration alternatesConfiguration - Changed"
2020-08-12T15:13:25.046-05:00 expc02 UTCTime="2020-08-12 20:13:25,046" Module="developer.clusterdb.alternatesmanager" Level="INFO" Node="clusterdb@expc02.apolo.local" PID="<0.143.0>" Detail="alternate peer changed info recieved"
2020-08-12T15:13:25.047-05:00 expc02 UTCTime="2020-08-12 20:13:25,046" Module="developer.clusterdb.peernameresolver" Level="INFO" Node="clusterdb@expc02.apolo.local" PID="<0.136.0>" Detail="Notifying databasemanager (Management Framework)"
2020-08-12T15:13:25.047-05:00 expc02 UTCTime="2020-08-12 20:13:25,047" Event="System Configuration Changed" Node="clusterdb@expc02.apolo.local" PID="<0.543.0>" Detail="xconfiguration alternatesConfiguration - Changed"
2020-08-12T15:13:25.049-05:00 expc02 UTCTime="2020-08-12 20:13:25,049" Event="System Configuration Changed" Node="clusterdb@expc02.apolo.local" PID="<0.543.0>" Detail="xconfiguration alternatesConfiguration - Changed"
 2020-08-12T15:13:25.136-05:00 expc02 management: UTCTime="2020-08-12 20:13:25,136" Module="developer.diagnostics.alarmmanager" Level="INFO" CodeLocation="alarmmanager(173)" Detail="Raising alarm" UUID="e2b8e3d1-b731-4d7d-b606-4682a8f0c2e6" Parameters="null"
2020-08-12T15:13:25.139-05:00 expc02 management: Level="WARN" Event="Alarm Raised" Id="20007" UUID="e2b8e3d1-b731-4d7d-b606-4682a8f0c2e6" Severity="warning" Detail="Restart required: Cluster configuration has been changed, however a restart is required for this to take effect" UTCTime="2020-08-12 20:13:25,139"

Video

I video successivi potrebbero essere utili:

Come creare e aggiungere un peer a un cluster Expressway

Rimozione di un peer da un cluster Expressway

Correzione dell'errore di replica di Expressway "Conflitti di configurazione peer con primario"

Procedura di riavvio del cluster Expressway

Come aggiornare un cluster ExpresswayGenerazione di CSR per Autorità registrazione integrità/Expressway in cluster