Configurare il cluster di database del bridge di chiamate di Meeting Server (CMS)

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 primaria e il meccanismo di failover attivo. Un altro motivo è che il nodo del cluster primario sarebbe il nodo che dispone di connessioni alla maggior parte del database nel cluster. Solo 3 nodi possono essere uniti a un cluster di database e qualsiasi altro server può essere aggiunto al cluster utilizzando il comando database cluster connect.

•  Porta 5432 aperta sul firewall

Nota: il nodo primario del cluster di database resta in ascolto sulla porta 5432 per le connessioni dai nodi di replica. 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 (primario). 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. Generare la 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 database_cluster_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

Sul server CB che esegue il database primario, 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 server di certificazione locale come database primario per il cluster di database:

inizializzazione cluster di database

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

database cluster join <indirizzo IP CB primario>

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 primario.

Nota: Il database locale esistente prima del comando database cluster join verrà sovrascritto e pertanto il relativo contenuto verrà eliminato.

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 Primary
      10.48.36.118         : Connected Replica ( In Sync )
      10.48.36.182 (me)    : Connected Replica ( 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 ClusterCore1 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 ClusterCore1 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 ClusterCore1 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 ClusterCore1 postgres[20882]:  [2-10] #011PL/pgSQL function create_matching_domain(uuid,text,uuid,integer,integer,text) line 3 at SQL statement

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

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

ERROR                    : Couldn't upgrade the schema
Status                   : Error

Nodes:
    10.48.54.75          : Connected Primary
    10.48.54.76          : Connected Replica ( In Sync )
    10.48.54.119 (me)    : Connected Replica ( 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 sono in grado di connettersi al nodo primario 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 primario (replica) 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 verificare la presenza di traffico tra il peer non primario e il database primario.

4. Se non è presente traffico di ritorno dal server, è probabile che un firmware possa bloccare 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'indirizzo 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 primario
• Come si sposta il database primario
• Documentazione e supporto tecnico – Cisco Systems