Azure Event Hubs – Geo-haveriberedskap
Motståndskraft mot katastrofala avbrott i databehandlingsresurser är ett krav för många företag och i vissa fall till och med nödvändigt enligt branschregler.
Azure Event Hubs sprider redan risken för katastrofala fel på enskilda datorer eller till och med fullständiga rack mellan kluster som omfattar flera feldomäner i ett datacenter. Den implementerar transparenta mekanismer för felidentifiering och redundans så att tjänsten fortsätter att fungera på de säkra tjänstnivåerna och vanligtvis utan märkbara avbrott i händelse av sådana fel. Om du skapar ett Event Hubs-namnområde med tillgänglighetszoner aktiverade minskar du risken för avbrott ytterligare och aktiverar hög tillgänglighet. Med tillgänglighetszoner är avbrottsrisken ytterligare spridd över tre fysiskt avgränsade anläggningar, och tjänsten har tillräckligt med kapacitetsreserver för att omedelbart hantera hela anläggningens fullständiga, katastrofala förlust.
Den helt aktiva Azure Event Hubs-klustermodellen med stöd för tillgänglighetszoner ger återhämtning mot allvarliga maskinvarufel och till och med katastrofal förlust av hela datacenteranläggningar. Det kan dock finnas allvarliga situationer med omfattande fysisk förstörelse som inte ens dessa åtgärder kan försvara sig tillräckligt mot.
Funktionen Geo-haveriberedskap i Event Hubs är utformad för att göra det enklare att återställa efter en katastrof av den här storleken och överge en misslyckad Azure-region för gott och utan att behöva ändra dina programkonfigurationer. Att överge en Azure-region innebär vanligtvis flera tjänster och den här funktionen syftar främst till att bevara integriteten i den sammansatta programkonfigurationen.
Funktionen 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, och det gör att du kan initiera en redundansväxling endast en gång från den primära till den sekundära när som helst. Redundansväxlingen pekar om det valda aliasnamnet för namnområdet till det sekundära namnområdet och bryter sedan parkopplingen. 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.
Avbrott och katastrofer
Det är viktigt att notera skillnaden mellan "avbrott" och "katastrofer". Ett avbrott är den tillfälliga otillgängligheten för Azure Event Hubs och kan påverka vissa komponenter i tjänsten, till exempel ett meddelandearkiv eller till och med hela datacentret. Men när problemet har åtgärdats blir Event Hubs tillgängligt igen. Normalt orsakar ett avbrott inte förlust av meddelanden eller andra data. Ett exempel på ett sådant avbrott kan vara ett strömavbrott i datacentret. Vissa avbrott är bara korta anslutningsförluster på grund av tillfälliga problem eller nätverksproblem.
En katastrof definieras som permanent eller långsiktig förlust av ett Event Hubs-kluster, Azure-region eller datacenter. Regionen eller datacentret kanske inte blir tillgängligt igen eller kan vara nere i timmar eller dagar. Exempel på sådana katastrofer är brand, översvämningar eller jordbävning. En katastrof som blir permanent kan orsaka förlust av vissa meddelanden, händelser eller andra data. I de flesta fall bör det dock inte uppstå någon dataförlust och meddelanden kan återställas när datacentret har säkerhetskopierats.
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 eller tillfälliga avbrott. En detaljerad beskrivning av haveriberedskap i Microsoft Azure finns i den här artikeln.
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 anslutningssträng ä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) anslutningssträng. Program använder det här aliaset anslutningssträng 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 anslutningssträng ä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.
Konfiguration
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 anslutningssträng. Det går bara att lägga till nya namnområden i redundansparkopplingen.
Skapa det primära namnområdet.
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.
I Azure-portalen navigerar du till ditt primära namnområde.
Välj Geo-återställning på den vänstra menyn och välj Initiera parkoppling i verktygsfältet.
Följ dessa steg på sidan Initiera parkoppling :
- 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.
- För Alias anger du ett alias för geo-dr-parkopplingen.
- Välj sedan Skapa.
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.
På sidan Geo-DR Alias väljer du Principer för delad åtkomst på den vänstra menyn för att få åtkomst till den primära anslutningssträng för aliaset. Använd den här anslutningssträng i stället för att använda anslutningssträng till det primära/sekundära namnområdet direkt.
På den här översiktssidan kan du utföra följande åtgärder:
Bryt parkopplingen mellan primära och sekundära namnområden. Välj Bryt parkoppling i verktygsfältet.
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:
Om ett annat avbrott inträffar vill du kunna redundansväxla igen. Konfigurera därför ett annat passivt namnområde och uppdatera parkopplingen.
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.
Manuell redundans
Det här avsnittet visar hur du manuellt redundansväxlar med hjälp av Azure-portalen, CLI, PowerShell, C#osv.
I Azure-portalen navigerar du till ditt primära namnområde.
Välj Geo-återställning på den vänstra menyn.
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.
Överväganden
Observera följande saker att tänka på:
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.
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.
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.
Rederovering av en komplex distribuerad infrastruktur bör repeteras minst en gång.
Det kan ta lite tid att synkronisera entiteter, cirka 50–100 entiteter per minut.
Vissa aspekter av hanteringsplanet för det sekundära namnområdet blir skrivskyddade medan geo-recovery-parkoppling är aktiv.
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.
Tillgänglighetszoner
Event Hubs stöder Tillgänglighetszoner och tillhandahåller felisolerade platser i en Azure-region. Stöd för Tillgänglighetszoner är endast tillgängligt i Azure-regioner med tillgänglighetszoner. Både metadata och data (händelser) replikeras mellan datacenter i tillgänglighetszonen.
När du skapar ett namnområde visas följande markerade meddelande när du väljer en region som har tillgänglighetszoner.
Kommentar
När du använder Azure-portalen aktiveras zonredundans via stöd för tillgänglighetszoner automatiskt. Du kan inte inaktivera det i portalen. Du kan använda Azure CLI-kommandot az eventhubs namespace med --zone-redundant=false eller använda PowerShell-kommandot New-AzEventHubNamespace med -ZoneRedundant=false för att skapa ett namnområde med zonredundans inaktiverad.
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.
Rekommenderad konfiguration
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
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.