Geo-haveriberedskap för Azure Service Bus

Funktionen Geo-Haveriberedskap i Service Bus är ett av alternativen för att isolera Azure Service Bus-program mot avbrott och katastrofer, och syftar främst till att hjälpa till att bevara integriteten i den sammansatta programkonfigurationen.

Kommentar

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

Geo-Haveriberedskapsfunktionen säkerställer att hela konfigurationen av ett namnområde (entiteter, konfiguration, egenskaper) kontinuerligt replikeras från ett primärt namnområde till ett sekundärt namnområde som det är kopplat till, och det gör att du kan initiera en redundansväxling endast en gång 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ö, som erbjuds i geo-replikeringsfunktionen (offentlig förhandsversion).
• 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
  • Azure Event Grid-prenumerationer
• 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 kommer den senaste åtkomststatusen, som inte är en del av metadata, inte att vara 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-Disaster Recovery-funktionsuppsättningen , utan använda funktionen Geo-Replikering eller följa 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-Haveriberedskapsfunktionen är endast tillgänglig för Premium-nivån . Du behöver inte göra några niska veze ä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) niska veze. Program använder det här aliaset niska veze för att ansluta till ett namnområde. Om du använder ett alias ser du till att niska veze ä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 niska veze ä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 niska veze. 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-Recovery 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-haveriberedskapspareringen.

   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-Recovery 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 det primära niska veze för aliaset. Använd den här niska veze i stället för att använda niska veze 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 Säker redundans 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-Disaster Recovery-replikering slutförs innan du växlar över till den sekundära. Alternativt väntar inte tvingad eller manuell redundans tills väntande replikering har slutförts 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-Disaster Recovery-par.

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 niska veze) för att skapa konfigurationen för haveriberedskap via PS/CLI eller REST API.

Det beror på att ditt Azure Service Bus-standardnamnområde under migreringen niska veze/DNS-namnet 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 niska veze) för att ansluta till premiumnamnområdet där haveriberedskapsparingen 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 niska veze 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 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.

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.

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