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

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

Ett avbrott definieras som tillfällig otillgänglighet för Azure Service Bus. Avbrott kan påverka vissa komponenter i Service Bus, till exempel ett meddelandearkiv eller till och med hela datacentret. 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.

En katastrof definieras som permanent förlust av en Service Bus-skalningsenhet eller ett datacenter. Datacentret kanske inte blir tillgängligt igen. Vanligtvis orsakar en katastrof förlust av vissa eller alla meddelanden eller andra data. Exempel på katastrofer är brand, översvämningar eller jordbävning.

Skydd mot avbrott och katastrofer – premiumnivå

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

Geo-haveriberedskap

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

Tillgänglighetszoner

Service Bus Premium-nivån stöder 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 för premiumnivån är endast tillgängligt i Azure-regioner där tillgänglighetszoner finns.

När du skapar ett premiumnivånamnområde via portalen aktiveras stödet för tillgänglighetszoner (om det är tillgängligt i den valda regionen) automatiskt för namnområdet. När du skapar ett premiumnivånamnområde via andra mekanismer, till exempel ARM/Bicep-mallar, CLI eller PowerShell, måste egenskapen zoneRedundant uttryckligen anges för att true aktivera tillgänglighetszoner (om den är tillgänglig i den valda regionen). 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.

Skydd mot avbrott och katastrofer – standardnivå

För att uppnå motståndskraft mot datacenterstopp när du använder standardprisnivån för meddelanden har Service Bus stöd för två metoder: aktiv och 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.

Exemplet [geo-replikering med Service Bus-standardnivån][Geo-replikering med Service Bus Standard Tier] visar aktiv replikering av meddelandeentiteter.

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. I händelse av en katastrof får mottagaren aldrig 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: