Fiabilidade no Azure Communications Gateway

  • Artigo

O Azure Communications Gateway garante que seu serviço seja confiável usando mecanismos de redundância do Azure e comportamento de repetição específico do SIP. Sua rede deve atender a requisitos específicos para garantir a disponibilidade do serviço.

Modelo de redundância do Azure Communications Gateway

As implantações do Gateway de Comunicação do Azure de produção (também chamadas de implantações padrão) consistem em três regiões separadas: uma região de gerenciamento e duas regiões de serviço. As implantações de laboratório consistem em uma região de gerenciamento e uma região de serviço.

Este artigo descreve os dois tipos de região diferentes e seus modelos de redundância distintos. Ele cobre a confiabilidade regional com zonas de disponibilidade e a confiabilidade entre regiões com recuperação de desastres. Para obter uma visão geral mais detalhada da confiabilidade no Azure, consulte Confiabilidade do Azure.

Diagrama de duas regiões de serviço, uma região de gerenciamento e dois sites de operadores.

Regiões de serviço

As regiões de serviço contêm a infraestrutura de voz e API usada para lidar com o tráfego entre a rede e os serviços de comunicação escolhidos.

As implantações do Gateway de Comunicação do Azure de produção têm duas regiões de serviço que são implantadas em modo ativo-ativo (conforme exigido pelos programas Operator Connect e Teams Phone Mobile). O failover rápido entre as regiões de serviço é fornecido no nível de infraestrutura/IP e no nível do aplicativo (SIP/RTP/HTTP).

As regiões de serviço também contêm a infraestrutura para a API de provisionamento do Azure Communications Gateway.

Gorjeta

As implantações de produção sempre devem ter duas regiões de serviço, mesmo que uma das regiões de serviço escolhidas esteja em uma única região do Azure Geography (por exemplo, Catar). Se você escolher uma Geografia do Azure de região única, escolha uma segunda região do Azure em uma Geografia do Azure diferente.

As regiões de serviço são idênticas em operação e fornecem resiliência para falhas de Zona e Regionais. Cada região de serviço pode transportar 100% do tráfego usando a instância do Azure Communications Gateway. Como tal, os utilizadores finais devem continuar a poder efetuar e receber chamadas com êxito durante qualquer período de inatividade por Zona ou Região.

As implantações de laboratório têm uma região de serviço.

Requisitos de roteamento de chamadas

O Azure Communications Gateway oferece um modelo de redundância de "rediscagem bem-sucedida": chamadas tratadas por pares com falha são encerradas, mas novas chamadas são roteadas para pares íntegros. Este modelo espelha o modelo de redundância fornecido pelo Microsoft Teams.

Para implantações de produção, esperamos que sua rede tenha dois locais geograficamente redundantes. Cada site deve ser emparelhado com uma região do Azure Communications Gateway. O modelo de redundância depende da conectividade cruzada entre sua rede e as regiões de serviço do Azure Communications Gateway.

Diagrama de dois sites de operadores e duas regiões de serviço. Ambas as regiões de serviço se conectam a ambos os locais, com rotas primárias e secundárias.

As implantações de laboratório devem se conectar a um site na rede.

Cada região de serviço do Azure Communications Gateway fornece um registro SRV. Esse registro contém todos os pares SIP que fornecem funcionalidade SBC (para roteamento de chamadas para serviços de comunicações) dentro da região. Esse registro SRV pode apontar para qualquer endereço IP no intervalo de IP /28 fornecido a você pela sua equipe de integração.

Se o seu Gateway de Comunicação do Azure incluir MCP (Ponto de Controle Móvel), cada região de serviço fornecerá um registro SRV extra para MCP. Cada registro MCP por região contém MCP dentro da região com prioridade máxima e MCP na outra região com prioridade mais baixa.

Cada site da sua rede deve:

  • Envie tráfego para sua região de serviço local do Azure Communications Gateway por padrão.
  • Localize pares do Azure Communications Gateway dentro de uma região usando SRV DNS, conforme descrito na RFC 3263.
    • Faça uma pesquisa SRV de DNS no nome de domínio para a conexão da região de serviço com sua rede, usando _sip._tls.<regional-FQDN-from-portal>. Substitua <regional-FQDN-from-portal> pelos FQDNs por região dos campos Nome do host na página Visão geral do seu recurso no portal do Azure. Por exemplo, se sua implantação usa commsgw.azure.com nomes de _sip._tls.pstn-region1.<deployment-id>.commsgw.azure.com domínio, procure a primeira região.
    • Se a pesquisa SRV retornar vários destinos, use o peso e a prioridade de cada destino para selecionar um único destino.
  • Envie novas chamadas para os pares disponíveis do Azure Communications Gateway.
  • Ser capaz de receber tráfego de qualquer endereço IP em cada um dos intervalos de IP associados ao seu Gateway de Comunicações do Azure.

Quando sua rede roteia chamadas para os pares SIP do Azure Communications Gateway para a função SBC, ela deve:

  • Use SIP OPTIONS (ou uma combinação de OPTIONS e tráfego SIP) para monitorar a disponibilidade dos pares SIP do Azure Communications Gateway.
  • Tente novamente os convites que receberam 408 respostas, 503 respostas ou 504 respostas ou não receberam respostas, redirecionando-as para outros pares disponíveis no site local. Procure a outra região de serviço (definida pelo registro SRV da outra região) somente se todos os pares na região de serviço local tiverem falhado.
  • Nunca tente chamar novamente que recebam respostas de erro diferentes de 408, 503 e 504.

Se sua implantação do Gateway de Comunicação do Azure incluir MCP (Ponto de Controle Móvel) integrado, sua rede deverá fazer o seguinte para MCP:

  • Detete quando o MCP em uma região não está disponível, marque os destinos para o registro SRV dessa região como indisponíveis e tente novamente periodicamente para determinar quando a região estará disponível novamente. O MCP não responde às OPÇÕES SIP.
  • Lide com 5xx respostas do MCP de acordo com a política da sua organização. Por exemplo, você pode repetir a solicitação ou permitir que a chamada continue sem passar pelo Azure Communications Gateway e pelo Microsoft Phone System.

Os detalhes desse comportamento de roteamento são específicos para sua rede. Você deve concordá-los com sua equipe de integração durante seu projeto de integração.

Regiões de gestão

As regiões de gerenciamento contêm a infraestrutura usada para o pedido, monitoramento e cobrança do Gateway de Comunicação do Azure. Toda a infraestrutura nessas regiões é implantada de forma zonalmente redundante, o que significa que todos os dados são replicados automaticamente em cada zona de disponibilidade dentro da região. Todos os dados de configuração críticos também são replicados para cada uma das Regiões de Serviço para garantir o funcionamento adequado do serviço durante uma falha de região do Azure.

Suporte à zona de disponibilidade

As zonas de disponibilidade do Azure são pelo menos três grupos fisicamente separados de datacenters em cada região do Azure. Os datacenters dentro de cada zona são equipados com infraestrutura independente de energia, resfriamento e rede. No caso de uma falha de zona local, as zonas de disponibilidade são projetadas de modo que, se uma zona for afetada, os serviços regionais, a capacidade e a alta disponibilidade sejam suportados pelas duas zonas restantes.

As falhas podem variar de falhas de software e hardware a eventos como terremotos, inundações e incêndios. A tolerância a falhas é alcançada com redundância e isolamento lógico dos serviços do Azure. Para obter informações mais detalhadas sobre zonas de disponibilidade no Azure, consulte Regiões e zonas de disponibilidade.

Os serviços habilitados para zonas de disponibilidade do Azure são projetados para fornecer o nível certo de confiabilidade e flexibilidade. Eles podem ser configurados de duas maneiras. Eles podem ser redundantes de zona, com replicação automática entre zonas, ou zonais, com instâncias fixadas a uma zona específica. Você também pode combinar essas abordagens. Para obter mais informações sobre arquitetura zonal versus arquitetura com redundância de zona, consulte Recomendações para usar zonas e regiões de disponibilidade.

Experiência de zoneamento para regiões de serviço

Durante uma interrupção em toda a zona, as chamadas atendidas pela zona afetada são encerradas, com uma breve perda de capacidade dentro da região até que a autorrecuperação do serviço reequilibre os recursos subjacentes para zonas saudáveis. Esta autorrecuperação não depende da restauração da zona; espera-se que o estado de autorrecuperação do serviço gerenciado pela Microsoft compense uma zona perdida, usando a capacidade de outras zonas. Os recursos de transporte de tráfego são implantados de forma redundante de zona, mas na escala mais baixa o tráfego pode ser tratado por um único recurso. Nesse caso, os mecanismos de failover descritos neste artigo reequilibram todo o tráfego para a outra região de serviço enquanto os recursos que transportam tráfego são reimplantados em uma zona íntegra.

Experiência de zoneamento para a região de gestão

Durante uma interrupção em toda a zona, nenhuma ação é necessária durante a recuperação da zona. A região de gestão auto-cura-se e reequilibra-se para tirar partido da zona saudável automaticamente.

Recuperação de desastres: fallback para outras regiões

A recuperação de desastres (DR) consiste na recuperação de eventos de alto impacto, como desastres naturais ou implantações com falha que resultam em tempo de inatividade e perda de dados. Independentemente da causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que suporte ativamente a DR. Antes de começar a pensar em criar seu plano de recuperação de desastres, consulte Recomendações para projetar uma estratégia de recuperação de desastres.

Quando se trata de DR, a Microsoft usa o modelo de responsabilidade compartilhada. Em um modelo de responsabilidade compartilhada, a Microsoft garante que a infraestrutura de linha de base e os serviços da plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente ou recorrem de uma região com falha para replicação cruzada para outra região habilitada. Para esses serviços, você é responsável por configurar um plano de recuperação de desastres que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas de plataforma como serviço (PaaS) do Azure fornecem recursos e orientação para dar suporte à DR e você pode usar recursos específicos do serviço para dar suporte à recuperação rápida para ajudar a desenvolver seu plano de DR.

Esta seção descreve o comportamento do Azure Communications Gateway durante uma interrupção em toda a região.

Recuperação de desastres: failover entre regiões para regiões de serviço

Durante uma interrupção em toda a região, os mecanismos de failover descritos neste artigo (sondagem OPTIONS e repetição SIP em caso de falha) reequilibrarão todo o tráfego de chamadas para a outra região de serviço, mantendo a disponibilidade. Vamos começar a restaurar a redundância regional. Restaurar a redundância regional durante o tempo de inatividade estendido pode exigir o uso de outras regiões do Azure. Se precisarmos migrar uma região com falha para outra região, consultaremos você antes de iniciar qualquer migração.

A função SBC no Azure Communications Gateway fornece sondagem OPTIONS para permitir que sua rede determine a disponibilidade de pares. Para MCP, sua rede deve ser capaz de detetar quando o MCP não está disponível e tentar novamente periodicamente para determinar quando o MCP está disponível novamente. O MCP não responde às OPÇÕES SIP.

Os clientes de API de provisionamento entram em contato com o Azure Communications Gateway usando o nome de domínio base para sua implantação. O registo DNS para este domínio tem um tempo de vida (TTL) de 60 segundos. Quando uma região falha, o Azure atualiza o registro DNS para fazer referência a outra região, para que os clientes que fazem uma nova pesquisa de DNS recebam os detalhes da nova região. Recomendamos garantir que os clientes possam fazer uma nova pesquisa de DNS e repetir uma solicitação 60 segundos após um tempo limite ou uma resposta 5xx.

Gorjeta

As implantações de laboratório não oferecem failover entre regiões (porque têm apenas uma região de serviço).

Recuperação de desastres: failover entre regiões para regiões de gerenciamento

O tráfego de voz e o provisionamento por meio do Portal de Gerenciamento de Números não são afetados por falhas na região de gerenciamento, porque os recursos correspondentes do Azure são hospedados em regiões de serviço. Os utilizadores do Portal de Gestão de Números poderão ter de iniciar sessão novamente.

Os serviços de monitoramento podem estar temporariamente indisponíveis até que o serviço seja restaurado. Se a região de gerenciamento tiver um tempo de inatividade prolongado, migraremos os recursos afetados para outra região disponível.

Escolhendo regiões de gerenciamento e serviço

Uma única implantação do Azure Communications Gateway foi projetada para lidar com seu tráfego dentro de uma área geográfica. Implante ambas as regiões de serviço em uma implantação de produção dentro da mesma área geográfica (por exemplo, América do Norte). Esse modelo garante que a latência nas chamadas de voz permaneça dentro dos limites exigidos pelos programas Operator Connect e Teams Phone Mobile.

Considere os seguintes pontos ao escolher os locais da região de serviço:

  • Selecione na lista de regiões disponíveis do Azure. Você pode ver as regiões do Azure que podem ser selecionadas como regiões de serviço na página Produtos por região .
  • Escolha regiões próximas às suas próprias instalações e os locais de emparelhamento entre sua rede e a Microsoft para reduzir a latência de chamadas.
  • Prefira pares regionais para minimizar o tempo de recuperação se ocorrer uma interrupção em várias regiões.

Escolha uma região de gerenciamento na lista a seguir:

  • E.U.A. Leste
  • E.U.A. Centro-Oeste
  • Europa Ocidental
  • Sul do Reino Unido
  • Índia Central
  • Canadá Central
  • Leste da Austrália

As regiões de gestão podem ser colocalizadas com regiões de serviço. Recomendamos escolher a região de gerenciamento mais próxima de suas regiões de serviço.

Nota

Se você estiver habilitando a Visualização da Proteção de Chamada do Operador do Azure, a região de serviço selecionada pode não ser a região do Azure onde os recursos de suporte são implantados. Consulte Produtos do Azure por Região para obter a lista de regiões de serviço de Proteção de Chamadas do Operador do Azure atualmente suportadas e fale com sua equipe de integração se tiver dúvidas sobre qual região está selecionada.

Contratos de nível de serviço

O design de confiabilidade descrito neste documento é implementado pela Microsoft e não é configurável. Para obter mais informações sobre os SLAs (contratos de nível de serviço) do Azure Communications Gateway, consulte o SLA do Azure Communications Gateway.

Próximos passos