Configurar la flexibilidad de XMPP

Introducción

En este documento se describe cómo configurar la flexibilidad de Extensible Messaging and Presence Protocol (XMPP) en Cisco Meeting Server (CMS).

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• El clúster de base de datos se debe configurar antes de la flexibilidad de XMPP. Este es el enlace para configurar el clúster de base de datos:

https://www.Cisco.com/c/en/us/support/docs/Conferencing/Meeting-Server/210530-Configure-Cisco-Meeting-Server-Call-Brid.HTML

• El componente Callbridge se debe configurar en CMS.
• Cisco recomienda que tenga al menos 3 nodos XMPP para que pueda configurar la flexibilidad de XMPP.
• Cuando la configuración está en modo de flexibilidad, los servidores XMPP dentro de una implementación se cargan con la misma configuración.
• Comprensión de los certificados autofirmados y los certificados firmados por la Autoridad de certificación (CA).
• Se requiere un Servidor de nombres de dominios (DNS).
• Se requiere una autoridad de certificación local o una autoridad de certificación pública para generar certificados. 

Nota: No se recomienda el uso de certificados autofirmados en entornos de producción.

Componentes Utilizados

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

• CMS
• Software de emulación de terminales de Shell seguro (SSH) PuTTY para procesador de administración de Mainboard (MMP)
• Un navegador web, como Firefox o Chrome

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. If your network is live, make sure that you understand the potential impact of any command.

Configurar

 Diagrama de la red

Esta imagen muestra el intercambio de mensajes de XMPP y el tráfico de routing.

Configuración

En este ejemplo de implementación de flexibilidad de XMPP se utilizan tres servidores XMPP y se configuran por primera vez.

Nota: Si previamente se implementó la flexibilidad de XMPP, se recomienda restablecer todos los servidores.

Los servidores XMPP utilizan mensajes de actividad para la supervisión mutua y para la elección de un líder. Los mensajes de XMPP se pueden enviar a cualquier servidor. Como se puede ver en la imagen anterior, los mensajes se envían al servidor XMPP líder. Los servidores XMPP continúan realizando la supervisión mutua; si se produce un error en el servidor líder, se elige un nuevo servidor líder y los demás servidores XMPP envían el tráfico al nuevo servidor líder.

Paso 1. Genere certificados para el componente XMPP.

Genere una CSR y, a continuación, ejecute el siguiente comando para generar el certificado correspondiente a través de la autoridad de certificación local/autoridad de certificación pública, según se requiera.

pki csr  <key/cert basename> 

Paso 2. Utilice la CSR anterior y genere el certificado a través de la autoridad de certificación local. Puede usar la guía de certificación de VCS para generar certificados a través de la autoridad de certificación de Microsoft, apéndice 5, página 32.

https://www.Cisco.com/c/DAM/en/us/TD/docs/telepresence/Infrastructure/VCS/config_guide/X8-8/Cisco-VCS-Certificate-Creation-and-Use-Deployment-Guide-X8-8.PDF

Cargue el certificado en los 3 nodos mediante el uso del servidor WINSCP/SFTP. Para comprobar la carga de los certificados, utilice un comando en MMP/SSH

comando: pki list

Nota: En la práctica de laboratorio, se usa un certificado para los 3 nodos XMPP.

Paso 3. Configure CMS para utilizar el componente XMPP.

cb1> xmpp domain tptac9.com
cb1>xmpp listen a
cb1>xmpp certs abhiall.key abhiall.cer certall.cer
 
*certall.cer= CA certificate

Consejo: Si la CA proporciona un paquete de certificados, incluya el paquete como un archivo independiente del certificado. Un paquete de certificados es un único archivo (con una extensión .pem,.cer o .crt) que incluye una copia del certificado de la CA raíz y todos los certificados intermedios en la cadena. Los certificados deben estar ordenados en secuencia, y el certificado de la CA raíz es el último en el paquetes de certificados. Los clientes externos (como los navegadores web y los clientes XMPP) requieren que el certificado y el paquete de certificados sean presentados por el servidor XMPP respectivamente al configurar una conexión segura.

 Cuando se requiere un paquete de certificados. El comando anterior sería:

cb1> xmpp certs abhiall.key abhiall.cer certallbundle.cer
 
certallbundle.cer= CA certificate + Intermediate CA + Intermediate CA1 + Intermediate CA2 +.... + Intermediate CAn +  Root CA
 
where n is an integer

Al utilizar 3 certificados por los 3 nodos XMPP correspondientes. Asegúrese de incluir los certificados en un paquete.

xmppserver1.crt + xmppserver2.crt + xmppserver3.crt= xmpp-cluster-bundle.crt

Un único certificado abhiall.cer se utiliza en el documento.

Consulte esta guía para obtener más detalles sobre los certificados.

https://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-2/Certificate-Guidelines-Scalable-and-Resilient-Deployments-2-2.pdf

Paso 4. Cargue certificados a través de SFTP en todos los CMS, que ejecutan el componente XMPP.

cb1>> xmpp cluster trust xmpp-cluster-bundle.crt

En la práctica de laboratorio, la confianza del clúster de xmpp es abhiall.cer.

cb1>>xmpp cluster trust abhiall.cer

Paso 5. Agregue Call Bridges al servidor XMPP.

cb1> xmpp callbridge add cb1

Se genera un secreto y esto configura el servidor XMPP de modo que permita las conexiones con el Call Bridge denominado cb1.

Nota: Se generan el dominio, el nombre de Call Bridge y el secreto. Usted necesitará esta información más adelante cuando configure el acceso de Call Bridge al servidor XMPP (para que Call Bridge muestre los detalles de autenticación al servidor XMPP).

El comando anterior se utiliza para agregar otro Call Bridge al mismo nodo de XMPP.

cb1> xmpp callbridge add cb2

cb1> xmpp callbridge add cb3

Nota: Cada Call Bridge debe tener un nombre único. Si todavía no observó los detalles de los Call Bridges que ha agregado al servidor XMPP, utilice el comando: xmpp callbridge list

cb1> xmpp disable

Este comando deshabilita el nodo de servidor XMPP.

Paso 6. Habilite el clúster XMPP.

cb1> xmpp cluster enable

Inicialice el clúster de XMPP en este nodo. Este comando crea un clúster de xmpp de un nodo, el resto de los nodos (servidores xmpp) se conectan a este clúster.

cb1> xmpp cluster initialize

Vuelva a habilitar este nodo.

cb1>xmpp enable

Paso 7. Agregue Call Bridges al segundo nodo XMPP y únela a un clúster.

Agregue cada Call Bridge a este nodo. Esto requiere que el Call Bridge se agregue usando el mismo nombre de Call Bridge y el mismo secreto del primer nodo de servidor XMPP. Esto se logra mediante este comando:

cb2>> xmpp callbridge add-secret cb1

Introduzca el secreto de call bridge.

Para comprobar el secreto, ejecute el comando xmpp call bridge list. Arroja como resultado todos los secretos generados en el primer nodo.

Después de agregar todos los secretos de Call Bridge al segundo nodo.

cb2>> xmpp disable
cb2>> xmpp cluster enable
cb2>> xmpp enable
cb2>> xmpp cluster join <cluster>

Clúster: es la dirección IP o el nombre de dominio del primer nodo.

Paso 8. Agregue Call Bridges al tercer nodo XMPP y únase a un clúster.

Agregue cada Call Bridge a este nodo. Esto requiere que el Call Bridge se agregue usando el mismo nombre de Call Bridge y el mismo secreto del primer nodo de servidor XMPP. Esto se logra con el comando:

cb3>> xmpp callbridge add-secret cb1

Introduzca el secreto de call bridge.

Ahora para comprobar el secreto. Puede ejecutar el comando xmpp callbridge list. El comando arroja como resultado todos los secretos generados en el primer nodo.

Después de agregar todos los secretos de Call Bridge a este nodo, siga estos estos pasos.

cb3>> xmpp disable
cb3>> xmpp cluster enable
cb3>> xmpp enable
cb3>> xmpp cluster join <cluster>

Clúster: es la dirección IP o el nombre de dominio del primer nodo.

Paso 9. Configure cada Call Bridge con los detalles de autenticación de los servidores XMPP en el clúster. Esto permite que los Call Bridges accedan a los servidores XMPP.

Vaya a Webadmin > Configuration > General (Webadmin > Configuración > General) y realice lo siguiente:

1. Agregue un nombre de Call Bridge único; no se requiere ninguna parte de dominio.
2. Introduzca el dominio para el dominio del servidor XMPP tptac9.com.
3. Campo Server address (Dirección de servidor) del servidor XMPP. Configure este campo si desea que este Call Bridge use solo un servidor XMPP coubicado o si no tiene configurado DNS. Uso del servidor XMPP coubicado reduce la latencia.
4. Deje este campo vacío para permitir que este Call Bridge realice conmutación por error entre servidores XMPP; esto requiere la configuración de entradas DNS. 

Si tiene previsto utilizar el Servidor de nombres de dominio (DNS) para la conexión entre Call Bridges y servidores XMPP, también debe configurar un registro DNS SRV para que el clúster de xmpp se resuelva como el registro DNS A de cada uno de los servidores XMPP en el clúster. El formato del registro DNS SRV es: _xmpp-Component._tcp.

_xmpp-component._tcp.example.com. 86400 IN SRV 0 0 5222 xmppserver1.example.com,  _xmpp-component._tcp.example.com. 86400 IN SRV 0 0 5223 xmppserver2.example.com, _xmpp-component._tcp.example.com. 86400 IN SRV 0 0 5223 xmppserver3.example.com. 

En el ejemplo anterior se especifica el puerto 5223 (utilice otro puerto si 5223 ya está en uso).

El secreto compartido que se utiliza para el Call Bridge correspondiente. Por ejemplo, en la captura de pantalla anterior:

El secreto de Cb1 es

Callbridge: cb1

Dominio: tptac9.com

Secreto: kvgP1SRzWVabhiPVAb1

De manera similar para cb2 y cb3, repita estos pasos para los 3 Call Bridges cb1, cb2 y cb3.

Después de realizar estos pasos, compruebe el estado del clúster en los 3 Call Bridges.

Verificación

Ejecute cb1>> xmpp cluster status. Este comando permite obtener un informe del estado de actividad del clúster de xmpp. Si se produce un error en el clúster, este comando arroja las estadísticas del servidor xmpp, que se ejecuta en este Meeting Server solamente. Utilice este comando para intentar diagnosticar problemas de conectividad y colaborar con dicho diagnóstico.

En esta imagen se muestran los nodos: el nodo 10.106.81.30 es líder y el resto son secundarios.

De manera similar, compruebe el estado de los dos nodos restantes.

En el segundo nodo:

En el tercer nodo:

Troubleshoot

La flexibilidad de XMPP se ha configurado correctamente. Podrían surgir problemas cuando se utiliza la flexibilidad de XMPP.

Escenario 1. Si se selecciona la configuración de DNS, los errores de las capturas de pantalla apuntan a los problemas de DNS.

Si aparecen estos errores, controle la configuración de los registros de SRV.

En la flexibilidad de XMPP, el servidor XMPP al que se conecta un Call Bridge se controla a través del DNS. Esta opción se basa en la prioridad de DNS y el peso dado. Un Call Bridge solo se conecta a un servidor XMPP a la vez. No hay ningún requisito respecto a que todos los Call Bridges se conecten con el mismo servidor XMPP, ya que todo el tráfico se envía al principal. Si un problema de la red hace que el Call Bridge pierda la conexión con el servidor XMPP, el Call Bridge intentará volver a conectarse con otro servidor XMPP. El Call Bridge debe configurarse en cualquier servidor XMPP al que se puede conectar.

Para habilitar las conexiones de cliente, utilice el cliente WebRTC; se requiere un registro _xmpp-client._tcp. En una implementación típica, establece un vínculo con el puerto 5222. La LAN, si el servidor principal es directamente enrutable, puede establecer un vínculo con el servicio de XMPP, que se ejecuta en el servidor principal.

Por ejemplo: _xmpp-client._tcp.tptac9.com puede tener estos registros SRV:

_xmpp-client._tcp. tptac9.com 86400 IN SRV 10 50 5222 cb1. tptac9.com

Consejos sobre la configuración de registros DNS para los nodos de servidor XMPP. Para la flexibilidad de XMPP, debe utilizar DNS para la conexión entre Call Bridges y servidores XMPP; también debe configurar un registro DNS SRV para que el clúster de xmpp establezca un vínculo con el registro DNS A de cada uno de los servidores XMPP en el clúster. Este es el formato del registro DNS SRV: _xmpp-component._tcp.tptac9.com

De acuerdo con la configuración analizada para 3 servidores xmpp, se muestran los registros que establecen un vínculo con los 3 servidores.

_xmpp-component._tcp.tptac9.com. 86400 cb1.tptac9.com IN SRV 0 0 5223

_xmpp-component._tcp.tptac9.com. 86400 cb2.tptac9.com IN SRV 0 0 5223

_xmpp-component._tcp.tptac9.com. 86400 cb2.tptac9.com IN SRV 0 0 5223

En el ejemplo se especifica el puerto 5223; también se puede utilizar cualquier otro puerto si 5223 ya está en uso. Sin embargo, asegúrese de que el puerto utilizado esté abierto.

Situación hipotética 2. Cuando en la página de estado de CMS se muestra un error de autenticación.

El error de autenticación se ve principalmente cuando el secreto compartido no se ha introducido o se ha introducido incorrectamente. Asegúrese de introducir el secreto compartido si olvidó hacerlo y guárdelo bien. Establezca una conexión SSH con el servidor y ejecute este comando: xmpp callbridge list

En el documento se describe la configuración de flexibilidad de xmpp. Por lo tanto, ejecute el comando en los 3 servidores para asegurarse de que los secretos generados sean los mismos en todos los servidores. Como se muestra en las imágenes, el secreto compartido que se puede ver en el servidor cb1 es el mismo que el que se puede ver en cb3. Después de corroborar en otros servidores, se concluye que el secreto especificado para cb1 es incorrecto.

Situación hipotética 3. En xmpp cluster status, hay entradas duplicadas de nodos XMPP.

Este resultado muestra la entrada duplicada del nodo 10.61.7.91:5222.

cb1> xmpp cluster status
State: LEADER
List of peers
10.61.7.91:5222
 
10.61.7.91:5222
10.59.103.71:5222
10.59.103.70:5222 (Leader)
 

Precaución: se recomienda quitar los nodos xmpp del clúster antes de restablecerlos. Si se realiza el restablecimiento de XMPP en un nodo mientras este sigue siendo parte del clúster y luego vuelve a conectar el nodo con el clúster XMPP existente, se crea una entrada duplicada de ese nodo cuando corrobora el estado a través de xmpp cluster status.

Esto puede causar problemas en una configuración de flexibilidad. Se ha producido un defecto.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvi67717

Consulte la página 94 de esta guía: 

https://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-3/Cisco-Meeting-Server-2-3-Scalable-and-Resilient-Deployments.pdf