Hajautettujen järjestelmien perusteet Replikointi Kari Systä
Sisältö Replikointi Konsistenssimallit Datakeskeiset Asiakaskeskeiset Replikoiden hallinta Konsistenssiprotokollia
ACID (http://en.wikipedia.org/wiki/acid) ACID (atomicity, consistency, isolation, durability) is a set of properties that guarantee that db transactions are processed reliably. Atomicity requires that each transaction is "all or nothing": if one part of the transaction fails, the entire transaction fails, and the database state is left unchanged. The consistency property ensures that any transaction will bring the database from one valid state to another. Isolation refers to the requirement that no transaction should be able to interfere with another transaction. Durability means that once a transaction has been committed, it will remain so, even in the event of power loss, crashes, or errors.
Replikointi Replikointi on sitä, että sama data on monessa paikassa Prosessit kirjoittavat ja lukevat lähintä replikaa Hyöty: luotettavuus Suoritusta saatetaan voida jatkaa yhden replikan kaatuessa tai korruptoidutta Hyöty: suorituskyky Järjestelmän skaalautuessa maantieteellisesti kannattaa replikoida data lähelle prosesseja
Replikointi Replikointi on tyypillinen skaalaustekniikka Kuorman tasaus Datan ollessa lähellä käsittely nopeaa Haitta: Replikoiden ylläpito (ehkä) hidasta Käsittely-päivitys-suhde Uusi ongelma: konsistenssi Miten taataan, että kaikissa replikoissa on (edes suunnilleen) sama data?
Muistutus: Pankin arkkitehtuuri Hajautettujen perusteet / K. Systä 6
Konsistenssi Intuitio: Kaikissa replikoissa sama arvo vaatii synkronisen replikoinnin päivitys on atominen tapahtuma hidas ja vaikea toteuttaa On löydettävä tasapaino suorituskyvyn ja konsistenssin ylläpidon välille replikointi parantaa suorituskykyä replikoiden pitäminen konsistentteina vaatii globaalia synkronointia
Konsistenssi mittareita Numeerinen (numeric) Kuinka paljon jokin arvo/arvot voi poiketa? Tila (stateness) Kuinka vanhaa tietoa replikasta voi saada? Järjestys Voiko tapahtumien järjestys poiketa?
Konsistenssimallit Ratkaisu: luovutaan tiukasta konsistenssivaatimuksesta ja tyydytään vähempään Nyt lukuoperaatio ei palauta välttämättä viimeisintä kirjoitusta Konsistenssimalli on datasäiliön ja prosessien välinen sopimus Jos prosessi noudattaa sääntöjä, niin säiliö lupaa toimia oikein
Konsistenssimallit Datakeskeiset mallit Joukko rinnakkaisesta ohjelmoinnista perittyjä malleja Sarjallinen konsistenssi ja Kausaalinen konsistenssi Asiakaskeskeisyys Konsistenssi yhden asiakkaan näkökulmasta Monotoninen lukeminen Monotoninen kirjoittaminen
Datakeskeiset konsistenssimallit Luku- ja kirjoitusoperaatioiden suhteen Datan tallennus hajautettu monelle koneelle Kirjoitusoperaatiot kohdistetaan lähimpään replikaan ja propagoidaan muihin Lukuoperaatiot kohdistetaan lähimpään replikaan
Malli: Tarkka konsistenssi Strict consistency Jokainen x:n lukuoperaatio palauttaa sen arvon, joka x:ään viimeksi kirjoitettiin Täydellinen toteutus vaatisi globaalin ajan Joskus voidaan helpottaa olettamalla tarkat reaaliaikakellot, jakamalla aika viipaleisiin ja pitämällä huolta siitä, että joka viipaleessa suoritetaan enintään yksi operaatio
Malli: Sarjallinen konsistenssi Lamport (1979): Sequential consistency Suorituksen tulos on sama kuin, jos kaikkien prosessien operaatiot olisi suoritettu jossain sarjallisessa järjestyksessä ja jokaisen prosessin operaatiot esiintyvät tässä sekvenssissä ohjelman määräämässä järjestyksessä Mikä tahansa lomittelu on sallittu, mutta kaikki prosessit havaitsevat sen samana Analogia transaktioihin
Sarjallinen konsistenssi Konsistentti Epäkonsistentti
Malli: Kausaalinen konsistenssi Causal consistency Heikennetään sarjallista siten, että erotellaan potentiaalisesti kausaalisesti riippuvat tapahtumat Prosessien tulee havaita kirjoitukset, jotka ovat mahdollisesti kausaalisesti riippuvat, samassa järjestyksessä. Rinnakkaiset kirjoitukset voidaan havaita missä järjestyksessä tahansa
Kausaalinen konsistenssi Alla on kausaalisesti konsistentti säiliö Se ei ole sarjallisesti konsistentti
Kausaalinen konsistenssi Kausaalisesti epäkonsistentti konsistentti
Kausaalisen konsistenssin toteutuksesta Toteutuksessa täytyy tietää mitkä lukemiset prosessi on nähnyt riippuvuusgraafi vektoriaikaleimat
Operaatioiden ryhmittely Sarjallinen ja kausaalinen konsistenssi varsin hienojakoisia Ei välttämättä vastaa sovelluksen tai käyttäjän oletuksia Ryhmittely tehdään samoilla mekanismeilla kuin poissulkeminen ja transaktionaalisuus
Operaatioiden ryhmittely ENTER_CS ja LEAVE_CS CS = critical section Synkronoitimuuttujat Prosessi, jolla on synkronointimuuttuja voi vapaasti mennä ja tulla kriittiselle alueelle Myös ei-poissulkeva moodi Operaatio acquire hankkii muuttujan Operaatio release vapauttaa sen
Operaatioiden ryhmittely 1. Prosessin p acquire(x) ei saa edetä loppuun ennen kuin kaikki x:n vartioima data on päivitetty p:lle 2. Poissulkeva acquire(x) voidaan suorittaa loppuun vasta kun mikään muu prosessi ei omista x:ää (edes ei-poissulkevasti) 3. Poissulkevan moodin jälkeen toisen prosessin q ei-poissulkeva käsittely ei saa edetä ennen kuin data on päivitetty q:lle
Saapumiskonsistenssi Entry consistency Data synkronoidaan saavuttaessa kriittiselle alueelle Jokaisella data-alkiolla synkronointimuuttuja Synkronointimuuttujilla omistaja, joka voi saapua ja lähteä kriittiseltä alueelta kuten haluaa Halutessaan kriittiselle alueelle prosessi pyytää synkronointimuuttujan ja datan omistajalta
Saapumiskonsistenssi Laillinen operaatioiden ryhmittely
Asiakaskeskeiset konsistenssimallit (client-centric ) Datakeskeiset mallit yleisiä Usein kuitenkin päivitykset harvinaisia - DNS kirjoitus-kirjoitus-konfliktit harvinaisia - WWW Usein riittää, että konsistenssi saavutetaan joskus (eventual-consistency) Replikat konvergoivat kohti identtisiä kopioita, kun päivityksiä ei tehdä
Asiakaskeskeiset Eventual-konsistenssi toimii hyvin niin kauan, kun jokainen asiakas operoi yhden replikan kanssa Esim. mobiilit järjestelmät ongelmallisia Asiakaskeskeinen konsistenssi tarkoittaa konsistenssia yhden asiakkaan näkökulmasta Ei siis koko järjestelmän
Liikkuva asiakas ja asiakaskeskeinen konsistenssi
Monotoninen lukeminen Monotonic read consistency Jos prosessi lukee arvon datasta x, niin kaikki myöhemmät lukemiset palauttavat joko saman tai uudemman arvon Sähköpostiesimerkki Sähköpostilaatikko hajautettu Meilejä voidaan kirjoittaa missä tahansa (laiska päivittyminen käytössä) Luetaan paikassa A ja siirrytään paikkaan B Kaikki ne meilit, jotka nähtiin A:ssa näkyvät myös B:ssä
Monotoninen lukeminen a on monotonisesti konsistentti, b ei ole
Monotoninen kirjoitus Monotonic write Prosessin kirjoitus dataan x saatetaan loppuun ennen saman prosessin seuraavaa kirjoitusoperaatiota x:ään Takaa, että kirjoitukset propagoidaan oikeassa järjestyksessä replikoihin Esimerkiksi softakirjaston päivitys Vanhat funktiot päivitetään Monotoninen kirjoitus takaa, että kaikki aiemmat päivitykset on tehty
Monotoninen kirjoitus a on konsistentti, b ei (x 1 :n kirjoittamissesta L2:een ei takeita)
Muita malleja Lue-kirjoituksesi Read-your-writes consistency Prosessin itse tekemät kirjoitusoperaatiot ovat prosessin luettavissa mistä tahansa kopiosta Kirjoitukset seuraavat lukemista Writes-follow-reads consistency Prosessin tekemä kirjoitusoperaatio kohdistuu edelliseen luettuun tai uudempaan kopioon
Replikoiden hallinta Replikapalvelimen paikka Replikoiden syntyminen Missä, koska ja kenen aloitteesta replikoidaan Miten päivityksiä propagoidaan
Palvelimen paikka Optimointiongelma: mitkä ovat K parasta paikkaa N:stä mahdollisesta (K<N) Qiu et al. Lähtökohtana asiakkaiden ja palvelinten etäisyys (esim. niiden välinen latenssi) Valitaan yksi kerrallaan uusi palvelin siten, että keskimääräinen etäisyys minimoituu olettaen, että k palvelinta on sijoitettu
Pysyvä replika Erilaisia replikoita Esim. peilatut www-sivut Palvelinlähtöiset replikat www-esimerkki: kuorman kasvaessa kannattaa joskus palvelimen sisältö replikoida dynaamisesti eri paikkaan push cache Asiakaslähtöiset replikat Kätkö
Erilaisia replikoita
Palvelinlähtöinen replikointi Oletus replikapalvelimet on sijoitettu Nyt siis sijoitetaan sisältö palvelimiin Rabinovich et al. Algoritmi www-sivujen replikoimiseen dynaamisesti Oletus: päivityksiä harvoin lukemisia usein Pyritään vähentämään palvelinten kuormaa siirtämällä tiedostoja asiakkaiden läheisyyteen
Rabinovichin ja kumppaneiden algoritmi Palvelin pitää kirjaa tiedostojen latauspyyntöjen määrästä ja asiakkaista Järjestelmä tietää mikä palvelin on lähinnä asiakasta A Tuhoamis- ja replikointikynnys
Rabinovichin ja kumppaneiden algoritmi
Asiakaslähtöiset replikat Cache Jätetään periaatteessa asiakkaan huoleksi Lyhennetään saantiaikaa Dataa säilytetään kätkössä yleensä vain rajatun ajan Kätkö joko samassa koneessa tai lähellä Osuma (cache hit) kun kätköä käytetään Osumatarkkuutta voidaan parantaa jakamalla
Päivityksen propagoiminen o Notifikaatio: invalidoidaan dataa. Säästää kaistaa, jos lukuja harvoin o Data: Hyvä, jos lukuoperaatioita paljon o Operaatiot: Säästää joskus kaistaa, mutta vaatii laskentatehoa replikapalvelimilta
Päivityksen propagoiminen Push-based protocols (työntö) Usein pysyvän ja palvelinlähtöisen välillä read-to-update-suhde suuri Jokaista työntöä kohti tulee lukuja Suuret konsistenssivaatimukset Pull-based protocols (veto) Asiakasperustaiset protokollat read-to-update-suhde pieni Kätköissä käytetään vetoa
Propagointi: Unicast vai multicast Unicast Palvelin lähettää itse N viestiä Sopii pull-based-protokolliin Multicast Alla oleva verkko pitää huolta viestityksestä Usein tehokkaampi Sopii push-based-protokolliin
Konsistenssiprotokollia Primary-based protocols Datalla on primäärinen tallennuspaikka, joka koordinoi päivityksiä Äänestykseen perustuvat protokollat Naiiveja toteutuksia asiakaskeskeiseen konsistenssiin
Primääriperustaiset protokollat Primary-based protocols Yksinkertaisimmassa protokollassa yksi palvelin tekee kaikki operaatiot Vähän monimutkaisempi versio sallii asiakkaiden tehdä päivityksiä replikaan Replika lähettää päivitykset edelleen primäärikopiolle Tarjoavat suoraviivaisen tavan toteuttaa sarjallinen konsistenssi
Primary-backup protokolla
Primääriperustaiset protokollat Suorituskykyongelmat Voidaan helpottaa ei-blokkaavalla protokollalla Vikasietoisuusongelmat
Paikallinen kirjoitus -protokolla Primäärikopiota siirrellään Vanhaan tallennuspaikkaan jää kopio Jokaisesta dataoliosta x on yksi kopio Halutessaan kirjoittaa asiakas lähettää kirjoituspyynnön lähimmälle replikalle, joka hankkii kopion itselleen Hankala pitää kirjaa primäärikopion paikasta Asiakkaat voivat lukea paikallista kopiota Sopii mobiileille laitteille
Paikallinen kirjoitus
Äänestysperustaiset-protokollat Äänestetään replikoidun datan arvosta Esimerkki Tiedosto t on replikoitu N palvelimelle Päivittävän asiakkaan on tehtävä päivitys N/2+1:lle palvelimelle Kun päivitys on hyväksytty t:lle uusi versionumero Lukua varten on otettava yhteys N/2+1:een palvelimeen
Naiiveja asiakaskeskeisiä protokollia Asiakaskeskeiset protokollat suhteellisen yksinkertaisia, jos ei välitetä suorituskyvystä Jokaisella kirjoituksella globaali ID Annetaan palvelimessa, jossa päivitys initialisoidaan Jokaisella asiakkaalla on luku- ja kirjoitusjoukko
Yhteenveto Kaksi syytä replikoida: luotettavuus ja suorituskyky Täydellistä konsistenssia ei voida saavuttaa Siksi on kehitetty joukko konsistenssimalleja konsistenssiprotokolla toteuttaa tietyn konsistenssimallin