Geo-katastrofåterställning för Azure Service Bus

Du kan använda funktionen Service Bus Geo-Disaster Recovery för att isolera Azure Service Bus-program mot avbrott och katastrofer. Det hjälper till att bevara integriteten i den sammansatta programkonfigurationen.

Anteckning

Den här funktionen är tillgänglig för Premium-nivån för Azure Service Bus.

Funktionen Geo-Disaster Recovery replikerar kontinuerligt hela konfigurationen av ett namnområde (entiteter, konfiguration, egenskaper) från ett primärt namnområde till ett sekundärt parkopplat namnområde. Du kan när som helst initiera en engångsöverflyttning från den primära till den sekundära. Failover-åtgärden omdirigerar det valda aliasnamnet för namnområdet till det sekundära namnområdet och bryter sedan parkopplingen. Växlingen till redundans sker nästan omedelbart när den påbörjas.

Jämförelse med Geo-Replication

Azure Service Bus erbjuder två funktioner för geografisk motståndskraft: Geo-Replication och Geo-Disaster Recovery. Den viktigaste skillnaden är att Geo-Replication replikerar både metadata och data (meddelanden, meddelandetillstånd, egenskapsändringar) medan Geo-Disaster Recovery endast replikerar metadata. För de flesta haveriberedskapsscenarier är Geo-Replication det rekommenderade valet. En detaljerad jämförelse finns i Tillförlitlighet i Azure Service Bus – Motståndskraft mot regionomfattande fel.

Viktiga saker att tänka på

• Den här funktionen möjliggör omedelbar kontinuitet för drift med samma konfiguration, men den replikerar inte meddelandena som finns i köer, ämnesabonnemang, eller dödsbrevs-köer. För att bevara kösemantik kräver en sådan replikering inte bara replikering av meddelandedata utan även varje tillståndsändring i mäklaren. Den här replikeringen erbjuds i funktionenGeo-Replication.
• Rollbaserade åtkomstkontrolltilldelningar (RBAC) från 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
  • Azure Event Grid-prenumerationer
• Det går inte att para ihop ett partitionerat namnområde med ett icke-partitionerat namnområde.
• Om du aktiverar AutoDeleteOnIdle för en entitet kanske entiteten inte finns i det sekundära namnområdet vid redundansövergången. När den sekundära blir primär är 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.

Tips

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-Disaster Recovery-funktionsuppsättningen. Använd i stället funktionenGeo-Replication eller följ replikeringsvägledningen.

Grundläggande begrepp och termer

Funktionen Geo-Disaster Recovery implementerar återställning av metadata och förlitar sig på primära och sekundära namnområden för haveriberedskap. Geo-Katastrofåterställningsfunktionen är bara tillgänglig för Premiumnivån. Du behöver inte göra några ändringar i anslutningssträngen eftersom anslutningen görs via ett alias.

Följande termer används i den här artikeln:

• Alias: Benämningen på en konfiguration för haveriberedskap som du ställde in. Aliaset innehåller ett enda stabilt fullständigt domännamn (FQDN) anslutningssträng. Applikationer använder aliasanslutningssträngen för att ansluta till ett namnområde. Med hjälp av ett alias förblir anslutningssträngen oförändrad när failöver startar.

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

• Failover: Processen att aktivera det sekundära namnområdet.

Inställningar

Följande avsnitt innehåller en översikt över hur du konfigurerar parkoppling mellan namnrymderna.

Skapa eller använd först ett befintligt primärt namnområde och skapa ett nytt sekundärt namnområde. Koppla sedan ihop de två namnrymderna. 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. Du kan bara 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. Gå till ditt primära namnområde i Azure-portalen.

4. Välj Geo-Recovery på den vänstra menyn och välj Initiera parkoppling i verktygsfältet.

   

5. Följ dessa steg när du initierar 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-haveriberedskapspareringen.

   3. Välj Skapa.

      

6. Du bör se sidan Geo-DR-alias för Service Bus som visas i bilden nedan. Du kan också navigera till sidan Geo-DR Alias från den primära namnområdessidan genom att välja Geo-Recovery på den vänstra menyn.

   

7. På sidan Geo-DR Alias väljer du Principer för delad åtkomst i den vänstra menyn för att komma åt aliasets primära anslutningssträng. Använd den här anslutningssträngen i stället för att använda anslutningssträngen direkt till det primära eller sekundära namnområdet. 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. Växla manuellt över till det sekundära namnområdet.

      1. Välj Failover i verktygsfältet.

      2. Bekräfta att du vill växla över till det sekundära namnområdet genom att ange ditt alias.

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

         Anteckning

         • Den säkra failovern ser till att pågående replikeringar för geografisk katastrofåterställning slutförs innan växlingen till den sekundära utförs. Alternativt väntar varken tvingad eller manuell failover på att väntande replikeringar slutförs innan övergång till den sekundära sker.
         • 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 Failover.

         

         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-Disaster Recovery-par.

9. Lägg slutligen till en del övervakning för att identifiera om en redundansväxling krävs. I de flesta fall är tjänsten en del av ett stort ekosystem, så automatiska redundansväxlingar är sällan möjliga, eftersom redundansväxlingar ofta måste utföras i synkronisering med det återstående undersystemet eller infrastrukturen.

Service Bus standard till premiumversion

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

Under migreringen blir din Azure Service Bus-standardnamnområdesanslutningssträng och DNS-namn ett alias för ditt Azure Service Bus Premium-namnområde.

Klientapplikationerna måste använda det här aliaset (standardnamnområdets anslutningssträng för Azure Service Bus) för att ansluta till premiumnamnområdet där parkopplingen för katastrofåterställning konfigurerades.

Om du använder Azure-portalen för att konfigurera konfigurationen för haveriberedskap hanterar portalen den här informationen åt dig.

Redundansflöde

En kund utlöser en redundansväxling manuellt (antingen explicit via ett kommando eller via klientägd affärslogik som utlöser kommandot). Azure utlöser aldrig en redundansväxling. Den här metoden ger kunden fullständigt ägarskap och översikt för avbrottshantering i Azures stamnät.

Efter felövergångsutlösarna -

1. Aliasnamnets anslutningssträng uppdateras så att den 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 växla över till redundans igen. Så konfigurera ett annat sekundärt 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 konfigurationen av Geo-Disaster Recovery eller tar bort det gamla primära namnområdet.

Anteckning

Endast fail-forward semantik stöds. När du initierar en redundansväxling med hjälp av geo-haveriberedskap kan du parkoppla igen med ett nytt namnområde när redundansväxlingen har slutförts. Du kan inte växla tillbaka till den tidigare primära repliken. Dessa semantik kan skilja sig från andra datalager som du är van vid, till exempel Microsoft SQL Server-kluster.

Du kan automatisera redundansväxlingen antingen med hjälp av övervakningssystem eller med hjälp av anpassade övervakningslösningar. Sådan automatisering kräver dock extra planering och arbete, vilket ligger utanför den här artikelns omfång.

Ledning

Om du gör ett misstag, till exempel om du parkopplar fel regioner under den inledande installationen, kan du när som helst avbryta 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 möjliggöra Geo-Disaster Recovery.
• 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 geografisk katastrofåterhämtning 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å

Tänk på följande i den här versionen:

• Tänk på tidsfaktorn i redundansplaneringen. Om du till exempel förlorar anslutningen i mer än 15 till 20 minuter kan du välja att initiera redundansväxlingen.
• Eftersom inga data replikeras replikeras för närvarande inte aktiva sessioner. Dubblettidentifiering och schemalagda meddelanden kanske inte fungerar. Nya sessioner, nya schemalagda meddelanden och nya dubbletter fungerar nu.
• Du bör genomföra en övning för en failover av en komplex distribuerad infrastruktur 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.

Privata slutpunkter

Det här avsnittet innehåller fler överväganden när du använder Geo-Disaster Recovery 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. Använd samma konfigurationer på de primära och sekundära namnrymderna och i virtuella nätverk där du skapar privata slutpunkter.

Anteckning

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

Anteckning

Du kan komma åt det sekundära namnområdet som skrivskyddat, men du kan uppdatera konfigurationerna för privata slutpunkter.

Rekommenderad konfiguration

När du skapar en katastrofåterställningskonfiguration 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 i de virtuella nätverken 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 och VNET-2, och dessa primära och sekundära namnområden: ServiceBus-Namespace1-Primary och ServiceBus-Namespace2-Secondary. Slutför 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 failover: 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 utan problem.

Anteckning

Vägledning om geo-haveriberedskap för ett virtuellt nätverk finns i Virtuellt nätverk – Affärskontinuitet.

Rollbaserad åtkomstkontroll

Rollbaserade åtkomstkontrolltilldelningar (RBAC) från 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-Disaster Recovery här.
• Kör exemplet för geo-katastrofåterställning på GitHub.
• Se Geokatastrofberedskapsexemplet 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
• Hur man använder Service Bus ämnen och prenumerationer
• REST-API