Tillförlitlighet i Azure Event Grid och Event Grid-namnområdet

Den här artikeln innehåller detaljerad information om regional återhämtning för Event Grid- och Event Grid-namnområden med tillgänglighetszoner och haveriberedskap mellan regioner och affärskontinuitet.

En arkitekturöversikt över tillförlitlighet i Azure finns i Azures tillförlitlighet.

Stöd för tillgänglighetszon

Tillgänglighetszoner är fysiskt separata grupper av datacenter i varje Azure-region. När en zon misslyckas kan tjänsterna redundansväxla till en av de återstående zonerna.

Event Grid-resursdefinitioner för ämnen, systemämnen, domäner och händelseprenumerationer och händelsedata replikeras automatiskt mellan tre tillgänglighetszoner. När det uppstår ett regionalt fel i någon av tillgänglighetszonerna, växlar Event Grid-resurser automatiskt över till en annan tillgänglighetszon utan mänsklig inblandning. För närvarande är det inte möjligt för dig att styra (aktivera eller inaktivera) den här funktionen. När en befintlig region börjar stödja tillgänglighetszoner omdirigeras befintliga Event Grid-resurser automatiskt för att dra nytta av den här funktionen. Ingen kundåtgärd krävs.

Azure Event Grid-namnområdet ger också hög tillgänglighet inom regionen med hjälp av tillgänglighetszoner.

Förutsättningar

För stöd för tillgänglighetszoner måste dina Event Grid-resurser finnas i en region som stöder tillgänglighetszoner. Information om vilka regioner som stöder tillgänglighetszoner finns i listan över regioner som stöds.

Prissättning

Eftersom Event Grid stöder tillgänglighetszoner automatiskt i regioner som stöder tillgänglighetszoner finns det inga ändringar i priset.

Skapa en resurs med tillgänglighetszoner aktiverade

Eftersom Event Grid stöder tillgänglighetszoner automatiskt i regioner som stöder tillgänglighetszoner finns det ingen nödvändig konfigurationskonfiguration.

Migrera till tillgänglighetszonstöd

Om du flyttar dina Event Grid-resurser till en region som stöder tillgänglighetszoner får du automatiskt stöd för tillgänglighetszoner. Information om hur du flyttar dina resurser till en annan region som stöder tillgänglighetszoner finns i följande:

• Flytta Azure Event Grid-systemämnen till en annan region
• Flytta anpassade ämnen för Azure Event Grid till en annan region
• Flytta Azure Event Grid-domäner till en annan region

Haveriberedskap och affärskontinuitet mellan regioner

Haveriberedskap (DR) refererar till metoder som organisationer använder för 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 skapa din haveriberedskapsplan kan du läsa Rekommendationer för att utforma en strategi för haveriberedskap.

För DR använder Microsoft modellen delat ansvar. I den här modellen ser Microsoft till att baslinjeinfrastrukturen och plattformstjänsterna är tillgängliga. Många Azure-tjänster replikerar dock inte data automatiskt 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. Du kan använda de tjänstspecifika funktionerna i till att underlätta snabb återställning för att hjälpa till att utveckla din DR-plan.

Katastrofåterställning innebär vanligtvis att skapa en säkerhetskopieringsresurs för att förhindra avbrott när en region blir instabil. Under den här processen behövs en primär och sekundär region med Azure Event Grid-resurser i din arbetsbelastning.

Det finns olika sätt att återställa från en allvarlig förlust av programfunktioner. I det här avsnittet beskriver vi checklistan som du måste följa för att förbereda klienten att återhämta sig från ett fel på grund av en instabil resurs eller region.

Event Grid stöder både manuell och automatisk geo-haveriberedskap (GeoDR) på serversidan. Du kan fortfarande implementera haveriberedskapslogik på klientsidan om du vill ha en större kontroll över redundansväxlingsprocessen. Mer information om automatisk GeoDR finns i Geo-haveriberedskap på serversidan i Azure Event Grid. Mer information om hur du implementerar haveriberedskap på klientsidan finns i Implementering av redundans på klientsidan i Azure Event Grid.

I följande tabell visas stöd för redundans på klientsidan och geo-haveriberedskap i Event Grid.

Event Grid-namnområde

Event Grid-namnrymden stöder inte dr-fel mellan regioner. Du kan dock uppnå hög tillgänglighet mellan regioner genom implementering av redundans på klientsidan genom att skapa primära och sekundära namnområden.

Med en redundansimplementering på klientsidan kan du:

• Implementera en anpassad (manuell eller automatiserad) process för att replikera namnrymd, klientidentiteter och andra konfigurationer** inklusive CA-certifikat, klientgrupper, ämnesutrymmen, behörighetsbindningar, routning, mellan primära och sekundära regioner.

• Implementera en concierge-tjänst som ger kunder primära och sekundära slutpunkter genom att utföra hälsokontroller på slutpunkterna. Concierge-tjänsten kan vara en webbapplikation som replikeras och hålls tillgängligt med hjälp av DNS-omdirigeringstekniker, till exempel med hjälp av Azure Traffic Manager.

• Uppnå en Aktiv-Aktiv DR-lösning genom att replikera metadata och balansera belastningen över namnrymderna. En aktiv-passiv DR-lösning kan uppnås genom att replikera metadata för att hålla det sekundära namnområdet redo så att trafiken kan dirigeras till sekundärt namnområde när det primära namnområdet inte är tillgängligt.

Konfigurera haveriberedskap

För regioner som är kopplade erbjuder Event Grid en möjlighet att redundansväxla publiceringstrafiken till den kopplade regionen för anpassade ämnen, systemämnen och domäner. I bakgrunden synkroniserar Event Grid automatiskt resursdefinitioner av ämnen, systemämnen, domäner och händelseprenumerationer till den kopplade regionen. Händelsedata replikeras dock inte till den kopplade regionen. I det normala tillståndet lagras händelser i den region som du valde för den resursen. När ett regionavbrott inträffar och Microsoft påbörjar failover börjar nya händelser flöda till den geo-kopplade regionen och sänds därifrån utan några åtgärder från dig. Händelser som publicerats och godkänts i den ursprungliga regionen skickas därifrån efter att avbrottet har åtgärdats.

Du kan välja mellan två redundansalternativ, Microsoft-initierad redundans och kundinitierad. Detaljerade anvisningar om hur du konfigurerar båda dessa inställningar finns i Konfigurera datahemvist.

• Microsoft-initierad redundans används av Microsoft i sällsynta fall för att redundansväxla Event Grid-resurser från en berörd region till motsvarande geo-kopplade region. Microsoft förbehåller sig rätten att avgöra när det här alternativet ska användas. Den här mekanismen kräver inte ett användarmedgivande innan användarens trafik omkopplas.

  Aktivera den här funktionen genom att uppdatera konfigurationen för ditt ämne eller din domän. Välj Cross-Geo (standard) för att aktivera Microsoft-initierad redundans.

• Kundinitierad redundans definieras av din anpassade haveriberedskapsplan för Azure Event Grid-ämnen och domäner. Inga data av något slag replikeras till en annan region av Microsoft. Även om det här redundansalternativet kräver lite mer arbete möjliggör det snabbare redundans och du har kontroll över att välja sekundära regioner. Om du vill implementera haveriberedskap på klientsidan för Azure Event Grid-ämnen, se Skapa en egen haveriberedskap på klientsidan för Azure Event Grid-ämnen.

  Det finns några orsaker till varför du kanske vill inaktivera den Microsoft-initierade redundansfunktionen:

  • Microsoft-initierad redundans utförs på bästa sätt.
  • Vissa geo-par uppfyller inte organisationens krav på datahemvist.

  Aktivera den här funktionen genom att uppdatera konfigurationen för ditt ämne eller din domän. Välj Regional.

  

Om du använder en icke-trappad region replikeras dina metadata endast inom regionen, oavsett vilken dataplaceringskonfiguration du väljer.

Erfarenhet av övergång till reservsystem vid katastrofåterställning

Haveriberedskap mäts med två mått: Mål för återställningspunkt (RPO) och mål för återställningstid (RTO). Mer information finns i Vad är affärskontinuitet, hög tillgänglighet och haveriberedskap?.

Event Grids automatiska redundansväxling har olika RPO:er och RTO:er för din metadata (teman, domäner, händelseprenumerationer) och data (händelser). Om du behöver en annan specifikation än följande kan du fortfarande implementera din egen redundans på klientsidan med hjälp av ämnets hälso-API:er.

Mål för återställningspunkt (RPO)

• RPO för metadata: noll minuter. När en resurs skapas/uppdateras/tas bort för tillämpliga resurser replikeras resursdefinitionen synkront till geo-paret. När en redundansväxling inträffar går inga metadata förlorade.

• Data RPO: När en failover inträffar bearbetas nya data från den kopplade regionen. Så snart avbrottet har åtgärdats för den berörda regionen skickas de obearbetade händelserna därifrån. Om regionåterställningen krävde längre tid än det time-to-live-värde som angetts för händelser kan data tas bort. För att minska dataförlusten rekommenderar vi att du konfigurerar en destinationsplats för odeliverbara meddelanden för en händelseprenumeration. Om den berörda regionen går förlorad och inte går att återställa kommer det att uppstå viss dataförlust. I bästa fall håller prenumeranten jämna steg med publiceringsfrekvensen och bara några sekunders data går förlorade. Det värsta scenariot skulle vara när prenumeranten inte aktivt bearbetar händelser och med en maxtid på 24 timmar kan dataförlusten vara upp till 24 timmar.

Mål för återställningstid (RTO)

• RTO för metadata: Beslutsfattande vid redundans baseras på faktorer som tillgänglig kapacitet i en ihopkopplad region och kan variera mellan 60 minuter eller mer. När redundansväxlingen har initierats börjar Event Grid inom 5 minuter att acceptera anrop för att skapa/uppdatera/ta bort ämnen och prenumerationer.

• Data-RTO: Samma som ovanstående information.

Nästa steg

• Bygg din egen katastrofåterställning på klientens sida för Azure Event Grid-ämnen.

• Tillförlitlighet i Azure