Qué es el clúster de Expressway y cómo funciona

Introducción

Este documento describe cómo se diseñan los clústeres de Expressway para ampliar la resistencia y la capacidad de una instalación de Expressway.  

Antecedentes

Capacidad. El clúster de Expressway puede aumentar la capacidad de una implementación de Expressway en un factor máximo de cuatro, en comparación con un solo Expressway. Los peers de Expressway en un clúster comparten el uso del ancho de banda, así como el enrutamiento, la zona, FindMe y otras configuraciones.

Resistencia. El clúster de Expressway puede proporcionar redundancia mientras Expressway se encuentra en modo de mantenimiento, o en caso de que se vuelva inaccesible debido a una interrupción de la red o de la alimentación, o a otro motivo. Los terminales pueden registrarse en cualquiera de los pares de un clúster. Si los terminales pierden la conexión con su par inicial, pueden volver a registrarse en otro en el clúster.

Especificaciones

Expressway puede formar parte de un clúster de hasta seis Expressway. Al crear un clúster, se nombra a un par como el principal, desde el cual su configuración se replica a los otros pares. Todos los pares de Expressway en el clúster deben tener las mismas capacidades de routing. Si algún Expressway puede rutear una llamada a un destino, se supone que todos los peers de Expressway en ese clúster pueden rutear una llamada a ese destino.

Capacidad

No hay aumento de capacidad después de cuatro peers. Por ejemplo, en un clúster de seis pares, Expressway quinto y sexto no agregan capacidad de llamada adicional al clúster. La resistencia mejora con los pares adicionales, pero no con la capacidad.

• En el caso de las máquinas virtuales pequeñas (VM), el clúster solo es para redundancia y no para escalabilidad, y no hay aumento de capacidad en el clúster.
• La capacidad basada en la configuración del clúster de 4 peers se muestra en la siguiente imagen:

Elementos importantes de la página

Requirements

• Conocimiento básico de Secure Shell (SSH)
• Un clúster sólo debe contener nodos de Expressway-C o de Expressway-E.
• Todos los pares deben utilizar la misma versión de software.
• Todos los pares utilizan la plataforma de hardware, el dispositivo o la máquina virtual (VM), con capacidades equivalentes.
• Expressway admite un retraso de ida y vuelta de hasta 80 ms.
• El modo H323 está habilitado en cada par.
• Todos los pares tienen instalado el mismo conjunto de teclas de opción, con las siguientes excepciones:

• Para el servidor de control de vídeo (VCS): Licencias de llamadas transversales y no transversales
• Para Expressway: Sesiones multimedia
• Para Expressway: Licencias de registro del sistema de salas y del escritorio

Todas las demás claves de licencia deben ser idénticas en cada par.

• No debe haber traducción de direcciones de red (NAT) entre los pares de clúster.

Nota: Si Expressway-E utiliza un único controlador de interfaz de red (NIC), debe utilizar IP pública. Si Expressway-E utiliza NIC dual, la interfaz interna debe utilizarse para generar el clúster.

• Se deben configurar la dirección IP, el servicio de nombres de dominio (DNS) y el protocolo de tiempo de red (NTP). 

Conexiones y puertos de clúster

Configuraciones

Crear un nuevo clúster

1. Abra la interfaz web de Expressway.
2. Vaya a System > Clustering.
3. Introduzca los siguientes valores:

Nota: Debe crear un clúster de un peer (primario) primero y reiniciar el primario, antes de agregar otros peers. Puede agregar más peers después de haber establecido un clúster de uno.

Configuración principal: 1

Versión IP del clúster: Elija IPv4 o IPv6 para coincidir con el esquema de direcciones de red.

Opciones del modo de verificación TLS: Permiso (predeterminado) o Aplicación.

       Permisivo significa que los pares no validan los certificados de los demás cuando se establecen las conexiones de seguridad de la capa de transporte (TLS) dentro del clúster.

       La aplicación es más segura, pero requiere que cada par tenga un certificado válido y que todos los demás pares confíen en la Autoridad de Certificación (CA).

Dirección del par 1: Introduzca la dirección de Expressway (el par principal). Si el modo de verificación de TLS está establecido en Aplicar, debe introducir un nombre de dominio completo (FQDN) que coincida con el asunto Nombre común (CN) o un nombre alternativo de asunto (SAN) en el certificado de este par.

4. Seleccione Guardar.
5. Reiniciar el servidor.
6. Navegue hasta Mantenimiento > Opciones de reinicio, luego seleccione Reiniciar y confirme Aceptar.
7. Validar el certificado es válido, como se muestra en la siguiente imagen:

Agregar pares adicionales al clúster

 

Para agregar un peer adicional, siga los siguientes pasos:

1. Vaya a System > Clustering en Expressway principal.
2. En el primer campo vacío, introduzca la dirección del nuevo par de Expressway.
3. Seleccione Guardar.
4. El par 1 debe indicar Este sistema. El nuevo par debe indicar Desconocido y luego con una actualización debe indicar Fallado porque todavía no se ha unido completamente al clúster.
5. Navegue hasta System > Clustering en uno de los peers subordinados que ya se encuentran en el clúster y edite los siguientes campos:
   
   
   
   
6. Repita el paso anterior para cada uno de los peers subordinados que ya están en el clúster.
7. Seleccione Guardar.
8. Expressway provoca una alarma de falla de comunicación de clúster. La alarma se borra después del reinicio necesario.
9. Reinicie Expressway.
10. Después del reinicio, espere aproximadamente 2 minutos - esta es la frecuencia con la que se copia la configuración desde el primario.
11. Valide el estado de la base de datos del clúster.
    
    
12. Asegúrese de que la configuración se replica en un peer suborientado.

Aplicar verificación TLS

Precaución: Antes de continuar, verifique que sus SAN de certificado contengan los FQDN que se encuentran en los campos de dirección del par N. Debe ver mensajes de estado verdes para la agrupación en clúster y el certificado junto a cada campo de dirección antes de continuar.  

1. En el peer primario, configure el modo de verificación de TLS en Enforce.

Precaución: Se muestra una advertencia si algún certificado no es válido y evita que el clúster funcione correctamente en el modo de verificación TLS forzada.

2. El nuevo modo de verificación de TLS se replica en todo el clúster.
3. Verifique que el modo de verificación de TLS ahora se aplica entre sí.
4. Seleccione Save y reinicie el peer primario.
5. Después de que el peer primario vuelva a estar en línea, reinicie cada par uno por uno.
6. Espere a que el clúster se estabilice y valide que el estado Clúster y Certificado sea verde para todos los pares.

Cambiar el par principal

Nota: Puede realizar este proceso incluso si el par primario actual no está accesible.

1. En el nuevo Expressway primario, navegue hasta System > Clustering.
2. En el menú desplegable Configuration primary, seleccione el número de ID de la entrada de peer que dice This system.
3. Seleccione Guardar.

Nota: Mientras se lleva a cabo este proceso, ignore cualquier alarma en Expressway que informe de discordancia primaria del clúster o error de replicación del clúster.

4. En todos los demás peers de Expressway, comience por el peer antiguo primario (si aún es accesible).
5. Vaya a Sistema > Agrupación en clústeres.
6. En el menú desplegable Configuration primary, seleccione el número de ID de Expressway primario nuevo.
7. Seleccione Guardar.
8. Confirme que se ha aceptado el cambio a la configuración principal, navegue hasta System > Clustering y actualice la página.
9. Si algún Expressway no ha aceptado el cambio, repita el mismo procedimiento.
10. Valide que el estado de la base de datos del clúster informe como Activo.

Cambiar clúster para utilizar FQDN

Nota: Mientras se realiza este procedimiento, las comunicaciones entre pares se ven temporalmente afectadas, lo que significa que se espera ver alarmas que persisten hasta que se completen los cambios y el clúster acuerde las nuevas direcciones.

1. Inicie sesión en todos los pares del clúster y navegue hasta Sistema > Agrupación en clústeres.
2. Elija qué dirección de par se cambia. se recomienda comenzar con la dirección del par 1.
3. En cada par del clúster, siga el siguiente procedimiento:
4. Cambie el campo de dirección de peer seleccionado de la dirección IP a su FQDN.
5. Seleccione Guardar.
6. Cambie al par identificado por la dirección de peer que ha cambiado y reinicie el servidor.
7. Espere a que se resuelvan las alarmas de clúster transitorias.
8. Elija la siguiente dirección del par que se cambiará y luego repita los pasos 3 - 7.
9. Repita este procedimiento hasta que haya cambiado todas las direcciones de par y haya reiniciado todos los pares.

Asignación de direcciones de clúster para Expressway-E

Para implementaciones seguras como Mobile and Remote Access (MRA), cada par de Expressway-E debe tener un certificado con una SAN que contenga su FQDN público. El FQDN se asigna en el DNS público a la dirección IP pública de Expressway-E.

Nota: Si simplemente desea agrupar en clúster los pares de Cisco Expressway-E y no necesita la verificación de TLS entre ellos, puede formar el clúster con las direcciones IP privadas de los nodos. No necesita el mapeo de direcciones de clúster.

Las asignaciones de direcciones de clúster son pares FQDN:IP que se comparten alrededor del clúster, un par por cada par. Los pares consultan la Tabla de mapeo antes de consultar DNS y, si encuentran una coincidencia, no consultan DNS.

Si decide aplicar TLS, los pares también deben leer los nombres del campo SAN de los certificados de los demás y comprobar cada nombre en el lado FQDN de la asignación.

Se recomienda encarecidamente que introduzca las asignaciones en el peer primario. Las asignaciones de dirección se replican dinámicamente a través del clúster. Para configurar el Mapping de Direcciones, siga el siguiente procedimiento:

1. Elija System > Clustering en el peer primario, y cambie el menú desplegable Asignación de dirección de clúster habilitada a On (el valor predeterminado es Off). Se muestran los campos Asignación de direcciones de clúster.
2. Edite las asignaciones para que los FQDN públicos de los peers de Expressway-E correspondan a las direcciones IP de sus NIC internas.
3. Seleccione Guardar.

Precaución: No intente utilizar el DNS público para asignar los FQDN públicos de los pares a sus direcciones IP privadas, esta acción puede interrumpir la conectividad externa.  

Clúster con una sola NIC

Si desea que los pares de Expressway-E de un clúster verifiquen las identidades de cada uno con certificados, puede permitirles utilizar DNS para resolver los FQDN de peer de clúster en sus direcciones IP públicas. Esta es una forma perfectamente aceptable de formar un clúster si los nodos de Expressway-E tienen:

• Solo una NIC
• No hay NAT estática configurada
• Direcciones IP enrutables

Resolución de problemas

¿Qué activa un reinicio de fábrica?

Si borra todos los campos de dirección de peer de la página de agrupación en clúster y guarda la configuración, Expressway realiza de forma predeterminada un reinicio de fábrica la próxima vez que realice un reinicio. Esto significa que se elimina toda la configuración, excepto la configuración de red básica para la interfaz de red de área local 1 (LAN1), que incluye toda la configuración realizada después de borrar los campos y el siguiente reinicio.

Consejo: Si necesita evitar el restablecimiento de fábrica, restaure los campos de dirección de peer del clúster. Reemplace las direcciones de peer originales en el mismo orden y, a continuación, guarde la configuración para borrar el banner.

El restablecimiento de fábrica se activa automáticamente cuando el par se reinicia para eliminar los datos confidenciales y la configuración del clúster. El reinicio borra toda la configuración excepto la siguiente información básica de red:

Nota: Si utiliza la opción NIC dual, tenga en cuenta que cualquier configuración LAN2 se elimina por completo mediante el reinicio.

• Direcciones IP · cuentas de administrador y raíz y contraseñas
• Claves SSH
• Teclas de opción
• Acceso seguro (HTTPS) del protocolo de transferencia de hipertexto habilitado
• Acceso SSH habilitado

Nota: Desde la versión X12.6, el restablecimiento de fábrica elimina del par el certificado del servidor, la clave privada asociada y la configuración del almacén de confianza de la CA. En las versiones anteriores del software de Expressway, estos parámetros se conservan.

Falla de restablecimiento de fábrica

El restablecimiento de fábrica puede fallar, esto puede ocurrir si Expressway es un dispositivo de virtualización abierta (OVA) de instalación reciente y no se ha actualizado. 

Para corregir esto, siga cualquiera de las siguientes opciones:

• Actualice todos los nodos a la misma versión de software con el archivo tar.gz. Al final del proceso de actualización, reinicie el servidor, que luego activará el reinicio de fábrica.
• Cargue el archivo tar.gz directamente a la carpeta de restablecimiento de fábrica con WinSCP (/mnt/harddisk/Factory-reset/). A continuación, reinicie para iniciar el restablecimiento de fábrica o ejecute el restablecimiento de fábrica desde la CLI.

Nota: Asegúrese de realizar las copias de seguridad adecuadas antes de una actualización, un cambio de certificado o cuando haya una advertencia de restablecimiento de fábrica.

Reiniciar secuencia

Si es necesario reiniciar el clúster o cualquier peer, siga los siguientes pasos:

1. Reinicie el peer primario y espere a que se pueda acceder a él a través de la interfaz web.
2. Valide el estado de replicación del clúster en el estado primario y de todos los peers. Espere unos minutos, actualice las interfaces web del par ocasionalmente.
3. Reinicie otros pares, si es necesario, uno a uno. Cada vez, espere unos minutos después de que esté accesible y valide su estado de replicación.

Nota: Es posible que deba esperar unos 5 minutos después de realizar cualquier cambio en el clúster antes de que los peers de Expressway informen del estado correcto.

Alarmas y advertencias

Las alarmas de los errores de clúster se muestran en el formato: Error de replicación del clúster: (detalles) se requiere la sincronización manual de la configuración, algunos ejemplos de estos son los siguientes:

• Error de replicación del clúster: se requiere la sincronización manual de la configuración.
• Error de replicación del clúster: no se puede encontrar el archivo primario o el archivo de configuración de peer de este subordinado, se requiere la sincronización manual de la configuración.
• Error de replicación del clúster: el ID principal de la configuración no es coherente, se requiere la sincronización manual de la configuración.
• Error de replicación del clúster: la configuración de este par entra en conflicto con la configuración principal, se requiere la sincronización manual de la configuración.

Si un Expressway subordinado informa de la alarma mencionada, siga el siguiente procedimiento:

1. Inicie sesión como admin en un SSH u otra interfaz CLI.
2. Ejecute el siguiente comando: xcommand ForceConfigUpdate

Nota: Asegúrese de realizar las copias de seguridad adecuadas antes de una actualización, un cambio de certificado o cuando haya una advertencia de restablecimiento de fábrica.

3. Este comando elimina la configuración subordinada de Expressway y, a continuación, la obliga a actualizar su configuración de Expressway principal.

Si el problema persiste, podría estar relacionado con la clave de cifrado por peer de clúster. Normalmente ocurre cuando los peers se actualizan en el orden incorrecto, los peers subordinados no se sincronizan con el primario. Por lo tanto, si xcommand force no funciona, siga el siguiente procedimiento:

1. Inicie sesión en el peer primario y valide que está en buen estado.
2. Asegúrese de que la configuración del clúster muestre que este par es el primario.
3. Vuelva a actualizar el primario, utilice el mismo paquete que utilizó originalmente para actualizar.

La alarma de replicación se borra después de que el peer primario se haya actualizado y reiniciado. Esto suele ocurrir en los diez minutos posteriores al reinicio, pero puede ser hasta 20 minutos después del reinicio.

Alarmas frecuentes

Configuración de clustering no válida: El modo H.323 se debe activar: la agrupación en clúster utiliza las comunicaciones H.323 entre pares.

Para borrar esta alarma, asegúrese de que el modo H.323 esté encendido, navegue hasta Configuration > Protocols > H.323.

Falla en la base de datos de Expressway: Póngase en contacto con su representante de soporte técnico de Cisco.

Para resolver este tipo de alarma, siga el siguiente procedimiento:

1. Realice una instantánea del sistema y proporciónela a su representante de soporte técnico.
2. Quite Expressway del clúster.
3. Restaure la base de datos de Expressway desde una copia de seguridad realizada anteriormente en Expressway.
4. Vuelva a agregar Expressway al clúster.

Un segundo método es posible si la base de datos no se recupera:

1. Realice una instantánea del sistema y proporciónela al Technical Assistance Center (TAC).
2. Quite Expressway del clúster.
3. Inicie sesión como root y ejecute el siguiente comando clusterdb_detect_and_purge_data.sh.
4. Restaure la base de datos de Expressway desde una copia de seguridad realizada anteriormente en Expressway.
5. Vuelva a agregar Expressway al clúster. 

Nota: Asegúrese de realizar las copias de seguridad adecuadas antes de una actualización, un cambio de certificado o cuando haya una advertencia de restablecimiento de fábrica.

Precaución: clusterdb_detect_and_purge_data.sh es tan peligroso como suena: utilice esta opción como último recurso.

Problemas relacionados con la clave del sistema

Nota: La siguiente información se aplica a la versión X14 en adelante.

No se pudo actualizar las alarmas de archivos clave en Expressway en un solo escenario de nodo.

Siga el siguiente procedimiento para resolver este tipo de alarma:

1. Inicie sesión como administrador a través de la CLI (disponible de forma predeterminada en SSH y a través del puerto serial en las versiones de hardware).
2. Ejecute el siguiente comando: xCommand ForceSystemKeyUpdate.

No se pudo actualizar las alarmas de archivos clave se generan en Expressway en un escenario de clúster.

Siga el siguiente procedimiento para resolver este tipo de alarma:

1. Inicie sesión en el nodo como administrador a través de la CLI (disponible de forma predeterminada en SSH y a través del puerto serial en las versiones de hardware) donde no se produce esta alarma.
2. Ejecute el siguiente comando: xCommand ForceSystemKeyUpdate.

Detalles de registros

Al igual que cualquier otro registro en Expressway, puede habilitar los registros de diagnóstico con los vaciados de TCP.

En un estado normal, la Sincronización de la Base de Datos en el nodo Maestro se muestra en los registros como el siguiente resultado:

2020-07-21T15:16:50.321-05:00 expc01 replication: UTCTime="2020-07-21 20:16:50,321" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(270)" Detail="Starting synchronisation"
2020-07-21T15:16:50.330-05:00 expc01 replication: UTCTime="2020-07-21 20:16:50,330" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationutils(750)" AlternateIPAddresses="[u'(10.15.13.15 expc01)', u'(10.15.13.16 expc02)']" ConfigurationMasterIndex="0" LocalPeerIndex="0" 
2020-07-21T15:16:50.433-05:00 expc01 replication: UTCTime="2020-07-21 20:16:50,433" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(257)" Detail="This peer is the cluster master, local configuration has already been replicated to the other peers"
2020-07-21T15:16:50.437-05:00 expc01 replication: UTCTime="2020-07-21 20:16:50,437" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(336)" Detail="Synchronisation completed successfully"

Desde la perspectiva del nodo del par se muestra como el siguiente resultado:

2020-07-21T15:16:46.900-05:00 expc02 replication: UTCTime="2020-07-21 20:16:46,899" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(270)" Detail="Starting synchronisation"
2020-07-21T15:16:46.908-05:00 expc02 replication: UTCTime="2020-07-21 20:16:46,908" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationutils(750)" AlternateIPAddresses="[u'(10.15.13.15 expc01)', u'(10.15.13.16 expc02)']" ConfigurationMasterIndex="0" LocalPeerIndex="1" 
2020-07-21T15:16:46.947-05:00 expc02 replication: UTCTime="2020-07-21 20:16:46,946" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(254)" Detail="This peer is not the cluster master, local configuration is already up to date"
2020-07-21T15:16:46.950-05:00 expc02 replication: UTCTime="2020-07-21 20:16:46,950" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(336)" Detail="Synchronisation completed successfully"

En el siguiente resultado se muestra una Desconexión de Peer:

2020-08-12T14:57:43.353-05:00 expc01 UTCTime="2020-08-12 19:57:43,353" Module="developer.clusterdb.cdb" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.159.0>" Detail="Processed mnesia_down event from accessible node" Node="clusterdb@expc02.apolo.local"
2020-08-12T14:57:43.354-05:00 expc01 UTCTime="2020-08-12 19:57:43,353" Module="developer.clusterdb.cdb" Level="ERROR" Node="clusterdb@expc01.apolo.local" PID="<0.159.0>" Detail="Inconsistent Database" Context="from mnesia system - mnesia down" Node="clusterdb@expc02.apolo.local"
2020-08-12T14:57:43.354-05:00 expc01 UTCTime="2020-08-12 19:57:43,354" Module="developer.clusterdb.cdb" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.159.0>" Detail="Connecting database on mnesia running_partitioned_network event" Node="clusterdb@expc02.apolo.local"
2020-08-12T14:57:43.354-05:00 expc01 UTCTime="2020-08-12 19:57:43,354" Module="developer.clusterdb.cdb" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.14215.425>" Detail="Ready to perform node connection transaction" Node="clusterdb@expc02.apolo.local"
2020-08-12T14:57:43.354-05:00 expc01 UTCTime="2020-08-12 19:57:43,354" Module="developer.clusterdb.cdb" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.14215.425>" Detail="Running node connection transaction" Node="clusterdb@expc02.apolo.local"
2020-08-12T14:57:43.354-05:00 expc01 UTCTime="2020-08-12 19:57:43,354" Module="developer.clusterdb.synchronise" Level="WARN" Node="clusterdb@expc01.apolo.local" PID="<0.14215.425>" Detail="Failed connecting to node" Node="clusterdb@expc02.apolo.local" Reason="{ badrpc, { EXIT, { aborted, { noproc, { gen_server, call, [ kernel_safe_sup, { start_child, { dets_sup, { dets_sup, start_link,  }, permanent, 1000, supervisor, [ dets_sup ] } }, infinity ] } } } } }"
2020-08-12T14:57:43.524-05:00 expc01 alarm: Level="WARN" Event="Alarm Raised" Id="20006" UUID="0f96695e-d954-4f6f-85c1-2ef1eae6f764" Severity="warning" Detail="Cluster database communication failure: The database is unable to replicate with one or more of the cluster peers" UTCTime="2020-08-12 19:57:43,524"
2020-08-12T14:57:43.771-05:00 expc01 alarm: Level="WARN" Event="Alarm Raised" Id="20004" UUID="3bca6888-f622-11df-93be-07cc953d7b99" Severity="warning" Detail="Cluster communication failure: The system is unable to communicate with one or more of the cluster peers" UTCTime="2020-08-12 19:57:43,771"

2020-08-12T14:57:53.872-05:00 expc01 tvcs: UTCTime="2020-08-12 19:57:53,871" Module="network.h323" Level="INFO":  Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS SCI  SeqNum=52319 Retransmit=True"
2020-08-12T14:57:54.872-05:00 expc01 tvcs: UTCTime="2020-08-12 19:57:54,871" Module="network.h323" Level="INFO":  Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS LRQ  SeqNum=52320 Retransmit=True"
2020-08-12T14:57:56.872-05:00 expc01 tvcs: UTCTime="2020-08-12 19:57:56,871" Module="network.h323" Level="INFO":  Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS LRQ  SeqNum=52320 Retransmit=True"
2020-08-12T14:57:57.871-05:00 expc01 tvcs: UTCTime="2020-08-12 19:57:57,871" Module="network.h323" Level="INFO":  Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS SCI  SeqNum=52319 Retransmit=True"
2020-08-12T14:57:58.871-05:00 expc01 tvcs: Event="External Server Communications Failure" Reason="gatekeeper timed out" Service="NeighbourGatekeeper" Detail="name:10.15.13.16:1719" Level="1" UTCTime="2020-08-12 19:57:58,871"
2020-08-12T14:57:58.871-05:00 expc01 tvcs: UTCTime="2020-08-12 19:57:58,871" Module="network.h323" Level="INFO":  Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS LRQ  SeqNum=52320 Timeout=True"
2020-08-12T14:57:59.601-05:00 expc01 UTCTime="2020-08-12 19:57:59,601" Module="developer.clusterdb.peernameresolver" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.145.0>" Detail="Triggering forced peer update of peers which failed DNS and queueing next run" Queue-Time-ms="300000"
2020-08-12T14:58:01.871-05:00 expc01 tvcs: UTCTime="2020-08-12 19:58:01,871" Module="network.h323" Level="INFO":  Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS SCI  SeqNum=52319 Timeout=True"

El cambio a TLS Enforce en el nodo maestro se muestra en el siguiente resultado:

2020-08-12T15:13:24.970-05:00 expc01 UTCTime="2020-08-12 20:13:24,969" Module="developer.cdbtable.cdb.clusterConfiguration" Level="DEBUG" Node="clusterdb@expc01.apolo.local" PID="<0.345.0>" Detail="Inserting into table" TableName="clusterConfiguration"
2020-08-12T15:13:24.976-05:00 expc01 UTCTime="2020-08-12 20:13:24,975" Event="System Configuration Changed" Node="clusterdb@expc01.apolo.local" PID="<0.345.0>" Detail="xconfiguration clusterConfiguration tls_verify - changed from: Permissive to: Enforcing"
2020-08-12T15:13:24.976-05:00 expc01 httpd[15060]: web: Event="System Configuration Changed" Detail="configuration/cluster/tls_verify - changed from: 'Permissive' to: 'Enforcing'" Src-ip="10.15.13.30" Src-port="53155" User="admin" Level="1" UTCTime="2020-08-12 20:13:24" 
2020-08-12T15:13:24.979-05:00 expc01 management: UTCTime="2020-08-12 20:13:24,978" Module="developer.management.databasemanager" Level="INFO" CodeLocation="databasemanager(312)" Detail="Cluster configuration change detected"
2020-08-12T15:13:24.980-05:00 expc01 UTCTime="2020-08-12 20:13:24,980" Module="developer.cdbtable.cdb.clusterConfiguration" Level="DEBUG" Node="clusterdb@expc01.apolo.local" PID="<0.345.0>" Detail="Inserting into table" TableName="clusterConfiguration"
2020-08-12T15:13:24.986-05:00 expc01 management: UTCTime="2020-08-12 20:13:24,986" Module="developer.management.databasemanager" Level="INFO" CodeLocation="databasemanager(405)" Detail="TLS Verify change status" Startup="False" New="True"
2020-08-12T15:13:25.022-05:00 expc01 UTCTime="2020-08-12 20:13:25,022" Event="System Configuration Changed" Node="clusterdb@expc01.apolo.local" PID="<0.557.0>" Detail="xconfiguration alternatesConfiguration - Changed"
2020-08-12T15:13:25.022-05:00 expc01 UTCTime="2020-08-12 20:13:25,022" Module="developer.clusterdb.peernameresolver" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.145.0>" Detail="Notifying databasemanager (Management Framework)"
2020-08-12T15:13:25.022-05:00 expc01 UTCTime="2020-08-12 20:13:25,022" Module="developer.clusterdb.alternatesmanager" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.142.0>" Detail="alternate peer changed info recieved"
2020-08-12T15:13:25.031-05:00 expc01 UTCTime="2020-08-12 20:13:25,031" Event="System Configuration Changed" Node="clusterdb@expc01.apolo.local" PID="<0.557.0>" Detail="xconfiguration alternatesConfiguration - Changed" 
2020-08-12T15:13:25.192-05:00 expc01 management: UTCTime="2020-08-12 20:13:25,192" Module="developer.diagnostics.alarmmanager" Level="INFO" CodeLocation="alarmmanager(173)" Detail="Raising alarm" UUID="e2b8e3d1-b731-4d7d-b606-4682a8f0c2e6" Parameters="null"
2020-08-12T15:13:25.195-05:00 expc01 management: Level="WARN" Event="Alarm Raised" Id="20007" UUID="e2b8e3d1-b731-4d7d-b606-4682a8f0c2e6" Severity="warning" Detail="Restart required: Cluster configuration has been changed, however a restart is required for this to take effect" UTCTime="2020-08-12 20:13:25,194"

Desde la perspectiva del nodo de par se muestra en el siguiente resultado:

2020-08-12T15:13:24.976-05:00 expc02 UTCTime="2020-08-12 20:13:24,976" Event="System Configuration Changed" Node="clusterdb@expc02.apolo.local" PID="<0.390.0>" Detail="xconfiguration clusterConfiguration tls_verify - changed from: Permissive to: Enforcing"
2020-08-12T15:13:24.979-05:00 expc02 management: UTCTime="2020-08-12 20:13:24,978" Module="developer.management.databasemanager" Level="INFO" CodeLocation="databasemanager(312)" Detail="Cluster configuration change detected"
2020-08-12T15:13:24.982-05:00 expc02 management: UTCTime="2020-08-12 20:13:24,982" Module="developer.management.databasemanager" Level="INFO" CodeLocation="databasemanager(405)" Detail="TLS Verify change status" Startup="False" New="True"
2020-08-12T15:13:25.040-05:00 expc02 UTCTime="2020-08-12 20:13:25,040" Module="developer.clusterdb.peernameresolver" Level="INFO" Node="clusterdb@expc02.apolo.local" PID="<0.136.0>" Detail="Notifying databasemanager (Management Framework)"
2020-08-12T15:13:25.040-05:00 expc02 UTCTime="2020-08-12 20:13:25,040" Module="developer.clusterdb.alternatesmanager" Level="INFO" Node="clusterdb@expc02.apolo.local" PID="<0.143.0>" Detail="alternate peer changed info recieved"
2020-08-12T15:13:25.041-05:00 expc02 UTCTime="2020-08-12 20:13:25,041" Event="System Configuration Changed" Node="clusterdb@expc02.apolo.local" PID="<0.543.0>" Detail="xconfiguration alternatesConfiguration - Changed"
2020-08-12T15:13:25.042-05:00 expc02 UTCTime="2020-08-12 20:13:25,042" Event="System Configuration Changed" Node="clusterdb@expc02.apolo.local" PID="<0.543.0>" Detail="xconfiguration alternatesConfiguration - Changed"
2020-08-12T15:13:25.046-05:00 expc02 UTCTime="2020-08-12 20:13:25,046" Module="developer.clusterdb.alternatesmanager" Level="INFO" Node="clusterdb@expc02.apolo.local" PID="<0.143.0>" Detail="alternate peer changed info recieved"
2020-08-12T15:13:25.047-05:00 expc02 UTCTime="2020-08-12 20:13:25,046" Module="developer.clusterdb.peernameresolver" Level="INFO" Node="clusterdb@expc02.apolo.local" PID="<0.136.0>" Detail="Notifying databasemanager (Management Framework)"
2020-08-12T15:13:25.047-05:00 expc02 UTCTime="2020-08-12 20:13:25,047" Event="System Configuration Changed" Node="clusterdb@expc02.apolo.local" PID="<0.543.0>" Detail="xconfiguration alternatesConfiguration - Changed"
2020-08-12T15:13:25.049-05:00 expc02 UTCTime="2020-08-12 20:13:25,049" Event="System Configuration Changed" Node="clusterdb@expc02.apolo.local" PID="<0.543.0>" Detail="xconfiguration alternatesConfiguration - Changed"
 2020-08-12T15:13:25.136-05:00 expc02 management: UTCTime="2020-08-12 20:13:25,136" Module="developer.diagnostics.alarmmanager" Level="INFO" CodeLocation="alarmmanager(173)" Detail="Raising alarm" UUID="e2b8e3d1-b731-4d7d-b606-4682a8f0c2e6" Parameters="null"
2020-08-12T15:13:25.139-05:00 expc02 management: Level="WARN" Event="Alarm Raised" Id="20007" UUID="e2b8e3d1-b731-4d7d-b606-4682a8f0c2e6" Severity="warning" Detail="Restart required: Cluster configuration has been changed, however a restart is required for this to take effect" UTCTime="2020-08-12 20:13:25,139"

Vídeos

Los siguientes videos podrían ser útiles:

Creación y adición de un par a un clúster de Expressway

Remoción de un Peer de un Clúster de Expressway

Solución del Error de Replicación de Expressway "La configuración del par entra en conflicto con el principal"

Procedimiento de reinicio del clúster de Expressway

Cómo actualizar un clúster de ExpresswayGeneración de CSR para MRA/Expressway agrupadas