Dela via

Geo-replikering i Azure Service Bus (förhandsversion)

  • Artikel

Funktionen För Geo-replikering i Service Bus är ett av alternativen för att isolera Azure Service Bus-program mot avbrott och katastrofer, vilket ger replikering av både metadata (entiteter, konfiguration, egenskaper) och data (meddelandedata och meddelandeegenskap/tillståndsändringar).

Kommentar

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

Geo-replikeringsfunktionen säkerställer att metadata och data i ett namnområde kontinuerligt replikeras från en primär region till en eller flera sekundära regioner.

  • Köer, ämnen, prenumerationer, filter.
  • Data som finns i entiteterna.
  • Alla tillståndsändringar och egenskapsändringar som körs mot meddelandena i ett namnområde.
  • Namnområdeskonfiguration.

Kommentar

För närvarande stöds endast en sekundär.

Med den här funktionen kan du när som helst befordra valfri sekundär region till primär. När du befordrar en sekundär återpunkt pekar namnet på namnområdet till den valda sekundära regionen och växlar rollerna mellan den primära och sekundära regionen. Kampanjen är nästan omedelbar när den väl har initierats.

Viktigt!

  • Den här funktionen är för närvarande i offentlig förhandsversion och bör därför inte användas i produktionsscenarier.
  • Regionerna nedan stöds för närvarande i den offentliga förhandsversionen.
USA Europa
Centrala USA EUAP Italien, norra
Spanien, centrala
Norge, östra
  • Den här funktionen är för närvarande tillgänglig på nya namnområden. Om en namnrymd hade den här funktionen aktiverad tidigare kan den inaktiveras (genom att ta bort de sekundära regionerna) och återaktiveras.
  • Följande funktioner stöds för närvarande inte. Vi arbetar kontinuerligt med att ta fler funktioner till den offentliga förhandsversionen och uppdaterar listan med den senaste statusen.
    • Stöd för stora meddelanden.
    • VNET/avancerade nätverksfunktioner (privata slutpunkter, IP-ACL:er, NSP, tjänstslutpunkter).
    • Identiteter (MSI, inaktivera lokal autentisering) och krypteringsinställningar (cmk-kryptering med kundhanterad nyckel) eller BYOK-kryptering (Bring Your Own Key).
    • Autoskalning.
    • Partitionerade namnområden.
    • Skicka händelser till Event Grid.
  • Den här funktionen kan inte användas i kombination med geo-haveriberedskapsfunktionen i Azure Service Bus.

Scenarier

Geo-replikeringsfunktionen kan användas för att implementera olika scenarier, enligt beskrivningen här.

Haveriberedskap

Data och metadata synkroniseras kontinuerligt mellan de primära och sekundära regionerna. Om en region släpar efter eller inte är tillgänglig kan du höja upp en sekundär region som primär. Den här befordran möjliggör oavbruten drift av arbetsbelastningar i den nyligen befordrade regionen. En sådan befordran kan vara nödvändig genom försämring av Service Bus eller andra tjänster i din arbetsbelastning, särskilt om du vill köra de olika komponenterna tillsammans. Beroende på allvarlighetsgraden och vilka tjänster som påverkas kan kampanjen antingen planeras eller tvingas. Vid planerad befordran replikeras meddelanden under flygning innan befordran slutförs, medan detta utförs omedelbart med tvingad befordran.

Regionmigrering

Det finns tillfällen då du vill migrera dina Service Bus-arbetsbelastningar för att köras i en annan region. När Azure till exempel lägger till en ny region som ligger geografiskt närmare din plats, användare eller andra tjänster. Du kanske också vill migrera när de regioner där de flesta av dina arbetsbelastningar körs flyttas. Geo-Replikeringsfunktionen ger också en bra lösning i dessa fall. I det här fallet konfigurerar du geo-replikering på ditt befintliga namnområde med önskad ny region som sekundär region och väntar tills synkroniseringen har slutförts. Nu startar du en planerad kampanj som gör att alla meddelanden under flygning kan replikeras. När befordran är klar kan du nu ta bort den gamla regionen, som nu är den sekundära regionen, och fortsätta köra dina arbetsbelastningar i önskad region.

Grundläggande begrepp

Funktionen Geo-Replication implementerar metadata och datareplikering i en primär-sekundär replikeringsmodell. Vid en viss tidpunkt finns det en enda primär region, som betjänar både producenter och konsumenter. Sekundärfilerna fungerar som aktiva stand-by-regioner, vilket innebär att det inte går att interagera med dessa sekundära regioner. De körs dock i samma konfiguration som den primära regionen, vilket möjliggör snabb upphöjning, vilket innebär att dina arbetsbelastningar omedelbart kan fortsätta köras efter att befordran har slutförts. Geo-replikeringsfunktionen är tillgänglig för Premium-nivån.

Några av de viktigaste aspekterna av geo-replikeringsfunktionen är:

  • Service Bus-tjänster utför fullständigt hanterad replikering av metadata, meddelandedata och meddelandetillstånd och egenskapsändringar mellan regioner som följer replikeringskonsekvensen som konfigurerats i namnområdet.
  • Värdnamn för enskilt namnområde; När konfigurationen av ett geo-replikeringsaktiverat namnområde har slutförts kan användarna använda värdnamnet för namnområdet i klientprogrammet. Värdnamnet beter sig agnostikiskt för de konfigurerade primära och sekundära regionerna och pekar alltid på den primära regionen.
  • När en kund initierar en kampanj pekar värdnamnet på den region som valts som den nya primära regionen. Den gamla primära blir en sekundär region.
  • Det går inte att läsa eller skriva i de sekundära regionerna.
  • Synkrona och asynkrona replikeringslägen, som beskrivs mer här.
  • Kundhanterad befordran från primär till sekundär region, vilket ger fullständigt ägande och synlighet för avbrottsmatchning. Mått är tillgängliga, vilket kan hjälpa dig att automatisera befordran från kundsidan.
  • Sekundära regioner kan läggas till eller tas bort efter kundens gottfinnande.

Replikeringslägen

Det finns två replikeringslägen, synkrona och asynkrona. Det är viktigt att känna till skillnaderna mellan de två lägena.

Asynkron replikering

Med asynkron replikering utförs alla begäranden på den primära, varefter en bekräftelse skickas till klienten. Replikering till de sekundära regionerna sker asynkront. Användare kan konfigurera den maximala tillåtna fördröjningstiden. Fördröjningstiden är tjänstsidans förskjutning mellan den senaste åtgärden i de primära och sekundära regionerna. Om fördröjningen för en aktiv sekundär växer utöver användarkonfigurationen börjar den primära begränsningen av inkommande begäranden.

Synkron replikering

Med synkron replikering replikeras alla begäranden till den sekundära, som måste checka in och bekräfta åtgärden innan den utförs på den primära. Därför publicerar ditt program med den hastighet det tar att publicera, replikera, bekräfta och checka in. Dessutom innebär det också att ditt program är kopplat till tillgängligheten för båda regionerna. Om den sekundära regionen släpar efter eller inte är tillgänglig bekräftas inte meddelanden och bekräftas, och den primära begränsar inkommande begäranden.

Jämförelse av replikeringsläge

Med synkron replikering:

  • Svarstiden är längre på grund av de distribuerade incheckningsåtgärderna.
  • Tillgängligheten är kopplad till tillgängligheten för två regioner.

Å andra sidan ger synkron replikering den största försäkran om att dina data är säkra. Om du har synkron replikering checkar den in i alla regioner som du har konfigurerat för geo-replikering, vilket ger bästa möjliga datasäkerhet.

Med asynkron replikering:

  • Svarstiden påverkas minimalt.
  • Förlusten av en sekundär region påverkar inte tillgängligheten omedelbart. Tillgängligheten påverkas dock när den konfigurerade maximala replikeringsfördröjningen har nåtts.

Därför har den inte den absoluta garantin för att alla regioner har data innan vi checkar in dem som synkron replikering gör, och dataförlust eller duplicering kan inträffa. Men eftersom du inte längre påverkas omedelbart när en enskild region släpar efter eller inte är tillgänglig förbättras programtillgängligheten, förutom att du har en lägre svarstid.

Kapacitet Synkron replikering Asynkron replikering
Svarstid Längre på grund av distribuerade incheckningsåtgärder Minimal påverkan
Tillgänglighet Kopplat till tillgängligheten för sekundära regioner Förlust av en sekundär region påverkar inte omedelbart tillgängligheten
Datakonsekvens Data som alltid checkas in i båda regionerna före bekräftelse Data som checkas in i primär endast före bekräftelse
RPO (mål för återställningspunkt) RPO 0, ingen dataförlust vid befordran RPO > 0, möjlig dataförlust vid befordran

Replikeringsläget kan ändras när geo-replikering har konfigurerats. Du kan gå från synkron till asynkron eller från asynkron till synkron. Om du går från asynkron till synkron konfigureras din sekundära som synkron när fördröjningen når noll. Om du kör med en kontinuerlig fördröjning av någon anledning kan du behöva pausa dina utgivare för att fördröjningen ska nå noll och ditt läge för att kunna växla till synkront. Orsakerna till att synkron replikering är aktiverad, i stället för asynkron replikering, är knutna till vikten av data, specifika affärsbehov eller efterlevnadsskäl snarare än tillgängligheten för ditt program.

Kommentar

Om en sekundär region släpar efter eller blir otillgänglig kan programmet inte längre replikera till den här regionen och börjar begränsa när replikeringsfördröjningen har nåtts. Om du vill fortsätta använda namnområdet på den primära platsen kan den drabbade sekundära regionen tas bort. Om inga fler sekundära regioner har konfigurerats fortsätter namnområdet utan geo-replikering aktiverat. Det går att lägga till ytterligare sekundära regioner när som helst.

Val av sekundär region

Om du vill aktivera geo-replikeringsfunktionen måste du använda primära och sekundära regioner där funktionen är aktiverad. Funktionen Geo-Replication är beroende av att kunna replikera publicerade meddelanden från den primära till de sekundära regionerna. Om den sekundära regionen finns på en annan kontinent har detta en stor inverkan på replikeringsfördröjningen från den primära till den sekundära regionen. Om du använder geo-replikering av tillgänglighetsskäl är det bäst att sekundära regioner finns på minst samma kontinent där det är möjligt. Om du vill få en bättre förståelse för svarstiden som orsakas av geografiskt avstånd kan du lära dig mer om svarstidsstatistik för Azure-nätverkets svarstid.

Geo-replikeringshantering

Funktionen Geo-Replication gör det möjligt för kunder att konfigurera en sekundär region som de kan replikera metadata och data mot. Därför kan kunder utföra följande hanteringsuppgifter:

  • Konfigurera geo-replikering; Sekundära regioner kan konfigureras på alla nya eller befintliga namnområden i en region med funktionen Geo-Replication aktiverad.

    Kommentar

    För närvarande stöds endast nya namnområden i den offentliga förhandsversionen.

  • Konfigurera replikeringskonsekvensen. Synkron och asynkron replikering anges när geo-replikering har konfigurerats men kan också växlas efteråt.
  • Utlösarhöjning; Alla kampanjer är kundinitierade.
  • Ta bort en sekundär; Om du när som helst vill ta bort en sekundär region kan du göra det när data i den sekundära regionen har tagits bort.

Ställ in

Med Azure-portalen

Följande avsnitt är en översikt för att konfigurera geo-replikeringsfunktionen på ett nytt namnområde via Azure-portalen.

Kommentar

Den här upplevelsen kan ändras under den offentliga förhandsversionen. Vi uppdaterar det här dokumentet i enlighet med detta.

  1. Skapa ett nytt premiumnivånamnområde.
  2. Markera kryssrutan Aktivera geo-replikering under avsnittet Replikering (förhandsversion).
  3. Klicka på knappen Lägg till sekundär region och välj en region.
  4. Markera kryssrutan Synkron replikering eller ange ett värde för värdet asynkron replikering – maximal replikeringsfördröjning i sekunder. Skärmbild som visar funktionen Skapa namnområde med geo-replikering aktiverat.

Använda Bicep-mall

Om du vill skapa ett namnområde med geo-replikeringsfunktionen aktiverad lägger du till avsnittet geoDataReplication-egenskaper .

param serviceBusName string
param primaryLocation string
param secondaryLocation string
param maxReplicationLagInSeconds int

resource sb 'Microsoft.ServiceBus/namespaces@2023-01-01-preview' = {
  name: serviceBusName
  location: primaryLocation
  sku: {
    name: 'Premium'
    tier: 'Premium'
    capacity: 1
  }
  properties: {
    geoDataReplication: {
      maxReplicationLagDurationInSeconds: maxReplicationLagInSeconds
      locations: [
        {
          locationName: primaryLocation
          roleType: 'Primary'
        }
        {
          locationName: secondaryLocation
          roleType: 'Secondary'
        }
      ]
    }
  }
}

Hantering

När du har skapat ett namnområde med geo-replikeringsfunktionen aktiverad kan du hantera funktionen från bladet Replikering (förhandsversion).

Växla replikeringsläge

Om du vill växla mellan replikeringslägen eller uppdatera den maximala replikeringsfördröjningen klickar du på länken under Replikeringskonsekvens och klickar på kryssrutan för att aktivera/inaktivera synkron replikering eller uppdatera värdet i textrutan för att ändra den asynkrona maximala replikeringsfördröjningen. Skärmbild som visar hur du uppdaterar konfigurationen av geo-replikeringsfunktionen.

Ta bort sekundär region

Om du vill ta bort en sekundär region klickar du på ...-ellips bredvid regionen och klicka på Ta bort. Om du vill ta bort regionen följer du anvisningarna på popup-bladet. Skärmbild som visar hur du tar bort en sekundär region.

Befordransflöde

En befordran 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 du väljer Planerad befordran väntar tjänsten med att komma ikapp replikeringsfördröjningen innan du påbörjar kampanjen. Å andra sidan initierar tjänsten omedelbart befordran när du väljer Tvingad befordran. Namnområdet placeras i skrivskyddat läge från den tidpunkt då en kampanj begärs, tills kampanjen har slutförts. Det är möjligt att göra en tvångsbefordran när som helst efter att en planerad befordran har initierats. Detta ger användaren kontroll för att påskynda befordran när en planerad redundans tar längre tid än önskat.

Viktigt!

När du använder tvångshöjning kan alla data som inte har replikerats gå förlorade.

När kampanjen har initierats:

  1. Värdnamnet uppdateras så att det pekar på den sekundära regionen, vilket kan ta upp till några minuter.

    Kommentar

    Du kan kontrollera den aktuella primära regionen genom att initiera ett ping-kommando: pinga ditt-namnområde-fullständigt kvalificerade-namn

  2. Klienter återansluter automatiskt till den sekundära regionen.

Skärmbild av portalen som visar flödet av befordran från primär till sekundär region.

Du kan automatisera befordran 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.

Med Azure-portalen

I portalen klickar du på ikonen Höj upp och följer anvisningarna på popup-bladet för att ta bort regionen.

Screeshot som visar flödet för att höja upp sekundär region.

Använda Azure CLI

Kör Azure CLI-kommandot för att initiera befordran. Egenskapen Force är valfri och är som standard false.

az rest --method post --url https://management.azure.com/subscriptions/<subscriptionId>/resourceGroups/<resourceGroup>/providers/Microsoft.ServiceBus/namespaces/<namespaceName>/failover?api-version=2023-01-01-preview --body "{'properties': {'PrimaryLocation': '<newPrimaryocation>', 'api-version':'2023-01-01-preview', 'Force':'false'}}"

Övervaka datareplikering

Användare kan övervaka replikeringsjobbets förlopp genom att övervaka replikeringsfördröjningsmåttet i Log Analytics.

  • Aktivera måttloggar i Service Bus-namnområdet enligt beskrivningen i Övervaka Azure Service Bus.
  • När Måttloggar har aktiverats måste du skapa och använda data från namnområdet i några minuter innan du börjar se loggarna.
  • Om du vill visa måttloggar går du till avsnittet Övervakning i Service Bus och klickar på bladet Loggar . Du kan använda följande fråga för att hitta replikeringsfördröjningen (i sekunder) mellan de primära och sekundära regionerna.
AzureMetrics
| where TimeGenerated > ago(1h)
| where MetricName == "ReplicationLagDuration"

Publicera data

Publiceringsprogram kan publicera data till geo-replikerade namnområden via namnområdets värdnamn för det geo-replikeringsaktiverade namnområdet. Publiceringsmetoden är densamma som fallet med icke-geo-replikering och inga ändringar i dataplanets SDK:er eller klientprogram krävs. Publicering kanske inte är tillgänglig under följande omständigheter:

  • När du har begärt befordran av en sekundär region avvisar den befintliga primära regionen alla nya meddelanden som publiceras till Service Bus tills befordran har slutförts.
  • När replikeringsfördröjningen mellan primära och sekundära regioner når den maximala replikeringsfördröjningen kan arbetsbelastningen för utgivarens ingress begränsas.

Publisher-program kan inte komma åt några namnområden direkt i de sekundära regionerna.

Använda data

Användning av program kan använda data med namnområdets värdnamn för ett namnområde med geo-replikeringsfunktionen aktiverad. Konsumentåtgärder stöds inte från det ögonblick då befordran initieras förrän befordran har slutförts.

Att tänka på

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

  • I din upphöjningsplanering bör du också tänka på tidsfaktorn. Om du till exempel förlorar anslutningen i mer än 15 till 20 minuter kan du välja att starta upphöjningen.
  • Att främja en komplex distribuerad infrastruktur bör repeteras minst en gång.

Prissättning

Premium-nivån för Service Bus prissätts per meddelandeenhet. Med geo-replikeringsfunktionen körs sekundära regioner på samma antal MU:er som den primära regionen, och prissättningen beräknas över det totala antalet processorer. Dessutom debiteras en avgift baserat på den publicerade bandbredden gånger antalet sekundära regioner. Under den tidiga offentliga förhandsversionen avstår du från den här avgiften.

Nästa steg

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