[Avots] Augsta pieejamība SQL Server (1) ---- pārskats par augstu pieejamību

Kopš SQL Server 2005 Microsoft ir nodrošinājusi dažādas augstas pieejamības tehnoloģijas, lai samazinātu dīkstāvi un palielinātu biznesa datu aizsardzību, un, nepārtraukti izlaižot SQL Server 2008, SQL Server 2008 R2 un SQL Server 2012, SQL Server ir daudz augstas pieejamības tehnoloģiju, lai atbilstu dažādiem scenārijiem.

    Pirms sāku šo rakstu, es sākšu ar īsu pārskatu par to, kas nosaka, kuru augstas pieejamības tehnoloģiju izmantot.

    Daudziem uzņēmumiem ir nepieciešams, lai visi dati vai daļa no tiem būtu ļoti pieejami, piemēram, tiešsaistes iepirkšanās vietnēm, tiešsaistes produktu datubāzēm jābūt tiešsaistē 24 stundas diennaktī, 7 dienas nedēļā, pretējā gadījumā ļoti konkurētspējīgā tirgus vidē dīkstāve nozīmē zaudētus klientus un ieņēmumus. Piemēram, zvanu centrā, kas paļaujas uz SQL Server, ja datu bāze pazūd, visi zvanītāji var sēdēt tikai un atbildēt klientam "Atvainojiet, sistēmas kļūme", kas arī ir nepieņemami.

    Protams, ideālā pasaulē visi kritiskie dati vienmēr būs tiešsaistē, bet reālajā pasaulē būs dažādi iemesli, kāpēc datu bāze nebūs pieejama, jo nav iespējams paredzēt katastrofas laiku un formu, ir nepieciešams iepriekš veikt pasākumus, lai novērstu dažādas ārkārtas situācijas, tāpēc SQL Server nodrošina dažādas augstas pieejamības tehnoloģijas, šīs tehnoloģijas galvenokārt ietver: klasterizāciju, replicēšanu, spoguļošanu, žurnālu piegādi, AlwaysOn pieejamības grupas un citus, piemēram, failu grupu dublēšanu un atjaunošanu, Vienas instances augstas pieejamības tehnoloģijas, piemēram, tiešsaistes atjaunošanas indeksi. Augstas pieejamības tehnoloģijas izmantošana nav izvēlēties pazīstamu tehnoloģiju tiešai lietošanai, bet visaptveroši apsvērt biznesu un tehnoloģijas. Jo nav vienas tehnoloģijas, kas varētu sasniegt visas funkcijas. Kā pieņemt šīs tehnoloģijas, pamatojoties uz jūsu konkrēto biznesu un budžetu, ir tā saucamā augstas pieejamības stratēģija.

Izstrādājot augstas pieejamības stratēģiju, vispirms jāņem vērā šādi faktori:

• RTO (Recovery Time Objective) - tas ir, atgūšanas laika mērķis, nozīmē, cik daudz dīkstāves ir atļauts, parasti izteikts ar dažiem 9s, piemēram, 99,999% pieejamība nozīmē ne vairāk kā 5 minūtes dīkstāves gadā, 99,99% pieejamība nozīmē ne vairāk kā 52,5 minūtes dīkstāves gadā, un 99,9% pieejamība nozīmē ne vairāk kā 8,75 stundas dīkstāves gadā. Ir vērts atzīmēt, ka RTO aprēķina metodē tiek ņemts vērā, vai sistēma ir 24*365 vai tikai no 6 līdz 9 vakarā utt. Jums arī jāpievērš uzmanība tam, vai uzturēšanas periods tiek skaitīts kā dīkstāve, un ir vieglāk sasniegt lielāku pieejamību, ja uzturēšanas periodā ir atļauta datu bāzes uzturēšana un ielāpēšana.
• RPO (atkopšanas punkta mērķis) - pazīstams arī kā atkopšanas punkta mērķis, nozīmē, cik liels datu zudums ir atļauts. Parasti, ja veicat labu dublējumu, jūs varat viegli sasniegt nulles datu zudumu. Bet, ja notiek katastrofa, atkarībā no datu bāzes bojājuma apjoma, laiks, kas nepieciešams, lai atjaunotu datus no dublējumkopijas, izraisīs datu bāzes nepieejamību, kas ietekmēs RTO ieviešanu. Agrīns un slavenāks piemērs ir banku sistēma Eiropā un Amerikas Savienotajās Valstīs, tikai ņemot vērā RPO, sistēmā ir tikai pilni dublējumi un žurnālu dublējumi, pilni dublējumi ik pēc 3 mēnešiem, žurnālu dublējumi ik pēc 15 minūtēm, kad notiek katastrofa, tikai ar pilniem dublējumiem un žurnālu dublējumiem var atjaunot datus, tāpēc, lai gan nav datu zuduma, bet tāpēc, ka datu atjaunošanai bija nepieciešamas divas pilnas dienas, banku sistēma nebija pieejama 2 dienas, tāpēc tika zaudēts liels skaits klientu. Vēl viens pretējs piemērs ir vietējā tiešsaistes video vietne, kurā SQL Server tiek izmantots kā aizmugures relāciju datu bāze, priekšgals izmanto No-SQL un regulāri importē No-SQL datus relāciju datu bāzē kā dublējumu.
  

    Budžets - RTO un RPO kopā ir pazīstami kā SLA (pakalpojumu līmeņa līgumi), un, izstrādājot augstas pieejamības stratēģiju, jums ir jānovērtē, cik labi jūs izpildāt SLA, pamatojoties uz jūsu biznesu, atkarībā no jūsu budžeta un dažādu SLA izmaksu mērīšanas neveiksmes gadījumā. Vispārīgi runājot, ir grūti sasniegt augstus SLA ar ierobežotu budžetu, un pat tad, ja augsti SLA tiek sasniegti, izmantojot sarežģītas arhitektūras, sarežģītas arhitektūras nozīmē arī augstas ekspluatācijas un uzturēšanas izmaksas, tāpēc ir jāizvēlas pareizā tehnoloģija budžeta ietvaros, lai izpildītu SLA.

Tāpēc kopumā lielo augstas pieejamības sistēmu var noteikt ar vairākiem pasūtījumu pieņemšanas jautājumiem:

• Kāds ir dīkstāves laiks, ko akcionāri ir gatavi pieņemt?
• Kāds dīkstāves laiks ir pieņemams vadītājiem?
• Kāds ir budžets, kas paredzēts augstas pieejamības scenārijam?
• Cik lieli ir zaudējumi stundā dīkstāves dēļ?
  

• Aukstā dublēšana: gaidstāves serveris ir konfigurēts tā, lai pieņemtu primārā servera datus, un, ja tas neizdodas, manuāli atjaunojiet datus primārajā datu bāzē vai pārkonfigurējiet savienojuma virkni vai programmas atļaujas, lai dublējuma datu bāze būtu tiešsaistē.
• Iesildīšanās dublēšana: Primārie servera dati nepārtraukti pārsūtīs žurnālus uz rezerves serveri (neregulāros intervālos tas var būt 15 minūtes, 30 minūtes, 1 minūte utt.), Tādā veidā primārais serveris uz rezerves serveri parasti tiek atjaunināts asinhroni, tāpēc primārā servera un rezerves servera datus nevar garantēt. Turklāt šī shēma parasti neievieš automātisku kļūdu uzraudzību un kļūmju pārveidošanu.
• Karstā dublēšana: primārā servera dati tiek automātiski sinhronizēti rezerves serverī, un vairumā gadījumu tiek iekļauta automātiska kļūdu uzraudzība un failover, kā arī var garantēt primārā servera un rezerves servera datu konsekvenci.
  

    Tā kā auksti līdz silti līdz karstiem dublējumiem, izmaksas strauji pieaug.

    SQL Server atbalstītie augstas pieejamības līdzekļi ir cieši saistīti ar versiju, un Enterprise izdevums atbalsta visus augstas pieejamības līdzekļus, tostarp:

• Kļūmju klasteris
• l Datu bāzes attēls
• l Darījumu žurnāla pārsūtīšana
• l Datu bāzes momentuzņēmumi
• l Augstas pieejamības jauninājumi
• l Karstās slodzes atmiņa
• l Tiešsaistes indeksēšanas operācijas
• l Datu bāze daļēji tiešsaistē (tiek atjaunota tikai pamatfailu grupa vai pamatfailu grupa un papildu NDF faili)
  

    Konkrētas versijas, kuru augstas pieejamības līdzekļi ir atrodami, skatiet šeit:http://msdn.microsoft.com/zh-cn/library/cc645993.aspxIr vērts atzīmēt, ka bezmaksas Express versija var kalpot kā liecinieku serveris datu bāzes spoguļošanai, kā rezultātā tiek ietaupītas izmaksas.

Kļūmju klasteris

    Kļūmju klasteri nodrošina augstas pieejamības atbalstu visai SQL Server instancei, kas nozīmē, ka SQL Server instance klastera mezglā aparatūras kļūdu, operētājsistēmas kļūdu utt. Augstu pieejamību panāk vairāki serveri (mezgli), kas koplieto vienu vai vairākus diskus, un kļūmju klasteri tīklā parādās tāpat kā viens dators, bet ar augstas pieejamības īpašībām. Ir svarīgi atzīmēt, ka, tā kā kļūmju klasteri ir balstīti uz koplietojamiem diskiem, ir viens diska kļūmes punkts, tāpēc diska līmenī ir jāizvieto papildu aizsardzība, piemēram, SAN replicēšana. Visizplatītākais kļūmju klasteris ir divu mezglu kļūmju klasteris, ieskaitot galveno un vergu.

Darījumu žurnāla pārsūtīšana

    Darījumu žurnāla piegāde nodrošina datu bāzes līmeņa augstas pieejamības aizsardzību. Reģistrēšana tiek izmantota, lai uzturētu vienu vai vairākas gaidstāves datu bāzes (sauktas par "sekundārajām datu bāzēm") attiecīgajā ražošanas datu bāzē (saukta par "primāro datu bāzi"). Pirms kļūmjības notiek sekundārā datu bāze ir pilnībā jāatjaunina, manuāli lietojot visus neatjaunotos žurnāla dublējumus. Žurnālu piegāde ir elastīga, lai atbalstītu vairākas gaidstāves datu bāzes. Ja ir nepieciešamas vairākas alternatīvas datu bāzes, žurnālu piegādi var izmantot atsevišķi vai kā papildinājumu datu bāzes spoguļošanai. Ja šie risinājumi tiek izmantoti kopā, pašreizējās datu bāzes spoguļošanas konfigurācijas galvenā datu bāze ir arī pašreizējās žurnālu nosūtīšanas konfigurācijas primārā datu bāze.

    Darījumu žurnāla piegādi var izmantot, lai veiktu aukstu un siltu dublējumu.

Datu bāzes spoguļošana

    Datu bāzes spoguļošana faktiski ir programmatūras risinājums, kas nodrošina arī datu bāzes līmeņa aizsardzību, nodrošinot gandrīz tūlītēju kļūmju, lai uzlabotu datu bāzes pieejamību. Datu bāzes spoguli var izmantot, lai uzturētu vienu gaidstāves datu bāzi (vai "spoguļdatu bāzi") attiecīgajai ražošanas datu bāzei (sauktai par "galveno datu bāzi").
Tā kā spoguļdatu bāze vienmēr ir atjaunošanas stāvoklī, bet datu bāze netiek atjaunota, spoguļdatu bāzei nevar piekļūt tieši. Tomēr tikai lasāmām ielādēm, piemēram, atskaitēm, spoguļoto datu bāzi var izmantot netieši, izveidojot spoguļotās datu bāzes momentuzņēmumu. Datu bāzes momentuzņēmumi nodrošina klientiem tikai lasāmu piekļuvi datu bāzes datiem, kad momentuzņēmums tiek izveidots. Katra datu bāzes spoguļošanas konfigurācija ietver "galveno serveri", kas satur galveno datu bāzi, kā arī spoguļserveri, kas satur spoguļdatu bāzi. Spoguļserveris nepārtraukti atjaunina spoguļa datu bāzi ar galveno datu bāzi.
    Datu bāzes spoguļošana darbojas sinhronā darbībā augstas drošības režīmā vai asinhronā darbībā augstas veiktspējas režīmā. Augstas veiktspējas režīmā transakcijām nav jāgaida, kamēr spoguļserveris ieraksta žurnālus diskā, pirms tos var iesniegt, kas maksimāli palielina veiktspēju. Augstas drošības režīmā saistītus darījumus veic abi partneri, bet darījuma kavēšanās laiks tiek pagarināts. Vienkāršākā datu bāzes spoguļošanas konfigurācija ietver tikai galveno serveri un spoguļserveri. Šajā konfigurācijā, ja galvenais serveris tiek zaudēts, spoguļserveri var izmantot kā gaidstāves serveri, bet tas var izraisīt datu zudumu. Augstas drošības režīms atbalsta gaidīšanas konfigurāciju, augstas drošības režīmu ar automātisku kļūmi. Šī konfigurācija ietver trešās puses servera instanci, ko sauc par "liecinieku serveri", kas ļauj spoguļserveri izmantot kā karstu rezerves serveri. Pāreja no primārās datu bāzes uz spoguļdatu bāzi parasti aizņem dažas sekundes.

    Datu bāzes spoguļošanu var izmantot gan siltiem, gan karstiem dublējumiem.

kopija

    Replikācija nav tikai funkcija, kas paredzēta augstai pieejamībai, bet to var piemērot augstai pieejamībai. Replicēšana nodrošina datu bāzes objekta līmeņa aizsardzību. Replikācija izmanto publicēšanas un abonēšanas modeli, kurā primārais serveris, kas pazīstams kā izdevējs, publicē datus vienam vai vairākiem sekundārajiem vai abonentiem. Replicēšana nodrošina reāllaika pieejamību un mērogojamību starp šiem serveriem. Tas atbalsta filtrēšanu, lai abonentiem nodrošinātu datu apakškopu, vienlaikus atbalstot arī nodalījuma atjauninājumus. Abonents ir tiešsaistē un pieejams ziņošanai vai citām funkcijām bez vaicājuma atgūšanas. SQL Server piedāvā četrus replikācijas veidus: momentuzņēmumu replicēšanu, transakciju replicēšanu, vienādranga replicēšanu un sapludināšanas replikāciju.

Vienmēr ieslēgtsLietojamības grupa

    AlwaysOn pieejamības grupas ir jauns līdzeklis, kas ieviests SQL Server 2012. Tiek nodrošināta arī datu bāzes līmeņa aizsardzība. Tas arī paplašina ierobežojumu, ka datu bāzes spoguļošana var būt tikai 1:1, lai viena primārā replika varētu atbilst līdz pat 4 sekundārajām replikām (SQL Server 2014 šis ierobežojums tiek paplašināts līdz 8), no kurām 2 sekundārās replikas var sinhronizēt kā karstās dublēšanas un primārās replikas reāllaikā, un pārējās divas asinhronās sekundārās replikas var izmantot kā siltas dublēšanas. Turklāt sekundārās replikas var konfigurēt kā tikai lasāmas un tās var izmantot, lai uzņemtos dublējumu slodzi.

    Šī iemesla dēļ datu bāzes spoguļošana SQL Server 2012 ir atzīmēta kā "novecojusi".

    Pēc tam, kad esat izpratuši augstas pieejamības pamatjēdzienus un augstas pieejamības tehnoloģijas, kas tiek nodrošinātas SQL Server, apskatīsim augstas pieejamības stratēģijas izstrādi. Augstas pieejamības stratēģijas plānošanu var iedalīt četros posmos:

Apkopojiet prasības

    Pirmais solis, lai pieņemtu lēmumu par augstas pieejamības stratēģiju, neapšaubāmi ir apkopot biznesa prasības, lai izveidotu SLA. RTO un RPO ir vissvarīgākās daļas, un, pamatojoties uz to, nosaka reālistiskas prasības attiecībā uz pieejamības prasībām un izveido reālistisku augstas pieejamības stratēģiju, pamatojoties uz šīm cerībām.

Novērtējuma robežas

    Novērtēšanas ierobežojumi attiecas ne tikai uz dažādu augstas pieejamības tehnoloģiju ierobežojumiem SQL Server, bet arī uz tām, kas nav tehniskas. Ja jums ir tikai desmitiem tūkstošu juaņu budžets, bet vēlaties izveidot augstas pieejamības risinājumu, kas balstīts uz neklātienes datu centriem un SAN replikāciju, tas neapšaubāmi ir muļķa sapnis. Vēl viens netehnisks ierobežojums ir operāciju personāla līmenis, un bieži vien sarežģītas arhitektūras nozīmē kvalificētāku operāciju personālu. Citi netehniski ierobežojumi ietver diska vietas pieejamību datu centrā, vai barošanas avots un gaisa kondicionēšana var apmierināt vajadzības, un laiku, kas nepieciešams pieejamības stratēģijas īstenošanai.

    Tehniskie ierobežojumi ietver dažādas augstas pieejamības funkcijas un ierobežojumus, dažādu SQL Server versiju atbalstītās funkcijas, procesoru skaitu un atmiņas lielumu. Pirms augstas pieejamības politikas ieviešanas ieteicams vispirms iepazīties ar dažādu SQL Server versiju un līdzekļu ierobežojumiem Microsoft MSDN vietnē.

Izvēlieties tehnoloģiju

    Pēc prasību apkopošanas un ierobežojumu novērtēšanas nākamais solis ir izvēlēties tehnoloģijas vai tehnoloģiju kombināciju, kas aprakstītas iepriekš šajā rakstā, lai atbilstu SLA prasībām. Ja izvēlētā tehnoloģija neatbilst SLA, ir viegli ziņot, kādi ierobežojumi neatbilst SLA, ļaujot pieprasīt trūkstošos resursus vai kompromisu SLA.

Testēšana, validēšana un dokumentēšana

    Augstas pieejamības politikas ir rūpīgi jāpārbauda un jāapstiprina jau no paša sākuma, lai nodrošinātu, ka pašreizējās pieejamības politikas atbilst SLA. Tomēr, kad tiek uzsākta augstas pieejamības stratēģija, ir arī regulāri jāpārbauda un jāapstiprina, lai nodrošinātu, ka pašreizējā politika joprojām var atbilst SLA, neskatoties uz datu pieaugumu, uzņēmējdarbību vai prasību izmaiņām. Tajā pašā laikā pieejamības risinājuma konfigurācija, kļūmju metode un katastrofas atjaunošanas plāns ir jādokumentē vienlaicīgi, lai to varētu izsekot augstas pieejamības stratēģijas neveiksmes vai turpmākas korekcijas gadījumā.

Šajā rakstā ir izskaidroti augstas pieejamības pamatjēdzieni, SLA jēdziens, dažādi SQL Server atbalstītie augstas pieejamības līdzekļi un darbības, kas nepieciešamas, lai izstrādātu augstas pieejamības stratēģiju. Ir vērts atzīmēt, ka, lai gan šajā rakstā tiek runāts tikai par augstu pieejamību datu bāzes līmenī, augsta pieejamība ir ne tikai DBA jautājums, bet arī ietver dažādu lomu, piemēram, sistēmas darbības un uzturēšanas personāla, tīkla administratoru, izstrādātāju un vadītāju sadarbību, lai labāk izpildītu SLA.