Konfigurieren des CMS-Cluster (Meeting Server) für die Anrufbrücke der Datenbank

Einleitung

In diesem Dokument werden die Schritte zur Konfiguration des Datenbank-Clustering (DB) auf Cisco Meeting Server (CMS) oder Acano Call Bridges (CB) beschrieben.

Voraussetzungen

Anforderungen

• Cisco empfiehlt, dass Sie über mindestens 3 CMS-Knoten verfügen, um einen tragfähigen DB-Cluster erstellen zu können.

Anmerkung: Es wird empfohlen, eine ungerade Anzahl von DB-Cluster-Knoten zu verwenden, da dies für die primäre Auswahl und den aktiven Failover-Mechanismus wichtig ist. Ein weiterer Grund hierfür besteht darin, dass der primäre DB-Knoten der Knoten ist, der über Verbindungen mit der meisten DB im Cluster verfügt. Nur drei Knoten können einem Datenbank-Cluster hinzugefügt werden, und alle weiteren Server können dem Cluster mithilfe des Befehls database cluster connect hinzugefügt werden.

•  Port 5432 auf Firewall geöffnet

Hinweis: Der primäre DB-Cluster-Knoten überwacht Port 5432 auf Verbindungen von den Replikatknoten. Wenn also eine Firewall (FW) zwischen den Knoten vorhanden ist, stellen Sie sicher, dass dieser Port geöffnet ist.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Konfigurieren

Es gibt zwei Arten von Zertifikaten für das DB-Clustering:

1. Auftraggeber: Das Clientzertifikat wird, wie der Name vermuten lässt, von den DB-Clients für die Verbindung mit dem (primären) DB-Server verwendet. Dieses Zertifikat muss die Zeichenfolge "postgres" in seinem CN-Feld (Common Name) enthalten.

2. Server: Das Serverzertifikat wird, wie der Name vermuten lässt, vom DB-Server verwendet, um eine Verbindung mit der PostgreDB herzustellen.

Teil 1: Erstellung des Zertifikats

1. Stellen Sie eine Verbindung mit einer Secure Shell (SSH) mit den Administratoranmeldeinformationen für den Server-MMP her.

2. CSR (Certificate Signing Request) generieren:

antwort: Für das Client-Zertifikat des Datenbankclusters:

pki csr <Schlüssel/Zertifikatbasenname> CN:postgres

Beispiel: pki csr datenbankCluster_client CN:postgres

b. Für das Datenbankclusterserverzertifikat:

pki csr <Schlüssel-/Zertifikatbasisname> CN:<Domänenname>

Beispiel: pki csr datenbankCluster_server CN:vngtpres.aca

3. Senden Sie die CSRs an Ihre Zertifizierungsstelle, damit diese sie unterzeichnen können. Stellen Sie sicher, dass die Zertifizierungsstelle Ihnen die Stammzertifizierungsstelle (und alle dazwischen liegenden Zertifizierungsstellen) zur Verfügung stellt.

4. Laden Sie die signierten Zertifikate, Root-CA-Zertifikate (und alle dazwischen liegenden CAs) mithilfe eines SFTP-Clients (Secure File Transfer Protocol) (z. B. WinSCP) auf alle DB-Knoten hoch.

Anmerkung: Bei der CN für Teil A muss es sich um Postgres handeln, und Teil B kann der Domänenname der Anrufbrücke sein. Es sind keine SAN-Einträge (Subject Alternate Name) erforderlich.

Teil 2: Konfiguration der Anrufbrücke

Führen Sie auf der Zentralbank, die die primäre DB ausführt, folgende Schritte aus:

1. Geben Sie den folgenden Befehl ein, um die zu verwendende Schnittstelle auszuwählen:

Datenbankcluster-Gebietsknoten a

Dadurch kann die Schnittstelle "a" für das DB-Clustering verwendet werden.

2. Definieren Sie die Client-, Server- und Root-CA-Zertifikate sowie die privaten Schlüssel, die vom DB-Cluster verwendet werden sollen, mithilfe der folgenden Befehle:

Datenbankclusterzertifikate <client_key> <client_crt> <ca_crt>

Datenbankclusterzertifikate <server_key> <server_crt> <client_key> <client_crt> <ca_crt>

Anmerkung: Die gleichen Client- und Serverzertifikate können auf anderen zu clusterenden CB-Knoten verwendet werden, wenn Sie die privaten Schlüssel und Zertifikate auf die anderen Knoten kopieren. Dies ist möglich, da die Zertifikate keine SAN-Kopplung mit einer bestimmten Anrufbrücke enthalten. Es wird jedoch empfohlen, für jeden DB-Knoten individuelle Zertifikate zu verwenden.

 3. Initialisieren Sie diese DB auf der lokalen CB als primäre DB-Cluster:

Datenbankcluster initialisieren

 4. Führen Sie auf den CallBridges, die Teil der geclusterten DB und somit DB-Replikat wären, diesen Befehl aus, nachdem Sie die Schritte 1 und 2 für Teil 2 abgeschlossen haben:

database cluster join <Primäre CB-IP-Adresse>

Beispiele: Datenbank Cluster Join <10.48.36.61>

Dadurch wird die DB-Synchronisierung initiiert und vom primären Peer kopiert.

Anmerkung: Die lokale Datenbank, die vor dem Datenbankcluster-Join-Befehl existierte, wird überschrieben, und ihr Inhalt wird daher gelöscht.

Netzwerkdiagramm

Überprüfung

Nutzen Sie diesen Abschnitt, um zu überprüfen, ob Ihre Konfiguration ordnungsgemäß funktioniert.

Führen Sie diesen Befehl auf einem beliebigen Knoten im DB-Cluster aus, um den Status der geclusterten DB zu überprüfen:

Datenbankclusterstatus

Die Ausgabe ist ähnlich wie:

  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)

Fehlerbehebung

In diesem Abschnitt erhalten Sie Informationen zur Behebung von Fehlern in Ihrer Konfiguration.

Verwenden Sie diesen Befehl in der CLI, um die aktuellen Protokolle für das DB-Clustering anzuzeigen:

Syslog folgen

Protokollausgaben für die DB enthalten in der Regel die Postgre-Zeichenfolge. Beispiele:

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

Nachfolgend sind einige typische DB-Probleme und -Lösungen aufgeführt:

Problem: DB-Schemafehler auf einem nicht primären Peer

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)

Lösung:

1. Führen Sie zunächst diesen Befehl aus, um den Fehler zu löschen:

Fehler beim Löschen des Datenbankclusters

2. Folgen Sie diesem Befehl, um das DB-Schema zu aktualisieren:

Datenbankcluster Upgrade_Schema

3. Überprüfen Sie dann den Status des DB-Clustering mit:

Datenbankclusterstatus

Die Protokolle zeigen eine ähnliche Ausgabe:

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

Problem: Peer-Knoten können keine Verbindung mit dem primären DB-Knoten herstellen

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?|

Lösung:

Gehen Sie folgendermaßen vor, um Ablaufverfolgungen zur Behebung von Verbindungsproblemen zu sammeln:

1.  Führen Sie den Befehl pcap <Schnittstelle> auf dem nicht primären (Replikat-)Knoten aus, und stoppen Sie nach einigen Minuten die Erfassung mit Strg-C.

2.  Stellen Sie eine Verbindung mit einem SFTP-Client (Secure File Transfer Protocol) zum Server her, und laden Sie die .pcap-Datei aus dem Stammverzeichnis herunter:

3. Öffnen Sie die Erfassungsdatei in Wireshark, und filtern Sie nach Port 5432 mit tcp.port==5432, um den Datenverkehr zwischen dem nicht primären Peer und dem primären DB-Peer zu überprüfen.

4. Wenn kein Datenrückverkehr vom Server eingeht, ist es wahrscheinlich, dass eine FW den Port zwischen dem logischen Standort der beiden Server blockieren kann.

Im Folgenden finden Sie eine typische Paketerfassung aus einer funktionierenden Verbindung zwischen Client und Server:

In diesem Beispiel ist die Client-IP 10.48.54.119 und der Server 10.48.54.75.

Zugehörige Informationen

Weitere Informationen zur Fehlerbehebung sowie weitere Fragen zum Datenbank-Clustering finden Sie in den häufig gestellten Fragen unter den folgenden Links:

• Warum muss ich Datenbankserver bei Clustering an verschiedenen Standorten platzieren?
• Wir haben einen Datenbank-Cluster, und im Protokoll wird ein Datenbankfehler oder eine Datenbankwarnung angezeigt. Was sollte ich tun?
• Mindestens einer der Datenbankserver ist nicht verbunden oder befindet sich im "Synchronisierungsstatus". Was sollte ich tun?
• Was kann ich tun, wenn es keine primäre Datenbank gibt?
• Wie verschiebe ich die primäre Datenbank?
• Technischer Support und Dokumentation für Cisco Systeme