Partilhar via

Fiabilidade no Azure Communications Gateway

O Azure Communications Gateway garante que o seu serviço é fiável ao utilizar os mecanismos de redundância da Azure e o comportamento de nova tentativa específico do SIP. A sua rede deve cumprir requisitos específicos para garantir a disponibilidade do serviço.

Modelo de redundância do Azure Communications Gateway

As implementações de Gateway de Comunicações Azure em produção (também chamadas de implementações padrão) consistem em três regiões separadas: uma região de gestão e duas regiões de serviço. As implantações laboratoriais consistem numa região de gestão e numa região de serviço.

Este artigo descreve os dois tipos diferentes de regiões e os seus modelos distintos de redundância. Cobre tanto a fiabilidade regional com zonas de disponibilidade como a fiabilidade inter-regional 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 gestão e dois locais de operadores.

Regiões de serviço

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

As implementações Azure Communications Gateway de produção têm duas regiões de serviço que são implementadas 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 ao nível da infraestrutura/IP e ao nível da aplicação (SIP/RTP/HTTP).

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

Sugestão

As implementações em produção devem ter sempre duas regiões de serviço, mesmo que uma das regiões escolhidas esteja numa Geografia Azure de uma única região (por exemplo, Qatar). Se escolheres uma Geografia Azure de uma única região, escolhe uma segunda região Azure numa Geografia Azure diferente.

As regiões de serviço são idênticas em funcionamento e proporcionam resiliência tanto a falhas de Zona como Regionais. Cada região de serviço pode transportar 100% do tráfego usando a instância Azure Communications Gateway. Assim, os utilizadores finais deverão continuar a conseguir fazer e receber chamadas com sucesso durante qualquer indisponibilidade de Zona ou Região.

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

Requisitos de encaminhamento de chamadas

O Azure Communications Gateway oferece um modelo de redundância de 'rediscagem bem-sucedida': as chamadas tratadas por pares falhados são terminadas, mas as novas chamadas são encaminhadas para pares saudáveis. Este modelo espelha o modelo de redundância fornecido pelo Microsoft Teams.

Para implementações em produção, esperamos que a sua rede tenha dois locais geograficamente redundantes. Cada local deve ser emparelhado com uma região Azure Communications Gateway. O modelo de redundância baseia-se na conectividade cruzada entre a sua rede e as regiões de serviço Azure Communications Gateway.

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

As implementações laboratoriais têm de se ligar a um local na sua rede.

Cada região de serviço do Azure Communications Gateway fornece um registo SRV. Este registo contém todos os pares SIP que fornecem funcionalidade SBC (para encaminhamento de chamadas para serviços de comunicação) dentro da região. Este registo SRV pode apontar para qualquer endereço IP na faixa de IP /28 fornecido pela sua equipa de integração.

Se o seu Azure Communications Gateway incluir Mobile Control Point (MCP), cada região de serviço fornece um registo SRV extra para o MCP. Cada registo MCP por região contém MCP dentro da região com prioridade máxima e MCP na outra região com prioridade inferior.

Cada site da sua rede deve:

  • Enviar o tráfego, por padrão, para a região de serviço local do Gateway de Comunicações do Azure.
  • Localize os pares do Azure Communications Gateway dentro de uma região usando DNS SRV, conforme descrito no RFC 3263.
    • Faça uma pesquisa DNS SRV no nome de domínio da ligação da região de serviço à sua rede, usando _sip._tls.<regional-FQDN-from-portal>. Substitua <regional-FQDN-from-portal> pelos FQDNs por região a partir dos campos Nome do Anfitrião na página de Visão Geral para o seu recurso no portal Azure. Por exemplo, se a sua implementação usar commsgw.azure.com nomes de domínio, procure _sip._tls.pstn-region1.<deployment-id>.commsgw.azure.com para a primeira região.
    • Se a consulta SRV devolver múltiplos alvos, use o peso e a prioridade de cada alvo para selecionar um único alvo.
  • 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 Azure Communications Gateway.

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

  • Use SIP OPTIONS (ou uma combinação de OPTIONS e tráfego SIP) para monitorizar a disponibilidade dos pares SIP do Azure Communications Gateway.
  • Retente INVITES que tenham recebido 408 respostas, 503 ou 504 respostas ou que não tenham recebido respostas, redirecionando-as para outros pares disponíveis no site local. Redirecione para a outra região de serviço (definida pelo registo SRV da outra região) apenas se todos os pares da região de serviço local tiverem falhado.
  • Nunca volte a tentar chamadas que recebam respostas de erro que não sejam 408, 503 e 504.

Se a implementação do seu Azure Communications Gateway incluir um Ponto de Controlo Móvel (MCP) integrado, a sua rede deve fazer o seguinte para o MCP:

  • Detectar quando o MCP numa região está indisponível, marcar os alvos do registo SRV dessa região como indisponíveis e repetir periodicamente para determinar quando a região estará disponível novamente. O MCP não responde às SIP OPTIONS.
  • Trate das respostas 5xx do MCP de acordo com a política da sua organização. Por exemplo, pode tentar novamente o pedido, ou pode permitir que a chamada continue sem passar pelo Azure Communications Gateway e entrar no Microsoft Phone System.

Os detalhes deste comportamento de encaminhamento são específicos da sua rede. Deve acordar os detalhes com a sua equipa de onboarding durante o projeto de integração.

Regiões de gestão

As regiões de gestão contêm a infraestrutura utilizada para a encomenda, monitorização e faturação do Azure Communications Gateway. Toda a infraestrutura dentro destas regiões é implementada de forma zonalmente redundante, o que significa que todos os dados são automaticamente replicados em cada Zona de Disponibilidade dentro da região. Todos os dados críticos de configuração são também replicados para cada uma das Regiões de Serviço para garantir o funcionamento adequado do serviço durante uma falha na Região Azure.

Suporte à zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de datacenters dentro de cada região do Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.

Experiência de zona reduzida para regiões de serviço

Durante uma interrupção em toda a zona, as chamadas tratadas pela zona afetada são terminadas, com uma breve perda de capacidade na região até que a auto-recuperação do serviço reequilibre os recursos subjacentes para zonas saudáveis. Esta auto-cura não depende da restauração da zona; espera-se que o estado de auto-reparação do serviço gerido pela Microsoft compense uma zona perdida, utilizando capacidade de outras zonas. Recursos que transportam o tráfego são implementados de forma redundante em zonas, mas na escala mais baixa, o tráfego pode ser gerido por um único recurso. Neste 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 realocados numa zona saudável.

Experiência de redução de zona 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 cura-se e reequilibra-se automaticamente para tirar partido da zona saudável.

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

A recuperação de desastres (DR) refere-se a práticas que as organizações usam para se recuperar 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 criar seu plano de recuperação de desastres, consulte Recomendações para projetar uma estratégia de recuperação de desastres.

Para DR, a Microsoft usa o modelo de responsabilidade compartilhada . Neste modelo, a Microsoft garante que a infraestrutura de linha de base e os serviços da plataforma estejam disponíveis. No entanto, muitos serviços do Azure não replicam dados automaticamente nem possuem mecanismos de fallback para mudar de uma região com falha para outra região ativada. 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 da plataforma Azure como serviço (PaaS) fornece recursos e orientações para dar suporte à DR. Você pode usar recursos específicos do serviço para apoiar a recuperação rápida e ajudar a desenvolver o seu plano de DR.

Esta secção descreve o comportamento do Azure Communications Gateway durante uma interrupção regional.

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

Durante uma interrupção regional, os mecanismos de failover descritos neste artigo (sondagem OPTIONS e repetição SIP em caso de falha) redistribuem 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 redundância regional durante períodos prolongados de inatividade pode exigir a utilização de outras regiões Azure. Se precisarmos de migrar uma região falhada para outra região, consultámo-lo antes de iniciar qualquer migração.

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

Os clientes de API de provisionamento contactam o Azure Communications Gateway usando o nome de domínio base para a sua implementação. O registo DNS deste domínio tem um tempo de vida (TTL) de 60 segundos. Quando uma região falha, o Azure atualiza o registo DNS para se referir a outra região, pelo que os clientes que fazem uma nova pesquisa DNS recebem os detalhes da nova região. Recomendamos garantir que os clientes podem fazer uma nova pesquisa DNS e tentar novamente um pedido 60 segundos após um timeout ou uma resposta 5xx.

Sugestão

As implementaçõ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 de gestão

O tráfego de voz e o provisionamento através do Portal de Gestão de Números não são afetados por falhas na região de gestão, porque os recursos Azure correspondentes estão alojados em regiões de serviço. Os utilizadores do Portal de Gestão de Números podem precisar de iniciar sessão novamente.

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

Escolha das regiões de gestão e de serviço

Uma única implementação do Azure Communications Gateway foi concebida para gerir o seu tráfego dentro de uma área geográfica. Implantar ambas as regiões de serviço numa implementação em produção dentro da mesma área geográfica (por exemplo, América do Norte). Este modelo garante que a latência nas chamadas de voz se mantém dentro dos limites exigidos pelos programas Operator Connect e Teams Phone Mobile.

Considere os seguintes pontos ao escolher as localizações da sua região de serviço:

  • Selecione da lista de regiões Azure disponíveis. Pode ver as regiões Azure que podem ser selecionadas como regiões de serviço na página Produtos por região .
  • Escolha regiões próximas das suas próprias instalações e dos locais de peering entre a sua rede e a Microsoft para reduzir a latência das chamadas.
  • Prefira pares regionais para minimizar o tempo de recuperação caso ocorra uma falha em várias regiões.

Escolha uma região de gestão da seguinte lista:

  • 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 co-localizadas com regiões de serviço. Recomendamos escolher a região de gestão mais próxima das suas regiões de serviço.

Contratos de nível de serviço

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

Próximos passos

  • Last updated on