Configurare il cluster di database del bridge di chiamate di Cisco Meeting Server

Introduzione

In questo documento viene descritta la procedura per configurare il clustering del database (DB) su Cisco Meeting Server (CMS) o Acano Call Bridge (CB).

Prerequisiti

Requisiti

• Cisco consiglia di disporre di almeno 3 nodi CMS per poter creare un cluster di database valido

Nota: È consigliabile disporre di un numero dispari di nodi del cluster di database in quanto è importante per la selezione del master e il meccanismo di failover attivo. Un altro motivo è che il nodo del database master sarebbe il nodo che dispone di connessioni alla maggior parte del database nel cluster. In un cluster di database è possibile avere un massimo di 5 nodi.

•  Porta 5432 aperta sul firewall

Nota: il master del cluster di database resta in ascolto sulla porta 5432 per le connessioni dai nodi client. Se esiste un firewall (FW) tra i nodi, verificare che questa porta sia aperta.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Configurazione

Esistono due tipi di certificati per il clustering del database:

1. Cliente: Il certificato client, come suggerito dal nome, viene utilizzato dai client DB per la connessione al server DB (master). Il certificato deve contenere la stringa postgres nel campo Nome comune (CN).

2. Server: Il certificato del server, come suggerito dal nome, viene utilizzato dal server DB per connettersi al database postgres.

Parte 1. Creazione di certificati

1. Connettersi con SSH (Secure Shell) con le credenziali di amministratore al server MP.

2. Genera richiesta di firma del certificato (CSR):

     

r. Per il certificato client del cluster di database:

pki csr <nome base chiave/certificato> CN:postgres

Ad esempio: pki csr databasecluster_client CN:postgres

b. Per il certificato del server del cluster di database:

pki csr <nome_base_chiave/certificato> CN:<nome_dominio>

Ad esempio: pki csr databasecluster_server CN:vngtpres.aca

3. Inviare i CSR all'autorità di certificazione (CA) per la firma. Assicurarsi che la CA fornisca i certificati della CA radice (e di eventuali CA intermedie).

4. Caricare i certificati firmati, i certificati CA radice (e gli eventuali certificati CA intermedi) in tutti i nodi del database utilizzando un client SFTP (Secure File Transfer Protocol), ad esempio WinSCP.

Nota: La CN per la Parte A deve essere postgres e la Parte B può essere il nome di dominio del bridge di chiamate. Non sono richieste voci SAN (Subject Alternate Name).

Parte 2. Configurazione del bridge di chiamate

Sulla BC che esegue il database master, eseguire la procedura seguente:

1. Per selezionare l'interfaccia da utilizzare, immettere il comando:

cluster di database localnode a

Ciò consente di utilizzare l'interfaccia "a" per il clustering del database.

2. Definire i certificati del client, del server e della CA radice nonché le chiavi private che il cluster di database deve utilizzare con questi comandi:

certificati cluster di database <chiave_client> <crt_client> <crt_ca>

certificati cluster di database <chiave_server> <chiave_server> <chiave_client> <crt_client> <crt_ca>

Nota: Gli stessi certificati client e server possono essere utilizzati in altri nodi CB da inserire in un cluster quando si copiano le chiavi private e i certificati negli altri nodi. Ciò è possibile perché i certificati non contengono SAN che li legano a un bridge di chiamate specifico. È tuttavia consigliabile disporre di certificati singoli per ogni nodo del database.

 3. Inizializzare il database nel database locale come master per il cluster di database:

inizializzazione cluster di database

 4. Sui CallBridge che farebbero parte del database cluster e diventerebbero gli slave del database, eseguire questo comando dopo aver completato i passaggi 1 e 2 per la parte 2:

database cluster join <indirizzo IP CB principale>

Ad esempio: join del cluster di database <10.48.36.61>

In questo modo viene avviata la sincronizzazione del database e il database viene copiato dal peer master.

Nota: Il database locale esistente prima dell'avvio del comando database cluster join continuerà a esistere fino a quando il nodo non verrà rimosso dal database cluster. Pertanto, finché il nodo si trova nel cluster di database, il relativo database locale non viene utilizzato.

Esempio di rete

Verifica

Per verificare che la configurazione funzioni correttamente, consultare questa sezione.

Per controllare lo stato del database cluster, eseguire questo comando su uno dei nodi nel cluster di database:

stato del cluster di database

L'output è simile al seguente:

  Status                   : Enabled
  Nodes:
      10.48.36.61          : Connected Master
      10.48.36.118         : Connected Slave ( In Sync )
      10.48.36.182 (me)    : Connected Slave ( In Sync )
  Node in use              : 10.48.36.61

      Interface            : a

      Certificates
      Server Key           : dbclusterserver.key
      Server Certificate   : dbclusterserver.cer
      Client Key           : dbclusterclient.key
      Client Certificate   : dbclusterclient.cer
      CA Certificate       : vngtpRootca.cer
  Last command             : 'database cluster join 10.48.36.61' (Success)

Risoluzione dei problemi

Le informazioni contenute in questa sezione permettono di risolvere i problemi relativi alla configurazione.

Utilizzare questo comando, nella CLI, per visualizzare i log correnti relativi al clustering del database:

syslog follow

Gli output di log per il database contengono in genere la stringa postgres, ad esempio:

Mar 30 12:39:04 local0.warning DBMaster postgres[20882]:  [2-7] #011SQL statement "INSERT INTO domains(domain_id, domain_name, tenant_id, target, priority, passcode_separator) VALUES (inp_domain_id, inp_domain_name, inp_tenant_id, existing_target, inp_priority, inp_passcode_separator)"
Mar 30 12:39:04 local0.warning DBMaster postgres[20882]:  [2-8] #011PL/pgSQL function create_or_update_matching_domain(boolean,uuid,text,boolean,uuid,integer,integer,integer,text) line 61 at SQL statement
Mar 30 12:39:04 local0.warning DBMaster postgres[20882]:  [2-9] #011SQL statement "SELECT * FROM create_or_update_matching_domain(TRUE, inp_domain_id, inp_domain_name, TRUE, inp_tenant_id, inp_target_true, 0, inp_priority, inp_passcode_separator)"
Mar 30 12:39:04 local0.warning DBMaster postgres[20882]:  [2-10] #011PL/pgSQL function create_matching_domain(uuid,text,uuid,integer,integer,text) line 3 at SQL statement

L'agente di raccolta log CMS fornisce un'interfaccia utente semplice e intuitiva per raccogliere i log dal server CMS.

Di seguito sono riportati alcuni problemi e soluzioni tipici del database:

Problema: Errore dello schema del database in un peer non master

ERROR                    : Couldn't upgrade the schema
Status                   : Error

Nodes:
    10.48.54.75          : Connected Master
    10.48.54.76          : Connected Slave ( In Sync )
    10.48.54.119 (me)    : Connected Slave ( In Sync )
Node in use              : 10.48.54.75

Interface                : a

Certificates
  Server Key             : dbclusterServer.key
  Server Certificate     : dbserver.cer
  Client Key             : dbclusterClient.key
  Client Certificate     : dbclient.cer
  CA Certificate         : Root.cer

Last command             : 'database cluster upgrade_schema' (Failed)

Soluzione:

1. Eseguire innanzitutto questo comando per correggere l'errore:

errore di cancellazione del cluster di database

2. Seguire questo comando per aggiornare lo schema del database:

schema_aggiornamento cluster di database

3. Verificare quindi lo stato del clustering DB con:

stato del cluster di database

I log mostrano un output simile al seguente:

Mar 30 11:22:45 user.notice acanosrv05 schema_builder:  Upgrading schema with connect line 'connect_timeout=4 user=postgres host=127.0.0.1 port=9899 sslmode=verify-ca sslcert=/srv/pgsql/client.crt sslkey=/srv/pgsql/client.key sslrootcert=/srv/pgsql/ca.crt '

Mar 30 11:22:45 user.notice acanosrv05 schema_builder:  Using database name 'cluster'
Mar 30 11:22:45 user.notice acanosrv05 schema_builder:  schema build on database cluster complete
Mar 30 11:22:45 user.notice acanosrv05 schema_builder:  Using CiscoSSL 1.0.1u.4.13.322-fips  (caps 0x4FABFFFF)
Mar 30 11:22:45 user.notice acanosrv05 schema_builder:  Using 0x1000115F
Mar 30 11:22:45 user.notice acanosrv05 schema_builder:  INFO    : Waiting for database cluster to settle...
Mar 30 11:22:45 user.notice acanosrv05 schema_builder:  INFO    : Database cluster settled
Mar 30 11:22:45 user.notice acanosrv05 schema_builder:  Schema upgrade complete
Mar 30 11:22:45 user.info acanosrv05 dbcluster_watcher:  Operation Complete

Problema: I nodi peer non possono connettersi al nodo master del database

Mar 31 10:16:59 user.info acanosrv02 sfpool:  Health check 10.48.54.119: error (up = 1): could not connect to server: Connection refused|#011Is the server running on host "10.48.54.119" and accepting|#011TCP/IP connections on port 5432?|

Soluzione:

Per raccogliere le tracce per la risoluzione dei problemi di connessione, attenersi alla procedura seguente:

1.  Eseguire il comando pcap <interface> sul nodo non master (slave) e, dopo alcuni minuti, interrompere l'acquisizione con Ctrl-C.

2.  Connettersi al server con un client SFTP (Secure File Transfer Protocol) e scaricare il file .pcap dalla directory principale:

  

3. Aprire il file di acquisizione su Wireshark e filtrare sulla porta 5432 con tcp.port==5432 per controllare il traffico tra il peer non master e il master DB.

4. Se non è presente traffico di ritorno dal server, è probabile che un firmware blocchi la porta tra la posizione logica dei due server.

Di seguito viene riportata una tipica acquisizione di pacchetti da una connessione funzionante tra il client e il server:

Nell'esempio, l'IP del client è 10.48.54.119 e il server è 10.48.54.75.

Informazioni correlate

Per ulteriori informazioni sulla risoluzione dei problemi e per altre domande sul clustering di database, vedere le domande frequenti nei seguenti collegamenti:

• Perché è necessario posizionare i server di database in cluster in posizioni diverse?
• È presente un cluster di database e nel registro viene visualizzato un errore o un avviso relativo al database. Cosa devo fare
• Uno o più server di database non sono connessi o sono in stato di sincronizzazione. Cosa devo fare
• Cosa fare se non è disponibile un database master
• Come si sposta il database master
• Documentazione e supporto tecnico – Cisco Systems