Replicação geográfica no Azure SignalR

As empresas que buscam presença local ou que exigem um sistema de failover robusto geralmente optam por implantar 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 à interrupção regional: 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 de Backbone de rede global do Azure, garantindo uma rede rápida e estável.
• Configurações compartilhadas. Todas as réplicas retêm a configuração do recurso primário do Serviço do Azure SignalR.

Pré-requisitos

• Um Serviço do Azure SignalR na camada Premium.

Caso de uso de exemplo

A Contoso é uma empresa de mídia social com sua base de clientes espalhada pelos EUA e Canadá. Para atender a esses clientes e permitir que eles se comuniquem entre si, a Contoso executa seus serviços nos EUA Central. O Serviço do Azure SignalR é usado para lidar com conexões de usuário e facilitar a comunicação entre os usuários. Os usuários finais da Contoso são principalmente 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 de rede.

Antes do advento do recurso de replicação geográfica, a Contoso poderia configurar outro Serviço do Azure SignalR no Canadá Central para atender seus usuários canadenses. Ao configurar um Serviço do Azure SignalR geograficamente mais próximo, os usuários finais agora têm melhor qualidade de rede e menor latência.

No entanto, o gerenciamento de vários Serviços do Azure SignalR traz alguns desafios:

1. Um mecanismo de comunicação entre regiões seria necessário para habilitar a conversa entre usuários do Canadá e dos EUA.
2. A equipe de desenvolvimento precisaria gerenciar dois Serviços do Azure SignalR separados, cada um com domínio distinto e cadeia de conexão.
3. Se ocorrer uma interrupção regional, o tráfego precisará ser alternado 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 Canadá Central, superou efetivamente os obstáculos mencionados acima.

Criar uma réplica do SignalR

Portal

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á habilitado automaticamente após a criação.

Após a criação, você poderá exibir/editar sua réplica no portal clicando no nome da réplica.

Bicep

Use o Visual Studio Code ou seu editor favorito para criar um arquivo com o seguinte conteúdo e nomeie-o main.bicep:

@description('The name for your SignalR service')
param primaryName string = 'contoso'

@description('The region in which to create your SignalR service')
param primaryLocation string = 'eastus'

@description('Unit count of your SignalR service')
param primaryCapacity int = 1

resource primary 'Microsoft.SignalRService/signalr@2023-08-01-preview' = {
  name: primaryName
  location: primaryLocation
  sku: {
    capacity: primaryCapacity
    name: 'Premium_P1'
  }
  properties: {
  }
}

@description('The name for your SignalR replica')
param replicaName string = 'contoso-westus'

@description('The region in which to create the SignalR replica')
param replicaLocation string = 'westus'

@description('Unit count of the SignalR replica')
param replicaCapacity int = 1

@description('Whether to enable region endpoint for the replica')
param regionEndpointEnabled string = 'Enabled'

resource replica 'Microsoft.SignalRService/signalr/replicas@2023-08-01-preview' = {
  parent: primary
  name: replicaName
  location: replicaLocation
  sku: {
    capacity: replicaCapacity
    name: 'Premium_P1'
  }
  properties: {
    regionEndpointEnabled: regionEndpointEnabled
  }
}

Implantar o arquivo Bicep usando a CLI do Azure

az group create --name MyResourceGroup --location eastus
az deployment group create --resource-group MyResourceGroup --template-file main.bicep

Observação

• No momento, 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 os próprios unit e autoscale settings.

A réplica é um recurso de camada Premium do Serviço do 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 Canadá Central. A Contoso pagaria pela réplica no Canadá Central de acordo com sua unidade e mensagem no 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 a um cliente ou servidor após a transferência, ela será cobrada como uma mensagem de saída.

Excluir uma réplica

Depois de criar uma réplica para o Serviço do Azure SignalR, você poderá excluí-la a qualquer momento se ela não for mais necessária.

Para excluir uma réplica no portal do Azure:

1. Navegue até o Serviço do Azure SignalR e selecione a folha Réplicas. Clique na réplica que você deseja excluir.
2. Clique no botão Excluir na folha de visão geral da réplica.

Entender como a réplica do SignalR funciona

O diagrama a seguir fornece uma breve ilustração da funcionalidade das Réplicas do SignalR:

1. O cliente negocia com o servidor de aplicativos e recebe um redirecionamento para o serviço do 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 CNAME (Nome Canonical) da instância regional mais próxima do SignalR.
2. Com esse CNAME, o cliente estabelece uma conexão com a instância regional (Réplica).
3. As duas réplicas sincronizarão dados entre si. As mensagens enviadas para uma réplica seriam transferidas para outras réplicas, se necessário.
4. Caso uma réplica falhe na verificação de integridade realizada pelo Gerenciador de Tráfego (TM), o TM excluirá o ponto de extremidade da instância com falha de seu processo de resolução de domínio. Para obter detalhes, consulte Resiliência e Recuperação de Desastre abaixo

Observação

• 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 de desastre

O Serviço do 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:

• Clientes próximos a eastus serão direcionados para a réplica localizada em eastus.
• Da mesma forma, os clientes próximos a westus serão direcionados para a réplica em westus.

No caso de uma interrupção regional no leste (ilustrada abaixo), o gerenciador de tráfego detectará a falha de verificação de integridade dessa região. Em seguida, o DNS dessa réplica com falha será excluído dos resultados de resolução DNS do gerenciador de tráfego. Após uma duração de TTL (vida útil) do DNS, que é definida como 90 segundos, os clientes em eastus serão redirecionados para se conectarem à réplica em westus.

Depois que o problema no eastus for resolvido e a região estiver online novamente, a verificação de integridade terá êxito. Os clientes em eastus serão direcionados novamente para a réplica em sua região. Essa transição é tranquila, 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 nenhuma intervenção manual.

Para conexões de servidor, o failover e a recuperação funcionam da mesma maneira que para conexões de cliente.

Observação

• Esse mecanismo de failover é para o serviço do Azure SignalR. Interrupções regionais do servidor de aplicativos estão fora 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 desabilitado, a resolução DNS do FQDN primário não incluirá a réplica e, portanto, o tráfego não será direcionado para ela.

Você também pode habilitar a desabilitaçã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 desabilitar seu ponto de extremidade primeiro. Com o tempo, as conexões existentes serão desconectadas. Como não há conexões novas, a replicação fica ociosa. Isso garante um processo de exclusão contínuo.

Esse recurso também é útil para solucionar problemas regionais.

Observação

• Devido ao cache DNS, pode levar vários minutos para que a atualização DNS entre em vigor.
• As conexões existentes permanecem não afetadas até se desconectarem.

Impacto no desempenho após a adição de réplicas

Depois que as réplicas estiverem 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, a sobrecarga associada na Carga do Servidor é mínima para a maioria dos casos de uso comuns.

Especificamente, se seu aplicativo normalmente transmite para grupos maiores (tamanho >10) ou uma única conexão, o impacto no desempenho da sincronização é quase imperceptível. Se você estiver trocando mensagens com 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ção de desempenho, consulte Desempenho.

Configurações não herdadas e herdadas

As réplicas herdam a maioria das configurações do recurso primário; no entanto, algumas configurações devem ser configuradas diretamente nas réplicas. Veja abaixo a lista dessas configurações:

1. SKU: Cada réplica tem seu próprio nome de SKU e tamanho de unidade. As regras de dimensionamento automático para réplicas precisam ser configuradas separadamente com base nas respectivas métricas individuais.
2. Pontos de extremidade privados compartilhados: embora os pontos de extremidade privados compartilhados sejam automaticamente replicados para réplicas, aprovações separadas são necessárias em recursos de link privado de destino. Para adicionar ou remover pontos de extremidade privados compartilhados, gerencie-os no recurso primário. Não habilite a réplica até que seu ponto de extremidade privado compartilhado tenha sido aprovado.
3. Configurações de destino de log. Se não estiver configurado nas réplicas, somente os logs do recurso primário serão transferidos.
4. Alertas.

Todas as outras configurações são herdadas do recurso primário. Por exemplo, chaves de acesso, identidade, firewall do aplicativo, domínios personalizados, pontos de extremidade privados e controle de acesso.