Johdatus korkean käytettävyyden tietojenkäsittelyyn: käsitteet ja teoria

Keskitymme enemmän joihinkin klusterien hallinnan suurempiin arkkitehtuuriperiaatteisiin kuin mihinkään yksittäiseen teknologiaratkaisuun.

Näemme joitain varsinaisia ​​toteutuksia myöhemmin kirjassa - ja voit oppia paljon siitä, miten tämä toimii Amazonin AWS: ssä, Manningin Learn Amazon Web Services -oppaassa kuukauden lounaiden kirjassa. Mutta toistaiseksi varmista ensin, että olemme tyytyväisiä perusasioihin.

Palvelintoimintojen suorittaminen joko fyysisten tai virtuaalisten tietokoneiden klustereiden avulla on sekä luotettavuuden että suorituskyvyn parantamista yhdeltä suuritehoiselta palvelimelta odotettavissa. Voit lisätä luotettavuutta välttämällä koko infrastruktuurin ripustamista yhteen vikapisteeseen (eli yhteen palvelimeen). Ja voit parantaa suorituskykyä kyvyllä lisätä nopeasti laskentatehoa ja kapasiteettia suurentamalla ja pienentämällä.

Tämä voi tapahtua jakamalla työmäärät älykkäästi eri maantieteellisten ja kysyntätilojen (kuormituksen tasapainotus) kesken tarjoamalla

varmuuskopiointipalvelimet, jotka voidaan ottaa nopeasti käyttöön, jos toimiva solmu epäonnistuu (vikasietoisuus), optimoimalla datatason käyttöönottotavan tai sallimalla vikasietoisuuden löyhästi kytkettyjen arkkitehtuurien avulla.

Saamme kaiken sen. Ensinnäkin tässä on kuitenkin joitain perusmääritelmiä:

Solmu : Yksi kone (joko fyysinen tai virtuaalinen), joka suorittaa palvelinta, toimii itsenäisesti omalla käyttöjärjestelmällä. Koska mikä tahansa yksittäinen solmu voi epäonnistua, saatavuustavoitteiden saavuttaminen edellyttää, että useat solmut toimivat osana klusteria.

Klusteri : Kaksi tai useampia palvelinsolmuja, jotka toimivat yhdessä keskenään yksittäisten tehtävien suorittamiseksi osana suurempaa palvelua, jossa keskinäinen tietoisuus antaa yhden tai useammalle solmulle mahdollisuuden korvata toisen menetys.

Palvelinvirhe : Palvelinsolmun kyvyttömyys vastata riittävästi asiakaspyyntöihin. Tämä voi johtua täydellisestä kaatumisesta, yhteysongelmista tai siitä, että suuri kysyntä on ylittänyt sen.

Vikasietoisuus : Tapa, jolla klusteri yrittää tyydyttää yksittäisten palvelinsolmujen vikaantumisen vuoksi orpona jääneiden asiakkaiden tarpeet käynnistämällä tai ohjaamalla muita solmuja täyttämään palveluvajeen.

Takaisinkytkentä : Palautetaan vastuualueet palvelinsolmulle, kun se palautuu virheestä.

Replikointi : Kriittisten tietovarastojen kopioiden luominen mahdollistaa luotettavan synkronisen pääsyn useilta palvelinsolmuilta tai asiakkailta ja varmistaa, että ne selviävät katastrofeista. Replikointia käytetään myös luotettavan kuormituksen tasapainottamisen mahdollistamiseksi.

Redundanssi : Usean identtisen fyysisen tai virtuaalisen palvelimen solmun tarjoaminen, joista kuka tahansa voi hyväksyä toisen epäonnistuneen orpoja asiakkaita.

Jaetut aivot : Virhetila, jossa solmupisteiden tai jaetun tallennustilan välinen verkkoyhteys on jotenkin hajonnut, ja useat yksittäiset solmut, joista kukin uskoo olevan ainoa edelleen aktiivinen solmu, jatkavat pääsyä yhteiseen tietolähteeseen ja päivittävät sitä. Vaikka tämä ei vaikuta jaetun ei mitään -malleihin, se voi johtaa asiakasvirheisiin ja tietojen vioittumiseen jaetuissa klustereissa.

Miekkailu : Aivojen halkeamisen estämiseksi stonithd-daemon voidaan määrittää sulkemaan vikaantunut solmu automaattisesti tai asettamaan virtuaalinen aita sen ja muun klusterin tietoresurssien välille. Niin kauan kuin on mahdollista, että solmu voisi edelleen olla aktiivinen, mutta ei koordinoi kunnolla muun klusterin kanssa, se pysyy aidan takana. Stonith tarkoittaa "Ammu toinen solmu päähän". Todella.

Pätevyys : Voit määrittää miekkailun (tai pakotetun sammutuksen) asetettavaksi solmuille, jotka eivät ole yhteydessä toisiinsa tai johonkin jaettuun resurssiin. Pitoisuus määritellään usein yli puoleksi kaikista klusterin solmuista. Käyttämällä tällaisia ​​määriteltyjä kokoonpanoja vältät, että sinulla on kaksi solmujen alaryhmää, joista kukin uskoo toisten toimivan väärin, yrittäen lyödä toista.

Disaster Recover y: Infrastruktuuriasi tuskin voidaan pitää erittäin saatavilla olevana, jos sinulla ei ole automaattista varmuuskopiointijärjestelmää yhdessä integroidun ja testatun katastrofipalautussuunnitelman kanssa. Suunnitelmassasi on otettava huomioon klusterin jokaisen palvelimen uudelleenasennus.

Aktiivinen / passiivinen klusteri

Palvelun vikasietoisuuden takana on, että minkä tahansa palveluklusterissa olevan solmun äkillinen menetys korvaisi nopeasti toinen sen sijainen solmu. Jotta tämä toimisi, IP-osoite siirretään automaattisesti valmiussolmuun vikatilanteessa. Vaihtoehtoisesti verkon reititystyökaluja, kuten kuormituksen tasapainotimia, voidaan käyttää ohjaamaan liikenne pois epäonnistuneista solmuista. Tarkka tapa, jolla vianmääritys tapahtuu, riippuu siitä, miten olet määrittänyt solmut.

Vain yksi solmu määritetään alun perin palvelemaan asiakkaita, ja jatkaa sitä yksin, kunnes se jotenkin epäonnistuu. Vastuu nykyisistä ja uusista asiakkaista siirtyy tällöin passiiviselle tai varmuuskopiointisolmulle (ts. "Vianmääritys"), jota on tähän asti pidetty passiivisesti varauksessa. Mallin soveltaminen useisiin palvelimiin tai palvelintilakomponentteihin (kuten virtalähteet), n + 1 redundanssi tarjoaa vain tarpeeksi resursseja nykyiselle kysynnälle sekä yhden yksikön lisää kattamaan vian.

Aktiivinen / aktiivinen klusteri

Aktiivista / aktiivista suunnittelua käyttävässä klusterissa on kaksi tai useampia identtisesti määritettyjä solmuja, jotka palvelevat asiakkaita itsenäisesti.

Jos yksi solmu epäonnistuu, sen asiakkaat muodostavat automaattisesti yhteyden toiseen solmuun ja saavat resurssien täyden pääsyn, sikäli kuin resurssit sitä sallivat.

Kun ensimmäinen solmu on palautunut tai korvattu, asiakkaat jaetaan jälleen molempien palvelinsolmujen kesken.

Aktiivisten / aktiivisten klustereiden ensisijainen etu on kyky tasapainottaa solmujen ja jopa verkkojen välinen työmäärä tehokkaasti. Kuormituksen tasapainotin - joka ohjaa kaikki asiakkaiden pyynnöt käytettävissä oleville palvelimille - on määritetty seuraamaan solmu- ja verkkotoimintaa ja käyttämään ennalta määritettyä algoritmia reitittämään liikenne niihin solmuihin, jotka pystyvät parhaiten käsittelemään sitä. Reitityskäytännöt saattavat noudattaa kierroksen mallia, jossa asiakaspyynnöt yksinkertaisesti vuorotellaan käytettävissä olevien solmujen välillä, tai ennalta asetetulla painolla, jossa yhtä solmua suositaan jonkin toisen suhteen toiseen.

Jos passiivinen solmu toimii kumppaninsa valmiustilan korvaajana aktiivisessa / passiivisessa klusterikokoonpanossa, saadaan merkittävä sisäänrakennettu redundanssi. Jos toimintasi vaatii ehdottomasti keskeytymätöntä palvelua ja saumattomia viansiirtoja, aktiivisen / passiivisen arkkitehtuurin muunnelmien tulisi olla tavoitteesi.

Jaetut ei mitään vs. jaetut levyklusterit

Yksi hajautetun laskennan ohjaavista periaatteista on välttää sitä, että toimintasi luottaa mihinkään yksittäiseen vikapisteeseen. Toisin sanoen jokaisen resurssin tulisi olla joko aktiivisesti kopioitu (redundantti) tai itsenäisesti korvattava (Failover), eikä siinä saa olla yhtä elementtiä, jonka epäonnistuminen voisi kaataa koko palvelusi.

Kuvittele nyt, että sinulla on muutama tusina solmua, jotka kaikki luottavat toimintaansa yhteen tietokantapalvelimeen. Vaikka minkä tahansa solmumäärän vika ei vaikuta jäljellä olevien solmujen jatkuvaan terveyteen, jos tietokanta putoaa, koko klusteri muuttuu hyödyttömäksi. Jaetun ei-klusterin solmut ylläpitävät (yleensä) omia tietokantojaan siten, että mikään ulkoinen vika ei vaikuta niihin - olettaen, että ne on oikein synkronoitu ja määritetty jatkuvaa tapahtumien turvallisuutta varten.

Tällä on merkittävämpi vaikutus kuormituksen tasapainotettuun klusteriin, koska jokaisella kuormituksen tasapainotetulla solmulla on jatkuva ja kriittinen tarve saada tietoja samanaikaisesti käyttöön. Yksinkertaisen vikasietojärjestelmän passiivinen solmu saattaa kuitenkin selviytyä jonkin aikaa ilman pääsyä.

Vaikka tällainen kokoonpano saattaa hidastaa klusterin vastausta joihinkin pyyntöihin - osittain siksi, että pelko aivojen epäonnistumisista saattaa edellyttää ajoittaista aitaamista kivimuurin kautta - vaihto voi olla perusteltua tehtävän kannalta kriittisissä käyttöönotoissa, joissa luotettavuus on ensisijainen näkökohta.

Saatavuus

Kun suunnittelet klusteriasi, sinulla on oltava melko hyvä käsitys siitä, kuinka suvaitsevainen voit olla epäonnistumiseen. Tai toisin sanoen, ottaen huomioon palveluitasi käyttävien ihmisten tai koneiden tarpeet, kuinka kauan palveluhäiriö voi kestää, ennen kuin väkijoukko kaataa etuporttisi läpi pikahaarukoilla ja liekeillä. On tärkeää tietää tämä, koska suunnitelmallesi rakentamallasi redundanssilla on valtava vaikutus lopetuksiin, joita lopulta kohtaat.

On selvää, että järjestelmä, jonka rakennat palvelulle, joka voi mennä alas viikonloppuna ilman, että kukaan huomaa, on hyvin erilainen kuin verkkokauppasivusto, jonka asiakkaat odottavat pääsyä ympäri vuorokauden. Ainakin sinun tulisi yleensä pyrkiä käytettävyyskeskiarvoon vähintään 99% - jotkut toiminnot vaativat huomattavasti parempia tuloksia reaalimaailmassa. 99%: n lisäaika merkitsisi menetystä, joka on alle neljä päivää vuodessa.

On suhteellisen yksinkertainen kaava, jonka avulla voit rakentaa hyödyllisen arvion saatavuudesta (A). Ajatuksena on jakaa epäonnistumisen keskimääräinen aika epäonnistumisen keskimääräiseen aikaan ja korjauksen keskimääräiseen aikaan.

A = MTBF / (MTBF + MTTR)

Mitä lähempänä A: n arvo on 1, sitä paremmin klusterisi on käytettävissä. Saadaksesi realistisen arvon MTBF: lle, sinun on todennäköisesti käytettävä aikaa altistamalla todellinen järjestelmä vakaville rangaistuksille ja tarkkailemalla sitä huolellisesti ohjelmisto-, laitteisto- ja verkkovirheiden varalta. Oletan, että voisit myös tutustua julkaistuihin laitetoimittajien tai Backblaze-kaltaisten suurkuluttajien elinkaarimittareihin saadaksesi käsityksen siitä, kuinka kauan voimakkaasti käytettyjen laitteiden voidaan odottaa kestävän.

MTTR on sen tuotteen tulos, jonka klusterisi vie epäonnistuneelle palvelinsolmulle (prosessi, joka on samanlainen, vaikkakaan ei identtinen katastrofipalautuksen kanssa - joka keskittyy epäonnistuneiden laitteiden ja yhteyksien nopeaan korvaamiseen). Ihannetapauksessa se olisi arvo niin lähellä nolla sekuntia kuin mahdollista.

Ongelmana on, että todellisessa maailmassa on tavallisesti aivan liian monta tuntematonta muuttujaa, jotta tämä kaava olisi todella tarkka, koska solmuilla, jotka käyttävät erilaisia ​​ohjelmistokokoonpanoja ja jotka on rakennettu erilaisten profiilien ja ikäisten laitteistojen kanssa, on odotettavissa oleva elinaika laaja. Siitä huolimatta se voi olla hyvä työkalu, joka auttaa tunnistamaan projektisi parhaimman klusterisuunnittelun.

Näiden tietojen avulla voit helposti luoda arvion siitä, kuinka paljon seisokkeja palvelusi todennäköisesti todennäköisesti koko vuoden aikana.

Asiaan liittyvä huomio, jos käytät resurssejasi kolmannen osapuolen alustapalveluntarjoajalle, kuten VMWare tai Amazon Web Services, on palveluntarjoajan palvelutasosopimus (SLA). Esimerkiksi Amazonin EC2 takaa, että niiden laskennan esiintymät ja estettyjen tallennuslaitteiden kuukausittainen käyttöaika on vähintään 99,95% - mikä on alle viiden tunnin seisokkiaika vuodessa. AWS myöntää hyvityksiä kuukausina, joina he eivät saavuttaneet tavoitteitaan - tosin läheskään riittämättömästi kompensoimaan seisokkien liiketoiminnan kokonaiskustannuksia. Näiden tietojen avulla voit järjestää palvelun redundanssitason, joka sopii ainutlaatuisiin tarpeisiisi.

Oman asiakkaasi palveluntarjoajana saatat joutua julkaisemaan oman SLA: n MTBF- ja MTTR-arvioidesi perusteella.

Istunnon käsittely

Kaikille palvelin-asiakas-suhteille tilallisten HTTP-istuntojen luomat tiedot on tallennettava tavalla, joka tekee niistä tulevia vuorovaikutuksia varten. Klusteriarkkitehtuurit voivat tuoda vakavaa monimutkaisuutta näihin suhteisiin, koska tietty palvelin, jonka kanssa asiakas tai käyttäjä on vuorovaikutuksessa, saattaa vaihdella vaiheen välillä.

Kuvittele, että olet kirjautunut Amazon.com-sivustoon, selaillessasi heidän LPIC-koulutusta koskevia kirjojaan ja lisäämällä tuotetta säännöllisesti ostoskoriin (toivottavasti lisää kopioita tästä kirjasta). Siihen mennessä, kun olet valmis antamaan maksutietosi ja kirjautumaan ulos, palvelinta, jota käytit selaamiseen, ei ehkä enää ole edes olemassa. Mistä nykyinen palvelimesi tietää, mitkä kirjat päätit ostaa?

En tiedä tarkalleen, miten Amazon hoitaa tämän, mutta ongelma ratkaistaan ​​usein tietojen replikointityökalun, kuten memcached, joka toimii

ulkoinen solmu (tai solmut). Tavoitteena on tarjota jatkuva pääsy luotettavaan ja johdonmukaiseen tietolähteeseen kaikille solmuille, jotka sitä tarvitsevat.

Tämä artikkeli on mukautettu artikkeliin " Opeta itsellesi Linux-virtualisointi ja korkea käytettävyys: valmistaudu LPIC-3 304 -sertifiointikokeeseen ". Tutustu muihin kirjoihini AWS: stä ja Linux-hallinnosta , mukaan lukien Linux in Action ja Linux in Motion  - hybridikurssi, joka koostuu yli kahden tunnin videosta ja noin 40% Linux in Action -tekstistä.