Udostępnij przez

Niezawodność w usłudze Azure Communications Gateway

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ługowego.

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 produkcyjne Azure Communications Gateway mają dwa regiony obsługi wdrożone w trybie aktywny-aktywny (zgodnie z wymogami programów Operator Connect i Teams Phone Mobile). Szybkie przełączanie w trybie failover między regionami usług jest zapewniane na poziomie infrastruktury/adresu IP i poziomie aplikacji (SIP/RTP/HTTP).

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

Wskazówka

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 pod względem działania i zapewniają odporność zarówno na awarie stref, 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ługowy.

Wymagania dotyczące routingu wywołań

Usługa Azure Communications Gateway oferuje model nadmiarowości z udanym ponownym wybieraniem numeru: połączenia obsługiwane przez zawodzące elementy równorzędne są zakończone, lecz nowe połączenia są kierowane do elementów równorzędnych, które działają prawidłowo. 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 środowiska laboratoryjnego muszą łączyć się z jednym miejscem w sieci.

Każdy region usługi Azure Communications Gateway udostępnia rekord SRV. Ten rekord zawiera wszystkie równorzędne SIP zapewniające funkcjonalność SBC (w celu routingu połączeń do usług komunikacyjnych) w regionie. Ten rekord SRV może wskazywać na dowolny adres IP w zakresie /28 adresów IP dostarczony przez zespół wdrożeniowy.

Jeśli 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 priorytecie i MCP w innym regionie o niższym priorytecie.

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.
    • Przeprowadź wyszukiwanie DNS SRV dla nazwy domeny w celu połączenia regionu usługi z twoją siecią, używając polecenia _sip._tls.<regional-FQDN-from-portal>. Zastąp <regional-FQDN-from-portal> odpowiednimi dla regionu nazwami FQDN z pola Nazwa hosta na stronie Przegląd zasobu w portalu Azure. Na przykład, jeśli Twoje wdrożenie używa commsgw.azure.com nazw domen, wyszukaj _sip._tls.pstn-region1.<deployment-id>.commsgw.azure.com dla pierwszego regionu.
    • 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 połączenia do dostępnych węzłów 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 równorzędnych urządzeń SIP usługi Azure Communications Gateway w celu realizacji funkcji SBC, musi:

  • Użyj opcji SIP (lub kombinacji opcji i ruchu SIP), aby monitorować dostępność zasobów SIP bramy komunikacyjnej Azure.
  • Ponów próbę wysyłania INVITEs, które otrzymały odpowiedzi 408, 503 lub 504 albo nie otrzymały odpowiedzi, przekierowując je do innych dostępnych partnerów w lokalnej lokalizacji. Przeszukuj inny region usługi (zdefiniowany przez rekord SRV innego regionu) tylko wtedy, gdy wszystkie węzły równorzędne w lokalnym regionie usługi zawiodły.
  • 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 połączenia bez przekazywania przez Azure Communications Gateway do systemu telefonicznego Microsoft.

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

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.

Doświadczenie zmniejszenia strefy dla obszarów usługowych

Podczas awarii w całej strefie, połączenia obsługiwane przez dotkniętą problemem strefę zostaną przerwane, z chwilowym spadkiem przepustowości w regionie, aż usługa automatycznego odzyskiwania ponownie zrównoważy zasoby do stref poprawnie funkcjonujących. To samonaprawianie nie zależy od przywrócenia strefy. Zakłada się, że stan samonaprawiania usługi zarządzanej przez firmę Microsoft rekompensuje utratę strefy przy użyciu zasobów z innych stref. Zasoby obsługujące ruch są wdrażane w sposób strefowo redundantny, ale przy minimalnej 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ługowego, podczas gdy zasoby odpowiedzialne za ruch są przekierowywane do strefy będącej w dobrej kondycji.

Doświadczenie obniżenia zasobów dla obszaru zarządzania

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

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

Odzyskiwanie po awarii (DR) odnosi się do praktyk używanych przez organizacje do 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. Przed rozpoczęciem tworzenia planu odzyskiwania po awarii zobacz Zalecenia dotyczące projektowania strategii odzyskiwania po awarii.

W przypadku DR firma Microsoft używa modelu wspólnej odpowiedzialności . W tym modelu firma Microsoft zapewnia dostępność podstawowej infrastruktury i usług platformy. Jednak 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 włączonego regionu. W przypadku tych usług odpowiadasz za skonfigurowanie planu odzyskiwania danych po awarii, który jest dostosowany do Twojego obciążenia. Większość usług oferty platformy Azure jako usługa (PaaS) udostępnia funkcje i wskazówki wspierające DR. Możesz użyć funkcji specyficznych dla usługi, aby wspierać szybkie odzyskiwanie i ułatwić opracowanie 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

W przypadku awarii całego regionu mechanizmy przełączenia awaryjnego opisane w tym artykule (sondowanie OPCJE i ponawianie prób SIP po niepowodzeniu) przekierują cały ruch wywołań do innego regionu usługi, zapewniają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 MCP sieć musi móc wykryć, kiedy MCP jest niedostępna, i okresowo próbować ponownie, aby określić, kiedy MCP jest ponownie dostępna. MCP nie odpowiada na OPCJE SIP.

Klienci korzystający z interfejsu API aprowizacji kontaktują się z usługą Azure Communications Gateway, używając podstawowej nazwy domeny dla 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.

Wskazówka

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

Odzyskiwanie po awarii: przełączenie awaryjne między regionami dotyczące regionów zarządzania

Ruch głosowy i zapewnienie zasobów za pośrednictwem Portalu Zarządzania Numerami nie ma wpływu na błędy w regionie zarządzania, ponieważ odpowiadające 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 dotknięte zasoby 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 Operator Connect 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łasnej siedziby oraz lokalizacji peeringowych między Twoją siecią a firmą Microsoft, aby zmniejszyć opóźnienia połączeń.
  • 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
  • Europa Zachodnia
  • Południowe Zjednoczone Królestwo
  • Indie Środkowe
  • Kanada Środkowa
  • Australia Wschodnia

Regiony zarządzania mogą być współlokalizowane z regionami usług. Zalecamy wybranie regionu zarządzania najbliższego regionom usługi.

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.

Dalsze kroki

  • Last updated on