Configurer le cluster de base de données du pont d'appel du serveur de téléconférence (CMS)

Introduction

Ce document décrit les étapes pour configurer la mise en grappe de bases de données (DB) sur Cisco Meeting Server (CMS) ou Acano call bridge (CB).

Conditions préalables

Exigences

• Cisco recommande d'avoir au moins 3 noeuds CMS pour pouvoir créer un cluster de base de données viable

Remarque : Il est recommandé d'avoir un nombre impair de noeuds de cluster de base de données, car il est important pour la sélection principale et le mécanisme de basculement actif. Une autre raison est que le noeud de base de données principal serait le noeud qui a des connexions à la plus grande partie de la base de données dans le cluster. Seuls 3 noeuds peuvent être joints à un cluster de base de données et tous les autres serveurs peuvent être ajoutés au cluster à l'aide de la commande database cluster connect.

•  Port 5432 ouvert sur le pare-feu

Remarque : le noeud principal du cluster de base de données écoute sur le port 5432 les connexions des noeuds de réplication. Par conséquent, s'il existe un pare-feu entre les noeuds, assurez-vous que ce port est ouvert.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Configurer

Il existe deux types de certificats pour la mise en grappe de bases de données :

1. Client : Le certificat client, comme son nom l'indique, est utilisé par les clients de base de données pour se connecter au serveur de base de données (principal). Ce certificat doit contenir la chaîne, postgres, dans son champ Nom commun (CN).

2. Serveur : Le certificat de serveur, comme son nom l'indique, est utilisé par le serveur de base de données pour se connecter à la base de données postgres.

Partie 1. Création de certificat

1. Connectez-vous avec un Secure Shell (SSH) avec les informations d'identification d'administrateur au serveur MMP.

2. Générez une demande de signature de certificat (CSR) :

a. Pour le certificat client databasecluster :

pki csr <key/cert basename> CN:postgres

Par exemple : pki csr databasecluster_client CN:postgres

b. Pour le certificat de serveur de cluster de base de données :

pki csr <key/cert basename> CN : <domainname>

Par exemple : pki csr databasecluster_server CN:vngtpres.aca

3. Envoyez les CSR à votre autorité de certification (CA) pour qu'ils soient signés. Assurez-vous que l'autorité de certification vous fournit les certificats de l'autorité de certification racine (et de toute autorité de certification intermédiaire).

4. Téléchargez les certificats signés, les certificats d’autorité de certification racine (et tout certificat d’autorité de certification intermédiaire) sur tous les noeuds de base de données à l’aide d’un client SFTP (Secure File Transfer Protocol) (par exemple WinSCP).

Remarque : Le CN de la partie A doit être postgres et la partie B peut être le nom de domaine du pont d'appel, aucune entrée de nom alternatif de sujet (SAN) n'est requise.

Partie 2. Configuration du pont d'appel

Sur le BC qui exécute la base de données principale, procédez comme suit :

1. Pour sélectionner l'interface à utiliser, entrez la commande suivante :

cluster de base de données localnode a

Cela permet d'utiliser l'interface « a » pour le clustering de base de données.

2. Définissez les certificats d'autorité de certification client, serveur et racine, ainsi que les clés privées à utiliser par le cluster de base de données à l'aide des commandes suivantes :

certificats de cluster de base de données <client_key> <client_crt> <ca_crt>

certificats de cluster de base de données <server_key> <server_crt> <client_key> <client_crt> <ca_crt>

Remarque : Les mêmes certificats client et serveur peuvent être utilisés sur d'autres noeuds CB à mettre en grappe lorsque vous copiez les clés privées et les certificats sur les autres noeuds. Cela est possible parce que les certificats ne contiennent aucun SAN les liant à un pont d'appel spécifique. Cependant, il est recommandé d'avoir des certificats individuels pour chaque noeud de base de données.

 3. Initialisez cette base de données sur la base de données locale en tant que base principale pour ce cluster de bases de données :

initialisation du cluster de base de données

 4. Sur les ponts d'appel qui feraient partie de la base de données en cluster et deviendraient le réplica de base de données, exécutez cette commande après avoir effectué les étapes 1 et 2 pour la partie 2 :

jonction de cluster de base de données <adresse IP CB principale>

Exemple : jointure de cluster de base de données <10.48.36.61>

Cette opération lance la synchronisation de la base de données et copie la base de données à partir de l'homologue principal.

Remarque : La base de données locale qui existait avant la commande database cluster join va être écrasée, et donc son contenu va être supprimé.

Diagramme du réseau

Vérifier

Référez-vous à cette section pour vous assurer du bon fonctionnement de votre configuration.

Pour vérifier l'état de la base de données en cluster, exécutez cette commande sur l'un des noeuds du cluster de base de données :

état de cluster

Le résultat est similaire à :

  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)

Dépannage

Cette section fournit des informations que vous pouvez utiliser pour dépanner votre configuration.

Utilisez cette commande, sur l'interface de ligne de commande, pour afficher les journaux actuels relatifs au clustering de base de données :

Syslog Follow

Les sorties de journal de la base de données contiennent généralement la chaîne postgres, comme suit :

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

Voici quelques problèmes et solutions typiques de la base de données :

Problème : Erreur de schéma de base de données sur un homologue non principal

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)

Solution :

1. Exécutez d'abord cette commande pour effacer l'erreur :

erreur d'effacement de cluster

2. Suivis de cette commande pour mettre à niveau le schéma de base de données :

base de données cluster upgrade_schema

3. Vérifiez ensuite l'état de la mise en grappe DB avec :

état de cluster

Les journaux affichent un résultat similaire à celui-ci :

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

Problème : Les noeuds homologues ne peuvent pas se connecter au noeud principal de la base de données

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

Solution :

Suivez ces étapes pour collecter des traces afin de résoudre les problèmes de connexion :

1.  Exécutez la commande pcap <interface> sur le noeud non principal (réplica) et après quelques minutes, arrêtez la capture avec Ctrl-C.

2.  Connectez-vous avec un client SFTP (Secure File Transfer Protocol) au serveur et téléchargez le fichier .pcap à partir du répertoire racine :

3. Ouvrez le fichier de capture sur Wireshark et filtrez sur le port 5432 avec tcp.port==5432 pour vérifier le trafic entre l'homologue non principal et le DB principal.

4. S'il n'y a pas de trafic de retour en provenance du serveur, il est probable qu'un pare-feu bloque le port entre l'emplacement logique des deux serveurs.

Voici une capture de paquets typique d'une connexion active entre le client et le serveur :

Dans cet exemple, l'adresse IP du client est 10.48.54.119 et le serveur est 10.48.54.75.

Informations connexes

Pour plus d'informations sur la résolution des problèmes et pour toute autre question sur la mise en grappe de bases de données, reportez-vous aux FAQ disponibles sur les liens suivants :

• Lors de la mise en grappe de serveurs de base de données, pourquoi dois-je les placer sur des emplacements différents ?
• Nous avons un cluster de base de données et je vois une erreur ou un avertissement de base de données dans le journal. Que dois-je faire
• Un ou plusieurs serveurs de base de données ne sont pas connectés ou sont à l'état « Sync ». Que dois-je faire
• Que faire en l'absence de base de données principale ?
• Comment déplacer la base de données principale
• Assistance et documentation techniques - Cisco Systems