Dela via

Azure Event Hubs – Geo-haveriberedskap

  • Artikel

Kommentar

Den här artikeln handlar om funktionen ga geo-haveriberedskap som replikerade metadata och inte geo-replikeringsfunktionen för offentlig förhandsversion som beskrivs i Geo-replikering.

Den helt aktiva Azure Event Hubs-klustermodellen med stöd för tillgänglighetszoner ger återhämtning mot maskinvaru- och datacenteravbrott. Men om en katastrof där en hel region och alla zoner inte är tillgängliga kan du använda Geo-haveriberedskap för att återställa arbetsbelastningen och programkonfigurationen.

Geo-haveriberedskap säkerställer att hela konfigurationen av ett namnområde (Event Hubs, konsumentgrupper och inställningar) kontinuerligt replikeras från ett primärt namnområde till ett sekundärt namnområde när det är kopplat.

Funktionen Geo-haveriberedskap i Azure Event Hubs är en haveriberedskapslösning. Begreppen och arbetsflödet som beskrivs i den här artikeln gäller för katastrofscenarier och inte för tillfälliga avbrott. En detaljerad beskrivning av haveriberedskap i Microsoft Azure finns i den här artikeln.

Med Geo-Haveriberedskap kan du när som helst initiera en redundansväxling från den primära till den sekundära. Redundansväxlingen pekar det valda aliasnamnet för namnområdet till det sekundära namnområdet. Efter flytten tas parkopplingen bort. Redundansväxlingen är nästan omedelbar när den har initierats.

Viktigt!

  • Funktionen möjliggör omedelbar kontinuitet för åtgärder med samma konfiguration, men replikerar inte händelsedata. Om inte katastrofen orsakade förlusten av alla zoner kan händelsedata som bevaras i den primära händelsehubben efter redundansväxlingen återställas och de historiska händelserna kan hämtas därifrån när åtkomsten har återställts. Om du vill replikera händelsedata och använda motsvarande namnområden i aktiva/aktiva konfigurationer för att hantera avbrott och katastrofer ska du inte luta dig mot den här geo-haveriberedskapsfunktionen, utan följ replikeringsvägledningen.
  • Rollbaserade RBAC-tilldelningar (Microsoft Entra) till entiteter i det primära namnområdet replikeras inte till det sekundära namnområdet. Skapa rolltilldelningar manuellt i det sekundära namnområdet för att skydda åtkomsten till dem.

Grundläggande begrepp och termer

Haveriberedskapsfunktionen implementerar återställning av metadata och förlitar sig på primära och sekundära haveriberedskapsnamnområden.

Geo-haveriberedskapsfunktionen är endast tillgänglig för standard-, premium- och dedikerade SKU:er . Du behöver inte göra några niska veze ändringar eftersom anslutningen görs via ett alias.

Följande termer används i den här artikeln:

  • Alias: Namnet på en konfiguration för haveriberedskap som du har konfigurerat. Aliaset innehåller ett enda stabilt fullständigt domännamn (FQDN) niska veze. Program använder det här aliaset niska veze för att ansluta till ett namnområde.

  • Primärt/sekundärt namnområde: De namnområden som motsvarar aliaset. Det primära namnområdet är "aktivt" och tar emot meddelanden (kan vara ett befintligt eller nytt namnområde). Det sekundära namnområdet är "passivt" och tar inte emot meddelanden. Metadata mellan båda är synkroniserade, så båda kan smidigt acceptera meddelanden utan programkod eller niska veze ändringar. För att säkerställa att endast det aktiva namnområdet tar emot meddelanden måste du använda aliaset.

  • Metadata: Entiteter som händelsehubbar och konsumentgrupper och deras egenskaper för tjänsten som är associerade med namnområdet. Endast entiteter och deras inställningar replikeras automatiskt. Meddelanden och händelser replikeras inte.

  • Redundans: Processen för att aktivera det sekundära namnområdet.

Namnområdespar som stöds

Följande kombinationer av primära och sekundära namnområden stöds:

Primär namnområdesnivå Tillåten sekundär namnområdesnivå
Standard Standard, Dedikerad
Premium Premium
Dedikerad Dedikerad

Kommentar

Du kan inte parkoppla namnområden som finns i samma dedikerade kluster. Du kan parkoppla namnområden som finns i separata kluster.

Installations- och redundansflöde

Följande avsnitt är en översikt över redundansväxlingsprocessen och förklarar hur du konfigurerar den första redundansväxlingen.

Bild som visar översikten över redundansprocessen

Ställ in

Du skapar eller använder först ett befintligt primärt namnområde och ett nytt sekundärt namnområde och kopplar sedan ihop de två. Den här parkopplingen ger dig ett alias som du kan använda för att ansluta. Eftersom du använder ett alias behöver du inte ändra niska veze. Det går bara att lägga till nya namnområden i redundansparkopplingen.

  1. Skapa det primära namnområdet.

  2. Skapa det sekundära namnområdet i en annan region. Steget är valfritt. Du kan skapa det sekundära namnområdet när du skapar parkopplingen i nästa steg.

  3. I Azure-portalen navigerar du till ditt primära namnområde.

  4. Välj Geo-återställning på den vänstra menyn och välj Initiera parkoppling i verktygsfältet.

    Initiera parkoppling från det primära namnområdet

  5. Följ dessa steg på sidan Initiera parkoppling :

    1. Välj ett befintligt sekundärt namnområde eller skapa ett i en annan region. I det här exemplet väljs ett befintligt namnområde.
    2. För Alias anger du ett alias för geo-dr-parkopplingen.
    3. Välj sedan Skapa.

    Välj det sekundära namnområdet

  6. Du bör se sidan Geo-DR Alias . Du kan också navigera till den här sidan från det primära namnområdet genom att välja Geo-recovery på den vänstra menyn.

    Sidan Geo-DR-alias

  7. På sidan Geo-DR Alias väljer du Principer för delad åtkomst på den vänstra menyn för att få åtkomst till det primära niska veze för aliaset. Använd den här niska veze i stället för att använda niska veze till det primära/sekundära namnområdet direkt.

  8. På den här översiktssidan kan du utföra följande åtgärder:

    1. Bryt parkopplingen mellan primära och sekundära namnområden. Välj Bryt parkoppling i verktygsfältet.

    2. Redundansväxla manuellt till det sekundära namnområdet. Välj Redundans i verktygsfältet.

      Varning

      Om du redundansväxlar aktiveras det sekundära namnområdet och det primära namnområdet tas bort från geo-haveriberedskapspareringen. Skapa ett annat namnområde för att ha ett nytt geo-haveriberedskapspar.

Slutligen bör du lägga till viss övervakning för att identifiera om en redundansväxling krävs. I de flesta fall är tjänsten en del av ett stort ekosystem, vilket innebär att automatiska redundansväxlingar sällan är möjliga, eftersom redundansväxlingar ofta måste utföras i synkronisering med det återstående undersystemet eller infrastrukturen.

Exempel

I ett exempel på det här scenariot bör du överväga en POS-lösning (Point of Sale) som genererar meddelanden eller händelser. Event Hubs skickar dessa händelser till en mappnings- eller omformateringslösning, som sedan vidarebefordrar mappade data till ett annat system för vidare bearbetning. Då kan alla dessa system finnas i samma Azure-region. Beslutet om när och vilken del som ska redundansväxla beror på dataflödet i infrastrukturen.

Du kan automatisera redundansväxlingen antingen med övervakningssystem eller med anpassade övervakningslösningar. Sådan automatisering kräver dock extra planering och arbete, vilket ligger utanför den här artikelns omfång.

Redundansflöde

Om du initierar redundansväxlingen krävs två steg:

  1. Om ett annat avbrott inträffar vill du kunna redundansväxla igen. Konfigurera därför ett annat passivt namnområde och uppdatera parkopplingen.

  2. Hämta meddelanden från det tidigare primära namnområdet när det är tillgängligt igen. Därefter använder du det namnområdet för vanliga meddelanden utanför geo-återställningskonfigurationen eller tar bort det gamla primära namnområdet.

Kommentar

Endast vidarebefordran av redundans stöds. I det här scenariot redundansväxlar du och parkopplar sedan igen med ett nytt namnområde. Återställning efter fel stöds inte. till exempel i ett SQL-kluster.

Bild som visar redundansflödet

Manuell redundans

Det här avsnittet visar hur du manuellt redundansväxlar med hjälp av Azure-portalen, CLI, PowerShell, C#osv.

  1. I Azure-portalen navigerar du till ditt primära namnområde.

  2. Välj Geo-återställning på den vänstra menyn.

  3. Redundansväxla manuellt till det sekundära namnområdet. Välj Redundans i verktygsfältet.

    Varning

    Om du redundansväxlar aktiveras det sekundära namnområdet och det primära namnområdet tas bort från geo-haveriberedskapspareringen. Skapa ett annat namnområde för att ha ett nytt geo-haveriberedskapspar.

Hantering

Om du gjorde ett misstag; Du parade till exempel ihop fel regioner under den första installationen. Du kan när som helst bryta parkopplingen för de två namnrymderna. Om du vill använda de kopplade namnrymderna som vanliga namnområden tar du bort aliaset.

Att tänka på

Observera följande saker att tänka på:

  1. Event Hubs geo-haveriberedskap replikerar inte data och därför kan du inte återanvända det gamla förskjutningsvärdet för din primära händelsehubb på din sekundära händelsehubb. Vi rekommenderar att du startar om händelsemottagaren med någon av följande metoder:

    • EventPosition.FromStart() – Om du vill läsa alla data på din sekundära händelsehubb.
    • EventPosition.FromEnd() – Om du vill läsa alla nya data från tidpunkten för anslutningen till din sekundära händelsehubb.
    • EventPosition.FromEnqueuedTime(dateTime) – Om du vill läsa alla data som tas emot i din sekundära händelsehubb från ett visst datum och en viss tid.

  2. I redundansplaneringen bör du också ta hänsyn till tidsfaktorn. Om du till exempel förlorar anslutningen i mer än 15 till 20 minuter kan du välja att initiera redundansväxlingen.

  3. Det faktum att inga data replikeras innebär att aktuella aktiva sessioner inte replikeras. Dubblettidentifiering och schemalagda meddelanden kanske inte fungerar. Nya sessioner, schemalagda meddelanden och nya dubbletter fungerar.

  4. Rederovering av en komplex distribuerad infrastruktur bör repeteras minst en gång.

  5. Det kan ta lite tid att synkronisera entiteter, cirka 50–100 entiteter per minut.

  6. Vissa aspekter av hanteringsplanet för det sekundära namnområdet blir skrivskyddade medan geo-recovery-parkoppling är aktiv.

  7. Dataplanet för det sekundära namnområdet är skrivskyddat medan geo-återställningsparning är aktivt. Dataplanet i det sekundära namnområdet accepterar GET-begäranden för att aktivera verifiering av klientanslutnings- och åtkomstkontroller.

Privata slutpunkter

Det här avsnittet innehåller fler överväganden när du använder Geo-haveriberedskap med namnområden som använder privata slutpunkter. Mer information om hur du använder privata slutpunkter med Event Hubs i allmänhet finns i Konfigurera privata slutpunkter.

Nya parkopplingar

Om du försöker skapa en parkoppling mellan ett primärt namnområde med en privat slutpunkt och ett sekundärt namnområde utan en privat slutpunkt misslyckas parkopplingen. Parkopplingen lyckas endast om både primära och sekundära namnområden har privata slutpunkter. Vi rekommenderar att du använder samma konfigurationer på de primära och sekundära namnrymderna och i virtuella nätverk där privata slutpunkter skapas.

Kommentar

När du försöker parkoppla det primära namnområdet med en privat slutpunkt och ett sekundärt namnområde kontrollerar valideringsprocessen endast om det finns en privat slutpunkt i det sekundära namnområdet. Den kontrollerar inte om slutpunkten fungerar eller fungerar efter redundansväxlingen. Det är ditt ansvar att se till att det sekundära namnområdet med den privata slutpunkten fungerar som förväntat efter redundansväxlingen.

Om du vill testa att de privata slutpunktskonfigurationerna är samma i primära och sekundära namnområden skickar du en läsbegäran (till exempel Hämta händelsehubb) till det sekundära namnområdet utanför det virtuella nätverket och kontrollerar att du får ett felmeddelande från tjänsten.

Befintliga parkopplingar

Om det redan finns en parkoppling mellan det primära och sekundära namnområdet kommer det inte att gå att skapa en privat slutpunkt i det primära namnområdet. Lös problemet genom att skapa en privat slutpunkt på det sekundära namnområdet först och sedan skapa en för det primära namnområdet.

Kommentar

Även om vi tillåter skrivskyddad åtkomst till det sekundära namnområdet tillåts uppdateringar av de privata slutpunktskonfigurationerna.

När du skapar en konfiguration för haveriberedskap för ditt program och Event Hubs-namnområden måste du skapa privata slutpunkter för både primära och sekundära Event Hubs-namnområden mot virtuella nätverk som är värdar för både primära och sekundära instanser av ditt program.

Anta att du har två virtuella nätverk: VNET-1, VNET-2 och dessa primära och sekundära namnområden: EventHubs-Namespace1-Primary, EventHubs-Namespace2-Secondary. Du måste utföra följande steg:

  • På EventHubs-Namespace1-Primary skapar du två privata slutpunkter som använder undernät från VNET-1 och VNET-2
  • På EventHubs-Namespace2-Secondary skapar du två privata slutpunkter som använder samma undernät från VNET-1 och VNET-2

Privata slutpunkter och virtuella nätverk

Fördelen med den här metoden är att redundansväxling kan ske på programnivån oberoende av Event Hubs-namnområdet. Föreställ dig följande scenarier:

Redundans endast för program: Här finns inte programmet i VNET-1 utan övergår till VNET-2. Eftersom båda de privata slutpunkterna konfigureras på både VNET-1 och VNET-2 för både primära och sekundära namnområden fungerar programmet bara.

Redundans för endast Event Hubs-namnrymd: Här igen, eftersom båda de privata slutpunkterna har konfigurerats på båda de virtuella nätverken för både primära och sekundära namnområden, fungerar programmet bara.

Kommentar

Vägledning om geo-haveriberedskap för ett virtuellt nätverk finns i Virtuellt nätverk – Affärskontinuitet.

Rollbaserad åtkomstkontroll

Rollbaserade RBAC-tilldelningar (Microsoft Entra) till entiteter i det primära namnområdet replikeras inte till det sekundära namnområdet. Skapa rolltilldelningar manuellt i det sekundära namnområdet för att skydda åtkomsten till dem.

Nästa steg

Granska följande exempel eller referensdokumentation.