Geo-haveriberedskap för Azure Service Bus

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 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. Ett premiumnamnområde kan ha två eller flera meddelandeenheter och dessa meddelandeenheter är spridda över flera feldomäner i ett datacenter, vilket stöder en helt aktiv Service Bus-klustermodell.

För ett premiumnivånamnområde 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.

Geo-haveriberedskapsfunktionen i Service Bus är utformad 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. Att överge en Azure-region omfattar vanligtvis flera tjänster, och den här funktionen syftar främst till att bevara integriteten i den sammansatta programkonfigurationen. Funktionen är globalt tillgänglig för Service Bus Premium SKU.

Funktionen Geo-Haveriberedskap säkerställer att hela konfigurationen av ett namnområde (köer, ämnen, prenumerationer, filter) 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 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.

Viktiga saker att tänka på

• Funktionen möjliggör omedelbar kontinuitet för åtgärder med samma konfiguration, men replikerar inte meddelandena som finns i köer eller ämnesprenumerationer eller köer med obeställbara meddelanden. För att bevara kösemantik kräver en sådan replikering inte bara replikering av meddelandedata, utan för varje tillståndsändring i asynkron meddelandekö. För de flesta Service Bus-namnområden skulle den nödvändiga replikeringstrafiken vida överskrida programtrafiken och med köer med högt dataflöde replikeras de flesta meddelanden fortfarande till den sekundära medan de redan tas bort från den primära, vilket orsakar onödigt slösaktig trafik. För replikeringsvägar med långa svarstider, som gäller för många parkopplingar som du skulle välja för Geo-haveriberedskap, kan det också vara omöjligt för replikeringstrafiken att hålla jämna steg med programtrafiken på grund av fördröjningsinducerade begränsningseffekter.
• Rollbaserade RBAC-tilldelningar (Microsoft Entra) till Service Bus-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.
• Följande konfigurationer replikeras inte.
  • Konfigurationer av virtuella nätverk
  • Anslutningar med privat slutpunkt
  • Åtkomst till alla nätverk är aktiverad
  • Åtkomst till betrodd tjänst har aktiverats
  • Åtkomst till offentligt nätverk
  • Standardåtgärd för nätverk
  • Identiteter och krypteringsinställningar (kundhanterad nyckelkryptering eller BYOK-kryptering (Bring Your Own Key)
  • Aktivera automatisk skalning
  • Inaktivera lokal autentisering
• Det går inte att parkoppla ett partitionerat namnområde med ett namnområde som inte är partitionerat.
• Om AutoDeleteOnIdle är aktiverat för en entitet kanske entiteten inte finns i det sekundära namnområdet när redundansväxlingen sker. När den sekundära blir primär blir den senaste åtkomststatusen, som inte är en del av metadata, inte tillgänglig för den nya primära och entiteten kan tas bort som en del av AutoDeleteOnIdle rensningen.

Dricks

Om du vill replikera innehållet i köer och ämnesprenumerationer 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.

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 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 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.

Funktionen geo-haveriberedskap i Azure Service Bus ä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 Premium SKU . 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. Om du använder ett alias ser du till att anslutningssträng ändras när redundansväxlingen utlöses.

• Primärt/sekundärt namnområde: De namnområden som motsvarar aliaset. Det primära namnområdet är "aktivt" och tar emot meddelanden (det 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 köer, ämnen och prenumerationer och deras egenskaper för tjänsten som är associerade med namnområdet. Endast entiteter och deras inställningar replikeras automatiskt. Meddelanden replikeras inte.

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

Ställ in

Följande avsnitt är en översikt för att konfigurera parkoppling mellan namnrymderna.

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.

1. Skapa det primära premiumnivånamnområdet.

2. Skapa det sekundära premiumnivå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.

   

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 används ett befintligt namnområde som sekundärt namnområde.

   2. För Alias anger du ett alias för geo-dr-parkopplingen.

   3. Välj sedan Skapa.

      

6. Du bör se sidan För Geo-DR-alias för Service Bus enligt följande bild. Du kan också navigera till sidan Geo-DR Alias från den primära namnområdessidan genom att välja Geo-återställning på den vänstra menyn.

   

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 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. Till en början pekar aliaset på det primära namnområdet.

8. Växla till sidan Översikt . Du kan 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.

      1. Välj Redundans i verktygsfältet.

      2. Bekräfta att du vill redundansväxla till det sekundära namnområdet genom att skriva in ditt alias.

      3. Aktivera alternativet Valv redundansväxling för att på ett säkert sätt redundansväxla till det sekundära namnområdet.

         Kommentar

         • Den säkra redundansväxlingen ser till att väntande Geo-DR-replikering slutförs innan du växlar över till den sekundära. Framtvingad eller manuell redundans väntar inte på att väntande replikering ska slutföras innan du växlar över till den sekundära.
         • För närvarande misslyckas den säkra redundansväxlingen om de primära och sekundära namnrymderna inte finns i samma Azure-prenumeration.

      4. Välj sedan Redundans.

         

         Viktigt!

         Redundansväxling aktiverar det sekundära namnområdet och tar bort det primära namnområdet från Geo-Disaster Recovery-parkopplingen. Skapa ett annat namnområde för att ha ett nytt geo-haveriberedskapspar.

9. 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.

Service Bus standard till premium

Om du har migrerat ditt Azure Service Bus Standard-namnområde till Azure Service Bus Premium måste du använda det befintliga aliaset (dvs. ditt Service Bus Standard-namnområde anslutningssträng) för att skapa konfigurationen för haveriberedskap via PS/CLI eller REST API.

Det beror på att ditt Azure Service Bus-standardnamnområde anslutningssträng/DNS-namnet under migreringen blir ett alias för ditt Azure Service Bus Premium-namnområde.

Klientprogrammen måste använda det här aliaset (dvs. standardnamnområdet i Azure Service Bus anslutningssträng) för att ansluta till premiumnamnområdet där haveriberedskapsparet har konfigurerats.

Om du använder Azure-portalen för att konfigurera konfigurationen för haveriberedskap sammanfattar portalen den här varningen från dig.

Redundansflöde

En redundans utlöses manuellt av kunden (antingen explicit via ett kommando eller via klientägd affärslogik som utlöser kommandot) och aldrig av Azure. Det ger kunden fullständigt ägarskap och synlighet för avbrottsmatchning i Azures stamnät.

När redundansväxlingen har utlösts -

1. Aliaset anslutningssträng uppdateras så att det pekar på det sekundära Premium-namnområdet.

2. Klienter (avsändare och mottagare) ansluter automatiskt till det sekundära namnområdet.

3. Den befintliga parkopplingen mellan primärt och sekundärt premiumnamnområde är bruten.

När redundansväxlingen har initierats -

1. Om ett annat avbrott inträffar vill du kunna redundansväxla igen. Så konfigurera 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.

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.

Hantering

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

Använda befintligt namnområde som alias

Om du har ett scenario där du inte kan ändra anslutningarna för producenter och konsumenter kan du återanvända namnområdets namn som aliasnamn. Se exempelkoden på GitHub här.

Exempel

Exemplen på GitHub visar hur du konfigurerar och initierar en redundansväxling. De här exemplen visar följande begrepp:

• Ett .NET-exempel och inställningar som krävs i Microsoft Entra-ID för att använda Azure Resource Manager med Service Bus, för att konfigurera och aktivera geo-haveriberedskap.
• Steg som krävs för att köra exempelkoden.
• Så här använder du ett befintligt namnområde som alias.
• Steg för att aktivera geo-haveriberedskap via PowerShell eller CLI.
• Skicka och ta emot från det aktuella primära eller sekundära namnområdet med hjälp av aliaset.

Att tänka på

Observera följande saker att tänka på med den här versionen:

• 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 aktiva sessioner för närvarande inte replikeras. Dubblettidentifiering och schemalagda meddelanden kanske inte fungerar. Nya sessioner, nya 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. Prenumerationer och regler räknas också som entiteter.

Tillgänglighetszoner

Service Bus Premium SKU 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 programmen 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

Det Tillgänglighetszoner stödet för Azure Service Bus Premium ä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.

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 Service Bus i allmänhet finns i Integrera Azure Service Bus med Azure Private Link.

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 bara 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 det sekundära namnområdet 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 desamma skickar du en Get queues-begäran 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 misslyckas det med 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 Service Bus måste du skapa privata slutpunkter för både primära och sekundära Service Bus-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: ServiceBus-Namespace1-Primary, ServiceBus-Namespace2-Secondary. Du måste utföra följande steg:

• På ServiceBus-Namespace1-Primaryskapar du två privata slutpunkter som använder undernät från VNET-1 och VNET-2
• På ServiceBus-Namespace2-Secondaryskapar 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 Service Bus-namnområdet. Föreställ dig följande scenarier:

Programbaserad redundans: Här finns inte programmet i VNET-1 utan flyttas 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.

Service Bus-namnområdesbaserad redundans: 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 Service Bus-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

• Se REST API-referensen för geo-haveriberedskap här.
• Kör geo-haveriberedskapsexemplet på GitHub.
• Se geo-haveriberedskapsexemplet som skickar meddelanden till ett alias.

Mer information om Service Bus-meddelanden finns i följande artiklar:

• Service Bus-köer, ämnen och prenumerationer
• Komma igång med Service Bus-köer
• Använd Service Bus ämnen och prenumerationer
• REST-API