[Kilde] Høy tilgjengelighet i SQL Server (1) ---- en oversikt over høy tilgjengelighet

Siden SQL Server 2005 har Microsoft levert en rekke høytilgjengelighetsteknologier for å redusere nedetid og øke beskyttelsen av forretningsdata, og med den kontinuerlige lanseringen av SQL Server 2008, SQL Server 2008 R2 og SQL Server 2012 finnes det mange høytilgjengelighetsteknologier i SQL Server for å møte ulike scenarioer.

    Før jeg begynner på denne artikkelen, vil jeg gi en kort oversikt over hva som avgjør hvilken høytilgjengelighetsteknologi man skal bruke.

    Mange selskaper trenger at all eller deler av dataene sine er høyt tilgjengelige, som nettbutikker, og nettbaserte produktdatabaser må være tilgjengelige døgnet rundt, ellers i et svært konkurransepreget marked betyr nedetid tap av kunder og inntekter. For eksempel, i et kundesenter som er avhengig av SQL Server, hvis databasen går ned, kan alle innringere bare sitte der og svare kunden «Beklager, systemfeil», noe som også er uakseptabelt.

    Selvfølgelig, i en ideell verden vil all kritisk data være online til enhver tid, men i den virkelige verden vil det være ulike grunner til at databasen ikke er tilgjengelig, fordi det er umulig å forutsi tid og type katastrofe, det er nødvendig å ta tiltak på forhånd for å forhindre ulike nødsituasjoner, så SQL Server tilbyr en rekke høytilgjengelighetsteknologier, disse teknologiene inkluderer hovedsakelig: klynge, replikering, speiling, logglevering, AlwaysOn-tilgjengelighetsgrupper og andre som sikkerhetskopiering og gjenoppretting av filgrupper, Enkeltinstans høytilgjengelighetsteknologier som online gjenoppbyggingsindekser. Bruken av teknologi med høy tilgjengelighet er ikke å velge en kjent teknologi for direkte bruk, men å vurdere virksomheten og teknologien grundig. Fordi det ikke finnes én enkelt teknologi som kan utføre alle funksjoner. Hvordan ta i bruk disse teknologiene basert på din spesifikke virksomhet og budsjett kalles en strategi for høy tilgjengelighet.

Når du designer en strategi for høy tilgjengelighet, bør du først vurdere følgende faktorer:

• RTO (Recovery Time Objective) – det vil si gjenopprettingstidsmålet, betyr hvor mye nedetid som er tillatt, vanligvis uttrykt med noen få 9-ere, for eksempel betyr 99,999 % tilgjengelighet ikke mer enn 5 minutter nedetid per år, 99,99 % tilgjengelighet betyr ikke mer enn 52,5 minutter nedetid per år, og 99,9 % tilgjengelighet betyr ikke mer enn 8,75 timer nedetid per år. Det er verdt å merke seg at beregningsmetoden for RTO tar hensyn til om systemet er 24*365 eller bare fra kl. 06.00 til 21.00, osv. Du må også være oppmerksom på om vedlikeholdsvinduet regnes som nedetid, og det er lettere å oppnå høyere tilgjengelighet hvis databasevedlikehold og patching er tillatt i vedlikeholdsvinduet.
• RPO (Recovery Point Objective) – Også kjent som recovery point objective, betyr hvor mye datatap som er tillatt. Vanligvis, så lenge du lager en god sikkerhetskopi, kan du lett oppnå null datatap. Men når en katastrofe inntreffer, avhengig av omfanget av databasekorrupsjonen, vil tiden det tar å gjenopprette data fra en sikkerhetskopi føre til at databasen blir utilgjengelig, noe som vil påvirke implementeringen av RTO. Et tidlig og mer kjent eksempel er et banksystem i Europa og USA, som kun tar hensyn til RPO, det finnes kun fullstendige sikkerhetskopier og loggsikkerhetskopier i systemet, fullstendige sikkerhetskopier hver 3. måned, loggsikkerhetskopier hvert 15. minutt, når en katastrofe inntreffer, kan kun fullstendige sikkerhetskopier og loggsikkerhetskopier gjenopprettes data, så selv om det ikke er datatap, men fordi det tok to hele dager å gjenopprette data, var banksystemet utilgjengelig i to dager, så mange kunder gikk tapt. Et annet motsatt eksempel er et innenlandsk nettbasert videonettsted, som bruker SQL Server som backend-relasjonsdatabase, front-end bruker No-SQL, og importerer jevnlig No-SQL-data til relasjonsdatabasen som backup.
  

    Budsjett – RTO og RPO er samlet kjent som SLAs (Service Level Agreements), og når du designer en strategi for høy tilgjengelighet, må du måle hvor godt du oppfyller SLAs basert på virksomheten din, avhengig av budsjettet ditt og måle kostnaden for ulike SLA-er ved en feil. Generelt er det vanskelig å oppnå høye SLA-er med et begrenset budsjett, og selv om høye SLA-er oppnås gjennom komplekse arkitekturer, betyr komplekse arkitekturer også høye drifts- og vedlikeholdskostnader, så det er nødvendig å velge riktig teknologi innenfor budsjettet for å oppfylle SLA-ene.

Derfor kan det store rammeverket for høy tilgjengelighet generelt bestemmes av flere ordretakingsspørsmål:

• Hva er nedetiden aksjonærene er villige til å akseptere?
• Hvilken nedetid er akseptabel for ledere?
• Hva er budsjettet som settes av for et scenario med høy tilgjengelighet?
• Hvor mye er tapet per time på grunn av nedetid?
  

• Kald backup: Standby-serveren er konfigurert til å akseptere data fra primærserveren, og når det feiler, gjenopprettes dataene manuelt til primærdatabasen, eller tilkoblingsstrengen eller tillatelsene til programmet rekonfigureres for å bringe backup-databasen online.
• Varm backup: Primærserverdataene vil kontinuerlig sende logger til backup-serveren (med uregelmessige intervaller, det kan være 15 minutter, 30 minutter, 1 minutt osv.), på denne måten oppdateres vanligvis primærserveren til backup-serveren asynkront, så dataene til primærserveren og backup-serveren kan ikke garanteres. I tillegg implementerer denne ordningen vanligvis ikke automatisk feilovervåking og failover.
• Hot backup: Dataene til primærserveren synkroniseres automatisk på backup-serveren, og i de fleste tilfeller er automatisk feilovervåking og failover inkludert, og datakonsistensen til primærserveren og backup-serveren kan garanteres.
  

    Fra kald til varm til varm backup, kostnadene skyter i været.

    De høytilgjengelighetsfunksjonene som støttes i SQL Server er nært beslektet med versjonen, og Enterprise-utgaven støtter alle funksjoner med høy tilgjengelighet, inkludert:

• Failover-klynge
• l Databasebilde
• l Transaksjonsloggoverføring
• l Databasesnapshots
• Oppgraderinger med høy tilgjengelighet
• l Hot load-minne
• l Nettbaserte indekseringsoperasjoner
• l Database delvis online (kun masterfilgruppe eller masterfilgruppe og ytterligere NDF-filer gjenopprettes)
  

    For spesifikke versjoner av disse funksjonene med høy tilgjengelighet, se:http://msdn.microsoft.com/zh-cn/library/cc645993.aspxDet er verdt å merke seg at den gratis Express-versjonen kan fungere som en vitneserver for databasespeiling, noe som gir kostnadsbesparelser.

Failover-klynge

    Failover-klynger gir høy tilgjengelighetsstøtte for hele SQL Server-instansen, noe som betyr at en SQL Server-instans på en node i klyngen går over til andre noder i klyngen på grunn av maskinvarefeil, operativsystemfeil osv. Høy tilgjengelighet oppnås ved at flere servere (noder) deler én eller flere disker, og failover-klynger opptrer i nettverket på samme måte som en enkelt datamaskin, men med høy tilgjengelighetsegenskaper. Det er viktig å merke seg at siden failover-klynger er basert på delte disker, finnes det et enkelt punkt for diskfeil, så ytterligere beskyttelser som SAN-replikering må implementeres på disknivå. Den vanligste failover-klyngen er en to-node failover-klynge, inkludert master og slave.

Transaksjonsloggoverføring

    Transaksjonslogg gir databasenivå høy tilgjengelighetsbeskyttelse. Logging brukes til å vedlikeholde en eller flere standby-databaser (kalt "sekundærdatabaser") for den tilsvarende produksjonsdatabasen (kalt "primærdatabasen"). Før en failover skjer, må den sekundære databasen oppdateres fullstendig ved manuelt å anvende alle ugjenopprettede loggsikkerhetskopier. Logglevering har fleksibilitet til å støtte flere standby-databaser. Hvis flere alternative databaser er nødvendige, kan logglevering brukes separat eller som et supplement til databasespeiling. Når disse løsningene brukes sammen, er hoveddatabasen for den nåværende databasespeilingskonfigurasjonen også primærdatabasen for den nåværende loggforsendelseskonfigurasjonen.

    Transaksjonslogglevering kan brukes til å gjøre både kalde og varme sikkerhetskopier.

Databasespeiling

    Databasespeiling er faktisk en programvareløsning som også gir beskyttelse på databasenivå, og gir nesten umiddelbar failover for å forbedre databasetilgjengeligheten. Et databasespeil kan brukes til å opprettholde en enkelt standby-database (eller "speildatabase") for den tilsvarende produksjonsdatabasen (kalt "hoveddatabasen").
Siden speildatabasen alltid er i gjenopprettingstilstand, men databasen ikke er gjenopprettet, kan ikke speildatabasen aksesseres direkte. For skrivebeskyttede laster som rapporter kan du imidlertid bruke den speilede databasen indirekte ved å lage et databasesnapshot av den speilede databasen. Databasesnapshots gir klienter skrivebeskyttet tilgang til dataene i databasen når snapshotet opprettes. Hver databasespeilingskonfigurasjon involverer en "hovedserver" som inneholder hoveddatabasen, og også en speilserver som inneholder den speilede databasen. Speilserveren oppdaterer kontinuerlig speildatabasen med hoveddatabasen.
    Databasespeiling kjører synkron drift i høysikkerhetsmodus eller asynkron drift i høyytelsesmodus. I høyytelsesmodus trenger ikke transaksjoner å vente på at speilserveren skal skrive logger til disken før de kan sendes inn, noe som maksimerer ytelsen. I høysikkerhetsmodus forpliktes forpliktede transaksjoner av begge partnere, men transaksjonsforsinkelsen er forlenget. Den enkleste konfigurasjonen av databasespeiling involverer kun hovedserveren og speilserveren. I denne konfigurasjonen, hvis hovedserveren går tapt, kan speilserveren brukes som standby-server, men det kan føre til datatap. Høysikkerhetsmodus støtter standby-konfigurasjon, høysikkerhetsmodus med automatisk failover. Denne konfigurasjonen involverer en tredjeparts serverinstans kalt en "witness server" som gjør det mulig å bruke speilserveren som en hot backup-server. Failover fra primærdatabasen til speildatabasen tar vanligvis noen sekunder.

    Databasespeiling kan brukes for både varme og varme sikkerhetskopier.

kopi

    Replikering er ikke strengt tatt en funksjon designet for høy tilgjengelighet, men den kan anvendes på høy tilgjengelighet. Replikering gir beskyttelse på databaseobjektnivå. Replikasjon bruker en publish-subscribe-modell, hvor data publiseres av primærserveren, kjent som utgiveren, til en eller flere sekundære abonnenter. Replikering gir sanntidstilgjengelighet og skalerbarhet mellom disse serverne. Den støtter filtrering for å gi et delsett av data til abonnenter, samtidig som den støtter partisjonsoppdateringer. Abonnenten er online og tilgjengelig for rapportering eller andre funksjoner uten gjenoppretting av forespørsler. SQL Server tilbyr fire replikasjonstyper: snapshot-replikasjon, transaksjonsreplikasjon, peer-to-peer-replikering og merge-replikasjon.

AlwaysOnBrukervennlighetsgruppe

    AlwaysOn Availability Groups er en ny funksjon introdusert i SQL Server 2012. Beskyttelse på databasenivå tilbys også. Den utvider også grensen for at databasespeiling kun kan være 1:1, slik at én primær replika kan tilsvare opptil 4 sekundære replikaer (i SQL Server 2014 utvides denne grensen til 8), hvorav 2 sekundærkopier kan synkroniseres som hot-backuper og primærreplikaer i sanntid, og de to andre asynkrone sekundærreplikaene kan brukes som varme sikkerhetskopier. I tillegg kan sekundære replikaer konfigureres som skrivebeskyttet og brukes til å håndtere belastningen av sikkerhetskopier.

    På grunn av dette er databasespeiling merket som «foreldet» i SQL Server 2012.

    Etter å ha forstått de grunnleggende konseptene for høy tilgjengelighet og de høytilgjengelighetsteknologiene som tilbys i SQL Server, la oss se på utformingen av en strategi for høy tilgjengelighet. Planlegging av en strategi for høy tilgjengelighet kan deles inn i fire faser:

Innsamlingskrav

    Det første steget i å bestemme en strategi for høy tilgjengelighet er utvilsomt å samle forretningsbehov for å etablere SLA-er. RTO og RPO er de mest kritiske delene, og på dette grunnlaget etableres realistiske forventninger til tilgjengelighetskrav og etableres en realistisk strategi for høy tilgjengelighet basert på disse forventningene.

Vurderingsgrenser

    Vurderingsgrenser er ikke bare begrenset til begrensningene til ulike høytilgjengelighetsteknologier i SQL Server, men også til de som ikke er tekniske. Hvis du bare har et budsjett på titusenvis av yuan, men ønsker å lage en løsning med høy tilgjengelighet basert på eksterne datasentre og SAN-replikasjon, er det utvilsomt en dårdrøm. En annen ikke-teknisk begrensning er nivået på driftspersonell, og ofte betyr komplekse arkitekturer mer kvalifiserte driftspersonell. Andre ikke-tekniske begrensninger inkluderer tilgjengeligheten av diskplass i datasenteret, om strømforsyning og klimaanlegg kan dekke behovene, og tiden som kreves for å implementere tilgjengelighetsstrategien.

    Tekniske begrensninger inkluderer ulike høytilgjengelighetsfunksjoner og begrensninger, funksjoner støttet av ulike SQL Server-versjoner, antall CPU-er og minnestørrelse. Det anbefales sterkt at du først undersøker begrensningene for ulike SQL Server-versjoner og funksjoner på Microsoft MSDN-nettsiden før du implementerer en høytilgjengelighetspolicy.

Utvalgt teknologi

    Etter å ha samlet inn krav og vurdert begrensninger, er neste steg å velge teknologier eller kombinasjoner av teknologier beskrevet tidligere i denne artikkelen for å oppfylle SLA-kravene. Hvis den valgte teknologien ikke oppfyller SLA-en, er det enkelt å rapportere hvilke begrensninger som ikke oppfyller SLA-en, slik at du kan be om manglende ressurser eller inngå kompromiss på SLA-en.

Test, valider og dokumenter

    Retningslinjer for høy tilgjengelighet må grundig testes og valideres fra starten av for å sikre at dagens tilgjengelighetspolicyer oppfyller SLA-er. Men når en strategi for høy tilgjengelighet lanseres, er det også nødvendig å regelmessig teste og validere den for å sikre at den nåværende policyen fortsatt kan oppfylle SLA-er til tross for datavekst, forretnings- eller kravendringer. Samtidig bør konfigurasjonen av tilgjengelighetsløsningen, failovermetoden og katastrofegjenopprettingsplanen dokumenteres samtidig slik at den kan spores ved feil eller fremtidig justering av høytilgjengelighetsstrategien.

Denne artikkelen forklarer de grunnleggende konseptene for høy tilgjengelighet, konseptet med SLA-er, de ulike typene høytilgjengelighetsfunksjoner som støttes i SQL Server, og stegene som kreves for å designe en strategi for høy tilgjengelighet. Det er verdt å merke seg at selv om denne artikkelen kun omtaler høy tilgjengelighet på databasenivå, er høy tilgjengelighet ikke bare et spørsmål for DBA, men inkluderer også samarbeid mellom ulike roller som systemdrifts- og vedlikeholdspersonell, nettverksadministratorer, utviklere og ledere for bedre å oppfylle SLA-er.