CAP-lause on hajautettujen järjestelmien teorian kulmakivi. Sitä ympäröivä kiista ei tietenkään lannistu: siinä esitetyt määritelmät eivät ole kanonisia, eikä tiukkaa näyttöä ole... Kuitenkin pysyen lujasti arkipäivän terveen järjen™ kannalla ymmärrämme intuitiivisesti, että lause on totta.
Ainoa asia, joka ei ole ilmeinen, on P-kirjaimen merkitys. Kun klusteri jaetaan, se päättää, eikö vastata, ennen kuin päätösvaltaisuus on saavutettu, vai palauttaako saatavilla olevat tiedot. Tämän valinnan tuloksista riippuen järjestelmä luokitellaan joko CP:ksi tai AP:ksi. Esimerkiksi Cassandra voi käyttäytyä kummalla tahansa tavalla, ei edes klusterin asetuksista, vaan kunkin pyynnön parametreista riippuen. Mutta jos järjestelmä ei ole "P" ja se halkeaa, mitä sitten?
Vastaus tähän kysymykseen on hieman odottamaton: CA-klusteri ei voi jakaa.
Mikä klusteri tämä on, joka ei voi hajota?
Tällaisen klusterin välttämätön ominaisuus on jaettu tiedontallennusjärjestelmä. Suurimmassa osassa tapauksista tämä tarkoittaa yhteyden muodostamista SAN-verkon kautta, mikä rajoittaa CA-ratkaisujen käytön suuriin yrityksiin, jotka pystyvät ylläpitämään SAN-infrastruktuuria. Jotta useat palvelimet voisivat toimia samoilla tiedoilla, tarvitaan klusteroitu tiedostojärjestelmä. Tällaisia tiedostojärjestelmiä on saatavana HPE (CFS), Veritas (VxCFS) ja IBM (GPFS) portfolioissa.
Oracle RAC
Real Application Cluster -vaihtoehto ilmestyi ensimmäisen kerran vuonna 2001, kun Oracle 9i julkaistiin. Tällaisessa klusterissa useat palvelinesiintymät toimivat saman tietokannan kanssa.
Oracle voi toimia sekä klusteroidun tiedostojärjestelmän että oman ratkaisunsa – ASM, Automatic Storage Management – kanssa.
Jokainen kopio pitää omaa päiväkirjaansa. Tapahtuman suorittaa ja sitoutuu yksi esiintymä. Jos ilmentymä epäonnistuu, yksi säilyvistä klusterisolmuista (esiintymistä) lukee lokinsa ja palauttaa kadonneet tiedot - mikä varmistaa saatavuuden.
Kaikilla esiintymillä on oma välimuisti, ja samat sivut (lohkot) voivat olla useiden esiintymien välimuistissa samanaikaisesti. Lisäksi, jos yksi ilmentymä tarvitsee sivun ja se on toisen ilmentymän välimuistissa, se voi saada sen naapuriltaan välimuistin yhdistämismekanismin avulla levyltä lukemisen sijaan.
Mutta mitä tapahtuu, jos jokin esiintymistä joutuu muuttamaan tietoja?
Oraclen erikoisuus on, että sillä ei ole erillistä lukituspalvelua: jos palvelin haluaa lukita rivin, lukitustietue sijoitetaan suoraan muistisivulle, jossa lukittu rivi sijaitsee. Tämän lähestymistavan ansiosta Oracle on suorituskyvyn mestari monoliittisten tietokantojen joukossa: lukituspalvelusta ei tule koskaan pullonkaulaa. Mutta klusterikokoonpanossa tällainen arkkitehtuuri voi johtaa intensiiviseen verkkoliikenteeseen ja lukkiutumiseen.
Kun tietue on lukittu, ilmentymä ilmoittaa kaikille muille esiintymille, että tietueen tallentavalla sivulla on yksinomainen säilytysoikeus. Jos toisen ilmentymän on muutettava samalla sivulla olevaa tietuetta, sen on odotettava, kunnes sivun muutokset on vahvistettu, eli muutostiedot kirjoitetaan levyllä olevaan lokiin (ja tapahtuma voi jatkua). Saattaa myös käydä niin, että sivua muutetaan peräkkäin useilla kopioilla, ja silloin kun kirjoitat sivua levylle, sinun on selvitettävä, kuka tämän sivun nykyisen version tallentaa.
Samojen sivujen satunnainen päivittäminen eri RAC-solmuissa saa tietokannan suorituskyvyn laskemaan dramaattisesti pisteeseen, jossa klusterin suorituskyky voi olla alhaisempi kuin yksittäisen esiintymän.
Oracle RAC:n oikea käyttö on osioida tiedot fyysisesti (esimerkiksi käyttämällä osioitua taulukkomekanismia) ja käyttää jokaista osiosarjaa erillisen solmun kautta. RAC:n päätarkoituksena ei ollut vaakasuora skaalaus, vaan vikasietoisuuden varmistaminen.
Jos solmu lakkaa vastaamasta sydämenlyöntiin, solmu, joka havaitsi sen ensin, aloittaa äänestysmenettelyn levyllä. Jos puuttuvaa solmua ei ole merkitty tähän, yksi solmuista ottaa vastuun tietojen palauttamisesta:
- "jäätyy" kaikki sivut, jotka olivat puuttuvan solmun välimuistissa;
- lukee puuttuvan solmun lokit (uudelleen) ja ottaa näihin lokeihin tallennetut muutokset uudelleen käyttöön samalla, kun tarkistaa, onko muilla solmuilla uudempia versioita muutettavista sivuista;
- peruuttaa odottavat tapahtumat.
Solmujen välisen vaihtamisen yksinkertaistamiseksi Oraclella on palvelukonsepti - virtuaalinen ilmentymä. Ilmentymä voi palvella useita palveluita, ja palvelu voi liikkua solmujen välillä. Tiettyä osaa tietokannasta palveleva sovellusesiintymä (esimerkiksi asiakasryhmä) toimii yhden palvelun kanssa, ja tästä tietokannan osasta vastaava palvelu siirtyy toiseen solmuun, kun solmu epäonnistuu.
IBM Pure Data Systems for Transactions
Klusteriratkaisu DBMS:lle ilmestyi Blue Giant -portfolioon vuonna 2009. Ideologisesti se on Parallel Sysplex -klusterin seuraaja, joka on rakennettu "tavallisille" laitteille. Vuonna 2009 julkaistiin DB2 pureScale, ohjelmistopaketti, ja vuonna 2012 IBM tarjosi Pure Data Systems for Transactions -nimisen laitteiston. Sitä ei pidä sekoittaa Pure Data Systems for Analyticsiin, joka on vain uudelleen nimetty Netezza.
Ensi silmäyksellä pureScale-arkkitehtuuri on samanlainen kuin Oracle RAC: samalla tavalla useat solmut on kytketty yhteiseen tiedontallennusjärjestelmään, ja jokainen solmu ajaa omaa DBMS-instanssiaan, jossa on omat muistialueet ja tapahtumalokit. Mutta toisin kuin Oracle, DB2:ssa on oma lukituspalvelu, jota edustaa joukko db2LLM*-prosesseja. Klusterikokoonpanossa tämä palvelu sijoitetaan erilliseen solmuun, jota kutsutaan rinnakkaissysplexissä CF:ksi ja Pure Datassa PowerHA:ksi.
PowerHA tarjoaa seuraavat palvelut:
- lukko johtaja;
- globaali puskuri välimuisti;
- prosessien välisen viestinnän alue.
Datan siirtämiseen PowerHA:sta tietokantasolmuihin ja takaisin käytetään etämuistin käyttöä, joten klusterin keskinäisen yhteyden on tuettava RDMA-protokollaa. PureScale voi käyttää sekä Infinibandia että RDMA:ta Ethernetin kautta.
Jos solmu tarvitsee sivun, mutta tämä sivu ei ole välimuistissa, solmu pyytää sivua yleisessä välimuistissa, ja vain jos sitä ei ole, lukee sen levyltä. Toisin kuin Oracle, pyyntö menee vain PowerHA:lle, ei naapurisolmuille.
Jos esiintymä muuttaa riviä, se lukitsee sen poissulkevaan tilaan ja sivun, jolla rivi sijaitsee, jaettuun tilaan. Kaikki lukot on rekisteröity maailmanlaajuiseen lukkohallintaan. Kun tapahtuma on valmis, solmu lähettää viestin lukituksen hallintaohjelmalle, joka kopioi muokatun sivun yleiseen välimuistiin, vapauttaa lukot ja mitätöi muokatun sivun muiden solmujen välimuistissa.
Jos sivu, jolla muokattu rivi sijaitsee, on jo lukittu, lukituksenhallinta lukee muokatun sivun muutoksen tehneen solmun muistista, vapauttaa lukon, mitätöi muokatun sivun muiden solmujen välimuistissa ja anna sivulukko solmulle, joka sitä pyysi.
”Dirty”, eli muuttuneet, sivut voidaan kirjoittaa levylle sekä tavallisesta solmusta että PowerHA:sta (castout).
Jos jokin pureScale-solmuista epäonnistuu, palautus rajoittuu vain niihin tapahtumiin, joita ei ollut vielä suoritettu loppuun epäonnistumishetkellä: kyseisen solmun muokkaamat sivut suoritetuissa tapahtumissa ovat PowerHA:n globaalissa välimuistissa. Solmu käynnistyy uudelleen pienennetyssä kokoonpanossa yhdessä klusterin palvelimista, peruuttaa odottavat tapahtumat ja vapauttaa lukitukset.
PowerHA toimii kahdella palvelimella ja pääsolmu replikoi tilansa synkronisesti. Jos ensisijainen PowerHA-solmu epäonnistuu, klusteri jatkaa toimintaansa varasolmun kanssa.
Tietenkin, jos käytät tietojoukkoa yhden solmun kautta, klusterin kokonaissuorituskyky on parempi. PureScale voi jopa huomata, että yksi solmu käsittelee tiettyä data-aluetta, ja sitten solmu käsittelee kaikki kyseiseen alueeseen liittyvät lukot paikallisesti ilman, että se kommunikoi PowerHA:n kanssa. Mutta heti kun sovellus yrittää käyttää näitä tietoja toisen solmun kautta, keskitetty lukon käsittely jatkuu.
IBM:n sisäiset testit 90 % luku- ja 10 % kirjoitustyökuormilla, jotka ovat hyvin samankaltaisia kuin todelliset tuotantotyökuormat, osoittavat lähes lineaarisen skaalauksen 128 solmuun asti. Testiolosuhteita ei valitettavasti julkisteta.
HPE NonStop SQL
Hewlett-Packardin Enterprise-portfoliolla on myös oma erittäin saatavilla oleva alusta. Tämä on NonStop-alusta, jonka Tandem Computers julkaisi markkinoille vuonna 1976. Vuonna 1997 Compaq osti yrityksen, joka fuusioitui Hewlett-Packardin kanssa vuonna 2002.
NonStopia käytetään kriittisten sovellusten rakentamiseen - esimerkiksi HLR- tai pankkikorttikäsittelyyn. Alusta toimitetaan ohjelmisto- ja laitteistokompleksina (appliance), joka sisältää laskentasolmut, tiedontallennusjärjestelmän ja viestintälaitteet. ServerNet-verkko (nykyaikaisissa järjestelmissä - Infiniband) palvelee sekä solmujen välistä vaihtoa että pääsyä tiedontallennusjärjestelmään.
Järjestelmän varhaiset versiot käyttivät omia prosessoreita, jotka synkronoitiin keskenään: useat prosessorit suorittivat kaikki toiminnot synkronisesti, ja heti kun yksi prosessoreista teki virheen, se sammutettiin ja toinen jatkoi toimintaansa. Myöhemmin järjestelmä siirtyi perinteisiin prosessoreihin (ensin MIPS, sitten Itanium ja lopulta x86), ja synkronointiin alettiin käyttää muita mekanismeja:
- viestit: jokaisessa järjestelmäprosessissa on "varjo"-kaksos, jolle aktiivinen prosessi lähettää ajoittain viestejä tilastaan; jos pääprosessi epäonnistuu, varjoprosessi alkaa toimia viimeisen viestin määrittämästä hetkestä;
- äänestäminen: tallennusjärjestelmässä on erityinen laitteistokomponentti, joka hyväksyy useita identtisiä käyttöoikeuksia ja suorittaa ne vain, jos pääsyt täsmäävät; Fyysisen synkronoinnin sijaan prosessorit toimivat asynkronisesti ja niiden työn tuloksia verrataan vain I/O-hetkellä.
Vuodesta 1987 lähtien relaatiotietokantajärjestelmä on ollut käynnissä NonStop-alustalla - ensin SQL/MP ja myöhemmin SQL/MX.
Koko tietokanta on jaettu osiin, ja jokainen osa vastaa omasta Data Access Manager (DAM) -prosessistaan. Se tarjoaa tietojen tallennus-, välimuisti- ja lukitusmekanismeja. Tietojen käsittelyn suorittaa Executor Server Processes, joka toimii samoissa solmuissa kuin vastaavat tiedonhallintaohjelmat. SQL/MX-ajastin jakaa tehtävät suorittajien kesken ja aggregoi tulokset. Kun sovittuja muutoksia on tarpeen tehdä, käytetään TMF (Transaction Management Facility) -kirjaston tarjoamaa kaksivaiheista toimitusprotokollaa.
NonStop SQL voi priorisoida prosesseja, jotta pitkät analyyttiset kyselyt eivät häiritse tapahtuman suorittamista. Sen tarkoitus on kuitenkin nimenomaan lyhyiden transaktioiden käsittely, ei analytiikka. Kehittäjä takaa NonStop-klusterin saatavuuden viiden "yhdeksän" tasolla, eli seisokkiaika on vain 5 minuuttia vuodessa.
SAP-HANA
HANA DBMS:n (1.0) ensimmäinen vakaa julkaisu julkaistiin marraskuussa 2010, ja SAP ERP -paketti vaihdettiin HANA:han toukokuussa 2013. Alusta perustuu ostettuihin teknologioihin: TREX Search Engine (haku sarakevarastosta), P*TIME DBMS ja MAX DB.
Itse sana "HANA" on lyhenne, High performance Analytical Appliance. Tämä DBMS toimitetaan koodin muodossa, jota voidaan käyttää millä tahansa x86-palvelimilla, mutta teolliset asennukset ovat sallittuja vain sertifioiduissa laitteissa. Ratkaisuja saatavana HP:ltä, Lenovolta, Ciscolta, Dellin, Fujitsun, Hitachin ja NEC:ltä. Jotkut Lenovon kokoonpanot mahdollistavat jopa toiminnan ilman SAN-verkkoa - yhteisen tallennusjärjestelmän roolia hoitaa paikallisilla levyillä oleva GPFS-klusteri.
Toisin kuin yllä luetellut alustat, HANA on muistissa oleva DBMS, eli ensisijainen datakuva tallennetaan RAM-muistiin ja vain lokit ja säännölliset tilannevedokset kirjoitetaan levylle palautusta varten katastrofin sattuessa.
Jokainen HANA-klusterisolmu vastaa omasta osastaan dataa, ja tietokartta on tallennettu erityiseen komponenttiin - Name Server, joka sijaitsee koordinaattorisolmussa. Dataa ei kopioida solmujen välillä. Lukitustiedot on myös tallennettu jokaiseen solmuun, mutta järjestelmässä on globaali lukkiutuman ilmaisin.
Kun HANA-asiakas muodostaa yhteyden klusteriin, se lataa sen topologian ja voi sitten käyttää mitä tahansa solmua suoraan riippuen siitä, mitä tietoja se tarvitsee. Jos tapahtuma vaikuttaa yksittäisen solmun tietoihin, se voidaan suorittaa paikallisesti kyseisellä solmulla, mutta jos useiden solmujen tiedot muuttuvat, aloittava solmu ottaa yhteyttä koordinaattorisolmuun, joka avaa ja koordinoi hajautetun tapahtuman ja sitoo sen käyttämällä optimoitu kaksivaiheinen vahvistusprotokolla.
Koordinaattorisolmu monistetaan, joten jos koordinaattori epäonnistuu, varasolmu ottaa välittömästi haltuunsa. Mutta jos dataa sisältävä solmu epäonnistuu, ainoa tapa päästä käsiksi sen tietoihin on käynnistää solmu uudelleen. Pääsääntöisesti HANA-klusterit ylläpitävät varapalvelinta, jotta kadonnut solmu voidaan käynnistää uudelleen mahdollisimman nopeasti.
Lähde: will.com