Ievads augstas pieejamības skaitļošanā: jēdzieni un teorija

Vairāk pievērsīsimies dažiem lielākiem kopu pārvaldības arhitektūras principiem, nevis jebkuram atsevišķam tehnoloģiju risinājumam.

Dažus faktiskos ieviešanas variantus mēs redzam vēlāk grāmatā - un jūs varat uzzināt daudz par to, kā tas darbojas Amazon AWS, manā Manning grāmatā Mēneša pusdienas. Bet pagaidām vispirms pārliecinieties, ka mums ir ērti ar pamatiem.

Servera darbību izpilde, izmantojot fizisko vai virtuālo datoru kopas, ir gan uzticamības, gan veiktspējas uzlabošana papildus tam, ko jūs varētu sagaidīt no viena, jaudīga servera. Jūs pievienojat uzticamību, izvairoties no visas infrastruktūras pakāršanas vienā kļūmes punktā (ti, vienā serverī). Un jūs varat palielināt veiktspēju, izmantojot iespēju ļoti ātri palielināt skaitļošanas jaudu un palielinot to.

Tas var notikt, saprātīgi sadalot darba slodzi dažādās ģeogrāfiskās un pieprasījuma vidēs (slodzes līdzsvarošana), nodrošinot

dublējuma serveri, kurus var ātri nodot ekspluatācijā, ja darba mezgls neizdodas (kļūmjpārlēce), optimizējot datu līmeņa izvietošanu vai pieļaujot kļūdu toleranci, izmantojot brīvi savienotas arhitektūras.

Pie visa tā tiksim. Pirmkārt, šeit ir dažas pamata definīcijas:

Mezgls : Viena mašīna (vai nu fiziska, vai virtuāla), kas serveri darbojas neatkarīgi, pati savā operētājsistēmā. Tā kā jebkurš atsevišķs mezgls var neizdoties, pieejamības mērķu sasniegšanai ir nepieciešami vairāki mezgli, kas darbojas kā kopas daļa.

Klasteris : divi vai vairāki servera mezgli, kas darbojas savstarpēji saskaņoti, lai veiktu atsevišķus uzdevumus kā daļu no lielāka pakalpojuma, kur savstarpēja informētība ļauj vienam vai vairākiem mezgliem kompensēt cita zaudēšanu.

Servera kļūme : servera mezgla nespēja atbilstoši reaģēt uz klienta pieprasījumiem. Tas varētu būt saistīts ar pilnīgu avāriju, savienojamības problēmām vai tāpēc, ka to ir pārņēmis liels pieprasījums.

Kļūmjpārlēce : veids, kā klasteris cenšas apmierināt klientu vajadzības, kas palikušas bez kļūmes par vienu servera mezglu, palaižot vai novirzot citus mezglus, lai aizpildītu pakalpojumu trūkumu.

Atgriešanās : servera mezgla pienākumu atjaunošana, atgūstoties no kļūmes.

Replikācija : kritisko datu krājumu kopiju izveide, lai nodrošinātu drošu sinhronu piekļuvi no vairākiem servera mezgliem vai klientiem un nodrošinātu, ka viņi pārdzīvo katastrofas. Replikācija tiek izmantota arī, lai nodrošinātu drošu slodzes līdzsvarošanu.

Redundance : vairāku identisku fizisko vai virtuālo serveru mezglu nodrošināšana, no kuriem jebkurš var pieņemt bāreņus no cita klienta, kurš neizdodas.

Sadalītas smadzenes : kļūdas stāvoklis, kurā tīkla komunikācija starp mezgliem vai koplietojamo krātuvi ir kaut kā sadalījusies un vairāki atsevišķi mezgli, katrs uzskatot, ka tas ir vienīgais joprojām aktīvais mezgls, turpina piekļūt kopējam datu avotam un atjaunina to. Lai gan tas neietekmē koplietošanas neko noformējumus, tas var izraisīt klienta kļūdas un datu bojājumus koplietojamās kopās.

Žogi : Lai novērstu smadzeņu sadalīšanu, stonithd dēmonu var konfigurēt automātiski izslēgt nepareizi funkcionējošu mezglu vai uzlikt virtuālu žogu starp to un pārējā klastera datu resursiem. Kamēr pastāv iespēja, ka mezgls joprojām varētu būt aktīvs, bet nav pareizi saskaņots ar pārējo kopu, tas paliks aiz žoga. Stonith nozīmē “Iešaujiet otru mezglu galvā”. Tiešām.

Kvorums : Jūs varat konfigurēt nožogojumu (vai piespiedu izslēgšanu), lai tas tiktu uzlikts mezgliem, kuri ir zaudējuši kontaktu savā starpā vai ar kādu kopīgu resursu. Kvorumu bieži definē kā vairāk nekā pusi no visiem kopas mezgliem. Izmantojot šādas definētas konfigurācijas, jums jāizvairās no diviem mezglu apakškopiem, kuri katrs uzskata, ka cits nedarbojas pareizi, mēģinot izsist otru.

Katastrofu atkopšana y: Jūsu infrastruktūru diez vai var uzskatīt par ļoti pieejamu, ja jums nav izveidota automatizēta dublēšanas sistēma kopā ar integrētu un pārbaudītu katastrofu atkopšanas plānu. Jūsu plānā būs jāņem vērā katra klastera servera pārvietošana.

Aktīvā / pasīvā kopa

Pakalpojuma kļūmes pārņemšanas ideja ir tāda, ka pēkšņu jebkura mezgla zaudēšanu pakalpojumu klasterī ātri kompensētu cits mezgls, kas aizstātu to. Lai tas darbotos, kļūmjpārlēces gadījumā IP adrese tiek automātiski pārvietota uz gaidīšanas mezglu. Alternatīvi, tīkla maršrutēšanas rīkus, piemēram, slodzes līdzsvarotājus, var izmantot, lai novirzītu trafiku prom no neizdevušiem mezgliem. Precīzs kļūmjpārlēces veids ir atkarīgs no tā, kā esat konfigurējis mezglus.

Sākotnēji tikai viens mezgls tiks konfigurēts klientu apkalpošanai un turpinās to darīt viens pats, līdz tas kaut kā neizdosies. Pēc tam atbildība par esošajiem un jaunajiem klientiem (ti, “pāreja”) tiks pārcelta uz pasīvo jeb rezerves mezglu, kas līdz šim tika pasīvi turēts rezervē. Piemērojot modeli vairākiem serveriem vai serveru telpas sastāvdaļām (piemēram, barošanas avotiem), n + 1 atlaišana nodrošina tikai pietiekami daudz resursu pašreizējam pieprasījumam un vēl vienu vienību, lai segtu kļūmi.

Aktīvā / aktīvā kopa

Klasterim, kurā tiek izmantots aktīvs / aktīvs noformējums, būs divi vai vairāki identiski konfigurēti mezgli, kas klientus neatkarīgi apkalpo.

Ja viens mezgls neizdodas, klienti automātiski izveidos savienojumu ar otro mezglu un, ciktāl resursi to atļauj, saņems pilnu piekļuvi resursiem.

Kad pirmais mezgls ir atjaunojies vai nomainīts, klienti atkal tiks sadalīti starp abiem servera mezgliem.

Aktīvo / aktīvo kopu palaišanas galvenā priekšrocība ir spēja efektīvi līdzsvarot slodzi starp mezgliem un pat tīkliem. Slodzes līdzsvarotājs, kas visus klientu pieprasījumus novirza uz pieejamiem serveriem, ir konfigurēts, lai uzraudzītu mezglu un tīkla darbību un izmantotu iepriekš noteiktu algoritmu, lai novirzītu trafiku uz tiem mezgliem, kas to vislabāk spēj apstrādāt. Maršrutēšanas politikas var sekot apļveida modelim, kur klienta pieprasījumi tiek vienkārši mainīti starp pieejamajiem mezgliem vai ar iepriekš iestatītu svaru, kur vienam mezglam ir kāda priekšrocība salīdzinājumā ar citu.

Ja pasīvs mezgls darbojas kā rezerves partneris aktīvā / pasīvā klastera konfigurācijā, tas nodrošina ievērojamu iebūvētu atlaišanu. Ja jūsu darbībai absolūti nepieciešams nepārtraukts serviss un vienmērīgas kļūmes pārejas, tad jūsu mērķim vajadzētu būt kādai aktīvas / pasīvas arhitektūras variācijai.

Koplietojamā un koplietojamā diska kopas

Viens no izplatītās skaitļošanas pamatprincipiem ir izvairīties no tā, ka jūsu darbība balstās uz jebkuru atsevišķu kļūmes punktu. Tas nozīmē, ka katram resursam jābūt vai nu aktīvi atkārtotam (liekam), vai patstāvīgi aizstājamam (kļūmjpārlēcei), un nedrīkst būt neviena elementa, kura kļūme varētu sagraut visu jūsu pakalpojumu.

Tagad iedomājieties, ka jūs izmantojat dažus desmitus mezglu, kas visi savu funkciju veikšanai paļaujas uz vienu datu bāzes serveri. Pat ja jebkura mezglu kļūme neietekmēs to palikušo mezglu veselību, ja datu bāze samazināsies, visa kopa kļūs bezjēdzīga. Mezgli koplietojamā nekā kopas kopienā (parasti) uzturēs savas datubāzes, lai, pieņemot, ka tie tiek pareizi sinhronizēti un konfigurēti pastāvīgai darījumu drošībai, ārēja kļūme tos neietekmēs.

Tas nozīmīgāk ietekmēs slodzes līdzsvarotu kopu, jo katram slodzes līdzsvarotam mezglam ir pastāvīga un kritiska vajadzība pēc vienlaicīgas piekļuves datiem. Pasīvais mezgls vienkāršā kļūmjpārlēces sistēmā tomēr varētu kādu laiku izdzīvot bez piekļuves.

Kaut arī šāda iestatīšana var palēnināt veidu, kā kopa reaģē uz dažiem pieprasījumiem - daļēji tāpēc, ka bailēm no sadalītām smadzenēm var būt nepieciešama periodiska nožogošana, izmantojot akmeni, kompromisu var pamatot ar misiju kritiski svarīgiem izvietojumiem, kur galvenais ir uzticamība.

Pieejamība

Veidojot kopu, jums ir diezgan labi jāapzinās, cik toleranti jūs varat izturēties pret neveiksmēm. Vai, citiem vārdiem sakot, ņemot vērā to cilvēku vai mašīnu vajadzības, kas patērē jūsu pakalpojumus, cik ilgi var notikt pakalpojumu pārtraukums, pirms pūlis izlien caur jūsu priekšējiem vārtiem ar piķa dakšām un liesmojošām lāpām. Tas ir svarīgi zināt, jo atlaišanas apjomam, ko iestrādājat savā dizainā, būs milzīga ietekme uz dīkstāvēm, ar kurām jūs galu galā saskarsieties.

Acīmredzot sistēma, kuru izveidojat pakalpojumam, kas var darboties nedēļas nogalē, nevienam nemanot, ļoti atšķirsies no e-komercijas vietnes, kurai klienti sagaida piekļuvi visu diennakti. Vismaz jums ir jātiecas panākt, lai pieejamības vidējais rādītājs būtu vismaz 99% - dažām darbībām reāli rezultāti ir ievērojami augstāki. Par 99% ilgāku laiku zaudējumi būtu mazāki par četrām dienām no katra gada.

Ir salīdzinoši vienkārša formula, kuru varat izmantot, lai izveidotu noderīgu pieejamības (A) novērtējumu. Ideja ir sadalīt vidējo laiku pirms neveiksmes ar vidējo laiku pirms neveiksmes un vidējo laiku, lai veiktu labošanu.

A = MTBF / (MTBF + MTTR)

Jo tuvāk A vērtība būs 1, jo jūsu klasteris būs ļoti pieejams. Lai iegūtu reālistisku MTBF vērtību, jums, iespējams, būs jāpavada laiks, pakļaujot reālu sistēmu nopietniem sodiem, un uzmanīgi to vērojot, vai nav programmatūras, aparatūras un tīkla kļūmju. Es pieņemu, ka jūs varētu arī iepazīties ar aparatūras pārdevēju vai liela mēroga patērētāju, piemēram, Backblaze, publicēto dzīves cikla metriku, lai iegūtu priekšstatu par to, cik ilgi var sagaidīt stipri lietoto aparatūru.

MTTR būs tā laika produkts, kas nepieciešams jūsu kopai, lai aizstātu neizdevušā servera mezgla funkcionalitāti (process ir līdzīgs, lai arī tas nav identisks katastrofu atkopšanai - kas ir vērsts uz neveiksmīgas aparatūras un savienojamības ātru nomaiņu). Ideālā gadījumā tā būtu vērtība, kas ir pēc iespējas tuvāka nullei sekundes.

Problēma ir tā, ka reālajā pasaulē parasti ir pārāk daudz nezināmu mainīgo, lai šī formula būtu patiesi precīza, jo mezgliem, kuros darbojas dažādas programmatūras konfigurācijas un kas veidoti ar dažāda profila un vecuma aparatūru, būs plašs paredzamais dzīves ilgums. Neskatoties uz to, tas var būt labs rīks, kas palīdzēs jums noteikt savam projektam piemērotāko klastera dizainu.

Izmantojot šo informāciju, jūs varat viegli ģenerēt aprēķinu par to, cik lielu dīkstāves laiku jūsu pakalpojums varētu sagaidīt visa gada laikā.

Saistīts apsvērums, ja izvietojat resursus trešās puses platformu nodrošinātājam, piemēram, VMWare vai Amazon Web Services, ir pakalpojumu sniedzēja Pakalpojuma līmeņa līgums (SLA). Piemēram, Amazon EC2 garantē, ka to skaitļošanas gadījumi un bloķētās veikalu glabāšanas ierīces nodrošinās vismaz 99,95% ikmēneša izmantošanas laiku - tas ir mazāk nekā piecu stundu dīkstāves laiks gadā. AWS izsniedz kredītus mēnešiem, kuru laikā viņi nav izpildījuši savus mērķus - kaut arī ne tuvu, lai kompensētu jūsu dīkstāves kopējās uzņēmējdarbības izmaksas. Izmantojot šo informāciju, jūs varat noorganizēt tādu pakalpojumu atlaišanas līmeni, kas ir piemērots jūsu unikālajām vajadzībām.

Protams, jums kā pakalpojumu sniedzējam saviem klientiem, iespējams, būs jāpublicē sava SLA, pamatojoties uz MTBF un MTTR aplēsēm.

Sesiju apstrāde

Jebkurām servera un klienta attiecībām statisko HTTP sesiju radītie dati ir jāsaglabā tā, lai tie būtu pieejami turpmākajai mijiedarbībai. Klastera arhitektūras var radīt nopietnas sarežģītības šajās attiecībās, jo konkrētais serveris, ar kuru mijiedarbojas klients vai lietotājs, var mainīties starp vienu un otru soli.

Lai to ilustrētu, iedomājieties, ka esat pieteicies vietnē Amazon.com, pārlūkojot viņu grāmatas par LPIC apmācību un periodiski pievienojot vienumu grozam (cerams, ka vairāk šīs grāmatas eksemplāru). Līdz brīdim, kad esat gatavs ievadīt savu maksājumu informāciju un izrakstīties, serveris, kuru izmantojāt pārlūkošanai, var pat vairs nepastāvēt. Kā jūsu pašreizējais serveris uzzinās, kuras grāmatas jūs nolēmāt iegādāties?

Es precīzi nezinu, kā Amazon to rīkojas, taču problēma bieži tiek risināta, izmantojot datu replikācijas rīku, piemēram,

ārējais mezgls (vai mezgli). Mērķis ir nodrošināt pastāvīgu piekļuvi uzticamam un konsekventam datu avotam visiem mezgliem, kuriem tas varētu būt vajadzīgs.

Šis raksts ir pielāgots sadaļā “ Māciet sevi Linux virtualizācijai un augstai pieejamībai: sagatavojieties LPIC-3 304 sertifikācijas eksāmenam ”. Apskatiet citas manas grāmatas par AWS un Linux administrēšanu , tostarp Linux darbībā un Linux kustībā  - hibrīdkurss, kas sastāv no vairāk nekā divu stundu video un aptuveni 40% no Linux darbībā esošā teksta.