Dela via

Tillförlitlighet i Azure SQL Managed Instance

I den här artikeln beskrivs tillförlitlighetsstöd i Azure SQL Managed Instance, som omfattar intraregional återhämtning via tillgänglighetszoner och distributioner i flera regioner.

När du använder Azure är tillförlitlighet ett delat ansvar. Microsoft tillhandahåller en rad funktioner för att stödja återhämtning och återställning. Du ansvarar för att förstå hur dessa funktioner fungerar inom alla tjänster som du använder och välja de funktioner du behöver för att uppfylla dina affärsmål och drifttidsmål.

SQL Managed Instance är en fullständigt hanterad paaS-databasmotor (plattform som en tjänst). Den hanterar de flesta databashanteringsfunktioner som uppgradering, korrigeringar, säkerhetskopior och övervakning utan användarengagemang. SQL Managed Instance är en skalbar molndatabastjänst som körs på den senaste stabila versionen av SQL Server-databasmotorn och ett korrigerat operativsystem med inbyggd hög tillgänglighet. Det ger nästan 100% funktionskompatibilitet med SQL Server.

Rekommendationer för produktionsdistribution

För de flesta produktionsdistributioner av SQL Managed Instance bör du överväga följande rekommendationer:

Översikt över tillförlitlighetsarkitektur

Sql-hanterade instanser för generell användning körs på en enda nod som Hanteras av Azure Service Fabric . När databasmotorn eller operativsystemet uppgraderas, eller om ett fel upptäcks, fungerar SQL Managed Instance med Service Fabric för att flytta den tillståndslösa databasmotorprocessen till en annan tillståndslös beräkningsnod som har tillräckligt med ledig kapacitet. Databasfiler lagras i Azure Blob Storage, som har inbyggda redundansfunktioner. Data- och loggfiler kopplas från den ursprungliga beräkningsnoden och kopplas till den nyligen initierade databasmotorprocessen.

Affärskritiska SQL-hanterade instanser använder flera repliker i ett kluster. Klustret innehåller två typer av repliker:

  • En enda primär replik som kan nås för kundarbetsbelastningar med läs- och skrivbehörighet

  • Upp till fem sekundära repliker (beräkning och lagring) som innehåller kopior av data

Den primära repliken skickar kontinuerligt och sekventiellt ändringar till de sekundära replikerna, vilket säkerställer att data sparas på ett tillräckligt antal sekundära repliker innan varje transaktion genomförs. Den här processen garanterar att en fullständigt synkroniserad replik alltid är tillgänglig för redundans om den primära repliken eller en läsbar sekundär replik blir otillgänglig.

SQL Managed Instance och Service Fabric initierar redundans mellan repliker. När en sekundär replik blir den nya primära repliken skapas en annan sekundär replik för att säkerställa att klustret har tillräckligt många repliker för att upprätthålla kvorum. När redundansväxlingen är klar omdirigeras Azure SQL-anslutningar automatiskt till den nya primära repliken eller den läsbara sekundära repliken baserat på anslutningssträngen.

Redundans

Som standard uppnår SQL Managed Instance redundans genom att sprida beräkningsnoder och data i ett enda datacenter i den primära regionen. Den här metoden skyddar dina data under följande förväntade och oväntade driftstopp:

  • Kundinitierade hanteringsåtgärder som resulterar i en kort stilleståndstid

  • Serviceunderhållsåtgärder

  • Småskaliga nätverks- eller strömavbrott

  • Problem och avbrott i datacenter som omfattar följande komponenter:

    • Racket där datorerna som driver din tjänst är igång

    • Den fysiska dator som är värd för den virtuella datorn (VM) som kör SQL Database Engine.

    • Den virtuella dator som kör SQL Database Engine

  • Problem med SQL Database-motorn

  • Potentiella oplanerade lokaliserade avbrott

Mer information om hur SQL Managed Instance tillhandahåller redundans finns i Tillgänglighet via lokal redundans och zonredundans.

Tillfälliga fel

Tillfälliga fel är kortvariga, intermittenta fel i komponenter. De förekommer ofta i en distribuerad miljö som molnet, och de är en normal del av åtgärderna. Tillfälliga fel korrigerar sig själva efter en kort tidsperiod. Det är viktigt att dina program kan hantera tillfälliga fel, vanligtvis genom att försöka igen.

Alla molnbaserade program bör följa vägledningen för tillfälliga felhantering i Azure när de kommunicerar med molnbaserade API:er, databaser och andra komponenter. Mer information finns i Rekommendationer för hantering av tillfälliga fel.

SQL Managed Instance hanterar automatiskt kritiska underhållsaktiviteter, till exempel korrigeringar, säkerhetskopieringar och uppgraderingar av Windows- och SQL Database Engine. Den hanterar även oplanerade händelser, till exempel underliggande maskinvaru-, programvaru- eller nätverksfel. SQL Managed Instance kan snabbt återställas även under de mest kritiska omständigheterna, vilket säkerställer att dina data alltid är tillgängliga. De flesta användare märker inte att uppgraderingar utförs kontinuerligt.

När en instans korrigeras eller redundansväxlar har stilleståndstiden minimal effekt om du använder logik för återförsök i ditt program. Du kan testa programmets återhämtning för tillfälliga fel.

Stöd för tillgänglig zon

Anmärkning

Zonredundans är för närvarande inte tillgängligt för Nästa generation General Purpose-tjänstnivån.

Tillgänglighetszoner är fysiskt separata grupper av datacenter i varje Azure-region. När en zon misslyckas kan tjänsterna redundansväxla till en av de återstående zonerna.

När du aktiverar en zonredundant konfiguration kan du se till att din SQL-hanterade instans är motståndskraftig mot en stor uppsättning fel, inklusive oåterkalleliga datacenterfel, utan några ändringar i programlogik.

SQL Managed Instance uppnår zonredundans genom att placera tillståndslösa beräkningsnoder i olika tillgänglighetszoner. Den förlitar sig på tillståndskänslig ZRS som är kopplad till den nod som för närvarande innehåller den aktiva SQL Database Engine-processen. Om ett avbrott inträffar blir SQL Database Engine-processen aktiv på en av de tillståndslösa beräkningsnoderna, som sedan kommer åt data i den tillståndskänsliga lagringen.

SQL Managed Instance uppnår zonredundans genom att placera repliker av din SQL-hanterade instans i flera tillgänglighetszoner. För att eliminera en enskild felpunkt dupliceras även kontrollringen över flera zoner. Styrplanstrafiken dirigeras till en lastbalanserare som är också distribuerad över tillgänglighetszoner. Azure Traffic Manager styr trafikroutning från kontrollplanet till lastbalanseraren.

Kravspecifikation

För att aktivera zonredundans för din SQL-hanterade instans, ange inställningen för Redundans för säkerhetskopieringslagring till ZRS eller Geo-zonredundant lagring (GZRS).

Stöd för regioner

Zonredundans för SQL Managed Instance stöds i utvalda regioner. Mer information finns i Regioner som stöds.

Kostnad

När du aktiverar zonredundans kostar det extra för din SQL-hanterade instans och för zonredundanta säkerhetskopieringar. Mer information finns i Prissättning.

Du kan spara pengar genom att åta dig att använda beräkningsresurser till ett rabatterat pris under en tidsperiod, vilket inkluderar zonredundanta instanser på tjänstnivån Affärskritisk. Mer information finns i Reservationer för SQL Managed Instance.

Konfigurera stöd för tillgänglighetszoner

I det här avsnittet beskrivs hur du konfigurerar stöd för tillgänglighetszoner för dina SQL-hanterade instanser:

  • Aktivera zonredundans: Information om hur du konfigurerar zonredundans för nya och befintliga instanser finns i Konfigurera zonredundans.

    Alla skalningsåtgärder för SQL Managed Instance, inklusive aktivering av zonredundans, är onlineåtgärder och kräver minimal till ingen stilleståndstid. Mer information finns i Varaktighet för hanteringsåtgärder.

  • Inaktivera zonredundans: Du kan inaktivera zonredundans genom att följa samma steg för att aktivera zonredundans. Den här processen är en onlineåtgärd som liknar en vanlig uppgradering av servicenivåmål. I slutet av processen migreras instansen från zonredundant infrastruktur till en zoninfrastruktur.

Normala åtgärder

I det här avsnittet beskrivs vad du kan förvänta dig när din SQL-hanterade instans är konfigurerad att vara zonredundant och alla tillgänglighetszoner är i drift:

  • Trafikroutning mellan zoner: Under normala åtgärder dirigeras begäranden till den nod som kör sql Managed Instance-beräkningslagret.

  • Datareplikering mellan zoner: Databasfiler lagras i Azure Storage med hjälp av ZRS, som är kopplat till den nod som för närvarande innehåller den aktiva SQL Database Engine-processen.

    Skrivåtgärder är synkrona och anses inte vara slutförda förrän data har replikerats i alla tillgänglighetszoner. Den här synkrona replikeringen säkerställer stark konsistens och noll dataförlust vid zonfel. Det kan dock leda till något högre skrivfördröjning jämfört med lokalt redundant lagring.

  • Trafikroutning mellan zoner: Under normala åtgärder dirigeras begäranden till den primära repliken av din SQL-hanterade instans.

  • Datareplikering mellan zoner: Den primära repliken skickar kontinuerligt och sekventiellt ändringar till de sekundära replikerna i olika tillgänglighetszoner. Den här processen säkerställer att data sparas på ett tillräckligt antal sekundära repliker innan de genomför varje transaktion. Dessa repliker finns i olika tillgänglighetszoner. Den här processen garanterar att en fullständigt synkroniserad replik alltid är tillgänglig för redundans om den primära repliken eller en läsbar sekundär replik blir otillgänglig av någon anledning.

    Eftersom zonredundanta instanser har repliker i olika datacenter med ett visst avstånd mellan dem kan den ökade nätverksfördröjningen öka transaktionsincheckningstiden. Den här ökningen kan påverka prestandan för vissa OLTP-arbetsbelastningar (Online Transaction Processing). De flesta program är inte känsliga för den här extra svarstiden.

Avslappningsupplevelse

Det här avsnittet beskriver vad du kan förvänta dig när din SQL-hanterade instans är konfigurerad att vara zonredundant och en eller flera tillgänglighetszoner inte är tillgängliga:

  • Omdistribution av trafik: SQL Managed Instance fungerar med Service Fabric för att flytta databasmotorn till en lämplig tillståndslös beräkningsnod som finns i en annan tillgänglighetszon och har tillräckligt med ledig kapacitet. När redundansväxlingen är klar omdirigeras nya anslutningar automatiskt till den nya primära beräkningsnoden.

    En tung arbetsbelastning kan uppleva viss prestandaförsämring under övergången från en beräkningsnod till den andra beräkningsnoden eftersom den nya databasmotorprocessen börjar med en kall cache.

  • Omdirigering av trafik: SQL Managed Instance fungerar med Service Fabric för att välja ut en lämplig replik i en annan tillgänglighetszon för att bli den primära repliken. När en sekundär replik blir den nya primära repliken skapas en annan sekundär replik för att säkerställa att klustret har tillräckligt många repliker för att upprätthålla kvorum. När failover är klar, omdirigeras nya anslutningar automatiskt, baserat på anslutningssträngen, till antingen den nya primära repliken eller den läsbara sekundära repliken.

  • Förväntad stilleståndstid: Det kan finnas en liten mängd stilleståndstid under en redundansväxling i tillgänglighetszonen. Stilleståndstiden är vanligtvis mindre än 30 sekunder, vilket programmet bör tolerera om det följer vägledningen för tillfällig felhantering.

  • Förväntad dataförlust: Ingen dataförlust förväntas för bekräftade transaktioner under en redundansväxling i tillgänglighetszonen. Pågående transaktioner måste göras om.

Zonåterställning

När tillgänglighetszonen återställs fungerar SQL Managed Instance med Service Fabric för att återställa åtgärder i den återställda zonen. Ingen kundintervention krävs.

Testa för zonfel

SQL Managed Instance-plattformen hanterar trafikroutning, redundans och återställning efter fel för zonredundanta instanser. Eftersom den här funktionen är helt hanterad behöver du inte initiera eller verifiera felprocesser i tillgänglighetszonen. Du kan dock verifiera programmets hantering av fel.

Stöd för flera regioner

En enskild SQL Managed Instance distribueras inom en enda region. Du kan dock distribuera en sekundär SQL-hanterad instans i en separat Azure-region och konfigurera en redundansgrupp. Redundansgrupper geo-replikerar automatiskt dina data och kan automatiskt eller manuellt redundansväxla om ett regionalt fel inträffar, baserat på redundanspolicyn.

Det här avsnittet sammanfattar viktig information om redundansgrupper, men det är viktigt att du läser översikten över redundansgrupper och metodtips för att lära dig mer om hur de fungerar och hur du konfigurerar dem.

Redundansprinciper

När du skapar en redundansgrupp väljer du redundansprincipen, som anger vem som ansvarar för att identifiera ett avbrott och utföra en redundansväxling. Du kan konfigurera två typer av redundansprinciper:

  • Kundhanterad redundans (rekommenderas): När du använder en kundhanterad redundansprincip kan du bestämma om du vill utföra en redundansväxling, som inte medför dataförlust eller en tvingad redundansväxling, vilket kan medföra dataförlust. Tvingad redundans används som en återställningsmetod vid avbrott när den primära instansen inte kan nås.

  • Microsoft-hanterad failöver: Microsoft-hanterad failöver används endast i exceptionella situationer för att utlösa en tvingad failöver.

Viktigt!

Använd kundhanterade redundansalternativ för att utveckla, testa och implementera dina DR-planer. Förlita dig inte på Microsoft-hanterad redundans, som kanske bara används under extrema omständigheter. En Microsoft-hanterad redundans initieras sannolikt för en hel region. Det kan inte initieras för enskilda redundansgrupper, SQL-hanterade instanser, prenumerationer eller kunder. Omkoppling kan ske vid olika tidpunkter för olika Azure-tjänster. Vi rekommenderar att du använder kundhanterad redundansväxling.

Stöd för regioner

Du kan välja valfri Azure-region för SQL-hanterade instanser i redundansgruppen. På grund av den långa svarstiden för nätverk i stora områden använder geo-replikering en asynkron replikeringsmekanism. Om du vill minska nätverksfördröjningen väljer du regioner som har anslutningar med låg svarstid. Mer information om svarstid mellan Azure-regioner finns i Statistik över svarstider för Azure-nätverk tur och retur.

Kostnad

När du skapar flera SQL-hanterade instanser i olika regioner debiteras du för varje SQL-hanterad instans.

Men om din sekundära instans inte har några läsarbetsbelastningar eller program anslutna till den kan du spara på licenskostnader genom att ange repliken som en väntelägesinstans. Mer information finns i Konfigurera en licensfri standby-replik för SQL Managed Instance.

Mer information om priser för SQL Managed Instance finns i Prisinformation för tjänsten.

Konfigurera stöd för flera regioner

Information om hur du konfigurerar en redundansgrupp finns i Konfigurera en redundansgrupp för SQL Managed Instance.

Kapacitetsplanering och -hantering

Under en redundansväxling omdirigeras trafiken till en sekundär SQL-hanterad instans. Det är viktigt att din sekundära SQL-hanterade instans är redo att ta emot trafik. Skapa en sekundär SQL-hanterad instans med samma tjänstnivå, maskinvarugenerering och beräkningsstorlek som den primära instansen.

Mer information om hur du skalar SQL-hanterade instanser i en redundansgrupp finns i Skala instanser.

Normala åtgärder

Det här avsnittet beskriver vad du kan förvänta dig när SQL-hanterade instanser konfigureras för att använda redundansgrupper i flera regioner och alla regioner är i drift:

  • Trafikroutning mellan regioner: Under normala åtgärder går skrivskyddade begäranden till den enda primära instansen i den primära regionen.

    Redundansgrupper ger också en separat skrivskyddad lyssnarslutpunkt. Under normala åtgärder ansluter den här slutpunkten till den sekundära instansen för att dirigera skrivskyddad trafik som anges i anslutningssträngen.

    Mer information om hur redundansgrupper skickar trafik till varje instans och hur du kan dirigera trafik till en skrivskyddad lyssnarslutpunkt finns i Översikt över redundansgrupper och metodtips.

  • Datareplikering mellan regioner: Som standard replikeras data asynkront från den primära instansen till den sekundära SQL-hanterade instansen.

    Eftersom geo-replikering är asynkron kan du förlora data om du utför en tvingad omkoppling. Du kan övervaka replikeringsfördröjningen för att förstå den potentiella dataförlusten under en tvingad redundansväxling. Mer information finns i checklistan för dr.

    Om du behöver eliminera dataförlust från asynkron replikering under redundansväxlingar konfigurerar du programmet så att det blockerar den anropande tråden tills den bekräftar att den senast genomförda transaktionen har överförts och förstärkts i transaktionsloggen för den sekundära databasen. Den här metoden kräver anpassad utveckling och försämrar programmets prestanda. Mer information finns i Förhindra förlust av kritiska data.

Region-down-upplevelse

Det här avsnittet beskriver vad du kan förvänta dig när SQL-hanterade instanser konfigureras för att använda redundansgrupper i flera regioner och det uppstår ett avbrott i den primära regionen:

  • Identifiering och svar: Ansvaret för identifiering och svar beror på den redundansprincip som din redundansgrupp använder.

    • Kundhanterad redundansprincip: Du ansvarar för att identifiera felet i en region och utlösa en redundansväxling eller tvingad redundansväxling till den sekundära instansen i redundansgruppen.

      Om du utför en redundansväxling väntar SQL Managed Instance på att data ska synkroniseras till den sekundära instansen innan redundansväxlingen utförs.

      Om du utför en tvingad överflyttning kommer SQL Managed Instance omedelbart att byta den sekundära instansen till primär roll utan att vänta på att de senaste ändringarna ska spridas från den primära. Den här typen av redundans kan medföra dataförlust.

    • Microsoft-hanterad redundansprincip: Microsoft-hanterade redundans utförs under exceptionella omständigheter. När Microsoft utlöser en redundans utför redundansgruppen automatiskt en tvingad redundansväxling till den sekundära instansen i redundansgruppen. Vi rekommenderar dock att du använder en kundhanterad redundansprincip för produktionsarbetsbelastningar så att du kan styra när redundansväxlingen sker.

  • Anmälan: Regionfelhändelser kan övervakas via Service Health och Resource Health. Konfigurera aviseringar för dessa tjänster för att ta emot meddelanden om problem på regionnivå.

  • Aktiva begäranden: När en automatisk övergång inträffar avslutas alla begäranden som bearbetas och måste försöka igen. Information om hur du gör dina program motståndskraftiga mot dessa typer av problem finns i Tillfälliga felhantering.

  • Förväntad dataförlust: Mängden dataförlust beror på hur du konfigurerar ditt program. Mer information finns i Översikt över redundansgrupper och metodtips.

  • Förväntad stilleståndstid: Det kan finnas en liten mängd stilleståndstid under en omkoppling i en redundansgrupp. Stilleståndstiden är vanligtvis mindre än 60 sekunder.

  • Omdistribution av trafik: När redundansgruppen har slutfört redundansväxlingen dirigeras läs- och skrivtrafik automatiskt till den nya primära instansen. Om dina program använder redundansgruppens slutpunkter i anslutningssträngarna behöver de inte ändra sina anslutningssträngar efter redundansväxlingen.

Failback

Redundansgrupper redundansväxlar inte automatiskt tillbaka till den primära regionen när den återställs, så det är ditt ansvar att initiera en återställning efter fel.

Testning för regionfel

Du kan testa redundansväxlingen för en redundansgrupp.

Att testa en redundansgrupp är bara en del av att utföra ett DR-test. Mer information finns i Utföra DR-övningar.

Backups

Gör säkerhetskopior av dina databaser för att skydda mot olika risker, inklusive dataförlust. Säkerhetskopior kan återställas för att återställas från oavsiktlig dataförlust, skada eller andra problem. Säkerhetskopieringar är inte samma sak som geo-replikering, och de har olika syften och minimerar olika risker.

SQL Managed Instance tar automatiskt fullständiga, differentiella och transaktionsloggsäkerhetskopior av dina databaser. Mer information om typer av säkerhetskopior, deras frekvens, återställningsfunktioner, lagringskostnader och säkerhetskopieringskryptering finns i Automatiserade säkerhetskopieringar i SQL Managed Instance.

SQL Managed Instance tillhandahåller inbyggda automatiserade säkerhetskopior och stöder även användarinitierade kopiera-endast säkerhetskopior för användardatabaser. Mer information finns i Kopieringssäkerhetskopior.

Säkerhetskopieringsreplikering

När du konfigurerar automatiserade säkerhetskopieringar för din SQL-hanterade instans kan du ange hur säkerhetskopior ska replikeras. Säkerhetskopior som är konfigurerade att lagras på ZRS har en högre återhämtningsnivå. Vi rekommenderar att du konfigurerar dina säkerhetskopior så att de använder någon av följande lagringstyper:

  • ZRS för återhämtning inom regionen, om regionen har tillgänglighetszoner

  • GZRS för att förbättra motståndskraften hos dina säkerhetskopior mellan regioner om regionen har tillgänglighetszoner och är parad med en annan region

  • GRS om din region inte stöder tillgänglighetszoner men har en länkad region

Mer information om olika lagringstyper och deras funktioner finns i Redundans för säkerhetskopiering av lagring.

Geo-återställning

Geo-återställningsfunktionen är en grundläggande DR-lösning som gör att du kan återställa säkerhetskopior till en annan Azure-region. Geo-säkerhetskopiering kräver vanligtvis en betydande mängd stilleståndstid och dataförlust. För att uppnå högre återställningsnivåer om ett regionalt avbrott inträffar bör du konfigurera redundansgrupper.

Om du använder geo-återställning måste du överväga hur du gör dina säkerhetskopior tillgängliga i den sekundära regionen:

  • Om din primära region är kopplad använder du GZRS- eller GRS-säkerhetskopieringslagring för att stödja geo-återställning till den kopplade regionen.

  • Om din primära region inte är kopplad kan du skapa en anpassad lösning för att replikera dina säkerhetskopior till en annan region. Överväg att använda använda användarinitierade säkerhetskopior och lagra dem i ett lagringskonto som använder replikering av blobobjekt för att replikera till ett lagringskonto i en annan region.

Tillförlitlighet under tjänstunderhåll

När SQL Managed Instance utför underhåll på din instans förblir DEN SQL-hanterade instansen helt tillgänglig men kan bli föremål för korta omkonfigurationer. Klientprogram kan observera korta anslutningsstörningar när en underhållshändelse inträffar. Klientprogrammen bör följa vägledningen för tillfällig felhantering för att minimera effekterna.

Med SQL Managed Instance kan du ange ett underhållsperiod som vanligtvis används för tjänstuppgraderingar och andra underhållsåtgärder. Genom att konfigurera ett underhållsfönster kan du minimera eventuella bieffekter, till exempel automatiska redundansväxlingar, under kontorstid. Du kan också få förhandsmeddelanden om planerat underhåll.

Mer information finns i underhållsfönstret i SQL Managed Instance.

Serviceavtal

Serviceavtal (SLA) för Azure-tjänster beskriver den förväntade tillgängligheten för varje tjänst och de villkor som din lösning måste uppfylla för att uppnå den tillgänglighetsförväntningen. Mer information finns i Serviceavtal för onlinetjänster.

För SQL Managed Instance gäller serviceavtalet för tillgänglighet endast när ditt virtuella Azure-nätverk är korrekt konfigurerat så att det inte hindrar hanteringstrafiken. Den här konfigurationen omfattar undernätsstorlek, nätverkssäkerhetsgrupper (NSG), användardefinierade vägar (UDR), DNS-konfiguration och andra resurser som påverkar hanteringen och användningen av nätverksresurser. Mer information om den nätverkskonfiguration som krävs för SQL Managed Instance finns i Nätverkskrav.

Relaterat innehåll