Affärskontinuitet och haveriberedskap för Azure Arc-aktiverad SQL Managed Instance
Azure Arc-aktiverad SQL Managed Instance tillhandahåller funktioner för affärskontinuitet och haveriberedskap (BCDR) som hjälper företag att återställa från störningar och fortsätta att 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 med hög tillgänglighet för den 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-aktiverad SQL Managed Instance kan distribueras på två separata Kubernetes-kluster på två olika platser för haveriberedskap.
Följande arkitekturdiagram visar hur Arc-aktiverad SQL Managed Instance svarar när en haveriberedskapsredundans initieras.
Utformningsbeaktanden
Om du vill utvärdera effekten av Azure Arc-aktiverad 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 ligger på designrekommendationer endast för affärskontinuitet, men den höga tillgängligheten och motståndskraften för din instans är också beroende av tillgängligheten för den underliggande Kubernetes-infrastrukturen.
Återställning till 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.
Tänk på 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äkerhetskopieringar. Vägledning finns i Lagringsområden för Azure Arc-aktiverad 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-aktiverad SQL Managed Instance.
Säkerhetskopior utförs alltid på den primära repliken. Tänk på prestandaeffekterna av säkerhetskopierings- och återställningsprocesserna när du identifierar de resurser som allokeras till din instans.
Tänk på att återställningar till tidpunkt för 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-aktiverad SQL Managed Instance.
Hög tillgänglighet
Granska tillgänglighetskraven för din arbetsbelastning och bestäm vilken tjänstnivå som är bäst för din distribution av Arc-aktiverad SQL Managed Instance:
- På tjänstnivån Generell användning finns det en enda tillgänglig replik och den höga tillgängligheten uppnås via Kubernetes-orkestrering.
- På tjänstnivån Affärskritisk tillhandahåller Azure Arc-aktiverad SQL Managed Instance en innesluten tillgänglighetsgrupp, utöver vad som tillhandahålls internt av Kubernetes-orkestrering.
Tänk på de potentiella affärseffekterna av stilleståndstid på tjänstnivån Generell användning som kan uppstå på grund av att det bara finns en replik.
Tänk på hur många repliker – en till tre – som ska distribueras på tjänstnivån Affärskritisk.
När du distribuerar en instans på en tjänstnivå för affärskritisk 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å tjänstnivån Affärskritisk. Information om hur du ändrar numret finns i Konfigurera läsbara sekundärfiler.
Bestäm om du vill prioritera konsekvens framför tillgänglighet via antalet sekundära repliker som krävs för att genomföra en transaktion på tjänstnivån Affärskritisk 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 åtgärden 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 Prioriterad 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-aktiverad 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 egna slutpunkter. Fundera på 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 till 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 att standardvärdet ä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-aktiverad SQL Managed Instance.
Innan du påbörjar en återställningsåtgärd använder du den valfria parametern --dry-run 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 den höga tillgängligheten för din instans av Arc-aktiverad SQL Managed Instance. Exempel på detaljgranskningar är borttagning av en podd i en instans av generell användning och fel på en replik i en affärskritisk instans.
På nivån Affärskritisk 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-aktiverad 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 för 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 . Programmet niska veze 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 de primära och sekundära slutpunkterna och tillgänglighetsgruppens status.
Information om metodtipsen för att övervaka tillgängligheten för dina instanser finns i Hantering och övervakning för Azure Arc-aktiverad SQL Managed Instance.
Haveriberedskap
Kontrollera att dina instanser 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 haveriberedskapstest 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-aktiverad 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 med flera moln finns i följande artiklar:
- Vad är Azure Arc-aktiverade datatjänster?
- Översikt: Affärskontinuitet för Azure Arc-aktiverad SQL Managed Instance
- Kubernetes-validering av 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