Tilannekuvat ovat tärkeitä riippumatta siitä, käytätkö yksinkertaista virtuaalikonetta kotikoneellasi vai yrityksen tietokantaa, jota päivitetään ja muutetaan jatkuvasti. Tilannekuvien eli kopion koko tiedostojärjestelmästä sellaisena kuin se oli tiettynä ajankohtana on tärkeää.
Vähemmänkin usein katoaa tieto siitä, missä asiat menivät pieleen, tiedosto poistettiin eikä kukaan huomannut, että se oli kadonnut. Useita varmuuskopioita on kulunut ja nyt huomaat, että tärkeä tiedosto puuttuu kaikista saatavilla olevista varmuuskopioista viimeisten viiden viikon ajalta. Tässä opetusohjelmassa katsomme, miten ZFS-väliaikaistallennuksia käytetään ja käsittelemme erilaisia tilannekuvakäytäntöjä, jotka toimisivat optimaalisesti sekä resurssien käytön että palautettavuuden kannalta.
ZFS:llä on sekä korkean tason yleiskuva tiedostoista ja hakemistoista että ymmärrys siitä, miten tiedot kirjoitetaan levylle. Kun dataa kirjoitetaan fyysisesti levylle, se tehdään erillisinä lohkoina. Tyypillisesti lohkokoko voi olla jopa 1 MB, mutta oletusarvo on yleensä 128 KB. Tämä tarkoittaa, että jokainen muutos (lukeminen, kirjoittaminen tai poistaminen) tapahtuu erillisissä lohkoissa.
Copy-on-write-mekanismi varmistaa, että aina kun lohkoa muutetaan, sen sijaan, että lohkoa muutettaisiin suoraan, siitä tehdään kopio, jossa tarvittavat muutokset tehdään uuteen lohkoon.
Tämä on erityisen hyödyllistä tapauksissa, joissa vaikkapa sähkökatkos ja järjestelmä kaatuu, kun levylle kirjoitetaan uutta tietoa. Jos näin tapahtuu perinteisessä tiedostojärjestelmässä, tiedostosi vioittuvat tai niihin jää reikiä. Mutta jos käytät ZFS:ää, saatat menettää meneillään olevan tapahtuman, kun tämä tapahtui, mutta tiedostojesi viimeisin voimassa oleva tila säilyy koskemattomana.
Snapshotit tukeutuvat myös tähän toiminnallisuuteen, ja itse asiassa melko vahvasti. Kun otat tilannekuvan tietystä tietokokonaisuudesta (”tietokokonaisuus” on ZFS:n termi tiedostojärjestelmälle), ZFS vain tallentaa aikaleiman, jolloin tilannekuva tehtiin. Siinä kaikki! Mitään tietoja ei kopioida eikä ylimääräistä tallennustilaa kuluteta.
Vain silloin, kun tiedostojärjestelmä muuttuu ja siinä oleva data poikkeaa tilannekuvasta, tilannekuva alkaa kuluttaa ylimääräistä tallennustilaa. Konepellin alla tapahtuu näin – Sen sijaan, että ZFS kierrättäisi vanhoja lohkoja ajan mittaan, se pitää ne tallessa. Tämä parantaa myös tallennustilan käyttöä. Jos otat tilannekuvan 20 Gt:n tietokokonaisuudesta ja muokkaat vain muutamaa tekstitiedostoa siellä täällä, tilannekuva saattaa viedä vain muutaman Mt tilaa.
Tilannekuvien luominen
Tilannekuvien käytön havainnollistamiseksi aloitetaan yksinkertaisuuden vuoksi tietokokonaisuudesta, jossa on paljon tekstitiedostoja. Demossa käyttämässäni virtuaalikoneessa on käytössä FreeBSD 11.1-RELEASE-p3, joka on viimeisin saatavilla oleva vakaa julkaisu tätä kirjoitettaessa. Juuritiedostojärjestelmä on oletusarvoisesti asennettu zroot-pooliin, ja monet tutut hakemistot, kuten /usr/src, /home, /etc, ovat kaikki omia datasettejään, jotka on asennettu zrootiin. Jos et tiedä, mitä pool (tai zpool) tarkoittaa ZFS-kielessä, kannattaa tutustua siihen ennen kuin jatkat.
Yksi monista FreeBSD:ssä oletuksena olevista tiedostojärjestelmistä eli dataseteistä on: zroot/usr/src
Katsoaksesi sen ominaisuuksia, suorita seuraavalla komennolla.
:~$ zfs list zroot/usr/src
Kuten huomaatte, se kuluttaa tallennustilaa 633 Mt. Se sisältää koko käyttöjärjestelmän lähdepuun.
Viedään tilannekuva zroot/usr/src:stä
:~$ zfs snapshot zroot/usr/
Symboli @ toimii erotinmerkkinä datasetin ja tilannekuvan nimen välissä, joka meidän tapauksessamme on snapshot1.
Katsotaan nyt tilannekuvan tilaa sen syntyessä.
Ajamalla komennon:
zfs list -rt all zroot/usr/src
Voit nähdä, että tilannekuva ei käytä ylimääräistä tilaa syntyessään. Käytettävissä olevaa tilaa ei myöskään ole, koska kyseessä on tiukasti vain lukemiseen tarkoitettu tietokokonaisuus, eikä tilannekuva itsessään voi kasvaa, muuttua tai kutistua. Lisäksi sitä ei ole asennettu mihinkään, joten se on täysin eristetty kyseisestä tiedostojärjestelmähierarkiasta.
Poistetaan nyt sbin-hakemisto /usr/src/
:$ rm /usr/src/sbin
Katsomalla tilannekuvaa huomaat nyt, että se on kasvanut,
Tämä on odotettavissa, koska kopioi-kirjoitetaan-mekanismi on tässä toiminnassa, ja tiedostojen poistaminen (tai muokkaaminen) on johtanut siihen, että yhä enemmän dataa on liitetty vain tilannekuvaan eikä varsinaisesti käytössä olevaan datasetiin.
Huomaa REFER-sarake yllä olevassa tulosteessa. Se kertoo datasetin käytettävissä olevan datan määrän, kun taas USED-sarake kertoo vain sen, kuinka paljon tilaa fyysisellä levyllä on käytössä.
ZFS:n Copy-On-Write-mekanismi antaa usein näitä vastakkaisia tuloksia, joissa tiedoston poistaminen saa sen näyttämään siltä, että nyt käytetään enemmän tilaa kuin ennen. Kuitenkin, kun olet lukenut tähän asti, tiedät mitä oikeasti tapahtuu!
Ennen kuin lopetamme, palautetaan sbin snapshot1:stä. Sitä varten yksinkertaisesti ajetaan:
:/usr/src$ zfs rollback zroot/usr/
Snapshoting Policy
Seuraavana kysymyksenä on – Kuinka usein haluat ottaa snapshotit? Vaikka se voi vaihdella yrityksestä toiseen, otetaan esimerkkinä hyvin dynaaminen tietokanta, joka muuttuu aina silloin tällöin.
Aluksi ottaisit tilannekuvia noin kuuden tunnin välein, mutta koska tietokanta muuttuu niin paljon, kaikkien lukuisten luotujen tilannekuvien tallentaminen olisi pian mahdotonta. Seuraava askel olisi siis tyhjentää tilannekuvat, jotka ovat vanhempia kuin vaikkapa 48 tuntia.
Nyt ongelmana olisi palauttaa jotain, joka on kadonnut 49 tuntia sitten. Tämän ongelman kiertämiseksi voit pitää yhden tai kaksi tilannekuvaa tuosta 48 tunnin historiasta ja säilyttää niitä viikon ajan. Tyhjennä ne, kun ne ovat tätä vanhempia.
Ja jos pystyt jatkamaan tällä tavalla, voit ahtaa tilannekuvia aina järjestelmän syntyyn asti, vain vähenevässä järjestyksessä. Lopuksi haluaisin huomauttaa, että nämä tilannekuvat ovat READ-ONLY, mikä tarkoittaa, että jos saat tartunnan lunnasohjelmasta ja saat kaikki tietosi salattua (muokattua). Nämä tilannekuvat olisivat todennäköisesti edelleen ehjiä.