Affärskontinuitet och haveriberedskap för Azure Arc-aktiverade SQL Managed Instance
Azure Arc-aktiverade SQL Managed Instance tillhandahåller funktioner för affärskontinuitet och haveriberedskap (BCDR) som hjälper företag att återställa från avbrott och fortsätta arbeta med minimal stilleståndstid.
Den här artikeln innehåller viktiga designöverväganden och rekommendationer för att konfigurera och hantera funktioner för affärskontinuitet som återställning till tidpunkt, hög tillgänglighet och haveriberedskap.
Arkitektur
Följande arkitekturdiagram visar funktionerna för hög tillgänglighet för arc-aktiverade SQL Managed Instance på tjänstnivån Affärskritisk, som stöder redundans med nästan noll driftstopp. Om den primära instansen misslyckas slutar lastbalanseraren att skicka trafik till den instansen. Sedan befordras en av de sekundära instanserna till primär och den nyligen upphöjda instansen börjar ta emot läs- och skrivtrafik från lastbalanseraren. När den misslyckade instansen är online igen läggs den till som en sekundär instans.
Följande arkitekturdiagram visar hur Arc-aktiverade SQL Managed Instance kan distribueras på två separata Kubernetes-kluster på två olika platser för haveriberedskap.
Följande arkitekturdiagram visar hur Arc-aktiverade SQL Managed Instance svarar när en haveriberedskapsredundans initieras.
Designöverväganden
Om du vill utvärdera effekten av Azure Arc-aktiverade SQL Managed Instance på din övergripande BCDR-modell läser du BCDR-rekommendationerna för landningszoner i Affärskontinuitet och haveriberedskap. Observera att fokus för affärskontinuitet och haveriberedskap endast ligger på designrekommendationer för affärskontinuitet, men den höga tillgängligheten och återhämtningsförmågan för din instans beror också på tillgängligheten för den underliggande Kubernetes-infrastrukturen.
Återställning från tidpunkt
Definiera dina mål för mål för återställningspunkt (RPO) och mål för återställningstid (RTO).
Fastställ hur länge du vill behålla och återställa dina säkerhetskopior inom de kvarhållningsgränser som stöds.
Överväg konsekvenserna för lagringen och kostnaden för att öka kvarhållningsperioden för dina säkerhetskopior. Standardkvarhållningen är sju dagar. Med den här varaktigheten kan du återställa i upp till sju dagar och du får en fullständig säkerhetskopia, en daglig differentiell och säkerhetskopior av transaktionsloggar ungefär var femte minut.
Överväg vilken lagringsklass som ska användas för den beständiga volymen för säkerhetskopior. Vägledning finns i Lagringsområden för Azure Arc-aktiverade SQL Managed Instance.
Överväg storleken på den beständiga volymen för säkerhetskopior i kontexten för den förväntade datastorleken och den konfigurerade kvarhållningsperioden.
Metodtips för lagring finns i Lagringsområden för Azure Arc-aktiverade SQL Managed Instance.
Säkerhetskopior utförs alltid på den primära repliken. Överväg prestandaeffekterna av säkerhetskopierings- och återställningsprocesserna när du identifierar de resurser som allokeras till din instans.
Ta hänsyn till att återställningar till tidpunkt av en databas inte kan skriva över en befintlig databas. De kan dock återställa data till en ny databas på samma instans.
Överväg de ytterligare steg som krävs för att återställa databasen fullständigt om programmet är online under återställningsprocessen.
Överväg de extra steg som krävs för att återställa en databas till en instans med flera repliker, enligt beskrivningen i Återställa en databas till en instans med flera repliker.
Fastställ de verktyg som databasadministratörer använder för att konfigurera och återställa säkerhetskopior. Mer information finns i Ansluta till Azure Arc-aktiverade SQL Managed Instance.
Hög tillgänglighet
Granska tillgänglighetskraven för din arbetsbelastning och bestäm vilken tjänstnivå som passar bäst för distributionen av Arc-aktiverade SQL Managed Instance:
- På tjänstnivån Generell användning finns det en enda replik tillgänglig och hög tillgänglighet uppnås via Kubernetes-orkestrering.
- På tjänstnivån Affärskritisk tillhandahåller Azure Arc-aktiverade SQL Managed Instance en innesluten tillgänglighetsgrupp, utöver vad som tillhandahålls internt av Kubernetes-orkestrering.
Överväg de potentiella affärseffekterna av stilleståndstid på den Generell användning tjänstnivå som kan uppstå på grund av att det bara finns en replik.
Överväg hur många repliker – en till tre – som ska distribueras på tjänstnivån Affärskritisk.
När du distribuerar en instans på en Affärskritisk tjänstnivå med två eller flera repliker kan du konfigurera de sekundära replikerna som läsbara. Bestäm antalet sekundära repliker som ska distribueras på Affärskritisk tjänstnivå. Information om hur du ändrar numret finns i Konfigurera läsbara sekundärfiler.
Bestäm om du vill prioritera konsekvens framför tillgänglighet genom antalet sekundära repliker som krävs för att genomföra en transaktion på Affärskritisk tjänstnivå med hjälp av den valfria parametern--sync-secondary-to-commit. Om det finns anslutningsproblem mellan replikerna kanske den primära inte genomför några transaktioner:
- I en konfiguration med två repliker måste en transaktion checkas in på båda replikerna för att den primära ska få ett meddelande om att det lyckades.
- I en konfiguration med tre repliker måste minst två av de tre replikerna checka in en transaktion för att returnera ett lyckat meddelande.
Bestäm om du behöver ange en specifik replik som primär. Information om hur du anger en primär replik finns i Önskad primär replik.
Bestäm vilken Kubernetes-tjänsttyp du ska använda, LoadBalancer eller NodePort. Om du använder lastbalanseraren kan program återansluta till samma primära slutpunkt och Kubernetes omdirigerar anslutningen till den nya primära. Om du använder nodporten måste programmen återansluta till den nya IP-adressen.
Haveriberedskap
Instanserna av Azure Arc-aktiverade SQL Managed Instance på både geo-primära och geo-sekundära platser måste vara identiska i beräkning och kapacitet samt distribueras till samma tjänstnivåer.
Bestäm på en plats där speglingscertifikaten ska lagras när du skapar konfigurationen för haveriberedskap som är tillgänglig för båda kluster som är värdar för instansen.
Överväg hur du övervakar stilleståndstiden för den primära instansen för att bestämma när en redundansväxling ska utföras till den sekundära instansen.
Varje instans har sina egna slutpunkter. Överväg hur dina program kommer åt den primära slutpunkten med minsta möjliga avbrott vid redundansväxling.
Designrekommendationer
I följande avsnitt visas designrekommendationer för återställning till tidpunkt, hög tillgänglighet och haveriberedskap.
Återställning från tidpunkt
När du distribuerar en ny instans av Arc-aktiverad SQL Managed Instance definierar du alltid lagringsklassen för säkerhetskopior för att undvika standardinställningen för datalagringsklassen.
Använd en lagringsklass som stöder ReadWriteMany (RWX) för säkerhetskopieringsvolymen. Vägledning finns i Lagringsområden för Azure Arc-aktiverade SQL Managed Instance.
Innan du påbörjar en återställningsåtgärd använder du valfri parameter– torrkörning för att först verifiera om åtgärden skulle lyckas. Mer information finns i Skapa en databas från en tidpunkt med az CLI.
Skapa en process för att skicka säkerhetskopior som behöver längre kvarhållningsperioder till Azure eller annan lokal kall lagring.
Övervaka lagringen som förbrukas av dina säkerhetskopior för att avgöra om du kan hantera längre kvarhållning om det behövs.
Hög tillgänglighet
Utför regelbundna övningar för att verifiera hög tillgänglighet för din instans av Arc-aktiverade SQL Managed Instance. Exempel på detaljgranskningar är borttagning av en podd i en Generell användning-instans och fel på en replik i en Affärskritisk instans.
På den Affärskritisk nivån distribuerar du en instans i en konfiguration med tre repliker i stället för en konfiguration med två repliker för att uppnå nästan noll dataförlust.
För bättre tillgänglighet använder du LoadBalancer som tjänsttyp när du distribuerar en instans.
Granska begränsningarna för hög tillgänglighet för Azure Arc-aktiverade SQL Managed Instance.
Granska de tillgänglighetslägen som stöds för att bestämma vilket läge som ska användas baserat på dina behov av hög tillgänglighet.
När du distribuerar en Affärskritisk-instans med flera repliker använder du en av de sekundära replikerna för läsarbetsbelastningar. Programanslutningssträngen måste ange den sekundära slutpunkten som tjänstlyssnare för omdirigering till de sekundära replikerna. Information om slutpunkter finns i Hämta status för primära och sekundära slutpunkter och tillgänglighetsgruppen.
Information om metodtipsen för att övervaka tillgängligheten för dina instanser finns i Hantering och övervakning för Azure Arc-aktiverade SQL Managed Instance.
Haveriberedskap
Kontrollera att instanserna av Arc-aktiverade SQL Managed Instance har olika namn för primära och sekundära platser och att värdet för delat namn för platserna är identiskt.
Utför regelbundna programåterställningstest för att verifiera redundansväxlingen.
Skapa en process för att initiera både manuella och framtvingade redundansväxlingar.
Information om metodtips för att övervaka hälsotillståndet för klustren och för att förstå när en redundansväxling krävs finns i Hantering och övervakning för Azure Arc-aktiverade SQL Managed Instance.
Definiera DNS-posten för det delade namnet på den distribuerade tillgänglighetsgruppen på dns-servrarna för att undvika att behöva skapa DNS-poster manuellt under redundansväxlingen.
Nästa steg
Mer information om din hybrid- och molnresa över flera moln finns i följande artiklar:
- Vad är Azure Arc-aktiverade datatjänster?
- Översikt: Azure Arc-aktiverad SQL Managed Instance affärskontinuitet
- Kubernetes-validering för Azure Arc-aktiverade datatjänster
- Hantera din portfölj över hybrid- och multimolnåtgärder
- Azure Arc-aktiverade datatjänster för automatiserade scenarier med Azure Arc Jumpstart
- Ta Azure-innovation till dina hybridmiljöer med Azure Arc, en utbildningsväg från Microsoft Learn