Dela via

Tillförlitlighet i Azure Communications Gateway

  • Artikel

Azure Communications Gateway säkerställer att din tjänst är tillförlitlig med hjälp av Azure-redundansmekanismer och SIP-specifikt återförsöksbeteende. Nätverket måste uppfylla specifika krav för att säkerställa tjänstens tillgänglighet.

Azure Communications Gateways redundansmodell

Distributioner av Azure Communications Gateway för produktion (kallas även standarddistributioner) består av tre separata regioner: en hanteringsregion och två tjänstregioner. Labbdistributioner består av en hanteringsregion och en tjänstregion.

Den här artikeln beskriver de två olika regiontyperna och deras distinkta redundansmodeller. Den omfattar både regional tillförlitlighet med tillgänglighetszoner och tillförlitlighet mellan regioner med haveriberedskap. En mer detaljerad översikt över tillförlitligheten i Azure finns i Azures tillförlitlighet.

Diagram över två tjänstregioner, en hanteringsregion och två operatorplatser.

Tjänstregioner

Tjänstregioner innehåller den röst- och API-infrastruktur som används för att hantera trafik mellan ditt nätverk och dina valda kommunikationstjänster.

Distributioner av Azure Communications Gateway för produktion har två tjänstregioner som distribueras i aktivt-aktivt läge (vilket krävs av Operatörsanslutning- och Teams Telefon Mobile-program). Snabb redundans mellan tjänstregionerna tillhandahålls på infrastruktur-/IP-nivå och på programnivå (SIP/RTP/HTTP).

Tjänstregionerna innehåller också infrastrukturen för Azure Communications Gateways etablerings-API.

Dricks

Produktionsdistributioner måste alltid ha två tjänstregioner, även om en av de valda tjänstregionerna finns i en enda region i Azure Geography (till exempel Qatar). Om du väljer en Azure Geography för en enda region väljer du en andra Azure-region i ett annat Azure Geography.

Tjänstregionerna är identiska i drift och ger återhämtning till både zon- och regionalfel. Varje tjänstregion kan transportera 100 % av trafiken med hjälp av Azure Communications Gateway-instansen. Slutanvändarna bör därför fortfarande kunna ringa och ta emot samtal under en zon eller regional stilleståndstid.

Labbdistributioner har en tjänstregion.

Krav för samtalsroutning

Azure Communications Gateway erbjuder en "lyckad redundansmodell" : anrop som hanteras av misslyckade peer-datorer avslutas, men nya anrop dirigeras till felfria peer-datorer. Den här modellen speglar redundansmodellen som tillhandahålls av Microsoft Teams.

För produktionsdistributioner förväntar vi oss att nätverket har två geografiskt redundanta platser. Varje webbplats ska kopplas ihop med en Azure Communications Gateway-region. Redundansmodellen förlitar sig på korsanslutning mellan dina nätverks- och Azure Communications Gateway-tjänstregioner.

Diagram över två operatorplatser och två tjänstregioner. Båda tjänstregionerna ansluter till båda platserna, med primära och sekundära vägar.

Labbdistributioner måste ansluta till en plats i nätverket.

Varje Azure Communications Gateway-tjänstregion tillhandahåller en SRV-post. Den här posten innehåller alla SIP-peer-datorer som tillhandahåller SBC-funktioner (för routning av anrop till kommunikationstjänster) i regionen. Den här SRV-posten kan peka på valfri IP-adress i ip-intervallet /28 som tillhandahålls av ditt registreringsteam.

Om din Azure Communications Gateway innehåller Mobile Control Point (MCP) tillhandahåller varje tjänstregion en extra SRV-post för MCP. Varje MCP-post per region innehåller MCP i regionen med högsta prioritet och MCP i den andra regionen med lägre prioritet.

Varje plats i nätverket måste:

  • Skicka trafik till den lokala Azure Communications Gateway-tjänstregionen som standard.
  • Leta upp Azure Communications Gateway-peer-datorer i en region med DNS SRV, enligt beskrivningen i RFC 3263.
    • Gör en DNS SRV-sökning på domännamnet för tjänstregionens anslutning till nätverket med hjälp av _sip._tls.<regional-FQDN-from-portal>. Ersätt <regional-FQDN-from-portal> med FQDN per region från fälten Värdnamn på sidan Översikt för din resurs i Azure-portalen. Om distributionen till exempel använder commsgw.azure.com domännamn letar du upp _sip._tls.pstn-region1.<deployment-id>.commsgw.azure.com den första regionen.
    • Om SRV-sökningen returnerar flera mål använder du vikten och prioriteten för varje mål för att välja ett enda mål.
  • Skicka nya anrop till tillgängliga Azure Communications Gateway-peer-datorer.
  • Kunna ta emot trafik från valfri IP-adress i vart och ett av de IP-intervall som är associerade med din Azure Communications Gateway.

När nätverket dirigerar samtal till Azure Communications Gateways SIP-peer-datorer för SBC-funktionen måste den:

  • Använd SIP-ALTERNATIV (eller en kombination av ALTERNATIV och SIP-trafik) för att övervaka tillgängligheten för Azure Communications Gateway SIP-peer-datorer.
  • Försök igen med INVITEs som tog emot 408 svar, 503 svar eller 504 svar eller som inte fick svar, genom att omdirigera dem till andra tillgängliga peer-datorer på den lokala webbplatsen. Jaga till den andra tjänstregionen (definieras av den andra regionens SRV-post) endast om alla peer-datorer i den lokala tjänstregionen har misslyckats.
  • Försök aldrig igen med andra felsvar än 408, 503 och 504.

Om din Azure Communications Gateway-distribution innehåller en integrerad MCP (Mobile Control Point) måste nätverket göra följande för MCP:

  • Identifiera när MCP i en region inte är tillgänglig, markera målen för regionens SRV-post som otillgängliga och försök igen med jämna mellanrum för att avgöra när regionen är tillgänglig igen. MCP svarar inte på SIP-alternativ.
  • Hantera 5xx-svar från MCP enligt organisationens policy. Du kan till exempel försöka begära igen, eller låta anropet fortsätta utan att skicka via Azure Communications Gateway och till Microsoft Telefon System.

Informationen om det här routningsbeteendet är specifik för nätverket. Du måste godkänna dem med ditt registreringsteam under integrationsprojektet.

Hanteringsregioner

Hanteringsregioner innehåller den infrastruktur som används för beställning, övervakning och fakturering av Azure Communications Gateway. All infrastruktur inom dessa regioner distribueras på ett zonredundant sätt, vilket innebär att alla data replikeras automatiskt i varje tillgänglighetszon i regionen. Alla kritiska konfigurationsdata replikeras också till var och en av tjänstregionerna för att säkerställa att tjänsten fungerar korrekt under ett fel i Azure-regionen.

Stöd för tillgänglighetszon

Azure-tillgänglighetszoner är minst tre fysiskt separata grupper av datacenter i varje Azure-region. Datacenter i varje zon är utrustade med oberoende infrastruktur för ström, kylning och nätverk. Om det uppstår ett fel i den lokala zonen är tillgänglighetszoner utformade så att regionala tjänster, kapacitet och hög tillgänglighet stöds av de återstående två zonerna om den ena zonen påverkas.

Fel kan vara allt från programvaru- och maskinvarufel till händelser som jordbävningar, översvämningar och bränder. Tolerans mot fel uppnås med redundans och logisk isolering av Azure-tjänster. Mer detaljerad information om tillgänglighetszoner i Azure finns i Regioner och tillgänglighetszoner.

Azure-tillgänglighetszoner-aktiverade tjänster är utformade för att ge rätt nivå av tillförlitlighet och flexibilitet. De kan konfigureras på två sätt. De kan vara antingen zonredundanta, med automatisk replikering mellan zoner eller zoninstanser, med instanser fästa på en specifik zon. Du kan också kombinera dessa metoder. Mer information om zon- och zonredundant arkitektur finns i Rekommendationer för användning av tillgänglighetszoner och regioner.

Zon-ned-upplevelse för tjänstregioner

Under ett zonomfattande avbrott avslutas anrop som hanteras av den berörda zonen, med en kort kapacitetsförlust inom regionen tills tjänstens självåterställning balanserar om underliggande resurser till felfria zoner. Den här självåterställning är inte beroende av zonåterställning. Det förväntas att självåterställningstillståndet för Microsoft-hanterad tjänst kompenserar för en förlorad zon med hjälp av kapacitet från andra zoner. Trafik som transporterar resurser distribueras på ett zonredundant sätt, men i den lägsta skalan kan trafiken hanteras av en enda resurs. I det här fallet balanserar redundansmekanismerna som beskrivs i den här artikeln all trafik till den andra tjänstregionen medan resurserna som transporterar trafik omdistribueras i en felfri zon.

Zon ned för hanteringsregionen

Under ett zonomfattande avbrott krävs ingen åtgärd under zonåterställning. Hanteringsregionen läker och balanserar om sig själv för att dra nytta av den felfria zonen automatiskt.

Haveriberedskap: återställning till andra regioner

Haveriberedskap handlar om att återställa från händelser med hög påverkan, till exempel naturkatastrofer eller misslyckade distributioner som resulterar i driftstopp och dataförlust. Oavsett orsak är den bästa lösningen för en katastrof en väldefinierad och testad DR-plan och en programdesign som aktivt stöder DR. Innan du börjar fundera på att skapa en haveriberedskapsplan kan du läsa Rekommendationer för att utforma en strategi för haveriberedskap.

När det gäller dr använder Microsoft modellen för delat ansvar. I en modell med delat ansvar ser Microsoft till att baslinjeinfrastrukturen och plattformstjänsterna är tillgängliga. Samtidigt replikerar många Azure-tjänster inte automatiskt data eller återgår från en misslyckad region för att korsreparera till en annan aktiverad region. För dessa tjänster ansvarar du för att konfigurera en haveriberedskapsplan som fungerar för din arbetsbelastning. De flesta tjänster som körs på PaaS-erbjudanden (Plattform som en tjänst) i Azure ger funktioner och vägledning för att stödja DR och du kan använda tjänstspecifika funktioner för att stödja snabb återställning för att utveckla din DR-plan.

I det här avsnittet beskrivs beteendet för Azure Communications Gateway under ett regionomfattande avbrott.

Haveriberedskap: redundans mellan regioner för tjänstregioner

Under ett regionomfattande avbrott balanserar redundansmekanismerna som beskrivs i den här artikeln (ALTERNATIV-avsökning och SIP-återförsök vid fel) ombalansera all samtalstrafik till den andra tjänstregionen, vilket bibehåller tillgängligheten. Vi börjar återställa regional redundans. Återställning av regional redundans under längre stilleståndstider kan kräva användning av andra Azure-regioner. Om vi behöver migrera en misslyckad region till en annan region kontaktar vi dig innan du påbörjar migreringar.

SBC-funktionen i Azure Communications Gateway tillhandahåller ALTERNATIV-avsökning så att nätverket kan fastställa peer-tillgänglighet. För MCP måste nätverket kunna identifiera när MCP inte är tillgängligt och försöka igen regelbundet för att avgöra när MCP är tillgängligt igen. MCP svarar inte på SIP-alternativ.

Etablerings-API-klienter kontaktar Azure Communications Gateway med basdomännamnet för distributionen. DNS-posten för den här domänen har en TTL (time-to-live) på 60 sekunder. När en region misslyckas uppdaterar Azure DNS-posten så att den refererar till en annan region, så klienter som gör en ny DNS-sökning får information om den nya regionen. Vi rekommenderar att du ser till att klienter kan göra en ny DNS-sökning och försöka igen 60 sekunder efter en timeout eller ett 5xx-svar.

Dricks

Labbdistributioner erbjuder inte redundans mellan regioner (eftersom de bara har en tjänstregion).

Haveriberedskap: redundans mellan regioner för hanteringsregioner

Rösttrafik och etablering via nummerhanteringsportalen påverkas inte av fel i hanteringsregionen eftersom motsvarande Azure-resurser finns i tjänstregioner. Användare av nummerhanteringsportalen kan behöva logga in igen.

Övervakningstjänster kan vara tillfälligt otillgängliga tills tjänsten har återställts. Om hanteringsregionen upplever utökad stilleståndstid migrerar vi de berörda resurserna till en annan tillgänglig region.

Välja hanterings- och tjänstregioner

En enda distribution av Azure Communications Gateway är utformad för att hantera din trafik inom ett geografiskt område. Distribuera båda tjänstregionerna i en produktionsdistribution inom samma geografiska område (till exempel Nordamerika). Den här modellen säkerställer att svarstiden för röstsamtal ligger inom de gränser som krävs av Operatörsanslutning- och Teams Telefon Mobile-program.

Tänk på följande när du väljer platser för din tjänstregion:

  • Välj i listan över tillgängliga Azure-regioner. Du kan se de Azure-regioner som kan väljas som tjänstregioner på sidan Produkter efter region .
  • Välj regioner nära din egen lokal och peeringplatserna mellan nätverket och Microsoft för att minska samtalsfördröjningen.
  • Föredra regionala par för att minimera återställningstiden om ett avbrott i flera regioner inträffar.

Välj en hanteringsregion i följande lista:

  • USA, östra
  • USA, västra centrala
  • Europa, västra
  • Södra Storbritannien
  • Indien, centrala
  • Kanada, centrala
  • Australien, östra

Hanteringsregioner kan samplaceeras med tjänstregioner. Vi rekommenderar att du väljer den hanteringsregion som är närmast dina tjänstregioner.

Kommentar

Om du aktiverar förhandsversionen av Azure Operator Call Protection kanske inte den tjänstregion som du väljer är den Azure-region där stödresurser distribueras. Se Azure Products by Region (Azure-produkter efter region ) för listan över för närvarande stödda Azure Operator Call Protection-tjänstregioner och prata med ditt registreringsteam om du har några frågor om vilken region som har valts.

Serviceavtal

Den tillförlitlighetsdesign som beskrivs i det här dokumentet implementeras av Microsoft och kan inte konfigureras. Mer information om serviceavtal för Azure Communications Gateway (SLA) finns i serviceavtalet för Azure Communications Gateway.

Nästa steg