Sdílet prostřednictvím

Spolehlivost ve službě Azure Communications Gateway

  • Článek

Azure Communications Gateway zajišťuje, že vaše služba je spolehlivá pomocí mechanismů redundance Azure a chování opakování specifické pro SIP. Aby byla zajištěna dostupnost služeb, musí vaše síť splňovat konkrétní požadavky.

Model redundance služby Azure Communications Gateway

Produkční nasazení služby Azure Communications Gateway (označovaná také jako standardní nasazení) se skládají ze tří samostatných oblastí: oblasti správy a dvou oblastí služeb. Nasazení testovacího prostředí se skládají z jedné oblasti správy a jedné oblasti služby.

Tento článek popisuje dva různé typy oblastí a jejich odlišné modely redundance. Pokrývá regionální spolehlivost se zónami dostupnosti a spolehlivostí napříč oblastmi s využitím zotavení po havárii. Podrobnější přehled spolehlivosti v Azure najdete v tématu Spolehlivost Azure.

Diagram dvou oblastí služby, oblasti správy a dvou lokalit operátorů

Oblasti služeb

Oblasti služeb obsahují infrastrukturu hlasu a rozhraní API používanou ke zpracování provozu mezi vaší sítí a zvolenými komunikačními službami.

Produkční nasazení služby Azure Communications Gateway mají dvě oblasti služeb, které jsou nasazené v režimu aktivní-aktivní (podle požadavků programů Připojení operátora a Teams Telefon Mobile). Rychlé převzetí služeb při selhání mezi oblastmi služby je poskytováno na úrovni infrastruktury/IP adresy a na úrovni aplikace (SIP/RTP/HTTP).

Oblasti služby také obsahují infrastrukturu pro rozhraní API zřizování služby Azure Communications Gateway.

Tip

Produkční nasazení musí mít vždy dvě oblasti služeb, a to i v případě, že jedna z vybraných oblastí služby je v oblasti Azure Geography s jednou oblastí (například Katar). Pokud zvolíte oblast Azure Geography s jednou oblastí, zvolte druhou oblast Azure v jiné geografické oblasti Azure.

Oblasti služby jsou v provozu stejné a zajišťují odolnost vůči selháním zóny i oblasti. Každá oblast služby může přenášet 100 % provozu pomocí instance služby Azure Communications Gateway. Koncoví uživatelé by proto měli být stále schopni provádět a přijímat hovory úspěšně během jakéhokoli výpadku zóny nebo oblasti.

Nasazení testovacího prostředí mají jednu oblast služby.

Požadavky na směrování volání

Azure Communications Gateway nabízí model redundance úspěšného opakování: Volání zpracovávaná neúspěšnými partnerskými vztahy jsou ukončena, ale nová volání se směrují na partnerské vztahy, které jsou v pořádku. Tento model zrcadlí model redundance, který poskytuje Microsoft Teams.

U produkčních nasazení očekáváme, že vaše síť bude mít dvě geograficky redundantní lokality. Každá lokalita by měla být spárovaná s oblastí služby Azure Communications Gateway. Model redundance spoléhá na křížové připojení mezi oblastmi vaší sítě a služby Azure Communications Gateway.

Diagram dvou lokalit operátorů a dvou oblastí služby Obě oblasti služby se připojují k oběma lokalitám s primárními i sekundárními trasami.

Nasazení testovacího prostředí se musí připojit k jedné lokalitě ve vaší síti.

Každá oblast služby Azure Communications Gateway poskytuje záznam SRV. Tento záznam obsahuje všechny partnerské vztahy SIP poskytující funkce SBC (pro směrování volání do komunikačních služeb) v rámci oblasti. Tento záznam SRV může odkazovat na libovolnou IP adresu v rozsahu IP /28, který vám poskytl váš tým onboardingu.

Pokud vaše brána Azure Communications Gateway obsahuje mobilní řídicí bod (MCP), každá oblast služby poskytuje pro MCP další záznam SRV. Každý záznam MCP pro každou oblast obsahuje MCP v rámci oblasti s nejvyšší prioritou a MCP v druhé oblasti s nižší prioritou.

Každá lokalita v síti musí:

  • Ve výchozím nastavení můžete odesílat provoz do místní oblasti služby Azure Communications Gateway.
  • Vyhledejte partnerské vztahy služby Azure Communications Gateway v rámci oblasti pomocí SRV DNS, jak je uvedeno v dokumentu RFC 3263.
    • Nastavte vyhledávání SRV DNS v názvu domény pro připojení oblasti služby k vaší síti pomocí _sip._tls.<regional-FQDN-from-portal>. Nahraďte <regional-FQDN-from-portal> plně kvalifikovanými názvy domén pro jednotlivé oblasti z polí Název hostitele na stránce Přehled vašeho prostředku na webu Azure Portal. Pokud například vaše nasazení používá commsgw.azure.com názvy domén, vyhledejte _sip._tls.pstn-region1.<deployment-id>.commsgw.azure.com první oblast.
    • Pokud vyhledávání SRV vrátí více cílů, použijte k výběru jednoho cíle váhu a prioritu každého cíle.
  • Odesílání nových volání dostupným partnerským uzlům služby Azure Communications Gateway
  • Můžete přijímat provoz z libovolné IP adresy v každém rozsahu IP adres přidružených k vaší službě Azure Communications Gateway.

Když vaše síť směruje volání do partnerských vztahů SIP služby Azure Communications Gateway pro funkci SBC, musí:

  • Pomocí možností SIP (nebo kombinace možností a provozu SIP) můžete monitorovat dostupnost partnerských uzlů SIP služby Azure Communications Gateway.
  • Zkuste znovu invites, které obdržely 408 odpovědí, 503 odpovědí nebo 504 odpovědí nebo neobdržel odpovědi, tím, že je přesměruje na jiné dostupné peery v místním webu. Proaktivní vyhledávání do jiné oblasti služby (definované záznamem SRV druhé oblasti) pouze v případě, že všechny partnerské vztahy v místní oblasti služby selhaly.
  • Nikdy opakujte volání, která obdrží jiné odpovědi na chyby než 408, 503 a 504.

Pokud vaše nasazení služby Azure Communications Gateway zahrnuje integrovaný mobilní řídicí bod (MCP), musí vaše síť pro MCP provést takto:

  • Zjistěte, kdy není MCP v oblasti k dispozici, označte cíle pro záznam SRV dané oblasti jako nedostupné a zkuste pravidelně zjistit, kdy je oblast opět dostupná. MCP nereaguje na MOŽNOSTI PROTOKOLU SIP.
  • Zpracujte odpovědi 5xx od MCP podle zásad vaší organizace. Můžete například zkusit požadavek zopakovat nebo můžete povolit, aby volání pokračovalo bez průchodu službou Azure Communications Gateway a do systému Microsoft Telefon.

Podrobnosti o tomto chování směrování jsou specifické pro vaši síť. Během projektu integrace musíte souhlasit s vaším týmem pro onboarding.

Oblasti správy

Oblasti správy obsahují infrastrukturu používanou k objednávání, monitorování a fakturaci služby Azure Communications Gateway. Veškerá infrastruktura v těchto oblastech je nasazena zónově redundantním způsobem, což znamená, že se všechna data automaticky replikují napříč jednotlivými zónami dostupnosti v rámci oblasti. Všechna důležitá konfigurační data se také replikují do každé oblasti služby, aby se zajistilo správné fungování služby během selhání oblasti Azure.

Podpora zón dostupnosti

Zóny dostupnosti Azure jsou aspoň tři fyzicky oddělené skupiny datacenter v rámci každé oblasti Azure. Datová centra v každé zóně jsou vybavena nezávislou infrastrukturou napájení, chlazení a sítě. V případě selhání místní zóny jsou zóny dostupnosti navrženy tak, aby v případě ovlivnění jedné zóny, regionální služby, kapacity a vysoké dostupnosti podporovaly zbývající dvě zóny.

Selhání můžou být v rozsahu od selhání softwaru a hardwaru až po události, jako jsou zemětřesení, záplavy a požáry. Odolnost vůči selháním se dosahuje redundancí a logickou izolací služeb Azure. Podrobnější informace o zónách dostupnosti v Azure najdete v tématu Oblasti a zóny dostupnosti.

Služby s podporou zón dostupnosti Azure jsou navržené tak, aby poskytovaly správnou úroveň spolehlivosti a flexibility. Dají se nakonfigurovat dvěma způsoby. Můžou být buď zónově redundantní, s automatickou replikací napříč zónami, nebo zónově, s instancemi připnutými ke konkrétní zóně. Tyto přístupy můžete také kombinovat. Další informace o zónové a zónově redundantní architektuře najdete v tématu Doporučení pro použití zón dostupnosti a oblastí.

Zone down experience for service regions

Během výpadku v rámci zóny se volání zpracovávaná ovlivněnou zónou ukončí s krátkou ztrátou kapacity v rámci oblasti, dokud samoopravení služby nevyrovná podkladové prostředky do zón, které jsou v pořádku. Toto samoopravení není závislé na obnovení zóny; Očekává se, že stav samoobslužného opravy služby spravované Microsoftem kompenzuje ztrátu zóny pomocí kapacity z jiných zón. Přenosy prostředků se nasazují zónově redundantním způsobem, ale v nejnižším měřítku se provoz může zpracovat jedním prostředkem. V tomto případě mechanismy převzetí služeb při selhání popsané v tomto článku znovu vyrovnávají veškerý provoz do druhé oblasti služby, zatímco prostředky, které přenášejí provoz, se znovu nasadí v zóně, která je v pořádku.

Zone down experience for the management region

Během výpadku v rámci zóny se během obnovení zóny nevyžaduje žádná akce. Oblast správy se sama opraví a vyrovnává sama, aby automaticky využila výhod zdravé zóny.

Zotavení po havárii: náhradní do jiných oblastí

Zotavení po havárii (DR) se týká zotavení z událostí s vysokým dopadem, jako jsou přírodní katastrofy nebo neúspěšná nasazení, která vedou k výpadkům a ztrátě dat. Bez ohledu na příčinu je nejlepším řešením havárie dobře definovaný a otestovaný plán zotavení po havárii a návrh aplikace, který aktivně podporuje zotavení po havárii. Než začnete přemýšlet o vytvoření plánu zotavení po havárii, přečtěte si doporučení pro návrh strategie zotavení po havárii.

Pokud jde o zotavení po havárii, Microsoft používá model sdílené odpovědnosti. V modelu sdílené odpovědnosti Microsoft zajišťuje, aby byly dostupné základní služby infrastruktury a platformy. Současně mnoho služeb Azure automaticky nereplikuje data nebo se vrátí z oblasti, která selhala, aby se křížově replikovala do jiné povolené oblasti. Za tyto služby zodpovídáte za nastavení plánu zotavení po havárii, který funguje pro vaši úlohu. Většina služeb, které běží na nabídkách PaaS (Platforma jako služba) Azure, poskytuje funkce a pokyny pro podporu zotavení po havárii a pomocí funkcí specifických pro služby můžete podporovat rychlé obnovení , které vám pomůže s vývojem plánu zotavení po havárii.

Tato část popisuje chování služby Azure Communications Gateway během výpadku v celé oblasti.

Zotavení po havárii: Převzetí služeb při selhání mezi oblastmi služeb

Během výpadku v celé oblasti se mechanismy převzetí služeb při selhání popsané v tomto článku (možnosti dotazování a opakování PROTOKOLU SIP při selhání) znovu vyrovnávají veškerý provoz volání do jiné oblasti služby a zachová dostupnost. Začneme obnovovat regionální redundanci. Obnovení regionální redundance během delšího výpadku může vyžadovat použití jiných oblastí Azure. Pokud potřebujeme migrovat oblast, která selhala, do jiné oblasti, před zahájením jakýchkoli migrací vás budeme konzultovat.

Funkce SBC ve službě Azure Communications Gateway poskytuje dotazování MOŽNOSTI, které vaší síti umožní určit dostupnost partnerského uzlu. V případě MCP musí být vaše síť schopná zjistit, kdy je MCP nedostupná, a pravidelně se pokuste zjistit, kdy je MCP opět k dispozici. MCP nereaguje na MOŽNOSTI PROTOKOLU SIP.

Klienti rozhraní API zřizování kontaktují službu Azure Communications Gateway pomocí základního názvu domény pro vaše nasazení. Záznam DNS pro tuto doménu má hodnotu TTL (Time to Live) 60 sekund. Když se oblast nezdaří, Azure aktualizuje záznam DNS tak, aby odkazovat na jinou oblast, takže klienti, kteří vytvoří nové vyhledávání DNS, obdrží podrobnosti o nové oblasti. Doporučujeme zajistit, aby klienti mohli vytvořit nové vyhledávání DNS a opakovat požadavek 60 sekund po vypršení časového limitu nebo odpovědi 5xx.

Tip

Nasazení testovacího prostředí nenabízí převzetí služeb při selhání mezi oblastmi (protože mají jenom jednu oblast služby).

Zotavení po havárii: Převzetí služeb při selhání mezi oblastmi pro správu

Hlasový provoz a zřizování prostřednictvím portálu pro správu čísel nemají vliv na selhání v oblasti správy, protože odpovídající prostředky Azure jsou hostované v oblastech služeb. Uživatelé portálu pro správu čísel se možná budou muset znovu přihlásit.

Monitorovací služby můžou být dočasně nedostupné, dokud se služba neobnoví. Pokud u oblasti správy dojde k delšímu výpadku, provedeme migraci ovlivněných prostředků do jiné dostupné oblasti.

Volba oblastí správy a služeb

Jedno nasazení služby Azure Communications Gateway je navržené tak, aby zpracovával provoz v rámci geografické oblasti. Nasaďte obě oblasti služby v produkčním nasazení ve stejné geografické oblasti (například Severní Amerika). Tento model zajišťuje, aby latence hlasových hovorů zůstala v mezích požadovaných programy Připojení operátora a Teams Telefon Mobile.

Při výběru umístění oblastí služeb zvažte následující body:

  • Vyberte ze seznamu dostupných oblastí Azure. Oblasti Azure, které je možné vybrat jako oblasti služeb, můžete zobrazit na stránce Produkty podle oblastí .
  • Pokud chcete snížit latenci volání, zvolte oblasti blízko k vašemu místnímu prostředí a umístění peeringu mezi vaší sítí a Microsoftem.
  • Pokud dojde k výpadku více oblastí, upřednostněte páry oblastí, abyste minimalizovali dobu obnovení.

V následujícím seznamu zvolte oblast správy:

  • USA – východ
  • USA – středozápad
  • West Europe
  • Velká Británie – jih
  • Střední Indie
  • Střední Kanada
  • Austrálie – východ

Oblasti správy je možné společně přidělit s oblastmi služeb. Doporučujeme zvolit oblast správy, která je nejblíže vašim oblastem služeb.

Poznámka:

Pokud povolíte službu Azure Operator Call Protection Preview, oblast služby, kterou vyberete, nemusí být oblastí Azure, ve které jsou nasazeny podpůrné prostředky. Seznam aktuálněpodporovanýchchm oblastem najdete v seznamu aktuálně podporovaných oblastí služby Azure Call Protection a pokud máte nějaké dotazy ohledně toho, která oblast je vybraná, promluvte si s vaším týmem onboardingu.

Smlouvy o rozsahu služeb

Návrh spolehlivosti popsaný v tomto dokumentu implementuje Microsoft a není konfigurovatelný. Další informace o smlouvách o úrovni služeb (SLA) služby Azure Communications Gateway najdete ve smlouvě SLA služby Azure Communications Gateway.

Další kroky