Resiliência e recuperação de desastres no Serviço Azure Web PubSub

A resiliência e a recuperação de desastres são uma necessidade comum dos sistemas online. O Serviço Azure Web PubSub já garante 99,9% de disponibilidade, mas ainda é um serviço regional. Quando há uma interrupção em toda a região, é fundamental que o serviço continue processando mensagens em tempo real em uma região diferente.

Para a recuperação de desastres regionais, recomendamos as duas abordagens a seguir:

• Habilite a replicação geográfica (maneira fácil). Esse recurso lidará com failover regional para você automaticamente. Quando habilitado, permanece apenas uma instância do Azure SignalR e nenhuma alteração de código é introduzida. Verifique a replicação geográfica para obter detalhes.
• Utilize vários endpoints. Saiba como fazê-lo neste documento

Alta arquitetura disponível para o serviço Web PubSub

Há dois padrões típicos usando o serviço Web PubSub:

• Um é o padrão cliente-servidor em que os clientes enviam eventos para o servidor e o servidor envia mensagens por push para os clientes.
• Outro é o padrão cliente-cliente que os clientes publicam/sub mensagens através do serviço Web PubSub para outros clientes.

As seções abaixo descrevem diferentes maneiras de esses dois padrões fazerem a recuperação de desastres

Arquitetura de alta disponibilidade para padrão cliente-servidor

Para ter resiliência entre regiões para o serviço Web PubSub, você precisa configurar várias instâncias de serviço em regiões diferentes. Assim, quando uma região está inativa, as outras podem ser usadas como backup.

Uma configuração típica para cenários entre regiões é ter dois (ou mais) pares de instâncias de serviço Web PubSub e servidores de aplicativos.

Dentro de cada par o servidor de aplicativos e o serviço Web PubSub estão localizados na mesma região, e o serviço Web PubSub define o manipulador de eventos upstream para o servidor de aplicativos na mesma região.

Para ilustrar melhor a arquitetura, chamamos o serviço Web PubSub de serviço primário para o servidor de aplicativos no mesmo par. E chamamos os serviços Web PubSub em outros pares como os serviços secundários para o servidor de aplicativos.

O servidor de aplicativos pode usar a API de verificação de integridade do serviço para detetar se seus serviços primários e secundários estão íntegros ou não. Por exemplo, para um serviço Web PubSub chamado demo, o ponto de extremidade https://demo.webpubsub.azure.com/api/health retorna 200 quando o serviço está íntegro. O servidor do aplicativo pode chamar periodicamente os pontos de extremidade ou chamar os pontos de extremidade sob demanda para verificar se os pontos de extremidade estão íntegros. Os clientes WebSocket geralmente negociam com seu servidor de aplicativos primeiro para obter a URL conectada ao serviço Web PubSub, e o aplicativo usa essa etapa de negociação para fazer failover dos clientes para outros serviços secundários íntegros. Etapas detalhadas como abaixo:

1. Quando um cliente negocia com o servidor de aplicativos, o servidor de aplicativos DEVE retornar apenas pontos de extremidade de serviço Web PubSub primários para que, em casos normais, os clientes se conectem apenas aos pontos de extremidade primários.
2. Quando a instância primária estiver inativa, negociar DEVE retornar um ponto de extremidade secundário íntegro para que o cliente ainda possa fazer conexões e o cliente se conecte ao ponto de extremidade secundário.
3. Quando a instância primária estiver ativada, negociar DEVE retornar o ponto de extremidade primário íntegro para que os clientes agora possam se conectar ao ponto de extremidade primário
4. Quando o servidor de aplicativos transmitemensagens, ele DEVE transmitir mensagens para todos os pontos de extremidade íntegros, incluindo primário e secundário.
5. O servidor de aplicativos pode fechar conexões conectadas a pontos de extremidade secundários para forçar os clientes a se reconectarem ao ponto de extremidade primário íntegro.

Com essa topologia, a mensagem de um servidor ainda pode ser entregue a todos os clientes, pois todos os servidores de aplicativos e instâncias de serviço Web PubSub estão interconectados.

Ainda não integramos a estratégia no SDK, portanto, por enquanto, o aplicativo precisa implementar essa estratégia por si só.

Em resumo, o que o lado do aplicativo precisa implementar é:

1. Exame de saúde. O aplicativo pode verificar se o serviço está íntegro usando a API de verificação de integridade do serviço periodicamente em segundo plano ou sob demanda para cada chamada de negociação .
2. Lógica de negociação. O aplicativo retorna o ponto de extremidade primário íntegro por padrão. Quando o ponto de extremidade primário está inativo, o aplicativo retorna o ponto de extremidade secundário íntegro.
3. Lógica de transmissão. Quando as mensagens são enviadas para vários clientes, o aplicativo precisa certificar-se de que transmite mensagens para todos os pontos de extremidade íntegros .

Abaixo está um diagrama que ilustra essa topologia:

Sequência de failover e práticas recomendadas

Agora você tem a configuração correta da topologia do sistema. Sempre que uma instância do serviço Web PubSub estiver inativa, o tráfego online será roteado para outras instâncias. Aqui está o que acontece quando uma instância primária está inativa (e se recupera depois de algum tempo):

1. A instância de serviço principal está inativa, todos os clientes conectados a essa instância serão descartados.
2. Novos clientes ou reconectar cliente negociar com o servidor de aplicativo
3. O servidor de aplicativos deteta que a instância do serviço primário está inativa e a negociação interrompe o retorno desse ponto de extremidade e começa a retornar um ponto de extremidade secundário íntegro.
4. Os clientes se conectam à instância secundária.
5. Agora, a instância secundária recebe todo o tráfego online. Todas as mensagens do servidor para os clientes ainda podem ser entregues, pois o secundário está conectado a todos os servidores de aplicativos. Mas as mensagens de evento de cliente para servidor são enviadas apenas para o servidor de aplicativo upstream na mesma região.
6. Depois que a instância primária é recuperada e on-line novamente, o servidor de aplicativos deteta que a instância primária está de volta à íntegra. A negociação agora retornará o ponto de extremidade primário novamente para que novos clientes sejam conectados de volta ao principal. Mas os clientes existentes não serão descartados e continuarão conectados ao secundário até que se desconectem.

Os diagramas abaixo ilustram como o failover é feito:

Fig.1 Antes do failover

Fig.2 Após failover

Fig.3 Pouco tempo após a recuperação primária

Você pode ver, em casos normais, apenas o servidor de aplicativo primário e o serviço Web PubSub têm tráfego online (em azul).

Após o failover, o servidor de aplicativos secundário e o serviço Web PubSub também ficam ativos. Depois que o serviço Web PubSub principal estiver online novamente, novos clientes se conectarão ao Web PubSub principal. Mas os clientes existentes ainda se conectam ao secundário para que ambas as instâncias tenham tráfego.

Depois que todos os clientes existentes se desconectarem, seu sistema voltará ao normal (Fig.1).

Existem dois padrões principais para implementar uma arquitetura de alta disponibilidade entre regiões:

1. O primeiro é ter um par de servidor de aplicativos e uma instância de serviço Web PubSub tomando todo o tráfego on-line e ter outro par como backup (chamado ativo/passivo, ilustrado na Fig.1).
2. A outra é ter dois (ou mais) pares de servidores de aplicativos e instâncias de serviço Web PubSub, cada um fazendo parte do tráfego online e servindo como backup para outros pares (chamados ativo/ativo, semelhante à Fig.3).

O serviço Web PubSub pode suportar ambos os padrões, a principal diferença é como você implementa servidores de aplicativos. Se os servidores de aplicativos estiverem ativos/passivos, o serviço Web PubSub também será ativo/passivo (pois o servidor de aplicativo primário retorna apenas sua instância de serviço Web PubSub principal). Se os servidores de aplicativos estiverem ativos/ativos, o serviço Web PubSub também estará ativo/ativo (pois todos os servidores de aplicativos retornarão suas próprias instâncias primárias do Web PubSub, para que todos possam obter tráfego).

Não importa quais padrões você escolha usar, você precisará conectar cada instância do serviço Web PubSub a um servidor de aplicativos como função principal .

Também devido à natureza da conexão WebSocket (é uma conexão longa), os clientes experimentarão quedas de conexão quando houver um desastre e o failover ocorrer. Você precisará lidar com esses casos do lado do cliente para torná-los transparentes para seus clientes finais. Por exemplo, reconecte-se depois que uma conexão for fechada.

Arquitetura de alta disponibilidade para padrão cliente-cliente

Para o padrão cliente-cliente, atualmente ainda não é possível oferecer suporte a uma recuperação de desastres sem tempo de inatividade usando várias instâncias. Se você tiver requisitos de alta disponibilidade, considere o uso da replicação geográfica.

Como testar um failover

Siga as etapas para acionar o failover:

1. Na guia Rede do recurso principal no portal, desative o acesso à rede pública. Se o recurso tiver a rede privada habilitada, use regras de controle de acesso para negar todo o tráfego.
2. Reinicie o recurso primário.

Próximos passos

Neste artigo, você aprendeu como configurar seu aplicativo para obter resiliência para o serviço Web PubSub.

Use estes recursos para começar a criar seu próprio aplicativo: