Configuración del clúster de base de datos de Call Bridge de Cisco Meeting Server

Introducción

Este documento describe los pasos para configurar el agrupamiento de bases de datos (DB) en Cisco Meeting Server (CMS) o los puentes de llamadas de Acano (CB).

Prerequisites

Requirements

• Cisco recomienda que tenga al menos 3 nodos CMS para poder crear un clúster de base de datos viable

Nota: Se recomienda tener un número impar de nodos de clúster de DB ya que es importante para la selección maestra y el mecanismo de conmutación por fallas activo. Otra razón para esto es que el nodo principal de la base de datos sería el nodo que tiene conexiones a la mayor parte de la base de datos del clúster. Puede tener un máximo de 5 nodos en un clúster de DB.

•  Puerto 5432 abierto en el firewall

Nota: El maestro del clúster de la base de datos escucha en el puerto 5432 las conexiones de los nodos del cliente, por lo que si hay un firewall (FW) entre los nodos, asegúrese de que este puerto esté abierto.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

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 tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Configurar

Hay dos tipos de certificados para el agrupamiento de bases de datos:

1. Cliente: Los clientes de la base de datos utilizan el certificado de cliente, como el nombre indica, para conectarse al servidor de la base de datos (maestro). Este certificado debe contener la cadena, postgres, en su campo Nombre común (CN).

2. Servidor: El certificado del servidor, como el nombre sugiere, es utilizado por el servidor de la base de datos para conectarse a la base de datos de postgres.

Parte 1. Creación de certificado

1. Conéctese con un Secure Shell (SSH) con las credenciales de administrador al servidor MMP.

2. Generar solicitud de firma de certificado (CSR):

     

a. Para el certificado de cliente de la base de datos:

pki csr <key/cert basename> CN:postgres

Por ejemplo: pki csr databasecluster_client CN:postgres

b. Para el certificado del servidor de la base de datos:

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

Por ejemplo: pki csr databasecluster_server CN:vngtpres.aca

3. Envíe los CSR a su autoridad de certificación (CA) para que los firmen. Asegúrese de que la CA le proporcione los certificados de CA raíz (y cualquier CA intermedia).

4. Cargue los certificados firmados, los certificados de CA raíz (y los certificados de CA intermedia) en todos los nodos de base de datos mediante un cliente de protocolo de transferencia de archivos seguro (SFTP) (por ejemplo, WinSCP).

Nota: El CN para la parte A debe ser un postgres y la parte B puede ser el nombre de dominio del puente de llamada, no se requieren entradas de nombre alternativo del sujeto (SAN).

Parte 2. Configuración de Call Bridge

En el CB que ejecuta la base de datos maestra, siga estos pasos:

1. Para seleccionar la interfaz que se va a utilizar, ingrese el comando:

cluster de base de datos localnode a

Esto permite que la interfaz "a" se utilice para el agrupamiento de bases de datos.

2. Defina los certificados de cliente, servidor y ca raíz, así como las claves privadas que utilizará el clúster de DB con estos comandos:

certificados de clúster de base de datos <client_key> <client_crt> <ca_crt>

certificados de clúster de base de datos <server_key> <server_crt> <client_key> <client_crt> <ca_crt>

Nota: Los mismos certificados de cliente y servidor se pueden utilizar en otros nodos CB para ser agrupados cuando se copian las claves privadas y los certificados en los otros nodos. Esto es posible porque los certificados no contienen ninguna SAN que los vincule a un puente de llamadas específico. Sin embargo, se recomienda tener certificados individuales para cada nodo DB.

 3. Inicialice esta base de datos en el CB local como maestro para este clúster de la base de datos:

cluster de base de datos inicializar

 4. En CallBridges que formarían parte de la base de datos agrupada y se convertirían en esclavos de la base de datos, ejecute este comando después de completar los pasos 1 y 2 para la parte 2:

agrupación de la base de datos se une <dirección IP de Master CB>

Por ejemplo: agrupación de base de datos <10.48.36.61>

Esto inicia la sincronización de la base de datos y copia la base de datos del par maestro.

Nota: La base de datos local que existía antes de que se iniciara el comando database cluster Join, continúa existiendo hasta que el nodo se elimina de la base de datos agrupada. Mientras el nodo esté en el clúster de la base de datos, no se utilizará su base de datos local.

Diagrama de la red

Verificación

Use esta sección para confirmar que su configuración funciona correctamente.

Para verificar el estado de la base de datos agrupada, ejecute este comando en cualquiera de los nodos del clúster de la base de datos:

estado del clúster de la base de datos

El resultado es similar a:

  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)

Troubleshoot

En esta sección se brinda información que puede utilizar para resolver problemas en su configuración.

Utilice este comando, en la CLI, para ver los registros actuales relacionados con la agrupación en clústeres de la base de datos:

seguimiento de syslog

Los resultados de registro para la base de datos suelen contener la cadena de postgres, ejemplos como los siguientes:

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

El colector de registros CMS proporciona una interfaz de usuario (IU) fácil y fácil de usar para recopilar registros del servidor CMS.

Estos son algunos de los problemas y soluciones típicos de la base de datos:

Problema: Error de esquema de base de datos en un peer no maestro

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)

Solución:

1. Primero, ejecute este comando para borrar el error:

error de limpieza del clúster de la base de datos

2. Seguido por este comando para actualizar el esquema DB:

database cluster upgrade_Schema

3. A continuación, verifique el estado de la agrupación en clúster de la base de datos con:

estado del clúster de la base de datos

Los logs muestran resultados similares a estos:

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: Los nodos del par no se pueden conectar al nodo principal de la base de datos

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

Solución:

Utilice estos pasos para recopilar seguimientos para solucionar los problemas de conexión:

1.  Ejecute el comando pcap <interface> en el nodo no maestro (esclavo) y, después de unos minutos, detenga la captura con Ctrl-C.

2.  Conéctese con un cliente de protocolo seguro de transferencia de archivos (SFTP) al servidor y descargue el archivo .pcap del directorio raíz:

  

3. Abra el archivo de captura en Wireshark y filtre en el puerto 5432 con tcp.port==5432 para verificar el tráfico entre el peer no maestro y el maestro de la base de datos.

4. Si no hay tráfico de retorno del servidor, es probable que un FW esté bloqueando el puerto entre la ubicación lógica de los dos servidores.

A continuación se muestra una captura típica de paquetes de una conexión en funcionamiento entre el cliente y el servidor:

En este ejemplo, la IP del cliente es 10.48.54.119 y el servidor es 10.48.54.75.

Información Relacionada

Para obtener más información sobre cómo resolver problemas y otras preguntas sobre la agrupación en clústeres de bases de datos, consulte las preguntas frecuentes de estos enlaces:

• Al agrupar en clúster los servidores de bases de datos, ¿por qué es necesario colocarlos en distintas ubicaciones?
• Tenemos un clúster de base de datos y veo un error o advertencia en el registro. ¿Qué debo hacer
• Uno o más de los servidores de base de datos no están conectados o en estado "Sincronización". ¿Qué debo hacer
• ¿Qué hago si no hay una base de datos maestra?
• ¿Cómo se mueve la base de datos maestra?
• Soporte Técnico y Documentación - Cisco Systems