Udostępnij za pośrednictwem

Niezawodność w usłudze Azure Communications Gateway

  • Artykuł

Usługa Azure Communications Gateway zapewnia niezawodność usługi przy użyciu mechanizmów nadmiarowości platformy Azure i zachowania ponawiania prób specyficznych dla protokołu SIP. Sieć musi spełniać określone wymagania, aby zapewnić dostępność usługi.

Model nadmiarowości usługi Azure Communications Gateway

Wdrożenia usługi Azure Communications Gateway w środowisku produkcyjnym (nazywane również wdrożeniami standardowymi) składają się z trzech oddzielnych regionów: regionu zarządzania i dwóch regionów usług. Wdrożenia laboratorium składają się z jednego regionu zarządzania i jednego regionu usługi.

W tym artykule opisano dwa różne typy regionów i ich odrębne modele nadmiarowości. Obejmuje ona zarówno niezawodność regionalną ze strefami dostępności, jak i niezawodnością między regionami z odzyskiwaniem po awarii. Aby uzyskać bardziej szczegółowe omówienie niezawodności na platformie Azure, zobacz Niezawodność platformy Azure.

Diagram dwóch regionów usług, regionu zarządzania i dwóch lokacji operatorów.

Regiony usług

Regiony usługi zawierają infrastrukturę głosu i interfejsu API używaną do obsługi ruchu między siecią a wybranymi usługami komunikacyjnymi.

Wdrożenia usługi Azure Communications Gateway w środowisku produkcyjnym mają dwa regiony usługi wdrożone w trybie aktywny-aktywny (zgodnie z wymaganiami programów Kontakt z operatorem i Teams Phone Mobile). Szybkie przechodzenie w tryb failover między regionami usługi jest zapewniane na poziomie infrastruktury/adresu IP i na poziomie aplikacji (SIP/RTP/HTTP).

Regiony usługi zawierają również infrastrukturę interfejsu API aprowizacji usługi Azure Communications Gateway.

Napiwek

Wdrożenia produkcyjne muszą zawsze mieć dwa regiony usługi, nawet jeśli jeden z wybranych regionów usługi znajduje się w jednej lokalizacji geograficznej platformy Azure (na przykład Katar). Jeśli wybierzesz lokalizację geograficzną platformy Azure w jednym regionie, wybierz drugi region świadczenia usługi Azure w innej lokalizacji geograficznej platformy Azure.

Regiony usługi są identyczne w operacji i zapewniają odporność zarówno na awarie strefy, jak i regionów. Każdy region usługi może przenosić 100% ruchu przy użyciu wystąpienia usługi Azure Communications Gateway. W związku z tym użytkownicy końcowi powinni nadal mieć możliwość pomyślnego nawiązywania połączeń i odbierania ich podczas przestoju w strefie lub regionie.

Wdrożenia laboratorium mają jeden region usługi.

Wymagania dotyczące routingu wywołań

Usługa Azure Communications Gateway oferuje "udany model nadmiarowości ponownej": wywołania obsługiwane przez zakończone niepowodzeniem elementów równorzędnych, ale nowe wywołania są kierowane do elementów równorzędnych w dobrej kondycji. Ten model odzwierciedla model nadmiarowości udostępniany przez usługę Microsoft Teams.

W przypadku wdrożeń produkcyjnych oczekujemy, że sieć będzie mieć dwie geograficznie nadmiarowe lokacje. Każda lokacja powinna być sparowana z regionem usługi Azure Communications Gateway. Model nadmiarowości opiera się na łączności krzyżowej między siecią a regionami usługi Azure Communications Gateway.

Diagram dwóch lokacji operatorów i dwóch regionów usług. Oba regiony usługi łączą się z obydwoma lokacjami z trasami podstawowymi i pomocniczymi.

Wdrożenia laboratorium muszą łączyć się z jedną lokacją w sieci.

Każdy region usługi Azure Communications Gateway udostępnia rekord SRV. Ten rekord zawiera wszystkie elementy równorzędne SIP zapewniające funkcje SBC (na potrzeby routingu wywołań do usług komunikacyjnych) w regionie. Ten rekord SRV może wskazywać dowolny adres IP w zakresie adresów IP /28 dostarczony przez zespół dołączania.

Jeśli brama usługi Azure Communications Gateway zawiera punkt kontroli mobilnej (MCP), każdy region usługi zapewnia dodatkowy rekord SRV dla mcP. Każdy rekord MCP w poszczególnych regionach zawiera mcp w regionie o najwyższym priorytetu i MCP w innym regionie o niższym priorytcie.

Każda lokacja w sieci musi:

  • Domyślnie wysyłaj ruch do lokalnego regionu usługi Azure Communications Gateway.
  • Znajdź elementy równorzędne usługi Azure Communications Gateway w regionie przy użyciu serwera SRV systemu DNS, zgodnie z opisem w artykule RFC 3263.
    • Wprowadź wyszukiwanie SRV DNS w nazwie domeny dla połączenia regionu usługi z siecią przy użyciu polecenia _sip._tls.<regional-FQDN-from-portal>. Zastąp <regional-FQDN-from-portal> ciąg nazwami FQDN dla regionu z pól Nazwa hosta na stronie Przegląd zasobu w witrynie Azure Portal. Jeśli na przykład wdrożenie używa commsgw.azure.com nazw domen, wyszukaj _sip._tls.pstn-region1.<deployment-id>.commsgw.azure.com pierwszy region.
    • Jeśli wyszukiwanie SRV zwraca wiele obiektów docelowych, użyj wagi i priorytetu każdego obiektu docelowego, aby wybrać pojedynczy element docelowy.
  • Wysyłaj nowe wywołania do dostępnych elementów równorzędnych usługi Azure Communications Gateway.
  • Możliwość odbierania ruchu z dowolnego adresu IP w każdym z zakresów adresów IP skojarzonych z usługą Azure Communications Gateway.

Gdy sieć kieruje wywołania do wirtualnych elementów równorzędnych SIP usługi Azure Communications Gateway dla funkcji SBC, musi ona:

  • Użyj OPCJI SIP (lub kombinacji OPCJI i ruchu SIP), aby monitorować dostępność elementów równorzędnych SIP bramy komunikacji platformy Azure.
  • Ponów próbę odpowiedzi INVITEs, które odebrały 408 odpowiedzi, 503 odpowiedzi lub 504 odpowiedzi lub nie otrzymały odpowiedzi, przekierowując je do innych dostępnych elementów równorzędnych w lokacji lokalnej. Wyszukiwanie w innym regionie usługi (zdefiniowanym przez rekord SRV innego regionu) tylko wtedy, gdy wszystkie elementy równorzędne w regionie usługi lokalnej nie powiodły się.
  • Nigdy nie ponawiaj próby wywołań, które odbierają odpowiedzi o błędach innych niż 408, 503 i 504.

Jeśli wdrożenie usługi Azure Communications Gateway obejmuje zintegrowany punkt sterowania urządzeniami przenośnymi (MCP), sieć musi wykonywać następujące czynności w przypadku mcp:

  • Wykryj, kiedy protokół MCP w regionie jest niedostępny, oznacz elementy docelowe rekordu SRV tego regionu jako niedostępne i okresowo spróbuj ponownie ustalić, kiedy region jest dostępny. MCP nie odpowiada na OPCJE SIP.
  • Obsługa odpowiedzi 5xx z MCP zgodnie z zasadami organizacji. Możesz na przykład ponowić próbę żądania lub zezwolić na kontynuowanie wywołania bez przekazywania przez usługę Azure Communications Gateway i do systemu Telefon Microsoft.

Szczegóły tego zachowania routingu są specyficzne dla twojej sieci. Podczas projektu integracji musisz je uzgodnić z zespołem dołączania.

Regiony zarządzania

Regiony zarządzania zawierają infrastrukturę używaną do zamawiania, monitorowania i rozliczeń usługi Azure Communications Gateway. Cała infrastruktura w tych regionach jest wdrażana w sposób strefowo nadmiarowy, co oznacza, że wszystkie dane są automatycznie replikowane w każdej strefie dostępności w regionie. Wszystkie krytyczne dane konfiguracji są również replikowane do każdego z regionów usługi, aby zapewnić prawidłowe działanie usługi podczas awarii regionu świadczenia usługi platformy Azure.

Obsługa strefy dostępności

Strefy dostępności są fizycznie oddzielnymi grupami centrów danych w każdym regionie świadczenia usługi Azure. Gdy jedna strefa ulegnie awarii, usługi mogą przejść w tryb failover do jednej z pozostałych stref.

Aby uzyskać więcej informacji na temat stref dostępności na platformie Azure, zobacz Co to są strefy dostępności?.

Środowisko strefowe w dół dla regionów usługi

Podczas awarii całej strefy wywołania obsługiwane przez strefę, której dotyczy problem, zostaną zakończone z krótką utratą pojemności w regionie do momentu ponownego równoważenia zasobów bazowych przez usługę do stref w dobrej kondycji. To samonaprawianie nie zależy od przywrócenia strefy; Oczekuje się, że stan samonaprawiania usługi zarządzanej przez firmę Microsoft rekompensuje utratę strefy przy użyciu pojemności z innych stref. Ruch przewożące zasoby są wdrażane w sposób strefowo nadmiarowy, ale w najmniejszej skali ruch może być obsługiwany przez jeden zasób. W takim przypadku mechanizmy trybu failover opisane w tym artykule ponownie równoważą cały ruch do innego regionu usługi, podczas gdy zasoby, które przewożą ruch, są ponownie wdrażane w strefie w dobrej kondycji.

Środowisko w dół strefy dla regionu zarządzania

Podczas awarii całej strefy nie jest wymagana żadna akcja podczas odzyskiwania strefy. Region zarządzania samodzielnie leczy się i ponownie równoważy się, aby automatycznie korzystać ze strefy w dobrej kondycji.

Odzyskiwanie po awarii: powrót do innych regionów

Odzyskiwanie po awarii dotyczy odzyskiwania po wystąpieniu zdarzeń o dużym wpływie, takich jak klęski żywiołowe lub nieudane wdrożenia, które powodują przestoje i utratę danych. Niezależnie od przyczyny najlepszym rozwiązaniem dla awarii jest dobrze zdefiniowany i przetestowany plan odzyskiwania po awarii oraz projekt aplikacji, który aktywnie obsługuje odzyskiwanie po awarii. Zanim zaczniesz myśleć o tworzeniu planu odzyskiwania po awarii, zobacz Zalecenia dotyczące projektowania strategii odzyskiwania po awarii.

Jeśli chodzi o odzyskiwanie po awarii, firma Microsoft korzysta z modelu wspólnej odpowiedzialności. W modelu wspólnej odpowiedzialności firma Microsoft zapewnia dostępność infrastruktury bazowej i usług platformy. Jednocześnie wiele usług platformy Azure nie replikuje automatycznie danych ani nie wraca z regionu, w którym wystąpił błąd, aby przeprowadzić replikację krzyżową do innego regionu z włączoną obsługą. W przypadku tych usług ponosisz odpowiedzialność za skonfigurowanie planu odzyskiwania po awarii, który działa dla obciążenia. Większość usług uruchamianych na platformie Azure jako usługa (PaaS) oferuje funkcje i wskazówki dotyczące obsługi odzyskiwania po awarii. Funkcje specyficzne dla usługi umożliwiają szybkie odzyskiwanie w celu ułatwienia opracowania planu odzyskiwania po awarii.

W tej sekcji opisano zachowanie usługi Azure Communications Gateway podczas awarii całego regionu.

Odzyskiwanie po awarii: przechodzenie w tryb failover między regionami dla regionów usługi

Podczas awarii całego regionu mechanizmy trybu failover opisane w tym artykule (OPCJE sondowania i ponawiania prób SIP po awarii) ponownie zrównoważą cały ruch wywołań do innego regionu usługi, zachowując dostępność. Zaczniemy przywracać nadmiarowość regionalną. Przywrócenie nadmiarowości regionalnej podczas rozszerzonego przestoju może wymagać użycia innych regionów świadczenia usługi Azure. Jeśli musimy przeprowadzić migrację regionu, który zakończył się niepowodzeniem do innego regionu, przed rozpoczęciem migracji skontaktujemy się z Tobą.

Funkcja SBC w usłudze Azure Communications Gateway udostępnia sondowanie OPTIONS, aby umożliwić sieci określenie dostępności komunikacji równorzędnej. W przypadku umowy MCP sieć musi być w stanie wykryć, kiedy mcP jest niedostępna, i okresowo ponów próbę określenia, kiedy mcP jest ponownie dostępny. MCP nie odpowiada na OPCJE SIP.

Klienci interfejsu API aprowizacji kontaktuje się z usługą Azure Communications Gateway przy użyciu podstawowej nazwy domeny wdrożenia. Rekord DNS dla tej domeny ma czas wygaśnięcia (TTL) 60 sekund. Gdy region ulegnie awarii, platforma Azure aktualizuje rekord DNS w celu odwoływania się do innego regionu, więc klienci tworzący nowe wyszukiwanie DNS otrzymują szczegóły nowego regionu. Zalecamy upewnienie się, że klienci mogą utworzyć nowe wyszukiwanie DNS i ponowić żądanie 60 sekund po przekroczeniu limitu czasu lub odpowiedzi 5xx.

Napiwek

Wdrożenia laboratorium nie oferują trybu failover między regionami (ponieważ mają tylko jeden region usługi).

Odzyskiwanie po awarii: tryb failover między regionami dla regionów zarządzania

Ruch głosowy i aprowizowanie za pośrednictwem portalu zarządzania numerami nie ma wpływu na błędy w regionie zarządzania, ponieważ odpowiednie zasoby platformy Azure są hostowane w regionach usług. Użytkownicy portalu zarządzania numerami mogą wymagać ponownego zalogowania się.

Usługi monitorowania mogą być tymczasowo niedostępne do czasu przywrócenia usługi. Jeśli w regionie zarządzania wystąpi dłuższy przestój, zmigrujemy zasoby, których dotyczy ten wpływ, do innego dostępnego regionu.

Wybieranie regionów zarządzania i usług

Pojedyncze wdrożenie usługi Azure Communications Gateway jest przeznaczone do obsługi ruchu w obszarze geograficznym. Wdróż oba regiony usługi we wdrożeniu produkcyjnym w tym samym obszarze geograficznym (na przykład Ameryka Północna). Ten model zapewnia, że opóźnienie połączeń głosowych pozostaje w granicach wymaganych przez programy Kontakt z operatorem i Teams Phone Mobile.

Podczas wybierania lokalizacji regionów usługi należy wziąć pod uwagę następujące kwestie:

  • Wybierz z listy dostępnych regionów świadczenia usługi Azure. Regiony platformy Azure, które można wybrać jako regiony usług, można wyświetlić na stronie Produkty według regionów .
  • Wybierz regiony w pobliżu własnego środowiska lokalnego i lokalizacji komunikacji równorzędnej między siecią a firmą Microsoft, aby zmniejszyć opóźnienie wywołań.
  • Preferuj pary regionalne, aby zminimalizować czas odzyskiwania, jeśli wystąpi awaria w wielu regionach.

Wybierz region zarządzania z następującej listy:

  • Wschodnie stany USA
  • Zachodnio-środkowe stany USA
  • West Europe
  • Południowe Zjednoczone Królestwo
  • Indie Środkowe
  • Kanada Środkowa
  • Australia Wschodnia

Regiony zarządzania można przenosić z regionami usług. Zalecamy wybranie regionu zarządzania najbliższego regionom usługi.

Uwaga

Jeśli włączasz usługę Azure Operator Call Protection w wersji zapoznawczej, wybrany region usługi może nie być regionem świadczenia usługi, w którym są wdrażane zasoby pomocnicze. Zobacz Produkty platformy Azure według regionów , aby uzyskać listę aktualnie obsługiwanych regionów usługi Azure Operator Call Protection i porozmawiaj z zespołem dołączania, jeśli masz pytania dotyczące wybranego regionu.

Umowy dotyczące poziomu usług

Projekt niezawodności opisany w tym dokumencie jest implementowany przez firmę Microsoft i nie można go konfigurować. Aby uzyskać więcej informacji na temat umów dotyczących poziomu usług (SLA) usługi Azure Communications Gateway, zobacz Umowę SLA bramy komunikacji platformy Azure.

Następne kroki