[Kilde] Høj tilgængelighed i SQL Server (1) ---- et overblik over høj tilgængelighed

Siden SQL Server 2005 har Microsoft leveret en række højtilgængelighedsteknologier for at reducere nedetid og øge beskyttelsen af forretningsdata, og med den kontinuerlige udgivelse af SQL Server 2008, SQL Server 2008 R2 og SQL Server 2012 findes der mange højtilgængelighedsteknologier i SQL Server til at imødekomme forskellige scenarier.

    Før jeg starter denne artikel, vil jeg starte med en kort oversigt over, hvad der afgør, hvilken højtilgængelighedsteknologi man skal bruge.

    Mange virksomheder har brug for, at hele eller dele af deres data er højt tilgængelige, såsom online shoppingwebsites, online produktdatabaser skal være online 24/7, ellers betyder nedetid i et meget konkurrencepræget markedsmiljø tabte kunder og indtægter. For eksempel, i et callcenter, der er afhængigt af SQL Server, hvis databasen går ned, kan alle opkaldere kun sidde og svare kunden med "Beklager, systemfejl", hvilket også er uacceptabelt.

    Selvfølgelig vil alle kritiske data i en ideel verden være online hele tiden, men i den virkelige verden vil der være forskellige grunde til, at databasen ikke er tilgængelig, fordi det er umuligt at forudsige tidspunktet og formen for katastrofen, og det er nødvendigt at tage forholdsregler på forhånd for at forhindre forskellige nødsituationer, så SQL Server tilbyder en række højtilgængelighedsteknologier, disse teknologier omfatter hovedsageligt: klyngedannelse, replikering, spejling, loglevering, AlwaysOn-tilgængelighedsgrupper og andre såsom filgruppebackup og -gendannelse, Enkeltinstans-højtilgængelighedsteknologier såsom online genopbygningsindekser. Brugen af højtilgængelighedsteknologi er ikke for at vælge en velkendt teknologi til direkte brug, men for at overveje forretningen og teknologien grundigt. Fordi der ikke findes én teknologi, der kan udføre alle funktioner. Hvordan man tager disse teknologier i brug baseret på din specifikke virksomhed og dit budget, kaldes en high availability-strategi.

Når du designer en strategi for høj tilgængelighed, bør du først overveje følgende faktorer:

• RTO (Recovery Time Objective) – det vil sige genopretningstidsmål – betyder, hvor meget nedetid der er tilladt, normalt udtrykt med nogle få 9'ere, for eksempel betyder 99,999% tilgængelighed højst 5 minutters nedetid om året, 99,99% tilgængelighed betyder højst 52,5 minutters nedetid om året, og 99,9% tilgængelighed betyder højst 8,75 timers nedetid om året. Det er værd at bemærke, at beregningsmetoden for RTO tager højde for, om systemet er 24*365 eller kun fra kl. 6 til 21 osv. Du skal også være opmærksom på, om vedligeholdelsesvinduet tælles som nedetid, og det er lettere at opnå højere tilgængelighed, hvis databasevedligeholdelse og patching er tilladt i vedligeholdelsesvinduet.
• RPO (Recovery Point Objective) – Også kendt som recovery point objective, betyder hvor meget datatab der er tilladt. Normalt, så længe du laver en god backup, kan du nemt opnå nul datatab. Men når en katastrofe opstår, afhængigt af omfanget af databasekorruptionen, vil den tid, det tager at gendanne data fra en backup, gøre databasen utilgængelig, hvilket vil påvirke implementeringen af RTO. Et tidligt og mere kendt eksempel er et banksystem i Europa og USA, hvor man kun tager hensyn til RPO, der kun er fulde backups og log-backups i systemet, fulde backups hver 3. måned, log-backups hvert 15. minut, og når en katastrofe indtræffer, kan kun fulde backups og logbackups gendanne data, så selvom der ikke er noget datatab, men fordi det tog to hele dage at gendanne data, var banksystemet utilgængeligt i 2 dage, så et stort antal kunder gik tabt. Et andet modsat eksempel er en indenlandsk online videohjemmeside, der bruger SQL Server som back-end relationel database, front-end bruger No-SQL og importerer regelmæssigt No-SQL-data til den relationelle database som backup.
  

    Budget – RTO og RPO kaldes samlet for SLA'er (Service Level Agreements), og når du designer en strategi for høj tilgængelighed, skal du måle, hvor godt du opfylder SLA'er baseret på din virksomhed, afhængigt af dit budget og måle omkostningerne ved forskellige SLA'er i tilfælde af en fejl. Generelt er det svært at opnå høje SLA'er med et begrænset budget, og selvom høje SLA'er opnås gennem komplekse arkitekturer, betyder komplekse arkitekturer også høje drifts- og vedligeholdelsesomkostninger, så det er nødvendigt at vælge den rette teknologi inden for budgettet for at opfylde SLA'erne.

Derfor kan det store rammeværk for høj tilgængelighed generelt bestemmes ved flere ordre-takningsspørgsmål:

• Hvad er den nedetid, som aktionærerne er villige til at acceptere?
• Hvilken nedetid er acceptabel for ledere?
• Hvad er budgettet, der er afsat til et højtilgængelighedsscenarie?
• Hvor stort er tabet pr. time på grund af nedetid?
  

• Kold backup: Standby-serveren er konfigureret til at acceptere data fra primærserveren, og når det fejler, gendannes dataene manuelt til primærdatabasen eller programmets forbindelsesstreng eller tilladelser for at bringe backup-databasen online.
• Varm backup: Primærserverens data vil kontinuerligt sende logfiler til backupserveren (med uregelmæssige intervaller, det kan være 15 minutter, 30 minutter, 1 minut osv.), på denne måde opdateres primærserveren til backupserveren normalt asynkront, så dataene fra primærserveren og backupserveren kan ikke garanteres. Derudover implementerer denne metode typisk ikke automatisk fejlovervågning og failover.
• Hot backup: Data fra primærserveren synkroniseres automatisk på backup-serveren, og i de fleste tilfælde er automatisk fejlovervågning og failover inkluderet, og datakonsistensen for primærserveren og backup-serveren kan garanteres.
  

    Fra kolde til varme til varme backups skyder omkostningerne i vejret.

    De højtilgængelighedsfunktioner, der understøttes i SQL Server, er tæt beslægtede med versionen, og Enterprise-udgaven understøtter alle funktioner med høj tilgængelighed, herunder:

• Failover-klynge
• l Databasebillede
• l Transaktionslogoverførsel
• l Databasesnapshots
• Høj tilgængelighed opgraderinger
• l Hot load-hukommelse
• l Online indekseringsoperationer
• l Database delvist online (kun masterfilgruppe eller masterfilgruppe samt yderligere NDF-filer gendannes)
  

    For specifikke versioner af disse højtilgængelighedsfunktioner, se:http://msdn.microsoft.com/zh-cn/library/cc645993.aspxDet er værd at bemærke, at den gratis Express-version kan fungere som en vidneserver til databasespejling, hvilket resulterer i besparelser.

Failover-klynge

    Failover-klynger giver høj tilgængelighedsunderstøttelse for hele SQL Server-instansen, hvilket betyder, at en SQL Server-instans på en node i klyngen går over til andre noder i klyngen på grund af hardwarefejl, operativsystemfejl osv. Høj tilgængelighed opnås ved, at flere servere (noder) deler en eller flere diske, og failover-klynger optræder i netværket på samme måde som en enkelt computer, men med høje tilgængelighedskarakteristika. Det er vigtigt at bemærke, at da failover-klynger er baseret på delte diske, er der et enkelt punkt for diskfejl, så yderligere beskyttelser som SAN-replikering skal implementeres på diskniveau. Den mest almindelige failover-klynge er en to-node failover-klynge, inklusive master og slave.

Transaktionslogoverførsel

    Transaktionslogforsendelse giver databaseniveau høj tilgængelighedsbeskyttelse. Logning bruges til at vedligeholde en eller flere standby-databaser (kaldet "sekundære databaser") for den tilsvarende produktionsdatabase (kaldet "primærdatabasen"). Før en failover sker, skal den sekundære database opdateres fuldt ud ved manuelt at anvende alle uoprettede logbackups. Loglevering har fleksibiliteten til at understøtte flere standby-databaser. Hvis der kræves flere alternative databaser, kan loglevering bruges separat eller som supplement til databasespejling. Når disse løsninger bruges sammen, er hoveddatabasen for den aktuelle databasespejlingskonfiguration også den primære database for den nuværende logforsendelseskonfiguration.

    Transaktionsloglevering kan bruges til at lave kolde og varme backups.

Databasespejling

    Databasespejling er faktisk en softwareløsning, der også tilbyder databasebeskyttelse og næsten øjeblikkelig failover for at forbedre databasens tilgængelighed. En databasespejl kan bruges til at vedligeholde en enkelt standby-database (eller "spejldatabase") for den tilsvarende produktionsdatabase (kaldet "principal database").
Fordi spejldatabasen altid er i gendannelsestilstand, men databasen ikke gendannes, kan spejl-databasen ikke tilgås direkte. Men til skrivebeskyttede indlæsninger som rapporter kan du indirekte bruge den spejlede database ved at oprette et databasesnapshot af den spejlede database. Databasesnapshots giver klienter skrivebeskyttet adgang til dataene i databasen, når snapshot'et oprettes. Hver databasespejlingskonfiguration involverer en "principal server", der indeholder principal-databasen, og også en mirror-server, der indeholder den spejlede database. Spejlserveren opdaterer løbende spejl-databasen med hoveddatabasen.
    Databasespejling kører synkron drift i højsikkerhedstilstand eller asynkron drift i højtydende tilstand. I højtydende tilstand behøver transaktioner ikke vente på, at spejlserveren skriver logfiler til disken, før de kan indsendes, hvilket maksimerer ydeevnen. I højsikkerhedstilstand bliver forpligtede transaktioner forpligtet af begge partnere, men transaktionsforsinkelsen er forlænget. Den simpleste konfiguration af databasespejling involverer kun hovedserveren og spejlserveren. I denne konfiguration, hvis hovedserveren går tabt, kan spejlserveren bruges som standby-server, men det kan forårsage datatab. Højsikkerhedstilstand understøtter standby-konfiguration, højsikkerhedstilstand med automatisk failover. Denne konfiguration involverer en tredjeparts serverinstans kaldet en "vidneserver", som gør det muligt at bruge mirror-serveren som hot backup-server. Failover fra den primære database til spejldatabasen tager typisk et par sekunder.

    Databasespejling kan bruges til både varme og varme backups.

eksemplar

    Replikering er ikke strengt taget en funktion designet til høj tilgængelighed, men den kan anvendes på høj tilgængelighed. Replikering giver beskyttelse på databaseobjektniveau. Replikation bruger en publicish-subscribe-model, hvor data udgives af den primære server, kendt som udgiveren, til en eller flere sekundære abonnenter. Replikering giver realtidstilgængelighed og skalerbarhed mellem disse servere. Den understøtter filtrering for at levere et delmængde af data til abonnenter, samtidig med at den understøtter partitionsopdateringer. Abonnenten er online og tilgængelig for rapportering eller andre funktioner uden forespørgselsgenvinding. SQL Server tilbyder fire replikationstyper: snapshot-replikering, transaktionel replikation, peer-to-peer-replikering og merge-replikering.

AlwaysOnBrugervenlighedsgruppe

    AlwaysOn Tilgængelighedsgrupper er en ny funktion, der blev introduceret i SQL Server 2012. Der tilbydes også beskyttelse på databaseniveau. Den udvider også grænsen for, at databasespejling kun kan være 1:1, så én primær replika kan svare til op til 4 sekundære replikaer (i SQL Server 2014 udvides denne grænse til 8), hvoraf 2 sekundære replikaer kan synkroniseres som hot backups og primære replikaer i realtid, og de to andre asynkrone sekundære replikaer kan bruges som varme backups. Derudover kan sekundære replikaer konfigureres som skrivebeskyttede og bruges til at håndtere belastningen af backups.

    På grund af dette er databasespejling markeret som "forældet" i SQL Server 2012.

    Efter at have forstået de grundlæggende koncepter om høj tilgængelighed og de højtilgængelighedsteknologier, der tilbydes i SQL Server, lad os se på designet af en strategi for høj tilgængelighed. Planlægning af en strategi for høj tilgængelighed kan opdeles i fire faser:

Indsamlingskrav

    Det første skridt i beslutningen om en strategi for høj tilgængelighed er uden tvivl at indsamle forretningskrav for at etablere SLA'er. RTO og RPO er de mest kritiske dele, og på dette grundlag etableres realistiske forventninger til tilgængelighedskrav og en realistisk strategi for høj tilgængelighed baseret på disse forventninger.

Vurderingsgrænser

    Vurderingsgrænser er ikke kun begrænset til begrænsningerne for forskellige højtilgængelighedsteknologier i SQL Server, men også til dem, der ikke er tekniske. Hvis du kun har et budget på titusindvis af yuan, men ønsker at lave en højtilgængelighedsløsning baseret på eksterne datacentre og SAN-replikation, er det uden tvivl en tåbelig drøm. En anden ikke-teknisk begrænsning er niveauet af operationspersonale, og ofte betyder komplekse arkitekturer mere kvalificeret operationspersonale. Andre ikke-tekniske begrænsninger inkluderer tilgængeligheden af diskplads i datacentret, om strømforsyning og aircondition kan opfylde behovene, samt den tid, der kræves for at implementere tilgængelighedsstrategien.

    Tekniske begrænsninger inkluderer forskellige højtilgængelighedsfunktioner og begrænsninger, funktioner understøttet af forskellige SQL Server-versioner, antallet af CPU'er og hukommelsesstørrelsen. Det anbefales kraftigt, at du først undersøger begrænsningerne for forskellige SQL Server-versioner og funktioner på Microsoft MSDN-hjemmesiden, før du implementerer en højtilgængelighedspolitik.

Udvalgt teknologi

    Efter at have indsamlet krav og vurderet begrænsninger, er næste skridt at vælge de teknologier eller kombinationer af teknologier, der blev beskrevet tidligere i denne artikel, for at opfylde SLA-kravene. Hvis den valgte teknologi ikke opfylder SLA'en, er det nemt at rapportere, hvilke begrænsninger der ikke opfylder SLA'en, hvilket giver dig mulighed for at anmode om manglende ressourcer eller gå på kompromis med SLA'en.

Test, valider og dokumenter

    Højtilgængelighedspolitikker skal grundigt testes og valideres fra starten for at sikre, at nuværende tilgængelighedspolitikker opfylder SLA'er. Når en højtilgængelighedsstrategi lanceres, er det dog også nødvendigt regelmæssigt at teste og validere den for at sikre, at den nuværende politik stadig kan opfylde SLA'er trods datavækst, forretnings- eller kravændringer. Samtidig bør konfigurationen af tilgængelighedsløsningen, failover-metoden og katastrofeberedskabsplanen dokumenteres samtidig, så den kan spores i tilfælde af fejl eller fremtidig justering af højtilgængelighedsstrategien.

Denne artikel forklarer de grundlæggende begreber om høj tilgængelighed, begrebet SLA'er, de forskellige typer højtilgængelighedsfunktioner, der understøttes i SQL Server, og de trin, der kræves for at designe en strategi for høj tilgængelighed. Det er værd at bemærke, at selvom denne artikel kun omtaler høj tilgængelighed på databaseniveau, er høj tilgængelighed ikke kun et spørgsmål for DBA, men omfatter også samarbejde mellem forskellige roller såsom systemdrifts- og vedligeholdelsespersonale, netværksadministratorer, udviklere og ledere for bedre at opfylde SLA'er.