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

En el siguiente ejemplo, 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 sitio A tiene XSP1 y XSP2 delante deLB1, y el Sitio B tiene XSP3 y XSP4 delante deLB2. Solo los balanceadores de carga se expone a la red pública, y los XSP están en las redes privadas DMZ.

Configuración de DNS

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

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

Ejemplo: El registro A del DNS del socio para la detección de los balanceadores de carga/servidor de XSP para Internet en turnos

Failover

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

• Si la falla 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 hacia 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 hasta la siguiente IP.

• Si no se recibe ninguna respuesta HTTP en el plazo de 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 hacia la siguiente IP.

Cada solicitud se intenta 3 veces antes de que se reporte una falla al microservicio.

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

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

Estado

El estado de la conectividad de los servicios de la nube de Webex a los XSP o niveladores de carga se puede observar 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 pueda alcanzar la interfaz en uno de los IP en la búsqueda de registros A.

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

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

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

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

• Correo electrónico/activación automática no confiable

• Control de estado del servicio de Broadworks

Configuración de DNS

La aplicación de Webex accede a los servicios Xtended Services Interface (XSI-Actions & XSI-Events) y a los servicios de Device Servicio de administración (DMS) en el XSP.

Realizará la búsqueda de SRV DNS para _xsi-client._tcp.<xsi domain> de la URL configurada para buscar los hosts O niveladores de carga de XSP para el servicio de XSI.

A continuación, se muestra un ejemplo SRV registros.

Cada registro A/AAAA debe asignarse a una dirección IP. Si hay varios XSP en una DMZ detrás del dispositivo de nivelador de carga/límite, se requiere que el nivelador de carga se configure para mantener la persistente sesión para enrutar todas las solicitudes de la misma sesión al mismo XSP. Recomendamos esta configuración porque los heartbeats del evento XSI del cliente deben ir al mismo XSP que se usa para establecer el canal del evento. Si asigna el nombre A/AAAA a más de una dirección IP, o si el elemento de nivelador de carga/límite no mantiene la persistente sesión, el cliente eventualmente envía el heartbeat a un XSP donde no establece un canal de eventos. Esto provoca que el canal se desplome, y también un tráfico interno considerablemente más afectado el rendimiento de su grupo de XSP.

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

Ejemplo: REGISTRO A de DNS para la detección de servidores XSP/balanceadores de carga de Internet con equilibrio de ida y vuelta por la aplicación de Webex para descargar archivos de configuración a través de DMS:

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

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

1. El cliente recupera inicialmente las URL de Xsi-Actions/Xsi-Events de la nube de Webex (las introdujo al crear el grupo de llamadas de BroadWorks asociado). El nombre de host/dominio Xsi se analiza a partir de la URL y el cliente realiza SRV búsqueda como se muestra a continuación:

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

   2. Si la SRV búsqueda de datos devuelve uno o más objetivos:

      1. El cliente realiza una búsqueda de A/AAAA para esos objetivos y almacena las direcciones IP devueltas en el caché.

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

   3. Si la SRV búsqueda rápida no devuelve ningún objetivo:

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

      Como se mencionó, el registro A/AAAA debe resolverse en una dirección IP por las mismas razones.

2. (Opcional) Posteriormente, puede proporcionar detalles personalizados de XSI-Actions/XSI-Events en la configuración del dispositivo para la aplicación de 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 precedencia sobre cualquier configuración en su grupo de BroadWorks en el Concentrador de control.

   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 volverá a inicializar sus acciones de XSI/conectividad de XSI Events. El primer paso de esto es realizar el mismo proceso de búsqueda de DNS listado en el paso 1: esta vez se solicita una búsqueda del valor del parámetro %XSI_ROOT_WXT% de su archivo de configuración.

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

Failover

Durante el inicio de sesión, la aplicación de Webex realiza una búsqueda de DNS SRV para _xsi-client._tcp. , genera una lista de hosts y se conecta a uno de los hosts según la prioridad SRV y luego el<xsi domain="">peso. Este host conectado se convierte en el seleccionado para todas las solicitudes futuras. Luego, se abre un canal de eventos al organizador seleccionado y se envía heartbeat de manera regular para verificar el canal. Todas las solicitudes enviadas después de la primera incluyen una cookie que se devuelve en la respuesta HTTP y, por lo tanto, es importante que el nivelador de carga mantenga la persistente sesión (afinidad) y siempre envíe solicitudes al mismo servidor XSP de backend.

Si falla una solicitud o una solicitud de heartbeat a un host, pueden suceder varias cosas:

• Si la falla se debe a un error de red (por ejemplo: TCP, SSL), la aplicación de Webex enruta inmediatamente el avance al siguiente host de la lista.

• Si se devuelve un código de error (HTTP 5xx), la solicitud fallará inmediatamente.

• Si no se recibe una respuesta dentro de un período de tiempo, se considera que la solicitud falló debido al tiempo de espera y las siguientes solicitudes se envían al siguiente host. Sin embargo, la solicitud con tiempo de espera se considera fallida. Se vuelve a intentar algunas solicitudes después de la falla (si aumenta el tiempo de reintento). No se reinteponen las solicitudes que asumen que no son vitales.

Cuando se intenta con éxito un nuevo host, se convierte en el nuevo anfitrión seleccionado si el anfitrión está presente en la lista. Después de probar al último anfitrión de la lista, la aplicación de Webex se revierte al primero.

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

Tenga en cuenta que la aplicación de Webex no realiza la recuperación de fallas, y que la detección de servicios DNS se realiza solo 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 registro 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 utilizando un token SSO prueba. Si esto falla por cualquier motivo, inténtelo nuevamente, pero con el nombre de usuario y la contraseña del dispositivo.