[Lähde] Korkea saatavuus SQL Serverissä (1) ---- yleiskatsaus korkeaan saatavuuteen

SQL Server 2005:stä lähtien Microsoft on tarjonnut monipuolisia korkean käytettävyyden teknologioita käyttökatkojen vähentämiseksi ja liiketoimintadatan suojaamisen parantamiseksi, ja SQL Server 2008:n, SQL Server 2008:n ja SQL Server 2012:n jatkuvan julkaisun myötä SQL Serverissä on monia korkean käytettävyyden teknologioita erilaisiin tilanteisiin.

    Ennen kuin aloitan tämän artikkelin, aloitan lyhyellä yleiskatsauksella siitä, mikä määrittää, mitä korkean saatavuuden teknologiaa käytän.

    Monet yritykset tarvitsevat kaiken tai osan datastaan olevan erittäin saatavilla, kuten verkkokaupat, tuotetietokannat ovat verkossa 24/7, muuten erittäin kilpaillussa markkinaympäristössä käyttökatkot tarkoittavat asiakkaiden ja liikevaihdon menetyksiä. Esimerkiksi puhelinpalvelukeskuksessa, joka käyttää SQL Serveriä, jos tietokanta kaatuu, kaikki soittajat voivat vain istua ja vastata asiakkaalle "Anteeksi, järjestelmävika", mikä on myös hyväksymätöntä.

    Tietenkin ihanteellisessa maailmassa kaikki kriittinen data olisi jatkuvasti verkossa, mutta todellisessa maailmassa tietokannan käyttökelvottomuudelle on monia syitä, koska katastrofin aikaa ja muotoa ei voi ennustaa, ja on tarpeen ryhtyä etukäteen toimenpiteisiin erilaisten hätätilanteiden estämiseksi, joten SQL Server tarjoaa monenlaisia korkean käytettävyyden teknologioita. Näihin teknologiaan kuuluvat pääasiassa klusterointi, replikaatio, peilaus, lokien toimitus, AlwaysOn-saatavuusryhmät sekä esimerkiksi tiedostoryhmien varmuuskopiointi ja palautus, Yksittäiset instanssiteknologiat, korkean käytettävyyden teknologiat, kuten verkkopohjaiset uudelleenrakennusindeksit. Korkean käytettävyyden teknologian käyttö ei tarkoita tuttua teknologiaa suoraan käyttöön, vaan liiketoimintaa ja teknologiaa kokonaisvaltaisesti. Koska ei ole olemassa yhtä ainoaa teknologiaa, joka voisi saavuttaa kaikki toiminnot. Näiden teknologioiden käyttöönotto oman yrityksesi ja budjetin perusteella on niin sanottu korkean saatavuuden strategia.

Kun suunnittelet korkean saatavuuden strategiaa, sinun tulisi ensin ottaa huomioon seuraavat tekijät:

• RTO (Recovery Time Objective) – eli toipumisajan tavoite tarkoittaa, kuinka paljon käyttökatkoa sallitaan, yleensä muutamalla 9:llä, esimerkiksi 99,999 % saatavuus tarkoittaa enintään 5 minuuttia käyttökatkoa vuodessa, 99,99 % saatavuus tarkoittaa enintään 52,5 minuuttia käyttökatkoa vuodessa ja 99,9 % saatavuus tarkoittaa enintään 8,75 tuntia käyttökatkoa vuodessa. On syytä huomata, että RTO:n laskentamenetelmä ottaa huomioon, onko järjestelmä 24*365 vai vain klo 6–21 jne. Sinun täytyy myös kiinnittää huomiota siihen, lasketaanko ylläpitoikkuna käyttökatkoksi, ja on helpompi saavuttaa suurempi käytettävyys, jos tietokannan ylläpito ja korjaukset sallitaan ylläpitoikkunan aikana.
• RPO (Recovery Point Objective) – Tunnetaan myös nimellä palautuspisteen tavoite, tarkoittaa sitä, kuinka paljon datan menetystä sallitaan. Yleensä, kunhan teet hyvän varmuuskopion, voit helposti saavuttaa nollan datan menetyksen. Mutta katastrofin sattuessa, tietokannan korruption laajuudesta riippuen varmuuskopiosta palautettava tietokanta menettää tietokannan, mikä vaikuttaa RTO:n toteutukseen. Varhainen ja tunnetumpi esimerkki on pankkijärjestelmä Euroopassa ja Yhdysvalloissa, jossa otetaan huomioon vain RPO, järjestelmässä on vain täydelliset varmuuskopiot ja lokivarmuuskopiot, täydet varmuuskopiot kolmen kuukauden välein, lokivarmuuskopiot 15 minuutin välein, katastrofin sattuessa vain täydelliset varmuuskopiot ja lokivarmuuskopiot voivat palauttaa dataa, joten vaikka tietojen palautus kesti kaksi kokonaista päivää, pankkijärjestelmä oli poissa käytöstä kahteen päivään, joten suuri määrä asiakkaita menetettiin. Toinen vastakkainen esimerkki on kotimainen verkkovideosivusto, joka käyttää SQL Serveriä taustalla olevana relaatiotietokantana, front-end käyttää No-SQL:ää ja tuo säännöllisesti No-SQL-tietoja relaatiotietokantaan varmuuskopioksi.
  

    Budjetti – RTO ja RPO tunnetaan yhdessä nimellä SLA:t (Service Level Agreements), ja kun suunnittelet korkean saatavuuden strategiaa, sinun tulee mitata, kuinka hyvin täytät SLA:t liiketoimintasi perusteella, riippuen budjetistasi ja mittaamalla eri SLA-sopimusten kustannuksia epäonnistumisen sattuessa. Yleisesti ottaen on vaikeaa saavuttaa korkeita SLA-arvoja rajallisella budjetilla, ja vaikka korkeat SLA:t saavutettaisiin monimutkaisilla arkkitehtuureilla, monimutkaiset arkkitehtuurit tarkoittavat myös korkeita käyttö- ja ylläpitokustannuksia, joten budjetin sisällä on valittava oikea teknologia SLA:iden täyttämiseksi.

Siksi yleisesti ottaen suuri viitekehys korkealle saatavuudelle voidaan määrittää useilla tilausten ottamiskysymyksillä:

• Mikä on se seisokki, jonka osakkeenomistajat ovat valmiita hyväksymään?
• Mikä taukoaika on esimiehille hyväksyttävää?
• Mikä on budjetti korkean saatavuuden skenaariolle?
• Kuinka paljon tappio tunnissa on käyttökatkojen takia?
  

• Kylmä varmuuskopiointi: Valmiuspalvelin on konfiguroitu vastaanottamaan ensisijaisen palvelimen tiedot, ja kun se epäonnistuu, palauttaa tiedot manuaalisesti päätietokantaan tai konfiguroida uudelleen ohjelman yhteysmerkkijonon tai käyttöoikeudet varmuuskopiotietokannan saattamiseksi verkkoon.
• Lämmin varmuuskopiointi: Ensisijaiset palvelimen tiedot välittävät jatkuvasti lokitietoja varmuuskopiopalvelimelle (epäsäännöllisin väliajoin, voi olla 15 minuuttia, 30 minuuttia, 1 minuuttia jne.), näin ensisijaiselta palvelimelta varmuuskopiolle päivitetään yleensä asynkronisesti, joten ensisijaisen palvelimen ja varapalvelimen tietoja ei voida taata. Lisäksi tämä järjestelmä ei tyypillisesti toteuta automaattista vikojen seurantaa ja varainkäyttöä.
• Kuuma varmuuskopiointi: Ensisijaisen palvelimen data synkronoidaan automaattisesti varmuuskopiopalvelimella, ja useimmissa tapauksissa automaattinen vikavalvonta ja varajärjestelmä sisältyvät mukana, ja ensisijaisen palvelimen ja varmuuskopiopalvelimen tietojen johdonmukaisuus voidaan taata.
  

    Kylmästä lämpimään ja kuumiin varalaitteisiin kustannukset nousevat räjähdysmäisesti.

    SQL Serverin tukemat korkean käytettävyyden ominaisuudet liittyvät läheisesti versioon, ja Enterprise-versio tukee kaikkia korkean käytettävyyden ominaisuuksia, mukaan lukien:

• Failover-klusteri
• l Tietokantakuva
• l Transaktiolokin siirto
• l Tietokannan snapshotit
• l Korkean saatavuuden päivitykset
• l Lataa muisti kuumana
• l Verkkoindeksointitoiminnot
• l Tietokanta osittain verkossa (vain päätiedostoryhmä tai päätiedostoryhmä sekä lisätiedostot palautetaan)
  

    Tietyistä versioista, joissa on korkea käytettävyys, katso:http://msdn.microsoft.com/zh-cn/library/cc645993.aspxOn syytä huomata, että ilmainen Express-versio voi toimia tietokannan peilauksen todistajapalvelimena, mikä säästää kustannuksia.

Failover-klusteri

    Failover-klusterit tarjoavat korkean käytettävyyden tuen koko SQL Server -instanssille, mikä tarkoittaa, että SQL Server -instanssi klusterin solmussa siirtyy muille solmuille laitevirheiden, käyttöjärjestelmävirheiden jne. vuoksi. Korkea käytettävyys saavutetaan, kun useat palvelimet (solmut) jakavat yhtä tai useampaa levyä, ja varaklusterit ilmestyvät verkkoon samalla tavalla kuin yksi tietokone, mutta niillä on korkeat käytettävyysominaisuudet. On tärkeää huomata, että koska failover-klusterit perustuvat jaettuihin levyihin, levyn vikaantumispiste on vain yksi, joten lisäsuojat, kuten SAN-replikaatio, on otettava käyttöön levytasolla. Yleisin failover-klusteri on kahden solmun failover-klusteri, johon kuuluvat master ja slave.

Transaktiolokin siirto

    Transaktiolokin lähetys tarjoaa tietokantatason korkean saatavuuden suojan. Lokitusta käytetään ylläpitämään yhtä tai useampaa valmiustietokantaa (kutsutaan "toissijaisiksi tietokannoiksi") vastaavasta tuotantotietokannasta (ns. "ensisijainen tietokanta"). Ennen kuin varayhteys tapahtuu, toissijainen tietokanta on päivitettävä kokonaan manuaalisesti soveltamalla kaikki palauttamattomat lokivarmuuskopiot. Lokitoimituksella on joustavuutta tukea useita valmiustietokantoja. Jos tarvitaan useita vaihtoehtoisia tietokantoja, lokitoimitusta voidaan käyttää erikseen tai täydentämään tietokantapeilausta. Kun näitä ratkaisuja käytetään yhdessä, nykyisen tietokannan peilauskonfiguraation pääasiallinen tietokanta on myös nykyisen lokitoimituskonfiguraation ensisijainen tietokanta.

    Tapahtumalokin toimitusta voidaan käyttää sekä kylmä- että lämpimien varmuuskopioiden tekemiseen.

Tietokannan peilaus

    Tietokannan peilaus on itse asiassa ohjelmistoratkaisu, joka tarjoaa myös tietokantatason suojan, tarjoten lähes välittömän varayhteyden tietokannan saatavuuden parantamiseksi. Tietokantapeiliä voidaan käyttää ylläpitämään yhtä valmiustietokantaa (tai "peilitietokantaa") vastaavalle tuotantotietokannalle (jota kutsutaan "päätietokannaksi").
Koska peilitietokanta on aina palautustilassa, mutta tietokantaa ei palauteta, peilitietokantaan ei pääse suoraan käsiksi. Kuitenkin vain luku -latauksissa, kuten raporteissa, peilattua tietokantaa voi käyttää epäsuorasti luomalla peilatun tietokannan tilannekuvan. Tietokannan snapshotit antavat asiakkaille vain luku -oikeuden tietokantaan snapshotin luomisen yhteydessä. Jokainen tietokannan peilauskokoonpano sisältää "pääpalvelimen", joka sisältää päätietokannan, ja lisäksi peilipalvelin, joka sisältää peilatun tietokannan. Peilipalvelin päivittää peilitietokantaa jatkuvasti päätietokannalla.
    Tietokannan peilaus toimii synkronisessa tilassa korkean turvallisuuden tilassa tai asynkronisessa korkean suorituskyvyn tilassa. Korkean suorituskyvyn tilassa transaktioiden ei tarvitse odottaa, että peilipalvelin kirjoittaa lokit levylle ennen kuin ne voidaan lähettää, mikä maksimoi suorituskyvyn. Korkean turvallisuuden tilassa sitoutuneet transaktiot tehdään molempien osapuolten toimesta, mutta transaktioiden viive pitenee. Tietokannan peilauksen yksinkertaisin konfiguraatio sisältää vain pääpalvelimen ja peilipalvelimen. Tässä kokoonpanossa, jos pääpalvelin menetetään, peilipalvelinta voidaan käyttää varapalvelimena, mutta se voi aiheuttaa tietojen menetystä. Korkean turvallisuuden tila tukee valmiustilassa konfigurointia, korkean turvallisuuden tila automaattisella varauksella. Tämä kokoonpano sisältää kolmannen osapuolen palvelininstanssin, jota kutsutaan "todistajapalvelimeksi", ja joka mahdollistaa peilipalvelimen käytön kuumana varmuuskopiopalvelimena. Varasiirtymä ensisijaisesta tietokannasta peilitietokantaan kestää tyypillisesti muutaman sekunnin.

    Tietokannan peilausta voidaan käyttää sekä lämpimiin että kuumiin varmuuskopioihin.

kopioida

    Replikaatio ei ole varsinaisesti ominaisuus, joka on suunniteltu korkeaan saatavuuteen, mutta sitä voidaan soveltaa korkeaan saatavuuteen. Replikaatio tarjoaa tietokantaobjektitason suojan. Replikaatio käyttää julkaise-tilaa-mallia, jossa data julkaistaan ensisijaisen palvelimen, eli julkaisijan, kautta yhdelle tai useammalle toissijaiselle tai tilaajalle. Replikaatio tarjoaa reaaliaikaisen saatavuuden ja skaalautuvuuden näiden palvelimien välillä. Se tukee suodatusta, joka tarjoaa tilaajille osan tiedoista, mutta tukee myös osiopäivityksiä. Tilaaja on verkossa ja käytettävissä raportointiin tai muihin toimintoihin ilman kyselyjen palautusta. SQL Server tarjoaa neljä replikaatiotyyppiä: snapshot-replikaatio, transaktionaalinen replikaatio, vertaisreplikaatio ja yhdistämisreplikaatio.

AlwaysOnKäytettävyysryhmä

    AlwaysOn Availability Groups on uusi ominaisuus, joka esiteltiin SQL Server 2012:ssa. Tietokantatason suojaus on myös tarjolla. Se laajentaa myös rajaa, jonka mukaan tietokantapeilaus voi olla vain 1:1, jolloin yksi ensisijainen replika voi vastata enintään neljää toissijaista replikaatiota (SQL Server 2014:ssä tämä rajoitus on laajennettu 8:aan), joista kaksi toissijaista replikaa voidaan synkronoida kuumina varmuuskopioina ja ensisijaisina replikoina reaaliajassa, ja kaksi muuta asynkronista toissijaista replikaa voidaan käyttää lämpiminä varmuuskopioina. Lisäksi toissijaiset replikat voidaan konfiguroida vain luku -lukuksi ja niitä voidaan käyttää varmuuskopioiden kantamiseen.

    Tästä syystä tietokannan peilaus on merkitty SQL Server 2012:ssa "vanhentuneeksi".

    Kun ymmärrämme korkean saatavuuden peruskäsitteet ja SQL Serverin tarjoamat korkean käytettävyyden teknologiat, tarkastellaan korkean käytettävyyden strategian suunnittelua. Korkean saatavuuden strategian suunnittelu voidaan jakaa neljään vaiheeseen:

Keräysvaatimukset

    Ensimmäinen askel korkean saatavuuden strategian päättämisessä on epäilemättä liiketoiminnan vaatimusten kerääminen SLA:iden määrittämiseksi. RTO ja RPO ovat kriittisimmät osat, ja tämän pohjalta ne asettavat realistiset odotukset saatavuusvaatimuksille ja luodaan realistinen korkean saatavuuden strategia näiden odotusten pohjalta.

Arviointirajat

    Arviointirajat eivät rajoitu vain SQL Serverin erilaisten korkean käytettävyyden teknologioiden rajoituksiin, vaan myös niihin, jotka eivät ole teknisiä. Jos budjettisi on vain kymmeniä tuhansia juania, mutta haluat tehdä korkean saatavuuden ratkaisun, joka perustuu ulkopuolisiin datakeskuksiin ja SAN-replikaatioon, se on epäilemättä turha. Toinen ei-tekninen rajoite on operatiivisen henkilöstön taso, ja usein monimutkaiset arkkitehtuurit tarkoittavat taitavampaa operatiivista henkilöstöä. Muita ei-teknisiä rajoituksia ovat datakeskuksen levytilan saatavuus, virtalähde ja ilmastointi riittävät sekä käytettävyysstrategian toteuttamiseen tarvittava aika.

    Teknisiä rajoituksia ovat erilaiset korkean käytettävyyden toiminnot ja rajoitukset, eri SQL Server -versioiden tukemat toiminnot, suorittimien määrä sekä muistin koko. On vahvasti suositeltavaa, että tutustut ensin eri SQL Server -versioiden ja ominaisuuksien rajoituksiin Microsoftin MSDN-verkkosivustolla ennen korkean käytettävyyden politiikan käyttöönottoa.

Valikoitu teknologia

    Vaatimusten keräämisen ja rajoitteiden arvioinnin jälkeen seuraava vaihe on valita aiemmin tässä artikkelissa kuvatut teknologiat tai niiden yhdistelmä täyttämään SLA-vaatimukset. Jos valittu teknologia ei täytä SLA:ta, on helppo ilmoittaa, mitkä rajoitukset eivät täytä SLA:ta, jolloin voit pyytää puuttuvia resursseja tai tehdä kompromisseja SLA:ssa.

Testaa, validoi ja dokumentoi

    Korkean saatavuuden politiikat on testattava ja validoitava perusteellisesti alusta alkaen, jotta nykyiset saatavuuspolitiikat täyttävät SLA-vaatimukset. Kun korkean saatavuuden strategia käynnistetään, on myös tarpeen testata ja validoida sitä säännöllisesti, jotta varmistetaan, että nykyinen politiikka täyttää SLA-vaatimukset datan kasvusta, liiketoiminnan tai vaatimusten muutoksista huolimatta. Samaan aikaan käytettävyysratkaisun konfiguraatio, varatoimitusmenetelmä ja katastrofipalautussuunnitelma tulisi dokumentoida samanaikaisesti, jotta ne voidaan jäljittää vian sattuessa tai korkean käytettävyyden strategian tulevassa säätämisessä.

Tässä artikkelissa selitetään korkean saatavuuden peruskäsitteet, SLA-käsitteet, SQL Serverin tukemat erilaiset korkean käytettävyyden ominaisuudet sekä korkean saatavuuden strategian suunnittelun vaiheet. On syytä huomata, että vaikka tämä artikkeli käsittelee vain korkeaa saatavuutta tietokantatasolla, korkea saatavuus ei ole vain DBA:n asia, vaan sisältää myös eri roolien, kuten järjestelmän operoinnin ja ylläpidon, verkonylläpitäjien, kehittäjien ja johtajien, yhteistyön SLA-vaatimusten parantamiseksi.