Replicação geográfica no Azure SignalR
As empresas que procuram presença local ou necessitam de um sistema de ativação pós-falha robusto optam frequentemente por implementar serviços em várias regiões do Azure. Com a integração da replicação geográfica no Azure SignalR, o gerenciamento de cenários de várias regiões tornou-se significativamente mais fácil.
Benefícios do uso da replicação geográfica
- Mais resiliente a interrupções regionais: se ocorrer uma interrupção regional, o DNS do Azure SignalR será resolvido para réplicas íntegras em outras regiões.
- Comunicação entre regiões. Réplicas diferentes podem se comunicar entre si como se fossem a mesma instância.
- Velocidade de rede aprimorada: clientes geograficamente dispersos se conectarão à réplica mais próxima. Essas réplicas se comunicam por meio do backbone de rede global do Azure, garantindo uma rede rápida e estável.
- Configurações compartilhadas. Todas as réplicas mantêm a configuração do recurso principal do Serviço Azure SignalR.
Pré-requisitos
- Um Serviço SignalR do Azure na camada Premium.
Exemplo de caso de uso
A Contoso é uma empresa de mídia social com sua base de clientes espalhada pelos EUA e Canadá. Para atender esses clientes e permitir que eles se comuniquem uns com os outros, a Contoso executa seus serviços na região central dos EUA. O Serviço Azure SignalR é usado para lidar com conexões de usuário e facilitar a comunicação entre usuários. Os usuários finais da Contoso são, em sua maioria, usuários de telefone. Devido às longas distâncias geográficas, os usuários finais no Canadá podem experimentar alta latência e baixa qualidade da rede.
Antes do advento do recurso de replicação geográfica, a Contoso podia configurar outro Serviço SignalR do Azure no Canada Central para atender seus usuários canadenses. Ao configurar um Serviço Azure SignalR geograficamente mais próximo, os usuários finais agora têm melhor qualidade de rede e menor latência.
No entanto, gerenciar vários Serviços do Azure SignalR traz alguns desafios:
- Seria necessário um mecanismo de comunicação entre regiões para permitir a conversação entre os utilizadores do Canadá e dos EUA.
- A equipe de desenvolvimento precisaria gerenciar dois Serviços SignalR do Azure separados, cada um com domínio e cadeia de conexão distintos.
- Se ocorrer uma interrupção regional, o tráfego precisa ser transferido para outra região.
Aproveitando a replicação geográfica
Com o novo recurso de replicação geográfica, a Contoso agora pode estabelecer uma réplica no Canada Central, superando efetivamente os obstáculos acima mencionados.
Criar uma réplica do SignalR
Para criar uma réplica, navegue até a folha Réplicas do SignalR no portal do Azure e clique em Adicionar para criar uma réplica. Ele será ativado automaticamente após a criação.
Após a criação, você poderá visualizar/editar sua réplica no portal clicando no nome da réplica.
Nota
- Atualmente, a contagem de réplicas está limitada a um máximo de 8 por recurso primário.
Preços e unidade de recursos
Cada réplica tem o seu próprio unit
e autoscale settings
.
A réplica é um recurso da camada Premium do Serviço Azure SignalR. Cada réplica é cobrada separadamente de acordo com sua própria unidade e tráfego de saída. A cota de mensagens gratuitas também é calculada separadamente.
No exemplo anterior, a Contoso adicionou uma réplica no Canada Central. A Contoso pagaria pela réplica na Canada Central de acordo com sua unidade e mensagem em Preço Premium.
Haverá taxas de saída para o tráfego de saída entre regiões. Se uma mensagem for transferida entre réplicas e enviada com êxito para um cliente ou servidor após a transferência, ela será cobrada como uma mensagem de saída.
Eliminar réplicas
Depois de criar uma réplica para seu Serviço Azure SignalR, você pode excluí-la a qualquer momento se não for mais necessária.
Para excluir uma réplica no portal do Azure:
- Navegue até o Serviço Azure SignalR e selecione a folha Réplicas . Clique na réplica que deseja excluir.
- Clique no botão Excluir na folha de visão geral da réplica.
Entender como a réplica do SignalR funciona
O diagrama abaixo fornece uma breve ilustração da funcionalidade das réplicas do SignalR:
- O cliente negocia com o servidor de aplicativos e recebe um redirecionamento para o serviço Azure SignalR. Em seguida, ele resolve o FQDN (nome de domínio totalmente qualificado) do serviço SignalR —
contoso.service.signalr.net
. Esse FQDN aponta para um Gerenciador de Tráfego, que retorna o Nome Canônico (CNAME) da instância regional SignalR mais próxima. - Com esse CNAME, o cliente estabelece uma conexão com a instância regional (Réplica).
- As duas réplicas sincronizarão os dados entre si. As mensagens enviadas para uma réplica seriam transferidas para outras réplicas, se necessário.
- Caso uma réplica falhe na verificação de integridade conduzida pelo Gerenciador de Tráfego (TM), a TM excluirá o ponto de extremidade da instância com falha de seu processo de resolução de domínio. Para obter detalhes, consulte abaixo Resiliência e recuperação de desastres
Nota
- No plano de dados, um recurso primário do Azure SignalR funciona de forma idêntica às suas réplicas
Resiliência e recuperação após desastre
O Serviço Azure SignalR utiliza um gerenciador de tráfego para verificações de integridade e resolução de DNS para suas réplicas. Em circunstâncias normais, quando todas as réplicas estiverem funcionando corretamente, os clientes serão direcionados para a réplica mais próxima. Por exemplo:
- Os clientes próximos
eastus
serão direcionados para a réplica localizada emeastus
. - Da mesma forma, os clientes próximos serão
westus
direcionados para a réplica emwestus
.
No caso de uma interrupção regional em Eastus (ilustrado abaixo), o gerente de tráfego detetará a falha na verificação de integridade para essa região. Em seguida, o DNS dessa réplica defeituosa será excluído dos resultados da resolução DNS do gerenciador de tráfego. Após uma duração de tempo de vida (TTL) do DNS, que é definida como 90 segundos, os clientes em eastus
serão redirecionados para se conectar com a réplica no westus
.
Assim que o problema for eastus
resolvido e a região estiver novamente online, a verificação de integridade será bem-sucedida. Os clientes serão eastus
, então, mais uma vez, direcionados para a réplica em sua região. Essa transição é suave, pois os clientes conectados não serão afetados até que essas conexões existentes sejam fechadas.
Esse processo de failover e recuperação é automático e não requer intervenção manual.
Para conexões de servidor, o failover e a recuperação funcionam da mesma forma que para conexões de cliente.
Nota
- Esse mecanismo de failover é para o serviço Azure SignalR. As interrupções regionais do servidor de aplicativos estão além do escopo deste documento.
Desabilitar ou habilitar o ponto de extremidade de réplica
Ao configurar uma réplica, você tem a opção de habilitar ou desabilitar seu ponto de extremidade. Se estiver desabilitada, a resolução DNS do FQDN principal não incluirá a réplica e, portanto, o tráfego não será direcionado para ela.
Você também pode ativar a desativação do ponto de extremidade depois que ele for criado. Na folha de réplicas do recurso primário, clique no botão de reticências no lado direito da réplica e escolha Habilitar ponto de extremidade ou Desabilitar ponto de extremidade:
Antes de excluir uma replicação, considere desativar seu ponto de extremidade primeiro. Com o tempo, as conexões existentes serão desconectadas. Como não há novas conexões chegando, a replicação fica ociosa finalmente. Isso garante um processo de exclusão contínuo.
Esse recurso também é útil para solucionar problemas regionais.
Nota
- Devido ao cache DNS, pode levar vários minutos para que a atualização de DNS entre em vigor.
- As conexões existentes permanecem inalteradas até que se desconectem.
Impacto no desempenho após a adição de réplicas
Depois que as réplicas forem habilitadas, os clientes distribuirão naturalmente com base em suas localizações geográficas. Embora o SignalR assuma a responsabilidade de sincronizar dados entre essas réplicas, você ficará satisfeito em saber que a sobrecarga associada na Carga do Servidor é mínima para os casos de uso mais comuns.
Especificamente, se seu aplicativo normalmente transmite para grupos maiores (tamanho >10) ou uma única conexão, o impacto na sincronização no desempenho é quase impercetível. Se você estiver enviando mensagens para grupos pequenos (tamanho < 10) ou usuários individuais, poderá notar um pouco mais de sobrecarga de sincronização.
Para garantir um gerenciamento de failover eficaz, é recomendável definir o tamanho da unidade de cada réplica para lidar com todo o tráfego. Como alternativa, você pode habilitar o dimensionamento automático para gerenciar isso.
Para obter mais avaliações de desempenho, consulte Desempenho.