Preparar su entorno

Los XSP de Broadworks pueden implementarse directamente en Internet o pueden residir en una DMZ con un elemento de equilibrio de carga como el F5 BIG-IP. Para proporcionar redundancia geográfica, los XSP pueden implementarse en dos (o más) centros de datos, cada uno de los cuales puede ser encabezado por un equilibrador de carga, cada uno con una dirección IP pública. Si los XSP están detrás de un equilibrador de carga, los microservicios y la aplicación de Webex solo ven la dirección IP del equilibrador de carga y Broadworks parece tener solo un XSP, incluso si hay varios XSP detrás.

En el ejemplo siguiente, los XSP se implementan en dos sitios, el sitio A y el sitio B. Hay dos XSP encabezados por un nivelador de carga en cada sitio. El centro A tiene XSP1 y XSP2 frontadas por LB1, y el centro B tiene XSP3 y XSP4 frontadas por LB2. Solo los niveladores de carga están expuestos en la red pública, y los XSP están en las redes privadas DMZ.

Configuración de DNS

Los microservicios en la nube de Webex deben ser capaces de encontrar los servidores XSP de Broadworks para conectarse a las interfaces de Xsi, el servicio de autenticación y CTI.

Los microservicios en la nube de Webex realizarán una búsqueda A/AAAA de DNS del nombre de host de XSP configurado y se conectarán a la dirección IP devuelta. Esto podría ser un elemento de borde de equilibrio de carga o podría ser el propio servidor XSP. Si se devuelven varias direcciones IP, se seleccionará la primera IP de la lista. Actualmente, la búsqueda de SRV no es compatible.

Ejemplo: El registro A de DNS del socio para el descubrimiento de balanceadores de carga/servidor XSP orientado a Internet equilibrados Round-Robin.

Conmutación por error

Cuando los microservicios de Webex envían una solicitud al nivelador de carga/XSP y la solicitud falla, pueden suceder varias cosas:

• Si el fallo se debe a un error de red (por ejemplo: TCP, SSL), los microservicios de Webex marcan la IP como bloqueada e inmediatamente realizan un avance de ruta a la siguiente IP.

• Si se devuelve un código de error (HTTP 5xx), los microservicios de Webex marcan la IP como bloqueada e inmediatamente realizan un avance de ruta a la siguiente IP.

• Si no se recibe ninguna respuesta HTTP en 2 segundos, el tiempo de espera de la solicitud y los microservicios de Webex marcan la IP como bloqueada y realizan un avance de ruta a la siguiente IP.

Cada solicitud se prueba 3 veces antes de que se notifique un fallo al microservicio.

Cuando una IP está en la lista de bloqueados, no se incluirá en la lista de direcciones para probar al enviar una solicitud a un XSP. Después de un período de tiempo predeterminado, una IP bloqueada caduca y vuelve a la lista para intentarlo cuando se realiza otra solicitud.

Si todas las direcciones IP están bloqueadas, el microservicio intentará enviar la solicitud seleccionando al azar una dirección IP de la lista bloqueada. Si se realiza correctamente, esa dirección IP se elimina de la lista bloqueada.

Estado

El estado de la conectividad de los servicios en la nube de Webex a los XSP o niveladores de carga se puede ver en Control Hub. En un grupo de llamadas de BroadWorks, se muestra un estado de conexión para cada una de estas interfaces:

• XSI Actions

• XSI Events

• Servicio de autenticación

El estado de conexión se actualiza cuando se carga la página o durante las actualizaciones de entrada. Los estados de las conexiones pueden ser:

• Verde: Cuando se puede acceder a la interfaz en una de las IP de la búsqueda de registros A.

• Rojo: Cuando no se puede acceder a todas las direcciones IP de la búsqueda de registros A y la interfaz no está disponible.

Los siguientes servicios utilizan los microservicios para conectarse a los XSP y se ven afectados por la disponibilidad de la interfaz de XSP:

• Inicio de sesión en la aplicación de Webex

• Actualización de tokens de la aplicación Webex

• Activación automática/correo electrónico no confiable

• Comprobación del estado del servicio de Broadworks

Configuración de DNS

La aplicación Webex accede a los servicios de la interfaz de servicios xtended (XSI-Actions & XSI-Events) y del servicio de administración de dispositivos (DMS) en el XSP.

Para encontrar el servicio de XSI, la aplicación de Webex realiza una búsqueda de SRV de DNS _xsi-client._tcp.<webex app xsi domain>. El SRV señala la URL configurada para los hosts XSP o los equilibradores de carga para el servicio XSI. Si la búsqueda de SRV no está disponible, la aplicación de Webex volverá a la búsqueda de A/AAAA.

El SRV puede resolverse a varios destinos A/AAAA. Sin embargo, cada registro A/AAAA debe asignarse solo a una dirección IP única. Si hay varios XSP en una DMZ detrás del dispositivo de nivelador de carga/borde, se requiere que el nivelador de carga esté configurado para mantener la persistencia de la sesión para enrutar todas las solicitudes de la misma sesión al mismo XSP. Exigimos esta configuración porque los XSI-event heartbeats del cliente deben ir al mismo XSP que se utiliza para establecer el canal del evento.

En el ejemplo 1, el registro A/AAAA para webex-app-xsp.example.com no existe y no es necesario. Si su DNS requiere que se defina un registro A/AAAA, solo se debe devolver 1 dirección IP. Independientemente de ello, el SRV aún debe definirse para la aplicación de Webex. Si la aplicación de Webex utiliza el nombre A/AAAA que se resuelve en más de una dirección IP, o si el equilibrador de carga/elemento de borde no mantiene la persistencia de la sesión, el cliente finalmente envía latidos cardíacos a un XSP donde no estableció un canal de eventos. Esto provoca que el canal se rompa y también que el tráfico interno sea significativamente mayor, lo que afecta el rendimiento de su grupo de XSP. Debido a que la nube de Webex y la aplicación de Webex tienen diferentes requisitos en la búsqueda de registros A/AAAA, debe utilizar un FQDN separado para la nube de Webex y la aplicación de Webex para acceder a sus XSP. Como se muestra en los ejemplos, la nube de Webex utiliza Un registro webex-cloud-xsp.example.com y la aplicación de Webex utiliza SRV _xsi-client._tcp.webex-app-xsp.example.com.

Ejemplo 1: varios XSP, cada uno detrás de equilibradores de carga independientes

En este ejemplo, el SRV apunta a mutilar los registros A y cada registro A apunta a un equilibrador de carga diferente en un sitio diferente. La aplicación de Webex siempre utilizará la primera dirección IP de la lista y solo se moverá al siguiente registro si la primera está desactivada.

Ejemplo 2: varios XSP detrás de un único equilibrador de carga (con puente TLS)

Para la solicitud inicial, el equilibrador de carga selecciona un XSP aleatorio. Ese XSP devuelve una cookie que la aplicación de Webex incluye en solicitudes futuras. Para solicitudes futuras, el equilibrador de carga utiliza la cookie para enrutar la conexión al XSP correcto, asegurándose de que el canal del evento no se rompa.

URL DE DMS

Durante el proceso de conexión, la aplicación de Webex también recuperará la URL de DMS para descargar su archivo de configuración. El host en la URL se analizará y la aplicación Webex realizará una búsqueda de DNS A/AAAA del host para conectarse al XSP que aloja el servicio de DMS.

Ejemplo: Registro A de DNS para el descubrimiento de niveladores de carga/servidores XSP orientados a Internet equilibrados Round-Robin de la aplicación Webex para descargar archivos de configuración a través de DMS:

Cómo la aplicación de Webex encuentra las direcciones XSP

El cliente intenta localizar los nodos XSP mediante el siguiente flujo de DNS:

1. El cliente recupera inicialmente las URL de Xsi-Actions/Xsi-Events desde la nube de Webex (las introdujo al crear el grupo de llamadas de BroadWorks asociado). El nombre de host/dominio Xsi se analiza desde la URL y el cliente realiza la búsqueda de SRV de la siguiente manera:

   1. El cliente realiza una búsqueda SRV para el cliente _xsi._tcp.<xsi domain="">

   2. Si la búsqueda de SRV devuelve uno o más destinos A/AAAA:

      1. El cliente busca A/AAAA esos objetivos y almacena en caché las direcciones IP devueltas.

      2. El cliente se conecta a uno de los targets (y por tanto su registro A/AAAA con una única dirección IP) en función de la prioridad SRV, luego el peso (o al azar si todos son iguales).

   3. Si la búsqueda de SRV no devuelve ningún destino:

      El cliente realiza una búsqueda A/AAAA del parámetro raíz Xsi y luego intenta conectarse a la dirección IP devuelta. Esto podría ser un elemento de borde de equilibrio de carga o podría ser el propio servidor XSP.

      Como se ha señalado, el registro A/AAAA debe resolverse a una dirección IP por los mismos motivos.

2. (Opcional) Posteriormente, puede proporcionar detalles personalizados de XSI-Actions/XSI-Events en la configuración del dispositivo para la aplicación Webex, utilizando las siguientes etiquetas:

   <protocols>
   	<xsi>
   		<paths>
   			<root>%XSI_ROOT_WXT%</root>
   			<actions>%XSI_ACTIONS_PATH_WXT%</actions>
   			<events>%XSI_EVENTS_PATH_WXT%</events>
   		</paths>
   	</xsi>
   </protocols>

   1. Estos parámetros de configuración tienen prioridad sobre cualquier configuración de su grupo de BroadWorks en Control Hub.

   2. Si existen, el cliente se comparará con la dirección XSI original que recibió a través de la configuración del grupo de BroadWorks.

   3. Si se detecta alguna diferencia, el cliente reinicializará su conectividad XSI Actions/XSI Events. El primer paso es realizar el mismo proceso de búsqueda de DNS que se indica en el paso 1, solicitando esta vez una búsqueda del valor en el parámetro %XSI_ROOT_WXT% desde su archivo de configuración.

      Asegúrese de crear los registros SRV correspondientes si utiliza esta etiqueta para cambiar las interfaces de Xsi.

Conmutación por error

Durante el inicio de sesión, la aplicación de Webex realiza una búsqueda de SRV de DNS para el cliente _xsi._tcp.<xsi domain="">, crea una lista de hosts y se conecta a uno de los hosts en función de la prioridad de SRV y, a continuación, pondera. Este host conectado se convierte en el seleccionado para todas las solicitudes futuras. A continuación, se abre un canal de evento al organizador seleccionado y se envía regularmente un latido cardíaco para verificar el canal. Todas las solicitudes enviadas después de la primera incluyen una cookie que se devuelve en la respuesta HTTP, por lo tanto, es importante que el equilibrador de carga mantenga la persistencia de la sesión (afinidad) y envíe siempre las solicitudes al mismo servidor XSP backend.

Si falla una solicitud o una solicitud de latido cardíaco a un organizador, pueden ocurrir varias cosas:

• Si el fallo se debe a un error de red (por ejemplo: TCP, SSL), la ruta de la aplicación Webex avanza inmediatamente al siguiente organizador de la lista.

• Si se devuelve un código de error (HTTP 5xx), la aplicación de Webex marca esa dirección IP como bloqueada y el enrutamiento avanza al siguiente organizador de la lista.

• Si no se recibe una respuesta en un período de tiempo, la solicitud se considera fallida debido al tiempo de espera y las siguientes solicitudes se envían al siguiente organizador. Sin embargo, la solicitud con tiempo de espera se considera fallida. Algunas solicitudes se vuelven a intentar después de un error (con un tiempo de reintento cada vez mayor). Las peticiones de que los supuestos no vitales no sean reprobados.

Cuando un nuevo organizador se prueba correctamente, se convierte en el nuevo organizador seleccionado si el organizador está presente en la lista. Una vez que se pruebe el último organizador de la lista, la aplicación de Webex se trasladará al primero.

En el caso de heartbeat, si hay dos fallas de solicitud consecutivas, la aplicación de Webex reinicializará el canal del evento.

Tenga en cuenta que la aplicación Webex no realiza la recuperación de fallas, y la detección del servicio de DNS solo se realiza una vez al iniciar sesión.

Durante el inicio de sesión, la aplicación de Webex intenta descargar el archivo de configuración a través de la interfaz XSP/Dms. Realiza una búsqueda de registros A/AAAA del host en la URL de DMS recuperada y se conecta a la primera IP. Primero intentará enviar la solicitud para descargar el archivo de configuración con un token de SSO. Si esto falla por cualquier motivo, lo intentará de nuevo, pero con el nombre de usuario y la contraseña del dispositivo.