Azure Service Bus geo-haveriberedskap

Motståndskraft mot utstådd avbrott i databehandlingsresurser är ett krav för många företag och i vissa fall även av branschföreskrifter.

Azure Service Bus sprider redan risken för katastrofala fel på enskilda datorer eller till och med fullständiga rack över kluster som sträcker sig över flera feldomäner i ett datacenter och implementerar transparenta mekanismer för felidentifiering och redundans så att tjänsten fortsätter att fungera inom de garanterade servicenivåerna och vanligtvis utan märkbara avbrott när sådana fel inträffar. Om ett Service Bus-namnområde har skapats med det aktiverade alternativet för tillgänglighetszoner spridsrisken för avbrott ytterligare över tre fysiskt avgränsade anläggningar och tjänsten har tillräckligt med kapacitetsreserver för att omedelbart hantera den fullständiga, katastrofala förlusten av hela anläggningen.

Den helt aktiva Azure Service Bus-klustermodellen med stöd för tillgänglighetszoner är överlägset alla lokala produkter för meddelandekoordinatorer vad gäller motståndskraft mot maskinvarufel och till och med oåterkallelig förlust av hela datacenter. Det kan dock finnas allvarliga situationer med omfattande fysisk destruktion som inte ens dessa åtgärder kan skydda sig mot tillräckligt.

Funktionen Service Bus geo-haveriberedskap är utformad för att göra det enklare att återställa efter en katastrof av den här storleken och avbryta en misslyckad Azure-region för gott och utan att behöva ändra dina programkonfigurationer. Att lämna 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.

Med Geo-Disaster-återställningsfunktionen kan du säkerställa 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 att du när som helst kan initiera en redundans för en gång. Redundansflyttningen kommer att återreparera det valda aliasnamnet för namnområdet till det sekundära namnområdet och sedan bryta parkopplingen. Redundansen är nästan omedelbar när den har initierats.

Avbrott och katastrofer

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

Ett avbrott är den tillfälliga otillgängligheten i Azure Service Bus och kan påverka vissa komponenter i tjänsten, till exempel ett meddelandearkiv eller 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 eller kanske inte blir tillgängligt igen, eller kan vara nere på flera 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 ske någon dataförlust och meddelanden kan återställas när datacentret har återställts.

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 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 metadata för haveriberedskap och förlitar sig på primära och sekundära namnområden för haveriberedskap. Funktionen geo-haveriberedskap är endast tillgänglig för Premium SKU. 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: Namnet på en konfiguration för haveriberedskap som du har ställt in. Aliaset tillhandahåller en enda stabil FQDN-anslutningssträng (fullständigt kvalificerat domännamn). Program använder den här aliasanslutningssträngen för att ansluta till ett namnområde. Med ett alias säkerställer du att anslutningssträngen inte ändras när redundansen utlöses.

• Primärt/sekundärt namnområde: De namnrymder 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 sömlöst acceptera meddelanden utan ändringar i programkoden eller anslutningssträngen. 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.

Installation

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ängar. Endast nya namnrymder kan läggas till i redundanskopplingen.

1. Skapa det primära namnområdet.

2. Skapa det sekundära namnområdet i en annan region. Det här är valfritt. Du kan skapa den sekundära namnrymden när du skapar parkopplingen i nästa steg.

3. I Azure Portal 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. På sidan Initiera parkoppling följer du dessa steg:

   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 Service Bus Geo-DR-alias som du ser i följande bild. Du kan också gå 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ängen för aliaset. Använd den här anslutningssträngen i stället för att använda anslutningssträngen direkt till det primära/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. Dela upp parkopplingen mellan primära och sekundära namnrymder. Välj Bryt parkoppling i verktygsfältet.
   2. Redundans till den sekundära namnrymden manuellt.

      1. Välj Redundans i verktygsfältet.

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

      3. Aktivera alternativet Valv redundans för att på ett säkert sätt växla över till det sekundära namnområdet. Den här funktionen ser till att väntande replikeringar av geo-dr slutförs innan du växlar över till den sekundära.

      4. Välj sedan Redundans.

         

         Viktigt

         Om du misslyckas aktiveras det sekundära namnområdet och det primära namnområdet tas bort från den Geo-Disaster Recovery-parkopplingen. Skapa ett annat namnområde för att ha ett nytt återställningspar för geo-haveriberedskap.

9. Slutligen bör du lägga till övervakning för att identifiera om en redundans krävs. I de flesta fall är tjänsten en del av ett stort ekosystem, vilket innebär att automatiska redundanser sällan är möjliga, eftersom redundanser ofta måste utföras i synkronisering med återstående undersystem eller infrastruktur.

Service Bus standard till premium

Om du har migrerat Azure Service Bus Standard-namnområdet till Azure Service Bus Premiummåste du använda det befintliga aliaset (det vill säga din Service Bus Standard-anslutningssträng för namnrymd) för att skapa haveriberedskapskonfigurationen via PS/CLI eller REST API.

Det beror på att din Azure Service Bus Standard-anslutningssträng/DNS-namn blir ett alias för azure-Service Bus Premium namnområdet under migreringen.

Klientprogrammen måste använda det här aliaset (dvs. Anslutningssträngen för Azure Service Bus Standard-namnområdet) för att ansluta till Premium-namnområdet där haveriberedskapsparningen har ställts in.

Om du använder portalen för att konfigurera konfigurationen för haveriberedskap abstraherar 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 insyn för avbrottslösning i Azures stamnät.

När redundansen har utlösts –

1. Aliasanslutningssträngen uppdateras så att den pekar på Premium namnområdet.

2. Klienter (avsändare och mottagare) ansluter automatiskt till den sekundära namnrymden.

3. Den befintliga parkopplingen mellan den primära och sekundära premium-namnrymden är bruten.

När redundansen har initierats –

1. Om ett annat avbrott inträffar vill du kunna redundans igen. Konfigurera därför ytterligare ett passivt namnområde och uppdatera parkopplingen.

2. Hämta meddelanden från den tidigare primära namnrymden när den är tillgänglig igen. Efter det använder du det namnområdet för vanliga meddelanden utanför konfigurationen för geo-återställning eller tar bort det gamla primära namnområdet.

Du kan automatisera redundans med antingen övervakningssystem eller med anpassade övervakningslösningar. Sådan automatisering kräver dock extra planering och arbete, vilket ligger utanför omfånget för den här artikeln.

Hantering

Om du har gjort ett misstag; Om du till exempel har kopplat 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 parkopplade 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 ditt namnområdesnamn som aliasnamn. Se exempelkoden på GitHub här.

Exempel

Exemplen på GitHub visar hur du ställer in och initierar en redundans. De här exemplen demonstrerar följande begrepp:

• Ett .NET-exempel och inställningar som krävs i Azure Active Directory 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 ett alias.
• Steg för att alternativt aktivera geo-haveriberedskap via PowerShell eller CLI.
• Skicka och ta emot från den aktuella primära eller sekundära namnrymden med hjälp av aliaset.

Överväganden

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

1. När du planerar för redundans bör du även ta hänsyn till tidsfaktorn. Om du till exempel förlorar anslutningen i mer än 15 till 20 minuter kan du välja att starta redundansen.

2. Det faktum att inga data replikeras innebär att aktiva sessioner för närvarande inte replikeras. Dessutom kanske dubblettidentifiering och schemalagda meddelanden inte fungerar. Nya sessioner, nya schemalagda meddelanden och nya dubbletter fungerar.

3. Fel i en komplex distribuerad infrastruktur bör repeteras minst en gång.

4. Det kan ta lite tid att synkronisera entiteter, cirka 50–100 entiteter per minut. Prenumerationer och regler räknas också som entiteter.

Tillgänglighetszoner

Den Service Bus Premium SKU:n stöder Tillgänglighetszoner, vilket ger fel isolerade platser inom samma Azure-region. Service Bus hanterar tre kopior av meddelandearkivet (1 primär och 2 sekundär). Service Bus synkroniserar alla tre kopiorna för data- och hanteringsåtgärder. Om den primära kopian misslyckas upphöjs en av de sekundära kopiorna till den primära utan uppfattad avbrottstid. Om programmen ser tillfälliga frånkopplingar Service Bus återförsökslogiken i SDK:n återansluter automatiskt till Service Bus.

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

Du kan aktivera Tillgänglighetszoner endast på nya namnområden med hjälp av Azure Portal. Service Bus stöder inte migrering av befintliga namnområden. Du kan inte inaktivera zonredundans när du har aktivera den i namnområdet.

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

Nya par

Om du försöker skapa en koppling 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.

Befintliga parkopplingar

Om det redan finns en koppling mellan den primära och den sekundära namnrymden misslyckas skapandet av den privata slutpunkten i det primära namnområdet. Lös problemet genom att först skapa en privat slutpunkt i det sekundära namnområdet och sedan skapa en för det primära namnområdet.

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-namnrymder 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 andra namnområden: ServiceBus-Namespace1-Primary, ServiceBus-Namespace2-Secondary. Du måste göra följande:

• På ServiceBus-Namespace1-Primary skapar du två privata slutpunkter som använder undernät från VNET-1 och VNET-2
• På ServiceBus-Namespace2-Secondary skapar 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 redundans kan ske på programnivån oberoende av Service Bus-namnområdet. Beakta följande scenarier:

Endast program redundans: Här finns inte programmet i VNET-1 men flyttas till VNET-2. Eftersom både privata slutpunkter konfigureras på både VNET-1 och VNET-2 för både primära och sekundära namnrymder, fungerar programmet bara.

Service Bus redundans endast för namnrymd: Eftersom båda privata slutpunkterna har konfigurerats på båda virtuella nätverken för både primära och sekundära namnrymder fungerar programmet bara.

Rollbaserad åtkomstkontroll

Azure Active Directory (Azure AD) tilldelningar av rollbaserad åtkomstkontroll (RBAC) 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 referensen för geo-REST API här.
• Kör exemplet på geo-haveriberedskap på GitHub.
• Se exemplet på geo-haveriberedskap som skickar meddelanden till ett alias.

Mer information om Service Bus 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