Megosztás a következőn keresztül:

Megbízhatóság az Azure Communications Gatewayben

  • Cikk

Az Azure Communications Gateway azure-redundanciamechanizmusokkal és SIP-specifikus újrapróbálkozással biztosítja a szolgáltatás megbízhatóságát. A szolgáltatás rendelkezésre állásának biztosításához a hálózatnak meg kell felelnie bizonyos követelményeknek.

Az Azure Communications Gateway redundanciamodellje

Az Azure Communications Gateway éles üzembe helyezései (más néven standard üzemelő példányok) három különálló régióból állnak: egy felügyeleti régióból és két szolgáltatásrégióból. A labortelepítések egy felügyeleti régióból és egy szolgáltatási régióból állnak.

Ez a cikk a két különböző régiótípust és azok különböző redundanciamodelljeit ismerteti. Lefedi a regionális megbízhatóságot a rendelkezésre állási zónákkal és a régiók közötti megbízhatóságot vészhelyreállítással. Az Azure-beli megbízhatóság részletesebb áttekintéséhez tekintse meg az Azure megbízhatóságát.

Két szolgáltatásrégió, egy felügyeleti régió és két operátorhely diagramja.

Szolgáltatási régiók

A szolgáltatási régiók tartalmazzák a hálózat és a választott kommunikációs szolgáltatások közötti forgalom kezeléséhez használt hang- és API-infrastruktúrát.

Az éles Azure Communications Gateway üzembe helyezése két szolgáltatásrégióval rendelkezik, amelyek aktív-aktív módban vannak üzembe helyezve (a Szolgáltatói kapcsolat és a Teams Telefon Mobile-programoknak megfelelően). A szolgáltatásrégiók közötti gyors feladatátvételt az infrastruktúra/IP-szint és az alkalmazás (SIP/RTP/HTTP) szintjén biztosítjuk.

A szolgáltatási régiók az Azure Communications Gateway Kiépítési API-jának infrastruktúráját is tartalmazzák.

Tipp.

Az éles üzemelő példányoknak mindig két szolgáltatási régióval kell rendelkezniük, még akkor is, ha a kiválasztott szolgáltatási régiók egyike egy régiós Azure Geographyben (például Katarban) található. Ha egy régiós Azure Geography-t választ, válasszon egy másik Azure-régiót egy másik Azure Geography-ben.

A szolgáltatási régiók működés közben azonosak, és rugalmasságot biztosítanak a zóna- és regionális hibákra is. Minden szolgáltatási régió az Azure Communications Gateway-példány használatával a forgalom 100%-át képes szállítani. Ezért a végfelhasználóknak továbbra is képesnek kell lenniük a hívások sikeres indítására és fogadására bármely zóna- vagy regionális állásidő alatt.

A labortelepítések egyetlen szolgáltatási régióval rendelkeznek.

Hívásirányítási követelmények

Az Azure Communications Gateway "sikeres újraelosztási" redundanciamodellt kínál: a sikertelen társ által kezelt hívások leállnak, az új hívásokat azonban kifogástalan állapotú társhoz irányítják. Ez a modell a Microsoft Teams által biztosított redundanciamodellt tükrözi.

Éles környezetek esetén a hálózat két földrajzilag redundáns helyre számít. Minden helyet párosítani kell egy Azure Communications Gateway-régióval. A redundanciamodell a hálózat és az Azure Communications Gateway szolgáltatásrégiók közötti keresztkapcsolatra támaszkodik.

Két operátorhely és két szolgáltatásrégió diagramja. Mindkét szolgáltatási régió elsődleges és másodlagos útvonallal csatlakozik mindkét helyhez.

A labortelepítéseknek a hálózat egy helyéhez kell csatlakozniuk.

Minden Azure Communications Gateway szolgáltatásrégió SRV rekordot biztosít. Ez a rekord tartalmazza az összes SIP-társt, amely SBC-funkciókat biztosít (a kommunikációs szolgáltatások felé irányuló hívások átirányításához) a régión belül. Ez az SRV-rekord a /28 ip-címtartomány bármely IP-címére mutathat, amelyet az előkészítési csapat biztosít Önnek.

Ha az Azure Communications Gateway mobilvezérlési pontot (MCP) is tartalmaz, minden szolgáltatási régió további SRV rekordot biztosít az MCP számára. Minden régiónkénti MCP rekord a legfelső prioritású régión belüli MCP-t, a másik régióban pedig alacsonyabb prioritású MCP-t tartalmaz.

A hálózat minden helyének a következőnek kell lennie:

  • Forgalom küldése a helyi Azure Communications Gateway szolgáltatásrégióba alapértelmezés szerint.
  • Keresse meg az Azure Communications Gateway-társokat egy régióban a DNS SRV használatával, az RFC 3263-ban leírtak szerint.
    • Dns SRV-keresés készítése a szolgáltatásrégió hálózattal való kapcsolatának tartományneve alapján._sip._tls.<regional-FQDN-from-portal> Cserélje le <regional-FQDN-from-portal> a régiónkénti teljes tartományneveket az erőforrás Áttekintés lapján, az Azure Portal Gazdagépnév mezőiből. Ha például az üzembe helyezés tartományneveket használ commsgw.azure.com , keresse meg _sip._tls.pstn-region1.<deployment-id>.commsgw.azure.com az első régiót.
    • Ha az SRV-keresés több célt ad vissza, az egyes célok súlyával és prioritásával jelöljön ki egyetlen célt.
  • Új hívások küldése elérhető Azure Communications Gateway-partnereknek.
  • Az Azure Communications Gatewayhez társított IP-tartományok mindegyikében bármilyen IP-címről fogadhat forgalmat.

Amikor a hálózat a hívásokat az Azure Communications Gateway SBC-társához irányítja az SBC-függvényhez, a következőnek kell lennie:

  • Az Azure Communications Gateway SIP-társainak rendelkezésre állásának figyeléséhez használja a SIP-beállításokat (vagy az OPTIONS és a SIP-forgalom kombinációját).
  • Próbálkozzon újra az olyan INVIT-ekkel, amelyek 408 választ, 503 választ vagy 504 választ kaptak, vagy nem kaptak válaszokat, és átirányítja őket a helyi webhelyen elérhető többi elérhető társhoz. Csak akkor lépjen a másik szolgáltatásrégióba (amelyet a másik régió SRV rekordja határoz meg), ha a helyi szolgáltatási régióban lévő összes társ sikertelen volt.
  • Soha ne próbálkozzon újra olyan hívásokkal, amelyek a 408-nál, az 503-nál és az 504-nél eltérő hibaüzenetet kapnak.

Ha az Azure Communications Gateway üzembe helyezése integrált mobilvezérlő pontot (MCP) tartalmaz, a hálózatnak az alábbiak szerint kell elvégeznie az MCP-t:

  • Észleli, ha az MCP egy régióban nem érhető el, jelölje meg az adott régió SRV rekordjának céljait elérhetetlenként, és rendszeresen próbálkozzon újra annak megállapításához, hogy a régió mikor érhető el újra. Az MCP nem válaszol a SIP BEÁLLÍTÁSAIRA.
  • Az MCP 5xx válaszainak kezelése a szervezet szabályzata szerint. Megpróbálhatja például újra a kérést, vagy engedélyezheti a hívás folytatását anélkül, hogy áthaladna az Azure Communications Gatewayen és Microsoft Telefon rendszeren.

Ennek az útválasztási viselkedésnek a részletei a hálózatra vonatkoznak. Az integrációs projekt során meg kell egyeznie az előkészítési csapattal.

Felügyeleti régiók

A felügyeleti régiók tartalmazzák az Azure Communications Gateway megrendeléséhez, monitorozásához és számlázásához használt infrastruktúrát. Ezen régiók összes infrastruktúrája zónaredundáns módon van üzembe helyezve, ami azt jelenti, hogy minden adat automatikusan replikálódik a régión belüli rendelkezésre állási zónákra. A rendszer minden kritikus konfigurációs adatot replikál az egyes szolgáltatási régiókba is, hogy biztosítsa a szolgáltatás megfelelő működését egy Azure-régió meghibásodása esetén.

Rendelkezésre állási zóna támogatása

Az Azure rendelkezésre állási zónái legalább három fizikailag különálló adatközpont-csoport az egyes Azure-régiókban. Az egyes zónákban lévő adatközpontok független energiaellátási, hűtési és hálózati infrastruktúrával rendelkeznek. Helyi zónahiba esetén a rendelkezésre állási zónák úgy vannak kialakítva, hogy az egy zóna érintettsége esetén a fennmaradó két zóna támogassa a regionális szolgáltatásokat, a kapacitást és a magas rendelkezésre állást.

A hibák a szoftver- és hardverhibáktól az olyan eseményekig terjedhetnek, mint a földrengések, árvizek és tűzesetek. A hibáktól való tolerancia az Azure-szolgáltatások redundanciával és logikai elkülönítésével érhető el. Az Azure-beli rendelkezésre állási zónákkal kapcsolatos részletesebb információkért tekintse meg a Régiók és a rendelkezésre állási zónák című témakört.

Az Azure rendelkezésre állási zónákkal kompatibilis szolgáltatások a megfelelő megbízhatósági és rugalmassági szintet biztosítják. Ezek kétféleképpen konfigurálhatók. Ezek lehetnek zónaredundánsak, a zónák közötti automatikus replikációval vagy a zónák közötti automatikus replikációval, egy adott zónába rögzített példányokkal. Ezeket a megközelítéseket kombinálhatja is. A zónaredundáns és a zónaredundáns architektúrával kapcsolatos további információkért tekintse meg a rendelkezésre állási zónák és régiók Javaslatok.

Szolgáltatásrégiók zónaleállási felülete

A zónaszintű kimaradás során az érintett zóna által kezelt hívások leállnak, és rövid kapacitásvesztéssel járnak a régión belül, amíg a szolgáltatás öngyógyító erőforrásai újra ki nem egyensúlyoznak az egészséges zónákhoz tartozó erőforrások között. Ez az öngyógyítás nem függ a zóna helyreállításától; a Microsoft által felügyelt szolgáltatás öngyógyító állapota várhatóan kompenzálja az elveszett zónákat más zónák kapacitásának használatával. Az erőforrásokat szállító forgalom zónaredundáns módon van üzembe helyezve, de a legkisebb léptékű forgalmat egyetlen erőforrás kezelheti. Ebben az esetben a cikkben ismertetett feladatátvételi mechanizmusok újraegyensúlyozzák a másik szolgáltatási régióba irányuló összes forgalmat, míg a forgalmat magukban hordozó erőforrások újra üzembe helyezése kifogástalan állapotú zónában történik.

Zónaleállási élmény a felügyeleti régióban

Zónaszintű kimaradás esetén nincs szükség műveletre a zóna helyreállítása során. A felügyeleti régió öngyógyítja és kiegyensúlyozza magát, hogy automatikusan kihasználja az kifogástalan állapotú zónát.

Vészhelyreállítás: visszaesés más régiókba

A vészhelyreállítás (DR) a nagy hatású események, például a természeti katasztrófák vagy az állásidőt és adatvesztést eredményező sikertelen üzemelő példányok helyreállításáról szól. A katasztrófa okától függetlenül a legjobb megoldás egy jól definiált és tesztelt DR-terv, valamint egy olyan alkalmazásterv, amely aktívan támogatja a DR-t. Mielőtt elkezdene gondolkodni a vészhelyreállítási terv létrehozásáról, tekintse meg a Javaslatok a vészhelyreállítási stratégia megtervezéséhez.

A DR-ről a Microsoft a megosztott felelősségi modellt használja. Egy megosztott felelősségi modellben a Microsoft biztosítja, hogy az alapinfrastruktúra és a platformszolgáltatások elérhetők legyenek. Ugyanakkor számos Azure-szolgáltatás nem replikálja automatikusan az adatokat, vagy egy meghibásodott régióból visszaesik egy másik engedélyezett régióba történő keresztreplikáláshoz. Ezekért a szolgáltatásokért Ön felel a számítási feladathoz használható vészhelyreállítási terv beállításáért. Az Azure-platformon szolgáltatásként (PaaS) futó szolgáltatások többsége funkciókkal és útmutatással támogatja a DR-t, és szolgáltatásspecifikus funkciókkal támogatja a gyors helyreállítást a dr. csomag fejlesztéséhez.

Ez a szakasz az Azure Communications Gateway viselkedését ismerteti egy régiószintű kimaradás során.

Vészhelyreállítás: régiók közötti feladatátvétel szolgáltatási régiók esetén

Az egész régióra kiterjedő leállások során a cikkben ismertetett feladatátvételi mechanizmusok (AZ OPTIONS lekérdezése és az SIP újrapróbálkozása a hiba esetén) újraegyensúlyozza a másik szolgáltatásrégióba irányuló összes hívási forgalmat, fenntartva a rendelkezésre állást. Megkezdjük a regionális redundancia visszaállítását. A regionális redundancia visszaállítása hosszabb állásidő alatt más Azure-régiók használatát is szükségessé teheti. Ha egy sikertelen régiót át kell migrálni egy másik régióba, a migrálás megkezdése előtt konzultálunk Önrel.

Az Azure Communications Gateway SBC-függvénye az OPTIONS lekérdezést biztosítja, amely lehetővé teszi a hálózat számára a társ rendelkezésre állásának meghatározását. McP esetén a hálózatnak képesnek kell lennie észlelni, hogy az MCP mikor nem érhető el, és rendszeresen próbálkozzon újra annak megállapításához, hogy mikor érhető el újra az MCP. Az MCP nem válaszol a SIP BEÁLLÍTÁSAIRA.

Az API-ügyfelek üzembe helyezéshez használt alaptartománynév használatával kapcsolatba lépnek az Azure Communications Gatewayrel. A tartomány DNS-rekordja 60 másodperc élettartamú (TTL). Ha egy régió meghibásodik, az Azure frissíti a DNS-rekordot, hogy egy másik régióra hivatkozzon, így az új DNS-keresést készítő ügyfelek megkapják az új régió adatait. Javasoljuk, hogy az ügyfelek egy időtúllépés vagy 5xx válasz után 60 másodperccel végezzenek új DNS-kereséseket, és próbálkozzon újra egy kéréssel.

Tipp.

A labortelepítések nem kínálnak régiók közötti feladatátvételt (mivel csak egy szolgáltatási régióval rendelkeznek).

Vészhelyreállítás: régiók közötti feladatátvétel felügyeleti régiók esetén

A hangforgalmat és a számkezelési portálon keresztüli üzembe helyezést a felügyeleti régió hibái nem érintik, mivel a megfelelő Azure-erőforrások szolgáltatásrégiókban vannak üzemeltetve. Előfordulhat, hogy a Számkezelési portál felhasználóinak újra be kell jelentkeznie.

Előfordulhat, hogy a figyelési szolgáltatások átmenetileg nem érhetők el a szolgáltatás visszaállításáig. Ha a felügyeleti régió hosszabb állásidőt tapasztal, az érintett erőforrásokat egy másik elérhető régióba migráljuk.

Felügyeleti és szolgáltatási régiók kiválasztása

Az Azure Communications Gateway egyetlen üzembe helyezése úgy lett kialakítva, hogy egy földrajzi területen belüli forgalmat kezeljen. Mindkét szolgáltatásrégió üzembe helyezése ugyanazon a földrajzi területen (például Észak-Amerika) lévő éles környezetben. Ez a modell biztosítja, hogy a hanghívások késése a Szolgáltatói kapcsolat és a Teams Telefon Mobile-programok által megkövetelt korlátokon belül maradjon.

A szolgáltatásrégió helyének kiválasztásakor vegye figyelembe a következő szempontokat:

  • Válasszon az elérhető Azure-régiók listájából. A Termékek régiónként lapon megtekintheti azokat az Azure-régiókat, amelyek szolgáltatásrégióként választhatók ki.
  • Válassza ki a saját telephelyéhez közeli régiókat, valamint a hálózat és a Microsoft közötti társviszony-létesítési helyeket a hívás késésének csökkentése érdekében.
  • A regionális párok előnyben részesítése a helyreállítási idő minimalizálása többrégiós kimaradás esetén.

Válasszon egy felügyeleti régiót a következő listából:

  • USA keleti régiója
  • USA nyugati középső régiója
  • Nyugat-Európa
  • Az Egyesült Királyság déli régiója
  • Közép-India
  • Közép-Kanada
  • Kelet-Ausztrália

A felügyeleti régiók a szolgáltatási régiókkal együtt helyezhetők el. Javasoljuk, hogy a szolgáltatási régiókhoz legközelebbi felügyeleti régiót válassza.

Feljegyzés

Ha engedélyezi az Azure Operator Call Protection előzetes verzióját, előfordulhat, hogy a kiválasztott szolgáltatási régió nem az az Azure-régió, ahol a támogató erőforrások üzembe vannak helyezve. A jelenleg támogatott Azure Operator Call Protection szolgáltatásrégiók listájáért tekintse meg az Azure Termékek régiónként című témakört, és ha kérdése van a kiválasztott régióval kapcsolatban, forduljon az előkészítési csapathoz.

Szolgáltatásiszint-szerződések

A dokumentumban ismertetett megbízhatósági kialakítást a Microsoft implementálta, és nem konfigurálható. Az Azure Communications Gateway szolgáltatásiszint-szerződéseivel (SLA-kkal) kapcsolatos további információkért lásd az Azure Communications Gateway SLA-ját.

Következő lépések