Preparar seu ambiente

O Broadworks XSPs pode ser implantado diretamente na Internet, ou pode residir em um DMZ liderado por um elemento de balanceamento de carga, como o F5 BIG-IP. Para fornecer geo-redundância, os XSPs podem ser implantados em dois (ou mais) datacenters, cada um pode ser confrontado por um balanceador de carga, cada um com um endereço IP público. Se os XSPs estiverem por trás de um balanceador de carga, os microsserviços Webex e o aplicativo verão apenas o endereço IP do balanceador de carga e o Broadworks parecerão ter apenas um XSP, mesmo se houver vários XSPs atrás.

No exemplo abaixo, os XSPs são implantados em dois sites, Site A e Site B. Existem dois XSPs frontados por um balanceador de carga em cada site. O site A tem XSP1 e XSP2 com a frente LB1 e o site B tem XSP3 e XSP4 com a frente LB2. Somente os balanceadores de carga são expostos na rede pública, e os XSPs estão nas redes privadas DMZ.

CONFIGURAÇÃO DNS

Os microsserviços do Webex Cloud devem ser capazes de encontrar os servidores XSP do Broadworks para conexão com interfaces Xsi, serviço de autenticação e CTI.

Os microsserviços Webex Cloud executarão a pesquisa DNS A/AAAA do nome do organizador XSP configurado e se conectarão ao endereço IP retornado. Isso pode ser um elemento de borda de balanceamento de carga ou pode ser o próprio servidor XSP. Se vários endereços IP forem retornados, o primeiro IP na lista será selecionado. A pesquisa SRV não é suportada no momento.

Exemplo: O DNS Um Registro do parceiro para a descoberta de balanceadores de servidor XSP voltados para a internet Round-Robin balanceados/Carga.

Falha

Quando os microsserviços Webex enviam uma solicitação ao XSP/Load Balancer e a solicitação falha, várias coisas podem acontecer:

• Se a falha for devido a um erro de rede (ex: TCP, SSL), os microsserviços Webex marcam o IP como bloqueado e executam imediatamente um avanço de rota para o próximo IP.

• Se um código de erro (HTTP5xx) for retornado, os microsserviços Webex marcarão o IP como bloqueado e executarão imediatamente um avanço de rota para o próximo IP.

• Se nenhuma resposta HTTP for recebida dentro de 2 segundos, o tempo de solicitação expirará e os microsserviços Webex marcarão o IP como bloqueado e executarão um avanço de rota para o próximo IP.

Cada solicitação é tentada 3 vezes antes que uma falha seja relatada de volta ao microserviço.

Quando um IP está na lista bloqueada, ele não será incluído na lista de endereços para tentar ao enviar uma solicitação a um XSP. Após um período de tempo predeterminado, um IP bloqueado expira e volta para a lista para tentar quando outra solicitação é feita.

Se todos os endereços IP estiverem bloqueados, o microservice ainda tentará enviar a solicitação selecionando aleatoriamente um endereço IP da lista bloqueada. Se for bem-sucedido, esse endereço IP será removido da lista bloqueada.

Status

O status da conectividade dos serviços Webex Cloud aos XSPs ou balanceadores de carga pode ser visto no Control Hub. Em um Grupo de chamadas do BroadWorks, um status de conexão é exibido para cada uma destas interfaces:

• Ações XSI

• Eventos XSI

• Serviço de autentificação

O status da conexão é atualizado quando a página é carregada ou durante as atualizações de entrada. Os status das conexões podem ser:

• Verde: Quando a interface pode ser acessada em um dos IPs na pesquisa de registro A.

• Vermelho: Quando todos os IPs na pesquisa de um registro estão inacessíveis e a interface não está disponível.

Os seguintes serviços usam os microsserviços para se conectar aos XSPs e são afetados pela disponibilidade da interface XSP:

• Logon do aplicativo Webex

• Atualização do token do aplicativo Webex

• Ativação automática/e-mail não confiável

• Verificação de integridade do serviço Broadworks

CONFIGURAÇÃO DNS

O aplicativo Webex acessa os serviços Xtended Services Interface (XSI-Actions & XSI-Events) e Device Management Service (DMS) no XSP.

Para encontrar o serviço XSI, o aplicativo Webex executa a pesquisa SRV DNS para _xsi-client._tcp.<webex app xsi domain>. O SRV aponta para o URL configurado para os hosts XSP ou balanceadores de carga para o serviço XSI. Se a pesquisa SRV não estiver disponível, o aplicativo Webex voltará para a pesquisa A/AAAA.

O SRV pode ser resolvido em vários destinos A/AAAA. No entanto, cada registro A/AAAA deve mapear apenas para um único endereço IP. Se houver vários XSPs em um DMZ por trás do dispositivo balanceador de carga/borda, é necessário que o balanceador de carga seja configurado para manter a persistência da sessão para encaminhar todas as solicitações da mesma sessão para o mesmo XSP. Nós ordenamos essa configuração porque as pulsações do evento XSI do cliente devem ir para o mesmo XSP que é usado para estabelecer o canal do evento.

No exemplo 1, o registro A/AAAA para webex-app-xsp.example.com não existe e não precisa existir. Se o seu DNS exigir que um registro A/AAAA deve ser definido, então apenas 1 endereço IP deve ser retornado. Independentemente disso, o SRV ainda deve ser definido para o aplicativo Webex. Se o aplicativo Webex usar o nome A/AAAA que resolve para mais de um endereço IP ou se o elemento balanceador de carga/borda não mantiver a persistência da sessão, o cliente eventualmente enviará pulsações para um XSP onde não estabeleceu um canal de evento. Isso resulta no canal sendo dividido, e também em um tráfego significativamente mais interno que prejudica o desempenho do seu cluster XSP. Como a nuvem Webex e o aplicativo Webex têm requisitos diferentes na pesquisa de registro A/AAAA, você deve usar um FQDN separado para a nuvem Webex e o aplicativo Webex para acessar seus XSPs. Como mostrado nos exemplos, o Webex Cloud usa Um registro webex-cloud-xsp.example.com, e o aplicativo Webex usa SRV _xsi-client._tcp.webex-app-xsp.example.com.

Exemplo 1 — Vários XSPs, cada um atrás de balanceadores de carga separados

Neste exemplo, o SRV aponta para mutilar registros A com cada registro A apontando para um balanceador de carga diferente em um local diferente. O aplicativo Webex sempre usará o primeiro endereço IP na lista e será transferido para o próximo registro se o primeiro estiver inativo.

Exemplo 2 — Múltiplos XSPs por trás de um balanceador de carga única (com a ponte TLS)

Para a solicitação inicial, o balanceador de carga seleciona um XSP aleatório. Esse XSP retorna um cookie que o aplicativo Webex inclui em solicitações futuras. Para solicitações futuras, o balanceador de carga usa o cookie para encaminhar a conexão ao XSP correto, garantindo que o canal do evento não quebre.

URL DO DMS

Durante o processo de logon, o aplicativo Webex também recuperará a URL DMS para baixar seu arquivo de configuração. O organizador na URL será analisado e o aplicativo Webex executará a pesquisa DNS A/AAAA do organizador para se conectar ao XSP que hospeda o serviço DMS.

Exemplo: DNS Um Registro para a descoberta de balanceadores de servidor XSP/carga direcionados para a internet Round-Robin balanceados pelo aplicativo Webex para baixar arquivos de configuração por meio de DMS:

Como o aplicativo Webex encontra endereços XSP

O cliente tenta localizar os nós XSP usando o seguinte fluxo DNS:

1. Inicialmente, o cliente recupera as URLs de Xsi-Actions/Xsi-Events do Webex Cloud (você as inseriu ao criar o Grupo de chamadas BroadWorks associado). O nome do host/domínio Xsi é analisado a partir da URL e o cliente executa a pesquisa SRV da seguinte forma:

   1. O cliente executa uma pesquisa SRV para _xsi-cliente._tcp.<xsi domain="">

   2. Se a pesquisa SRV retornar um ou mais alvos A/AAAA:

      1. O cliente faz uma pesquisa A/AAAA para esses destinos e armazena em cache os endereços IP retornados.

      2. O cliente se conecta a um dos alvos (e, portanto, seu registro A/AAAA com um único endereço IP) com base na prioridade SRV, em seguida, peso (ou aleatoriamente se todos forem iguais).

   3. Se a pesquisa SRV não retornar nenhum destino:

      O cliente faz a pesquisa A/AAAA do parâmetro raiz Xsi e, em seguida, tenta se conectar ao endereço IP retornado. Isso pode ser um elemento de borda de balanceamento de carga ou pode ser o próprio servidor XSP.

      Como observado, o registro A/AAAA deve resolver para um endereço IP pelos mesmos motivos.

2. (Opcional) Posteriormente, você pode fornecer detalhes personalizados do XSI-Actions/XSI-Events na configuração do dispositivo para o aplicativo Webex usando as seguintes tags:

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

   1. Esses parâmetros de configuração têm precedência sobre qualquer configuração no Grupo BroadWorks no Control Hub.

   2. Se existirem, o cliente comparará com o endereço XSI original que recebeu através da configuração do grupo BroadWorks.

   3. Se houver alguma diferença detectada, o cliente reinicializará sua conectividade de Ações XSI/Eventos XSI. A primeira etapa é executar o mesmo processo de pesquisa DNS listado na etapa 1 - desta vez solicitando uma pesquisa do valor no %XSI_ROOT_WXT% parâmetro de seu arquivo de configuração.

      Certifique-se de criar os registros SRV correspondentes se você usar esta tag para alterar as interfaces Xsi.

Falha

Durante o logon, o aplicativo Webex executa uma pesquisa SRV DNS para _xsicliente._tcp.<xsi domain="">, constrói uma lista de organizadores e se conecta a um dos organizadores com base na prioridade SRV e, em seguida, no peso. Esse organizador conectado torna-se o selecionado para todas as solicitações futuras. Um canal de evento é então aberto ao organizador selecionado e uma pulsação é enviada regularmente para verificar o canal. Todas as solicitações enviadas após a primeira incluem um cookie que é retornado na resposta HTTP, portanto, é importante que o balanceador de carga mantenha a persistência da sessão (afinidade) e sempre envie solicitações para o mesmo servidor XSP back-end.

Se uma solicitação ou uma solicitação de pulsação para um organizador falhar, várias coisas podem acontecer:

• Se a falha for devida a um erro de rede (ex: TCP, SSL), a rota do aplicativo Webex avança imediatamente para o próximo organizador na lista.

• Se um código de erro (HTTP5xx) for retornado, o aplicativo Webex marcará esse endereço IP como bloqueado e encaminhará os avanços para o próximo organizador na lista.

• Se uma resposta não for recebida dentro de um período de tempo, a solicitação será considerada falhada devido ao tempo limite e as próximas solicitações serão enviadas para o próximo organizador. No entanto, a solicitação de tempo limite é considerada como falha. Algumas solicitações são repetidas após a falha (com o aumento do tempo de repetição). As solicitações que o não vital assumido não são repetidas.

Quando um novo organizador é tentado com êxito, ele se torna o novo organizador selecionado se o organizador estiver presente na lista. Depois que o último organizador na lista for testado, o aplicativo Webex será revertido para o primeiro.

No caso de pulsação, se houver duas falhas de solicitação consecutivas, o aplicativo Webex reinicializará o canal de evento.

Observe que o aplicativo Webex não executa o failback e a descoberta de serviços DNS é realizada apenas uma vez ao iniciar sessão.

Durante o início de sessão, o aplicativo Webex tenta baixar o arquivo de configuração por meio da interface XSP/Dms. Ele executa uma pesquisa de registro A/AAAA do host na URL DMS recuperada e se conecta ao primeiro IP. Primeiro, ele tentará enviar a solicitação para baixar o arquivo de configuração usando um token SSO. Se isso falhar por qualquer motivo, ele tentará novamente, mas com o nome de usuário e a senha do dispositivo.