Data Domain: Yleiskatsaus DDFS (Data Domain File System) -puhdistus- ja roskankeräysvaiheisiin (GC)

DDFS (Data Domain File System) eroaa monista yleisistä tiedostojärjestelmätodistutkinnoilla, sillä kun tiedosto poistetaan tiedoston käyttämästä tiedostojärjestelmätilasta, se ei ole heti käytettävissä uudelleenkäyttöä varten. Syynä tähän on se, että DDR (Data Domain Restorer) ei heti tiedä, poistetaanko poistetun tiedoston viittaamista tiedoista myös muut tiedostot ja onko niiden vuoksi turvallista poistaa nämä tiedot vai ei.

Puhdistus (jota kutsutaan joskus roskien keräämiseksi/GC) on prosessi, jolla DDR:

• Määrittää, mitkä levyn tiedot ovat tarpeettomia (eli objekteihin, kuten tiedostoihin tai tilannevedoksiin, ei enää viitata)
• Poistaa fyysisesti tarpeettomat tiedot, jotka tekevät pohjana olevan levytilan uudelleenkäyttöön (eli uusien tietojen saamisen)

Clean/GC on yleensä ajoitettu toteutumaan säännöllisin väliajoin (oletusarvoisesti se alkaa klo 6 joka tiistai), ja se voi olla:

• Pitkä juoksu
• Laskennallisesti kallis

Huomaa kuitenkin, että ei ole muuta keinoa kuin käynnissä puhdas/GC, jossa tietoja voidaan poistaa / tilaa fyysisesti vapauttaa data-verkkotunnuksen palauttajalla (eli tämän prosessin nopeuttamiseksi ei ole pikakuvakkeita).

Tässä artikkelissa kuvataan clean/GC yksityiskohtaisemmin:

• Yleensä puhdistavat vaiheet
• DDOSin eri versioissa käytetyt erilaiset puhtaat algoritmit

Ei mitään

Joka kerta, kun puhdas/GC suoritetaan, sillä on kaksi päätarkoitusta - ensinnäkin sen on löydettävä tarpeettomia tietoja DDR: stä - lyhyt katsaus siihen, miten tämä tehdään, on seuraava:

• Clean/GC luetteloi DDFS-tiedostojärjestelmän sisällön etsien objekteja, kuten tiedostoja, tilannevedoksia ja replikointilokeja, jotka ovat tällä hetkellä järjestelmässä
• Tämän jälkeen se määrittää kaikki levyn fyysiset tiedot, joihin nämä objektit aktiivisesti viittaavat.
• Tietojen, joihin viitataan aktiivisesti, sanotaan olevan "eläviä", eikä niitä voida poistaa DDR:stä, muuten tietoihin viittaavat objektit vahingoittuisivat (niitä ei enää voida lukea, koska niiden pohjana olevia tietoja, joista ne olivat riippuvaisia, ei enää olisi levyllä)
• Tietojen, joihin mikään esine ei aktiivisesti viittaa, sanotaan olevan "kuolleita" ja tarpeettomia - nämä tiedot voidaan poistaa järjestelmästä turvallisesti
• Kaikki DDR:n tiedot pakataan 4,5 Mt:n kokoisiin esineisiin, joita kutsutaan kontteihin
• Luetteloinnin avulla clean/GC voi määrittää, mitkä 4,5 Mt:n säiliöt pitävät hallussaan kuolleita tietoja ja kuinka paljon kuolleita tietoja kussakin
• Oletusarvon mukaan puhdas/GC valitsee 4,5 Mt säiliöitä, joissa > 8% kuolleita tietoja "käsittelyä" varten

Toiseksi sen on poistettava DDR:ää koskevat kuolleet tiedot - lyhyt selvitys siitä, miten tämä tehdään, on seuraava:

• Käsittelyä varten valitut kontit tarkistetaan uudelleen sen vahvistamiseksi, että niissä on hyvä määrä kuolleita tietoja
• Live-tiedot poimitaan näistä säiliöistä ja kirjoitetaan uusiin 4.5Mb-säiliöihin tiedostojärjestelmän lopussa
• Kun tämä on valmis, valitut säilöt (mukaan lukien niiden sisältämät kuolleet tiedot) poistetaan levyltä fyysisesti vapauttaen levytilaa

Puhdas prosessi on jaettu useisiin "vaiheisiin", joiden kokonaisvaiheiden määrä riippuu:

• DDOS-versio, jota käytetään DDR: ssä (eli puhdas algoritmi, jota oletusarvoisesti käytetään DDOS-versiossa)
• Järjestelmän kokoonpano/sisältö

Yleisesti ottaen "kuolleiden" tietojen löytäminen ja vastaavien säiliöiden valitseminen tapahtuu kuitenkin useissa vaiheissa, kun taas kuolleet tiedot poistetaan yhdessä vaiheessa, jota kutsutaan "kopioksi". Esimerkiksi tietyt DDOS-versiot suoritetaan puhtaina vaiheina seuraavasti:

1. Esiluettelointi - luettele DDFS-tiedostojärjestelmän sisältö
2. Esiyhdistäminen - suorita DDFS-indeksin yhdistäminen varmistaaksesi, että indeksitietojen uusin kopio tyhjennetaan levylle
3. Esisuodatus - selvitä, onko DDFS-tiedostojärjestelmässä päällekkäisiä tietoja ja jos on, missä tämä on
4. Esivalitsin - määritä, mitkä 4,5 Mt:n säiliöt "käsitellään" puhdistamalla
5. Kopioi - pura live-tiedot fyysisesti valituista säilöistä, kirjoita tämä uusiin säilöihin ja poista sitten valitut säilöt
6. Yhteenveto - uudelleenrakentamisen yhteenvetovektorit (joita käytetään optimointiin uusien tietojen käytön aikana)

Edellä mainituissa esimerkkivaiheissa 1–4 määritetään, missä DDR:ssä on "kuolleita" tietoja (joita kutsutaan tämän asiakirjan loppuosan luettelointivaiheissa), kun taas vaihetta 5 (jäljennös) käytetään näiden tietojen poistamiseen fyysisesti.

Huomaa, että järjestelmässä ei ole fyysisesti tilaa, ennen kuin puhdas/GC on kopiointivaiheessa. Tämän seurauksena puhtaan aloittamisen ja tilan vapauttamisen välillä voi olla merkittävä viive (koska luettelointiprosessin on ensin ajettava loppuun). Tästä syystä järjestelmien ei pitäisi antaa täyttyä 100% täyteen ennen puhtaan/GC:n aloittamista.

Luettelointivaiheet ovat yleensä kalliita suorittimen käytön kannalta (eli ne ovat yleensä suoritinsidonnaisia), kun taas kopiointivaihe on kallis sekä suorittimen että I/O:n kannalta (eli ne ovat yleensä suoritin- ja I/O-sidottuja). Yhteenvetona voidaan kuitenkin sanoa, että:

• Luettelointivaiheiden kokonaispituus riippuu DDR:n tietojen määrästä, joka on lueteltava
• Kopiointivaiheen kokonaispituus riippuu DDR:n kuolleiden tietojen määrästä, joka on poistettava, ja siitä, kuinka hajanaisia tiedot ovat levyllä (ks. jäljempänä)

Luettelointivaiheiden määrä/toiminnallisuus riippuu DDR:ssä käytettävän DDOS:n julkaisusta.

DDOS 5.4 (ja aiempi) - täysin puhdas algoritmi: Suorittaa 6 tai 10 vaihetta (kuten edellä on esitetty):

• DDFS-tiedostojärjestelmän sisältö on luetteloitu ylhäältä alaspäin (eli se on tiedostokeskeinen)
• DDFS löytää kaikki DDR:ssä olleet tiedostot ja tarkistaa sitten kukin tiedosto vuorollaan, mihin tietoihin tiedosto viittaa
• Näin clean/GC voi määrittää, mitkä levyn tiedot ovat "live".

DDOS 5.5 (ja uudempi) - fyysinen puhdas algoritmi (PGC): Suorittaa 7 tai 12 vaihetta:

• DDFS:n sisältö on luetteloitu alhaalta ylöspäin (eli se ei enää skannaa yksittäisiä tiedostoja)
• DDFS löytää tiedostojärjestelmän metatiedot, jotka viittaavat levyn fyysisiin tietoihin, ja tarkistaa metatiedot määrittääkseen, mihin tietoihin viitataan
• Näin clean/GC voi määrittää, mitkä levyn tiedot ovat "live".
• Tämä saavutetaan lisäämällä analyysivaihe (tästä johtuu vaiheiden määrän kasvu täysin puhtaaseen algoritmiin)
• Useimmissa tapauksissa fyysisen puhdistuksen kokonaiskeston odotetaan kuitenkin olevan lyhyempi kuin saman järjestelmän täydellinen puhdistus (huolimatta siitä, että se koostuu yksilöllisemmistä vaiheista)

DDOS 6.0 (ja uudempi) - täydellinen fyysinen puhdas algoritmi (PPGC):

• Tämä on yksinkertaisesti optimointi fyysiselle puhtaalle algoritmille, ja sitä käsitellään tarkemmin alla

Huomaa, että DDOS siirtyi täydellisestä puhtaasta algoritmista fyysiseen puhtaaseen algoritmiin parantaakseen luettelointiprosessin skaalautuvuutta / suorituskykyä - täydellisen puhtaan algoritmin ylhäältä alaspäin olevan luonteen vuoksi se ei skaalannut hyvin DDR: llä, jolla oli jompikumpi:

• Suuri määrä pieniä tiedostoja (kontekstivalitsimena siirryttäessä tiedoston luettelointista toiseen oli kallista /hidasta)
• Suuri kopiointisuhde (koska useat tiedostot viittasivat samaan fyysiseen dataan, joten samat tiedot lueteltiin useita kertoja)

DDR-algoritmit siirtyvät täydestä fyysiseen puhtaaseen algoritmiin automaattisesti, kun ne päivitetään DDOS 5.4:stä (tai aiemmasta) versioon 5.5 (tai uudempi). Ainoa poikkeus tähän ovat järjestelmät, jotka on määritetty laajennetulla säilyttämisellä ja joissa DDFS-tiedostojärjestelmän sisältö on tarkistettava "koostamistiedostojen" osalta, ennen kuin fyysinen puhdistus voidaan ottaa käyttöön - keskustelu tästä prosessista on tämän asiakirjan soveltamisalan ulkopuolella, mutta tämä tarkistus suoritetaan automaattisesti päivityksen jälkeen ja fyysinen puhdistus on käytössä tämän tarkistuksen päätyttyä ilman manuaalisia toimia.

Vastaavasti DDR-algoritmit siirtyvät fyysisistä täydellisiin fyysisiin puhtaisiin algoritmeihin automaattisesti, kun ne päivitetään DDOS 5.x:stä 6.0:aan (tai uudempiin). Huomaa kuitenkin, että täydellinen fyysinen puhdas algoritmi edellyttää, että indeksit ovat "index 2.0" -muodossa, ennen kuin sitä voidaan käyttää. Huomioi:

• Index 2.0 -muoto otettiin käyttöön DDOS 5.5:llä (joten kaikki 5.5 tai uudempi tiedostojärjestelmät käyttävät jo indeksiä 2.0)
• Tiedostojärjestelmä, joka on luotu 5.4 tai aiemmin, on aluksi indeksit indeksi 1.0 muodossa. Kun indeksit on päivitetty DDOS 5.5:een (tai uudempiin), ne muunnetaan indeksin 2,0-muotoon - muuntaminen tapahtuu aina, kun puhtaat ajot suoritetaan, mutta vain ~ 1% indekseistä muunnetaan jokaisen puhdistuksen aikana, joten indeksien muuntaminen täysin 2,0-muotoon voi kestää jopa 2 vuotta (olettaen, että puhtaat ajot suoritetaan viikoittain).

DDR:t, joissa on alun perin DDOS 5.4 (tai aiempi), mutta jotka on sittemmin päivitetty DDOS 5.5:een (tai uudempiin), voidaan pakottaa muuntamaan indeksit indeksin 2,0-muotoon yhdellä kertaa "indeksin uudelleenrakentamisella". Huomaa kuitenkin, että indeksin uudelleenrakentaminen vaatii ajanjakson, kun indeksejä rakennetaan fyysisesti uudelleen - tämän toiminnon suorittamiseen menee yleensä 2-8 tuntia DDR: n tietojen koon / määrän mukaan. Jos haluat keskustella indeksin uudelleenrakentamisen suorittamisesta, ota yhteyttä sopimusperusteiseen tukipalveluun.

Kuten edellä mainittiin, puhtaasta/GC-algoritmista riippumatta puhdas voi vaatia vaihtelevan määrän vaiheita - esimerkiksi täydellinen puhdas algoritmi voi vaatia 6 tai 10 vaihetta. Syynä tähän on se, että:

• Kun DDFS käyntiin, se varaa kiinteän määrän muistia puhtaan/GC:n käytettäväksi
• Tässä muistissa clean/GC luo tietorakenteita, jotka kuvaavat luetteloinnin tuloksia (eli kuvaavat, missä levyllä on live vs. kuollutta tietoa)
• Kun DDR sisältää suhteellisen pienen määrän tietoja, DDFS-tiedostojärjestelmän koko sisältö voidaan kuvata tällä muistialueella
• Monissa järjestelmissä tämä ei kuitenkaan ole mahdollista, ja tämä muistialue loppuisi ennen kuin koko DDFS-tiedostojärjestelmän sisältö lueteltiin
• Tämän seurauksena nämä järjestelmät suorittavat "näytteenottoa", mikä lisää tarvittavien puhtaiden vaiheiden määrää

Kun näytteenottoa käytetään puhtaana/GC:

• Suorita luetteloinnin näytteenotto koko tiedostojärjestelmässä - huomaa, että tämä luettelointi ei ole "täydellinen" (eli se ei tallenna täydellisiä tietoja tiedostojärjestelmän kustakin osasta, vaan sen sijaan arvioi tietoja tiedostojärjestelmän kustakin osasta)
• Näiden näytteenottotietojen avulla voit määrittää, mikä DDFS-tiedostojärjestelmän osa hyötyisi eniten siitä, että sitä vastaan käytetään puhdasta/GC:tä (eli mikä tiedostojärjestelmän osa antaisi parhaan tuoton vapautuessaan tilasta, jos se puhdistetaan)
• Suorita toinen täydellisen luetteloinnin kierros sitä tiedostojärjestelmän valittua osaa vastaan, jonka sisältö voidaan nyt kuvata kokonaan GC:lle varatussa muistissa

Näytteenotto otetaan tarvittaessa automaattisesti käyttöön puhdistuksen/GC:n aikana, mutta se aiheuttaa kuitenkin:

• Puhtaalla/GC:llä suoriteltavien vaiheiden määrän kasvu
• Vastaava lisäys puhtaan/GC:n kokonaiskestossa

Ennen DDOS 6.0:aa suurin osa DDR:istä suorittaa näytteenoton puhtaan/GC:n aikana (ellei niillä ole suhteellisen pientä tietojoukkoa). Täydellinen fyysinen puhdas algoritmi sisältää kuitenkin erilaisia optimointeja, jotka vähentävät puhtaan /GC: n vaatimaa muistia, kun tietoja luetteloidaan tiedostojärjestelmässä. Tämä tarkoittaa, että monet järjestelmät, jotka suorittivat näytteenottoa puhtaan/GC:n aikana DDOS 5.x:llä, eivät enää vaadi näytteenottoa DDOS 6.0:sta - tämä vähentää puhtaiden vaiheiden määrää ja vähentää vastaavasti puhdasta kokonaisajoaikaa (eli parantaa puhdasta suorituskykyä).

Käytettävissä ei ole tietoja, jotka suoraan määrittävät, että järjestelmä on siirtynyt fyysisestä puhtaasta algoritmista täydelliseen fyysiseen puhtaaseen algoritmiin, joka on muu kuin:

• Kun järjestelmä oli fyysisesti puhdas DDOS 5.5 - 5.7: llä, se suoritettiin 12 vaihetta puhtaan
• Kun järjestelmä on päivitetty DDOS 6.0:aan (tai uudempiin), se suorittaa vain 7 vaihetta puhtaan

Jos DDOS 6.0 -järjestelmää käyttävä järjestelmä tarvitsee vielä näytteenoton, se otetaan automaattisesti käyttöön puhdistuksen aikana ja se palaa 12 vaiheeseen puhdistuksen aikana.

Puhtaasta algoritmista riippumatta kopiointivaihe (jossa kuolleet tiedot poistetaan fyysisesti järjestelmästä) toimii samalla tavalla kaikissa julkaisuissa. Kopiointivaiheen suorituskyky riippuu yleensä:

• "Kuolleiden" tietojen määrä, joka on poistettava
• Kuolleiden tietojen "pirstoutuminen" (eli miten ne jakautuvat levylle)

Kuten edellä on kuvattu, kopioi toimii valitsemalla 4.5Mb-säiliöt, joissa on kuolleita tietoja, poimimalla kaikki elävät tiedot näistä säiliöistä ja kirjoittamalla kyseiset elävät tiedot uusiin säiliöihin ja poistamalla sitten alun perin valitut säilöt. Seuraavat esimerkit kuvaavat, miksi kuolleiden tietojen pirstoutuminen on tärkeää:

Esimerkki 1:

• Kopioitavaksi valitaan 10 konttia (45Mb kokonaisdataa)
• Kaikki, jos näissä säiliöissä ei ole eläviä tietoja (eli niiden hallussa olevia tietoja ei ole täysin päätelty/kuollut)
• Tämän seurauksena kopion on yksinkertaisesti merkitseä nämä säiliöt poistetuksi, jotta levyllä on 45 Mt fyysistä tilaa

Esimerkki 2:

• Kopioitavaksi valitaan 100 konttia (450Mb kokonaisdataa)
• Jokaisessa näistä säiliöistä on 90% elävää dataa / 10% kuolleita tietoja
• Näiden säilöjen käsitteleminen on:

On selvää, että esimerkissä 2 kuvatun kopion suorittaminen edellyttää huomattavasti suurempaa määrää I/O: ta ja suoritinta kuin esimerkissä 1, joten tässä esimerkissä kestää huomattavasti kauemmin vapauttaa 45Mb fyysistä tilaa levyllä.

Käyttäjillä ei yleensä ole määräysvaltaa DDR:n levyllä olevan kuolleen datan "pirstoutumiseen", koska tämä riippuu hyvin paljon järjestelmään kirjoitettaessa käyttötapauksesta tai -tyypistä. Huomaa kuitenkin, että clean/GC ylläpitää tilastoja, jotka auttavat määrittämään kopiointivaiheessa kohdatun kuolleiden tietojen "pirstoutumisen" (minkä vuoksi käyttäjä voi määrittää, voiko tämä pirstoutuminen selittää mahdollisesti pitkään käynnissä olevan kopiointivaiheen). Tällaiset tilastot clean/GC:n viimeisimmästä vaiheesta kerätään autotuena. Seuraavassa on esimerkiksi kopiointivaihe, jossa kuolleet tiedot olivat melko yhteneviä (eli suurin osa kopioitaessa valituista säiliöistä piti enimmäkseen kuolleita tietoja): Kopioitujen

live-tietojen prosenttiosuus:              3,6 % 4,3 %

Toisaalta seuraavassa esitetään kopiointivaihe, jossa kuolleet tiedot pirstoutuneina (eli suurin osa kopioitaessa valituista säiliöistä piti enimmäkseen live-tietoja): Kopioidun

live-datan prosenttiosuus:             70,9 % 71,5 %

Kuten edellä on kuvattu, puhtaan/GC:n on tehtävä toisessa skenaariossa suhteellisesti paljon enemmän työtä DDR:n fyysisesti vapaan tilan vapauttamiseksi, mikä vähentää kopiointivaiheen siirtomäärää.

Kopiointivaiheen siirtoon voivat vaikuttaa haitallisesti myös:

• Salauksen käyttö: Tiedot on ehkä purettava tai salattava uudelleen kopioinnin aikana, mikä lisää merkittävästi tarvittavaa prosessorin määrää
• Alhaisen kaistanleveyden optimoinnin käyttö: Säiliöt saattavat tarvita kopioinnin aikana kertyvää "luonnostietoa", joka myös lisää merkittävästi vaadittua prosessorin määrää

Huomaa, että jos kaistanleveyden optimointi ja/tai salaus on äskettäin otettu käyttöön, kaikki olemassa olevat säilöt (riippumatta siitä, onko ne valittu kopioitavaksi vai ei) on ehkä salattava ja/tai niitä vastaan on tuotettu luonnostietoja myöhemmän puhdistuksen aikana - tämä voi aiheuttaa sen, että puhdas toiminta (erityisesti kopiointivaihe) kestää huomattavasti normaalia kauemmin.

Lisätietoja puhtaan aikataulun ja kaasuvipujen tarkistamisesta/muokkaamisesta on seuraavassa KB:n artikkelissa: https://support.emc.com/kb/306100

Huomautus kuitenkin, että:

• Normaalioloissa puhtaana oleminen on ajoitettu toteutumaan enintään kerran viikossa - puhtaaksi juokseminen tätä useammin voi aiheuttaa levyllä olevan datan liiallisen "pirstoutumisen" (eli heikon paikkakunnan), mikä voi johtaa huonoon luku-/ replikointi- tai tiedonsiirtotulokseen
• Puhdas kaasuvipu ei vaikuta puhdistuksen kuluttaman suorittimen ja I/O-kaistanleveyden kokonaismäärään - sen sijaan se ohjaa, kuinka herkkä puhdistus on järjestelmän muuhun työmäärään. Esimerkki:

• Oletusarvon mukaan puhdas kaasu on asetettu 50 : een - käyttäjän vastuulla on testata toimintaa puhtaasti eri kaasuilla, kun taas DDR kokee normaalin työmäärän määrittääkseen kaasuasetuksen, joka mahdollistaa:

• Huomaa, että pitkään käynnissä ollut puhdistus ei välttämättä ole ongelma, kunhan:

• Laajennettua säilytystoimintoa käyttava järjestelmä on määritettävä siten, että

• Täydelliset tiedot viimeisimmästä puhtaasta toiminnosta sisältyvät automaattiseen tukeen ja yksityiskohtiin: