[Källa] Hög tillgänglighet i SQL Server (1) ---- en översikt över hög tillgänglighet

Sedan SQL Server 2005 har Microsoft tillhandahållit en rad högtillgängliga teknologier för att minska driftstopp och öka skyddet av affärsdata, och med den kontinuerliga lanseringen av SQL Server 2008, SQL Server 2008 R2 och SQL Server 2012 finns det många högtillgängliga teknologier i SQL Server för att möta olika scenarier.

    Innan jag börjar den här artikeln kommer jag att ge en kort översikt över vad som avgör vilken högtillgänglig teknik man ska använda.

    Många företag behöver att all eller delar av deras data ska vara mycket tillgänglig, såsom onlinebutiker, online-produktdatabaser måste vara tillgängliga dygnet runt, annars innebär stillestånd i en mycket konkurrensutsatt marknadsmiljö förlorade kunder och intäkter. Till exempel, i ett callcenter som är beroende av SQL Server, om databasen går ner, kan alla uppringare bara sitta och svara kunden med "Förlåt, systemfel", vilket också är oacceptabelt.

    Självklart, i en idealisk värld, skulle all kritisk data vara online hela tiden, men i verkligheten finns det olika anledningar till att databasen inte är tillgänglig, eftersom det är omöjligt att förutsäga tid och form av katastrof, det är nödvändigt att vidta åtgärder i förväg för att förhindra olika nödsituationer, så SQL Server erbjuder en mängd högtillgängliga teknologier, dessa teknologier inkluderar huvudsakligen: klustring, replikering, spegling, loggleverans, AlwaysOn-tillgänglighetsgrupper och andra såsom filgruppsbackup och återställning, Enkelinstans-högtillgänglighetsteknologier såsom online-återuppbyggnadsindex. Användningen av högtillgänglig teknik handlar inte om att välja en bekant teknik för direkt användning, utan om att betrakta affären och teknologin på ett heltäckande sätt. För det finns ingen enskild teknik som kan uppnå alla funktioner. Hur man använder dessa teknologier baserat på din specifika verksamhet och budget kallas en strategi för hög tillgänglighet.

När du utformar en strategi för hög tillgänglighet bör du först överväga följande faktorer:

• RTO (Recovery Time Objective) – det vill säga målet för återhämtningstid – betyder hur mycket drifttid som är tillåten, vanligtvis uttryckt med några 9:or, till exempel betyder 99,999 % tillgänglighet högst 5 minuter driftstopp per år, 99,99 % tillgänglighet betyder högst 52,5 minuter driftstopp per år, och 99,9 % tillgänglighet betyder högst 8,75 timmar driftstopp per år. Det är värt att notera att beräkningsmetoden för RTO tar hänsyn till om systemet är 24*365 eller bara 6 på morgonen till 21, osv. Du måste också vara uppmärksam på om underhållsfönstret räknas som driftstopp, och det är lättare att uppnå högre tillgänglighet om databasunderhåll och patchning tillåts under underhållsfönstret.
• RPO (Recovery Point Objective) – Även känt som recovery point objective, betyder hur mycket dataförlust som är tillåten. Vanligtvis, så länge du gör en bra backup, kan du enkelt uppnå noll dataförlust. Men när en katastrof inträffar, beroende på omfattningen av databaskorruptionen, kommer tiden det tar att återställa data från en backup att göra att databasen blir otillgänglig, vilket påverkar implementeringen av RTO. Ett tidigt och mer känt exempel är ett banksystem i Europa och USA, där endast RPO räknas, det finns endast fullständiga säkerhetskopior och loggsäkerhetskopior i systemet, fullständiga säkerhetskopior var tredje månad, loggsäkerhetskopior var 15:e minut, och när en katastrof inträffar kan endast fullständiga säkerhetskopior och loggsäkerhetskopior återställa data, så även om det inte sker någon dataförlust, så eftersom det tog två hela dagar att återställa data, var banksystemet otillgängligt i två dagar, vilket ledde till att ett stort antal kunder gick förlorade. Ett annat motsatt exempel är en inhemsk onlinevideowebbplats, där SQL Server används som backend-relationsdatabas, front-end använder No-SQL och regelbundet importerar No-SQL-data till relationsdatabasen som backup.
  

    Budget – RTO och RPO kallas gemensamt för SLAs (Service Level Agreements), och när du utformar en strategi för hög tillgänglighet behöver du mäta hur väl du uppfyller SLAs baserat på din verksamhet, beroende på din budget och på kostnaden för olika SLAs vid ett fel. Generellt sett är det svårt att uppnå höga SLA med en begränsad budget, och även om höga SLA uppnås genom komplexa arkitekturer, innebär komplexa arkitekturer också höga drifts- och underhållskostnader, så det är nödvändigt att välja rätt teknik inom budgeten för att uppfylla SLA:erna.

Därför kan det stora ramverket för hög tillgänglighet generellt bestämmas av flera ordertagandefrågor:

• Vilken nedgång är aktieägarna villiga att acceptera?
• Vilken stilleståndstid är acceptabel för chefer?
• Vad är budgeten för ett scenario med hög tillgänglighet?
• Hur stor är förlusten per timme på grund av driftstopp?
  

• Kallbackup: Standby-servern är konfigurerad att acceptera data från primärservern, och när den misslyckas återställs datan manuellt till primärdatabasen eller programmets anslutningssträng eller behörigheter för att ta backupdatabasen online.
• Varm backup: Primärserverns data skickar kontinuerligt loggar till backup-servern (med oregelbundna intervaller, det kan vara 15 minuter, 30 minuter, 1 minut osv.), på detta sätt uppdateras primärservern till backup-servern vanligtvis asynkront, så data från primärservern och backup-servern kan inte garanteras. Dessutom implementerar detta system vanligtvis inte automatisk felövervakning och failover.
• Hot backup: Data från primärservern synkroniseras automatiskt på backup-servern, och i de flesta fall ingår automatisk felövervakning och failover, och datakonsistensen mellan primärservern och backup-servern kan garanteras.
  

    Från kall till varm till varm backup skjuter kostnaderna i höjden.

    De högtillgänglighetsfunktioner som stöds i SQL Server är nära relaterade till versionen, och Enterprise-utgåvan stöder alla funktioner med hög tillgänglighet, inklusive:

• Failover-kluster
• l Databasbild
• l Transaktionsloggöverföring
• l Databasögonblicksbilder
• Hög tillgänglighet
• l Varmladdningsminne
• l Online-indexeringsoperationer
• l Databas delvis online (endast masterfilgrupp eller masterfilgrupp samt ytterligare NDF-filer återställs)
  

    För specifika versioner av dessa högtillgängliga funktioner, se:http://msdn.microsoft.com/zh-cn/library/cc645993.aspxDet är värt att notera att den kostnadsfria Express-versionen kan fungera som en vittnesserver för databasspegelning, vilket leder till kostnadsbesparingar.

Failover-kluster

    Failover-kluster ger hög tillgänglighetsstöd för hela SQL Server-instansen, vilket innebär att en SQL Server-instans på en nod i klustret går över till andra noder i klustret på grund av hårdvarufel, operativsystemfel med mera. Hög tillgänglighet uppnås genom att flera servrar (noder) delar en eller flera diskar, och failover-kluster förekommer i nätverket på samma sätt som en enskild dator, men med höga tillgänglighetsegenskaper. Det är viktigt att notera att eftersom failover-kluster baseras på delade diskar finns det en enda punkt för diskfel, så ytterligare skydd som SAN-replikering behöver implementeras på disknivå. Det vanligaste failover-klustret är ett två-nodes failover-kluster, inklusive master och slave.

Transaktionsloggöverföring

    Transaktionsloggfrakt ger databasnivå högt tillgänglighetsskydd. Loggning används för att underhålla en eller flera reservdatabaser (kallade "sekundära databaser") i motsvarande produktionsdatabas (kallad "primärdatabas"). Innan en failover sker måste den sekundära databasen uppdateras fullt ut genom att manuellt tillämpa alla oåterställda loggkopior. Loggleverans har flexibiliteten att stödja flera reservdatabaser. Om flera alternativa databaser krävs kan loggleverans användas separat eller som ett komplement till databasspegelning. När dessa lösningar används tillsammans är huvuddatabasen för den aktuella databasspeglingskonfigurationen också den primära databasen för den aktuella loggfraktkonfigurationen.

    Transaktionsloggleverans kan användas för att göra kalla och varma backuper.

Databasspegling

    Databasspegelning är faktiskt en mjukvarulösning som också ger skydd på databasnivå, vilket ger nästan omedelbar failover för att förbättra databastillgängligheten. En databasspegel kan användas för att underhålla en enda reservdatabas (eller "spegeldatabas") för motsvarande produktionsdatabas (kallad "huvuddatabas").
Eftersom spegeldatabasen alltid är i återställningsläge, men databasen inte återställs, kan spegeldatabasen inte nås direkt. För skrivskyddade inläsningar som rapporter kan du dock använda den speglade databasen indirekt genom att skapa en databassnapshot av den speglade databasen. Databassnapshots ger klienter skrivskyddad åtkomst till data i databasen när snapshoten skapas. Varje databasspegelkonfiguration involverar en "huvudserver" som innehåller huvuddatabasen, och även en spegelserver som innehåller den speglade databasen. Spegelservern uppdaterar kontinuerligt spegeldatabasen med huvuddatabasen.
    Databasspegling körs synkront i högsäkerhetsläge eller asynkront i högpresterande läge. I högpresterande läge behöver transaktioner inte vänta på att spegelservern ska skriva loggar till disken innan de kan skickas in, vilket maximerar prestandan. I högsäkerhetsläge genomförs committerade transaktioner av båda parter, men transaktionsfördröjningen förlängs. Den enklaste konfigurationen av databasspegling involverar endast huvudservern och spegelservern. I denna konfiguration, om huvudservern förloras, kan spegelservern användas som reservserver, men det kan orsaka dataförlust. Högsäkerhetsläge stödjer standby-konfiguration med högsäkerhetsläge och automatisk failover. Denna konfiguration involverar en tredjepartsserverinstans kallad en "vittnesserver" som gör det möjligt att använda spegelservern som en hot backup-server. Failover från primärdatabasen till spegeldatabasen tar vanligtvis några sekunder.

    Databasspegling kan användas för både varma och varma säkerhetskopior.

kopia

    Replikering är inte strikt en funktion som är utformad för hög tillgänglighet, men den kan tillämpas på hög tillgänglighet. Replikering ger skydd på databasens objektnivå. Replikering använder en publicish-subscribe-modell, där data publiceras av den primära servern, kallad publicisten, till en eller flera sekundära eller prenumeranter. Replikering ger tillgänglighet i realtid och skalbarhet mellan dessa servrar. Den stöder filtrering för att tillhandahålla en delmängd data till prenumeranter, samtidigt som den stöder partitionsuppdateringar. Prenumeranten är online och tillgänglig för rapportering eller andra funktioner utan återhämtning av frågor. SQL Server erbjuder fyra typer av replikering: snapshot-replikering, transaktionell replikering, peer-to-peer-replikering och sammanslagen replikering.

AlwaysOnAnvändbarhetsgrupp

    AlwaysOn Availability Groups är en ny funktion som introducerades i SQL Server 2012. Skydd på databasnivå tillhandahålls också. Den utökar också gränsen för att databasspegling endast kan vara 1:1, så att en primär replika kan motsvara upp till 4 sekundära repliker (i SQL Server 2014 utökas denna gräns till 8), varav 2 sekundära repliker kan synkroniseras som heta backuper och primära repliker i realtid, och de andra två asynkrona sekundärkopiorna kan användas som varma backuper. Dessutom kan sekundära repliker konfigureras som skrivskyddade och användas för att ta emot belastningen av säkerhetskopior.

    På grund av detta markeras databasspegelning som "föråldrad" i SQL Server 2012.

    Efter att ha förstått de grundläggande koncepten för hög tillgänglighet och de högtillgänglighetsteknologier som tillhandahålls i SQL Server, låt oss titta på utformningen av en högtillgänglighetsstrategi. Att planera en strategi för hög tillgänglighet kan delas in i fyra faser:

Insamlingskrav

    Det första steget i att bestämma en högtillgänglighetsstrategi är utan tvekan att samla in affärskrav för att upprätta SLA:er. RTO och RPO är de mest kritiska delarna, och på denna grund etableras realistiska förväntningar på tillgänglighetskrav och en realistisk strategi för hög tillgänglighet baserad på dessa förväntningar.

Bedömningsgränser

    Bedömningsgränser är inte bara begränsade till begränsningarna hos olika högtillgängliga teknologier i SQL Server, utan även till de som är icke-tekniska. Om du bara har en budget på tiotusentals yuan, men vill göra en högtillgänglig lösning baserad på externa datacenter och SAN-replikering, är det utan tvekan en dåraktig dröm. En annan icke-teknisk begränsning är nivån på operationspersonal, och ofta innebär komplexa arkitekturer mer kvalificerad operationspersonal. Andra icke-tekniska begränsningar inkluderar tillgången på diskutrymme i datacentret, om strömförsörjning och luftkonditionering kan möta behoven, samt den tid som krävs för att implementera tillgänglighetsstrategin.

    Tekniska begränsningar inkluderar olika funktioner och begränsningar för hög tillgänglighet, funktioner som stöds av olika SQL Server-versioner, antalet CPU:er och minnesstorleken. Det rekommenderas starkt att du först tittar på begränsningarna för olika SQL Server-versioner och funktioner på Microsofts MSDN-webbplats innan du implementerar en policy för hög tillgänglighet.

Utvald teknik

    Efter att ha samlat in krav och bedömt begränsningar är nästa steg att välja de teknologier eller kombinationer av teknologier som beskrivits tidigare i denna artikel för att uppfylla SLA-kraven. Om den valda teknologin inte uppfyller SLA:n är det enkelt att rapportera vilka begränsningar som inte uppfyller SLA:n, vilket gör att du kan begära saknade resurser eller kompromissa med SLA:n.

Testa, validera och dokumentera

    Högtillgänglighetspolicys måste noggrant testas och valideras från början för att säkerställa att nuvarande tillgänglighetspolicys uppfyller SLA:er. Men när en högtillgänglighetsstrategi lanseras är det också nödvändigt att regelbundet testa och validera den för att säkerställa att den nuvarande policyn fortfarande kan uppfylla SLA:er trots datatillväxt, affärs- eller kravändringar. Samtidigt bör konfigurationen av tillgänglighetslösningen, failovermetoden och katastrofåterställningsplanen dokumenteras samtidigt så att den kan spåras vid fel eller framtida justering av högtillgänglighetsstrategin.

Denna artikel förklarar de grundläggande koncepten för hög tillgänglighet, begreppet SLA:er, de olika typer av högtillgänglighetsfunktioner som stöds i SQL Server och de steg som krävs för att utforma en strategi för hög tillgänglighet. Det är värt att notera att även om denna artikel endast handlar om hög tillgänglighet på databasnivå, är hög tillgänglighet inte bara en fråga för DBA, utan inkluderar också samarbete mellan olika roller såsom systemdrift- och underhållspersonal, nätverksadministratörer, utvecklare och chefer för att bättre uppfylla SLA:er.