Dela via

Metodtips för isolering av program mot Service Bus-avbrott och katastrofer

  • Artikel

Verksamhetskritiska program måste fungera kontinuerligt, även om det finns oplanerade avbrott eller katastrofer. 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. Den här artikeln beskriver tekniker som du kan använda för att skydda Service Bus-program mot ett potentiellt driftstopp eller haveri.

Azure Service Bus sprider redan risken för katastrofala fel på enskilda datorer eller till och med kompletta rack över kluster som omfattar flera feldomäner i ett datacenter och implementerar transparenta mekanismer för felidentifiering och redundans, så att tjänsten fortsätter att fungera på säkra servicenivåer och vanligtvis utan märkbara avbrott när sådana fel inträffar.

Dessutom sprids avbrottsrisken ytterligare över tre fysiskt avgränsade anläggningar (tillgänglighetszoner) och tjänsten har tillräckligt med kapacitetsreserver för att omedelbart hantera den fullständiga, katastrofala förlusten av ett datacenter. Den helt aktiva Azure Service Bus-klustermodellen i en feldomän tillsammans med stöd för tillgänglighetszonen är överlägsen alla lokala meddelandekoordinatorprodukter när det gäller återhämtning mot allvarliga maskinvarufel och till och med katastrofal förlust av hela datacenteranläggningar. Ändå kan det finnas allvarliga situationer med utbredd fysisk förstörelse som inte ens dessa åtgärder kan försvara sig tillräckligt mot.

Funktionerna För geo-haveriberedskap och geo-replikering i Service Bus är utformade för att göra det enklare att återställa från en katastrof av den här storleken och överge en misslyckad Azure-region för gott och utan att behöva ändra dina programkonfigurationer.

Avbrott och katastrofer

Det är viktigt att notera skillnaden mellan "avbrott" och "katastrofer".

Ett avbrott är den tillfälliga otillgängligheten för Azure Service Bus 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 Service Bus tillgängligt igen. Normalt orsakar ett avbrott inte förlust av meddelanden eller andra data. Ett exempel på ett komponentfel är att ett visst meddelandearkiv inte är tillgängligt. Ett exempel på ett datacenteromfattande avbrott är ett strömavbrott i datacentret eller en felaktig nätverksväxel för datacenter. Ett avbrott kan pågå från några minuter till några dagar. 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 Service Bus-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 säkerhetskopieras.

Skydd mot avbrott och katastrofer

Det finns två funktioner som tillhandahåller Geo-Disaster Recovery i Azure Service Bus för Premium-nivån. Först finns det Geo-Disaster Recovery (Metadata DR) som tillhandahåller replikering av metadata (entiteter, konfiguration, egenskaper). För det andra finns geo-replikering, som för närvarande är i offentlig förhandsversion, vilket ger replikering av både metadata och data (meddelandedata och meddelandeegenskap/tillståndsändringar) i sig. Ingen av funktionerna för geo-haveriberedskap bör förväxlas med tillgänglighetszoner. Oavsett om det är Metadata DR eller Geo-replikering ger båda geo-grafiska återställningsfunktionerna motståndskraft mellan Azure-regioner som USA, östra och USA, västra.

Tillgänglighetszoner är tillgängliga på alla Service Bus-nivåer och stöd ger motståndskraft inom en specifik geografisk region, till exempel USA, östra. En detaljerad beskrivning av haveriberedskap i Microsoft Azure finns i den här artikeln.

Koncept för hög tillgänglighet och haveriberedskap är inbyggda direkt på Azure Service Bus Premium-nivån , både inom samma region (via tillgänglighetszoner) och i olika regioner (via Geo-Disaster Recovery och Geo-Replication).

Alternativ för geo-haveriberedskap

Geo-haveriberedskap

Service Bus Premium-nivån stöder Geo-Disaster Recovery på namnområdesnivå. Mer information finns i Geo-haveriberedskap för Azure Service Bus. Geo-Haveriberedskapsfunktionen, som endast är tillgänglig för Premium-nivån , implementerar haveriberedskap för metadata och förlitar sig på primära och sekundära namnområden. Med Geo-Disaster Recovery replikeras endast metadata för entiteter mellan primära och sekundära namnområden.

Geo-replikering

Service Bus Premium-nivån har också stöd för geo-replikering på namnområdesnivå. Mer information finns i Azure Service Bus Geo-Replication (offentlig förhandsversion). Geo-replikeringsfunktionen, som endast är tillgänglig för Premium-nivån och för närvarande i offentlig förhandsversion, implementerar metadata och haveriberedskap och förlitar sig på primära och sekundära regioner. Med geo-replikering replikeras både metadata och data för entiteter mellan primära och sekundära regioner.

Funktionsskillnader på hög nivå

Funktionen Geo-Disaster Recovery (Metadata DR) replikerar metadata för ett namnområde från ett primärt namnområde till ett sekundärt namnområde. Den stöder en engångsredundans till den sekundära regionen. Under den kundinitierade redundansväxlingen återpointas aliasnamnet för namnområdet till det sekundära namnområdet och sedan bryts parkopplingen. Inga data replikeras förutom metadata och inte heller replikeras RBAC-tilldelningar.

Geo-replikeringsfunktionen replikerar metadata och alla data från en primär region till en eller flera sekundära regioner. När en redundans utförs av kunden blir den valda sekundära den primära och den tidigare primära blir en sekundär. Användare kan utföra en redundansväxling tillbaka till den ursprungliga primära när så önskas.

Tillgänglighetszoner

Alla Service Bus-nivåer har stöd för tillgänglighetszoner som tillhandahåller felisolerade platser i samma Azure-region. Service Bus hanterar tre kopior av meddelandearkivet (1 primär och 2 sekundär). Service Bus håller alla tre kopiorna synkroniserade för data- och hanteringsåtgärder. Om den primära kopian misslyckas befordras en av de sekundära kopiorna till primär utan upplevd stilleståndstid. Om program ser tillfälliga frånkopplingar från Service Bus återansluts återförsökslogiken i SDK:n automatiskt till Service Bus.

När du använder tillgänglighetszoner replikeras både metadata och data (meddelanden) mellan datacenter i tillgänglighetszonen.

Kommentar

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

När du skapar ett namnområde aktiveras stödet för tillgänglighetszoner (om det är tillgängligt i den valda regionen) automatiskt för namnområdet. Det finns ingen extra kostnad för att använda den här funktionen och du kan inte inaktivera eller aktivera den här funktionen när namnområdet har skapats.

Kommentar

Tidigare var det nödvändigt att ange egenskapen zoneRedundant till true för att aktivera tillgänglighetszoner, men det här beteendet har ändrats för att aktivera tillgänglighetszoner som standard. Befintliga namnområden migreras också till tillgänglighetszoner och egenskapen zoneRedundant är inaktuell. Egenskapen zoneRedundant kan fortfarande visas som false, även när tillgänglighetszoner har aktiverats.

Skydd mot katastrofer – standardnivå

För att uppnå motståndskraft mot katastrofer med Service Bus Standard-nivån kan du använda aktiv eller passiv replikering. För varje metod, om en viss kö eller ett visst ämne måste vara tillgängligt i närvaro av ett datacenterfel, kan du skapa den i båda namnrymderna. Båda entiteterna kan ha samma namn. En primär kö kan till exempel nås under contosoPrimary.servicebus.windows.net/myQueue, medan dess sekundära motsvarighet kan nås under contosoSecondary.servicebus.windows.net/myQueue.

Kommentar

Konfigurationen av aktiv replikering och passiv replikering är allmänna lösningar och inte specifika funktioner i Service Bus. Replikeringslogik (skicka till 2 olika namnområden) finns i avsändarprogrammen och mottagaren måste ha anpassad logik för dubblettidentifiering.

Om programmet inte kräver permanent kommunikation mellan avsändare och mottagare kan programmet implementera en varaktig kö på klientsidan för att förhindra meddelandeförlust och skydda avsändaren från tillfälliga Service Bus-fel.

Aktiv replikering

Aktiv replikering använder entiteter i båda namnrymderna för varje åtgärd. Alla klienter som skickar ett meddelande skickar två kopior av samma meddelande. Den första kopian skickas till den primära entiteten (till exempel contosoPrimary.servicebus.windows.net/sales) och den andra kopian av meddelandet skickas till den sekundära entiteten (till exempel contosoSecondary.servicebus.windows.net/sales).

En klient tar emot meddelanden från båda köerna. Mottagaren bearbetar den första kopian av ett meddelande och den andra kopian ignoreras. För att förhindra duplicerade meddelanden måste avsändaren tagga varje meddelande med en unik identifierare. Båda kopiorna av meddelandet måste taggas med samma identifierare. Du kan använda egenskaperna ServiceBusMessage.MessageId eller ServiceBusMessage.Subject eller en anpassad egenskap för att tagga meddelandet. Mottagaren måste ha en lista över meddelanden som den redan har tagit emot.

Kommentar

Den aktiva replikeringsmetoden fördubblar antalet åtgärder, därför kan den här metoden leda till högre kostnader.

Passiv replikering

I det felfria fallet använder passiv replikering endast en av de två meddelandeentiteterna. En klient skickar meddelandet till den aktiva entiteten. Om åtgärden på den aktiva entiteten misslyckas med en felkod som anger att det datacenter som är värd för den aktiva entiteten kanske inte är tillgängligt, skickar klienten en kopia av meddelandet till entiteten för säkerhetskopiering. Då byter de aktiva entiteterna och säkerhetskopieringsentiteterna roller. Den sändande klienten anser att den gamla aktiva entiteten är den nya säkerhetskopieringsentiteten, och den gamla säkerhetskopieringsentiteten är den nya aktiva entiteten. Om båda sändningsåtgärderna misslyckas förblir rollerna för de två entiteterna oförändrade och ett fel returneras.

En klient tar emot meddelanden från båda köerna. Eftersom det finns en chans att mottagaren tar emot två kopior av samma meddelande måste mottagaren utelämna duplicerade meddelanden. Du kan utelämna dubbletter på samma sätt som beskrivs för aktiv replikering.

I allmänhet är passiv replikering mer ekonomisk än aktiv replikering eftersom det i de flesta fall bara utförs en åtgärd. Svarstid, dataflöde och monetär kostnad är identiska med det icke-replikerade scenariot.

När du använder passiv replikering kan meddelanden gå förlorade eller tas emot två gånger i följande scenarier:

  • Fördröjning eller förlust av meddelanden: Anta att avsändaren har skickat ett meddelande m1 till den primära kön och sedan blir kön otillgänglig innan mottagaren tar emot m1. Avsändaren skickar ett efterföljande meddelande m2 till den sekundära kön. Om den primära kön är tillfälligt otillgänglig tar mottagaren emot m1 när kön blir tillgänglig igen. När en katastrof inträffar kanske mottagaren aldrig får m1.
  • Duplicerad mottagning: Anta att avsändaren skickar ett meddelande m till den primära kön. Service Bus bearbetar m men kan inte skicka ett svar. Efter tidsgränsen för sändningsåtgärden skickar avsändaren en identisk kopia av m till den sekundära kön. Om mottagaren kan ta emot den första kopian av m innan den primära kön blir otillgänglig tar mottagaren emot båda kopiorna av m ungefär samtidigt. Om mottagaren inte kan ta emot den första kopian av m innan den primära kön blir otillgänglig tar mottagaren först bara emot den andra kopian av m, men får sedan en andra kopia av m när den primära kön blir tillgänglig.

Azure Messaging Replication Tasks med .NET Core-exemplet visar replikering av meddelanden mellan namnområden.

Nästa steg

Mer information om haveriberedskap finns i följande artiklar: