Dela via

Tillförlitlighet i Azure Event Hubs

  • Artikel

Den här artikeln beskriver tillförlitlighetsstöd i Azure Event Hubs och beskriver både intraregional återhämtning med tillgänglighetszoner och haveriberedskap mellan regioner och affärskontinuitet. En mer detaljerad översikt över tillförlitlighetsprinciper i Azure finns i Azures tillförlitlighet.

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.

Event Hubs implementerar transparenta mekanismer för felidentifiering och redundans så att tjänsten fortsätter att fungera inom de säkra tjänstnivåerna och utan märkbara avbrott när fel inträffar. Om du skapar ett Event Hubs-namnområde i en region som stöder tillgänglighetszoner aktiveras zonredundans automatiskt. Med zonredundans ökar feltoleransen och tjänsten har tillräckligt med kapacitetsreserver för att klara driftstoppet för en hel anläggning. Både metadata och data (händelser) replikeras mellan datacenter i varje zon.

Förutsättningar

Stöd för tillgänglighetszoner är endast tillgängligt i Azure-regioner med tillgänglighetszoner.

Skapa en resurs med tillgänglighetszoner aktiverade

När du använder Azure-portalen aktiveras zonredundans automatiskt. När du skapar ett namnområde visas följande markerade meddelande när du väljer en region som stöder tillgänglighetszoner.

Skärmbild som visar sidan Skapa namnområde med en region som har tillgänglighetszoner.

Inaktivera tillgänglighetszoner

Azure-portalen stöder inte inaktivering av tillgänglighetszoner. Om du vill inaktivera tillgänglighetszoner använder du någon av följande metoder:

Migrering av tillgänglighetszon

När du skapar tillgänglighetszoner i en region som stöder dem aktiveras tillgänglighetszoner automatiskt. Om du vill lära dig hur du flyttar din händelsehubb till en ny region som stöder tillgänglighetszoner kan du läsa Flytta händelsehubbar till en annan region.

Prissättning

Behöver information. Några prisöverväganden när du använder tillgänglighetszoner?

Haveriberedskap och affärskontinuitet mellan 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.

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.

Det finns två funktioner som ger geo-haveriberedskap i Azure Event Hubs.

  • Geo-haveriberedskap (Metadata DR), som bara tillhandahåller replikering av endast metadata.

    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.

    Detaljerad information, samt exempel och ytterligare dokumentation, om geo-haveriberedskap i Event Hubs finns i Azure Event Hubs – Geo-haveriberedskap.

  • Geo-replikering (offentlig förhandsversion), som ger replikering av både metadata och data, replikerar konfigurationsinformation och alla data från ett primärt namnområde till ett eller flera sekundära namnområden. När en redundansväxling utförs blir den valda sekundären den primära och den tidigare primära blir sekundär. Användare kan utföra en redundansväxling tillbaka till den ursprungliga primära när så önskas.

    Detaljerad information, samt exempel och ytterligare dokumentation, om geo-replikering i Event Hubs finns i Geo-replikering .

Nästa steg