RAID Atomicity
Kun teette, luin ylös RAID-tasoja kylvyssä. Aihe atomicity tuli, ja se on jotain halusin jakaa.
Ei yleensä luotettavin lähde teknisiä tietoja, mutta minä lainaan Wikipedia auttaa selittämään atomicity asettaa vaiheessa. Ote http://en.wikipedia.org/wiki/RAID varatuista "Ongelmat RAID" ...
Tämä on vasta vähän ja harvoin mainitaan vian irtisanotuille tallennusjärjestelmiä, jotka eivät käytä kaupallisen ominaisuuksia. Tietokannan tutkija Jim Gray kirjoitti "Update Place on Poison Apple" [28] aikana alkuaikoina relaatiotietokanta kaupallistamiseen. Kuitenkin tämä varoitus pitkälti meni huomaamatta ja putosi kelkasta, kun kynnyksellä RAID, jonka monet ohjelmistokehittäjiä luuli niin ratkaise kaikkia tiedon varastointiin rehellisyys ja luotettavuus ongelmia. Monet ohjelmistot päivitys varastointi objekti "in-place", eli he kirjoittavat uuden version esineen samalle levylle osoitteet vanha versio kohteen. Vaikka ohjelmisto voi kirjautua myös joitakin delta tietoja muualta, se odottaa varastointi esittää "atomi kirjoittaa semantiikka" eli kirjoittaa tietojen tapahtuivat joko kokonaan tai ei lainkaan.
Tämä on tullut takaisin valoon viime aikoina, mutta alle eri varjolla SSD kirjoituksen epäonnistumisen ongelmia. Monet SSD ja yritysasiakkaiden varastointi myyjät käsittelevät tätä uuden firmwaren, joka kirjoittaa kaikki tiedot järjestyksessä, ei koskaan liikaa kirjoittaa datalohkossa kunnes kaikki levy on kirjoitettu sitten alkaa liikaa kirjoittaa korttelia alusta (joka on ilmeisestikin vapautuneet ensin).
Tämä on kuitenkin unohdetaan kysymys perinteisiä pyörivät media ja usein ja hylkäsi ilman selkeää selitystä tai ymmärrystä. Ajatuksena on, että monet järjestelmät tulevat liian kirjoittaa dataa paikallaan, kirjoitus vahvisti, että se onnistuneesti kirjoitettu, mutta ei välttämättä, että data sovitettu mitä isäntä lähetetään. Yläpuolella tämän tarkistuksen asettaisi huomattavasti ylimääräistä kuormaa kuin jokainen kirjoitus olisi ylimääräinen lukea ja tarkistussumma ennen kuin kirjoitus on vahvistettu, ja kirjoituksen välimuisti voidaan huuhdella.
Tämä voi pahentaa ns "Kopioi Write" snapshot teknologiaa. Sen sijaan säilyttää tietoja, jotka on jo kirjoitettu tietyllä alalla levylle, alkuperäiset tiedot kopioidaan otos alueen eri osassa varastoinnin järjestelmä ennen alkuperäiset tiedot alan korvataan. Niin korkeita sovellus korvaa sen tiedot säännöllisesti (eli temp DB tai uusinta tukkeja, jotka tulevat huuhdellaan säännöllisesti, kuten Oracle lokit ennen arkistointia) voi olla varsin alttiita tällaista virhettä. Avainkysymys on, että kun tiedot on kirjoitettu ja vahvistanut, ei ole mitään mahdollisuutta korjata sen varastoinnin järjestelmä varmistaa sen ehjänä. Tämä voi olla valtava koputtaa vaikutus tietojen de-päällekkäisyyksiä. Jos ensimmäinen lohko kirjoitetaan vioittunut ala ilman tunnistettu, se voi sitten liittää sata toisten datalohkojen osana duplikaattien prosessi, mikä aiheuttaa suuren määrän tietoa korruptiota.
Tätä ei voida aina vahvistaa RAID pariteettia kuin RAID lasketaan kun raita on kirjoitettu. Sitä ei voida aina laskea muistiin joko täyden juova ei aina kirjoitettu, se voi olla osittain raita jolloin pariteetti on laskettu olevaan tietoon levylle ja data ei ole vielä kirjoitetaan levylle. Jos data on kirjoitettu levylle ja luettu sitten sen laskemiseksi pariteetin, se ei välttämättä ole vahvistettu vastaan lähteestä. On olemassa useita tapoja käsitellä tätä, ja useimmiten tämä täytyy tapahtua muistiin, yleensä tarkistussumma pidetään hyväksyttävänä lähestymistapaa. Lukeminen tiedot myöhemmin, kun vahvistettu kirjoitus ei voida taata, koska sinulla ei ole mitään verrata sitä vastaan, eheys on tarkistettava, kun tiedot ovat edelleen aktiivinen muistissa verrataan.
On olemassa useita tapoja, varastointi myyjät puuttua tähän, ja kuten odottaa Tulen kattaa mitä NetApp tekevät. WAFL tiedostojärjestelmä kirjoittaa jokainen vapaa Datalohko eikä koskaan aktiivisesti yli-kirjoittaa datalohkon. Luo ilmainen datalohkoja on mekaanisen prosessi, joka toimii taustalla, ajetaan koko tallennusjärjestelmän nuken lohkon ja kuulustelee onko kuva tai aktiivinen tiedostojärjestelmä osoittaa juuri tässä Datalohko. Jos näin ei ole, se poistuu tiedot lohkon ja merkitsee sen vapaa (tai unmarks sen käytön aikana olisi luultavasti enemmän oikeita). Tämä sallii tiedostojärjestelmän vahvistamaan, että ei vain datalohko ei käytetä, vaan itse asiassa sillä sivuvaikutuksena se leviää data kirjoittaa koko pinta-ala levy ja tyhjäksi tai minimoi vaikutukset atomicity. Lisäksi WAFL hangata analyyseissä datalohkoja tarkistaa levylle eheyden, näin levyt voivat olla ennalta ole perusteella levyn pinnan eheyden eivätkä fysikaaliset vajaatoiminta, sen jälkeen määritellyn kynnyksen hajonneen levyn alojen levy on epäonnistunut ja elpyminen on yritetty, ja kuuma vara aktivoitu. Niinpä NetApp järjestelmässä, samalla datalohkoja harvoin kirjoitetaan toistuvasti, vaikka (tai erityisesti) ja korkean toista liiketoimen järjestelmässä.
Ota kaikki edellä mainitut, ja voit myös alkaa ymmärtää, että koko tiedostojärjestelmä on huono tallennusratkaisun eri tavoin. Jos sinulla on täysi säilytysjärjestelmä, silloin on vähemmän vapaata korttelin kirjoittaa, joten pienempi osuus datalohkojen kirjoitetaan jatkuvasti. Tämä yhdisteiden mahdollisuuksia atomicity ja yleensä kasvaa levyn kulumista. Joten hyvä syy katsoa arkistointi, de-päällekkäisyyksiä ja yleensä pidät tiedostojärjestelmät puhdas ja väärin tallennusjärjestelmiä!
Joten kysy varastointi myyjältä miten ne suojaavat tietoja näihin kysymyksiin.
Very cool.