Configurar clúster de base de datos de Call Bridge de Meeting Server (CMS)

Introducción

En este documento se describen los pasos para configurar la agrupación en clústeres de la base de datos (DB) en Cisco Meeting Server (CMS) o en Call Bridges (CB) de Acano.

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 cluster de base de datos, ya que es importante para la selección principal y el mecanismo de failover activo. Otro motivo es que el nodo de base de datos principal sería el nodo que tiene conexiones con la mayor parte de la base de datos del cluster. Sólo se pueden unir 3 nodos a un clúster de base de datos y se pueden agregar más servidores al clúster mediante el comando database cluster connect.

•  Puerto 5432 abierto en el firewall

Nota: El nodo principal del clúster de base de datos escucha en el puerto 5432 las conexiones de los nodos de réplica, 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.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Configurar

Existen dos tipos de certificados para la agrupación en clústeres de BD:

1. Cliente: Los clientes de base de datos utilizan el certificado de cliente, como sugiere el nombre, para conectarse al servidor de base de datos (principal). Este certificado debe contener la cadena postgres en el campo Common Name (CN).

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

Parte 1. Creación de certificados

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

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

a. Para el certificado de cliente de clúster de base de datos:

pki csr <key/cert basename> CN:postgres

Por ejemplo: pki csr databasecluster_client CN:postgres

b. Para el certificado de servidor de clúster de 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 la autoridad de certificación (CA) para que los firme. 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 cualquier CA intermedia) en todos los nodos de la base de datos mediante un cliente de protocolo de transferencia de archivos segura (SFTP) (por ejemplo, WinSCP).

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

Parte 2. Configuración de Call Bridge

En el CB que ejecuta la BD primaria, siga estos pasos:

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

database cluster localnode a

Esto permite que la interfaz "a" se utilice para la agrupación en clústeres de la base de datos.

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

database cluster certs <client_key> <client_crt> <ca_crt>

database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>

Nota: Los mismos certificados de cliente y de servidor se pueden utilizar en otros nodos CB para agruparlos 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 de base de datos.

 3. Inicialice esta base de datos en el banco central local como el principal para este agrupamiento de bases de datos:

database cluster initialize

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

database cluster join <Primary CB IP address>

Por ejemplo: database cluster join <10.48.36.61>

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

Nota: La base de datos local que existía antes del comando database cluster join se va a sobrescribir y, por lo tanto, su contenido se va a eliminar.

Diagrama de la red

Verificación

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

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

estado del clúster de base de datos

El resultado es similar a:

  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)

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úster de la base de datos:

syslog follow

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

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

A continuación se indican algunos problemas y soluciones típicos de la base de datos:

Problema: Error de esquema de la base de datos en un peer no 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)

Solución:

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

Database Cluster Clear Error

2. Seguido de este comando para actualizar el esquema de la base de datos:

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 base de datos

Los logs muestran un resultado similar al siguiente:

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: Nodos del mismo nivel que no pueden conectarse 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 principal (réplica) y después de unos minutos, detenga la captura con Ctrl-C.

2.  Conéctese con un cliente Secure File Transfer Protocol (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 primario y el primario DB.

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

A continuación se muestra una captura de paquetes típica 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 agrupamiento de bases de datos, consulte las preguntas frecuentes en estos links:

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