Data Domain: Data Domain -pakkaamisen ymmärtäminen

Data Domainiin liittyvissä pakkaustekniikoissa käytetään uusimpia tekniikoita varmuuskopiotietojen vaatiman fyysisen tilan vähentämiseksi. Pakkaustasojen tekniikat ja mittaukset ovat näin ollen monimutkaisia aiheita.

Tässä artikkelissa käsitellään joitakin termejä, kompromisseja ja toimenpiteitä, joilla voidaan selittää paremmin käytetty pakkaustyyppi sekä muut Data Domain -ympäristön pakkaamiseen liittyvät näkökohdat.

KOSKEE SEURAAVIA: Kaikki Data Domain -mallit

Johdanto

Viimeksi päivitetty: Tammikuu 2024

• Pakkaus on tietojen vähentämistekniikka, jonka tarkoituksena on tallentaa tietojoukko käyttämällä vähemmän fyysistä tilaa.
• Data Domain Systems (DDOS) -järjestelmissä käyttäjätiedot pakataan deduplikointi ja paikallinen pakkaus. Deduplikointia eli deduplikointia käytetään tarpeettomien datasegmenttien tunnistamiseen ja vain yksilöllisten datasegmenttien tallentamiseen.
• Paikallinen pakkaus pakkaa yksilöllisiä datasegmenttejä edelleen tietyillä pakkausalgoritmeilla, kuten lz, gzfast, gz, niin edelleen.
• DDOS:n käyttäjätietojen yleinen pakkaus on tieto-optimoinnin ja paikallisen pakkauksen yhteinen ponnistus. DDOS mittaa tietojen pakkaamistehokkuutta pakkaussuhteella.
• Yleensä se on käyttäjätietojen kokonaiskoon suhde pakatun datan kokonaiskokoon tai käytetyn fyysisen tilan kokoon.
• Data Domain -tiedostojärjestelmä on lokirakenteinen deduplikointitiedostojärjestelmä.
• Lokirakenteinen tiedostojärjestelmä ainoastaan liittää järjestelmään tietoja, eikä poistaminen itsessään vapauta fyysistä tilaa.
• Kyseiset tiedostojärjestelmät vapauttavat tilaa, jota ei enää tarvita, käyttämällä muistin tiivistämistä.
• Lokirakenteisen tiedostojärjestelmän ja deduplikoidun tekniikan ominaisuudet yhdessä tekevät DDOS:n pakkauksen kaikkien näkökohtien selkeästä ymmärtämisestä hankalaa.

Pakkausta varten voidaan mitata monia näkökohtia.

Tässä artikkelissa käsitellään yksityiskohtaisia tietoja DDOS-pakkauksen ymmärtämiseksi.

• Aluksi selitetään järjestelmän yleinen pakkausvaikutus, joka kertoo meille Data Domain -järjestelmässä saavutetun realistisen pakkauksen, käyttäjätietojen määrän, kulutetun fyysisen tilan määrän ja niiden suhteen.
• Tätä suhdetta kutsutaan tässä artikkelissa "järjestelmän tehokkaaksi pakkaussuhteeksi".
• DDOS suorittaa deduplikoinnin upotettuna ja seuraa alkuperäisten käyttäjätietosegmenttien tilastoja, dedupen jälkeisiä yksilöllisiä datasegmenttejä ja paikallista pakkausvaikutusta yksilöllisiin datasegmentteihin.
• Kyseisiä inline-pakkaustilastoja käytetään inline-pakkaustehokkuuden mittaamiseen. Inline-pakkaustilastot voidaan mitata jokaiselle kirjoitukselle. DDOS seuraa myös tilastoja eri tasoilla: Tiedostot MTreesja koko järjestelmä.

Vastaisuudessa julkaistavien versioiden koko sisällön paikkansapitävyyttä ei voida taata.

Versiota 5.0 edeltävissä versioissa koko järjestelmässä on vain yksi mtree ja termi mtree ei ole nimenomaisesti mainittu.

Pakkaaminen: Järjestelmän kokonaisvaikutus:

Koko järjestelmän kattava kokonaispakkausvaikutus mitataan efektiivisellä pakkaussuhteella, joka on käyttäjätietojen koon suhde käytetyn fyysisen tilan kokoon. Sen raportoi "filesys show compression" (FSC) CLI-komento (vastaavat tiedot ovat saatavilla myös käyttöliittymässä). Näytteen tuotos FSC on esitetty alla:

# filesys show compression

From: 2023-12-31 03:00 To: 2024-01-07 03:00

Active Tier:
                   Pre-Comp   Post-Comp   Global-Comp   Local-Comp      Total-Comp
                      (GiB)       (GiB)        Factor       Factor          Factor
                                                                     (Reduction %)
----------------   --------   ---------   -----------   ----------   -------------
Currently Used:*     6439.6       113.4             -            -    56.8x (98.2)
Written:
  Last 7 days      135421.3      1782.0         35.1x         2.2x    76.0x (98.7)
  Last 24 hrs         532.5         1.5        334.3x         1.1x   356.5x (99.7)
----------------   --------   ---------   -----------   ----------   -------------
 * Does not include the effects of pre-comp file deletes/truncates
   since the last cleaning on 2024/01/05 11:34:13.

• •  
  • Järjestelmän efektiivinen puristussuhde ilmoitetaan komentoriviliittymän tuloksen tulososion rivillä 1. Rivi on korostettu edellä.
  • Käyttäjädatan kokonaiskooksi on merkitty "Pre-Comp".
  • Fyysisen tilan kokonaismäärä (sekä tietojen että metatietojen perusteella) on merkitty "Post-Compiksi".
  • Pre-Comp-numero ja Post-Comp-numero luetaan suorituksen aikana. FSC Implisiittisesti synkronoi koko järjestelmän ja kysyy sitten kahta numeroa.
    • Nämä kaksi lukua mitataan samalla tavalla kuin "filesys show space" komento.
    • Järjestelmän efektiivinen puristussuhde = Pre-Comp/Post-Comp

Jotkut toiminnot voivat vaikuttaa järjestelmän tehokkaaseen pakkaussuhteeseen:

• Nopea kopiointi
  • Kun a fastcopy tehdään aktiivisessa nimitilassa olevasta tiedostosta (ei tilannekuvasta), se on täydellinen deduplikointi, koska kohdetiedostolle ei tarvita ylimääräistä fyysistä tilaa. A fastcopy on, että käyttäjätietojen kokoa kasvatetaan kuluttamatta ylimääräistä fyysistä tilaa. Tämä lisää järjestelmän tehokasta puristussuhdetta. Kun monta fastcopies tehdään, järjestelmän tehokas puristussuhde voi nousta keinotekoisesti korkeaksi.
• Virtuaaliset synteettiset materiaalit
  • Virtuaaliset synteettiset varmuuskopiot näyttävät yleensä korkean järjestelmän tehokkaan pakkaussuhteen. Tämä johtuu siitä, että virtuaalisynteettiset tiedostot tekevät loogiset täydelliset varmuuskopiot, mutta vain siirretyt tai uudet tiedot siirretään Data Domain -järjestelmiin. Virtuaalisynteettisten materiaalien vaikutus järjestelmän tehokkaaseen pakkaussuhteeseen on jonkin verran samanlainen kuin fastcopy.
• Korvaa
  • Korvaukset vievät enemmän fyysistä tilaa, mutta eivät kasvata tietojoukon loogista kokoa, joten ne pienentävät järjestelmän tehokasta pakkaussuhdetta
• Harvojen tiedostojen tallentaminen
  • Hajanaisissa tiedostoissa on suuria reikiä, jotka lasketaan loogiseen kokoon, mutta jotka pakkaamisen ansiosta eivät vie fyysistä tilaa. Siksi ne saavat järjestelmän tehollisen pakkaussuhteen näyttämään korkealta.
• Pienten tiedostojen tallentaminen
  • DDOS lisää lähes 1 kt yleiskustannuksia jokaiseen tiedostoon tiettyjen sisäisten metatietojen osalta. Kun järjestelmä tallentaa huomattavan määrän pieniä tiedostoja (kooltaan alle 1 kt tai yksinumeroisina kilotavuina), metatietojen yleiskustannukset vetävät efektiivistä pakkaussuhdetta alaspäin.
• Esipakattujen tai salattujen tiedostojen tallentaminen
  • Pakkaaminen ja salaus voivat tehostaa tietojen muuttumista ja vähentää deduplikoinnin mahdollisuutta. Tällaisia tiedostoja ei yleensä voida kopioida hyvin ja alentaa järjestelmän tehokasta pakkaussuhdetta.
• Poistaa
  • Poistot pienentävät järjestelmän loogista kokoa, mutta järjestelmä ei saa vastaavaa käyttämätöntä tilaa takaisin ennen kuin muisti tiivistetään. Monet poistetut tiedostot tekevät pakkaussuhteesta alhaisen, kunnes Garbage Collection (GC) suoritetaan.
• Roskien keräys (GC) tai siivous
  • GC vapauttaa tilaa datasegmenteille, joita mikään tiedosto ei enää näe. Jos äskettäin on poistettu suuri määrä tiedostoja, muistin tiivistäminen saattaa parantaa järjestelmän pakkaussuhdetta pienentämällä fyysisen tilan kulutusta.
• Tilannekuvien aggressiivinen ottaminen
  • Kun tilannevedos Mtree otetaan, tietojoukon loogista kokoa ei muuteta. Kaikki tilannevedoksessa viitatut tietosegmentit on kuitenkin lukittava, vaikka kaikki tilannevedokseen tallennetut tiedostot poistettaisiin tilannevedoksen ottamisen jälkeen. GC ei pysty vapauttamaan tilannevedosten vielä tarvitsemaa tilaa, koska tilannevedoksia on paljon, järjestelmän todellinen pakkaussuhde saattaa vaikuttaa alhaiselta. Tilannevedokset ovat kuitenkin hyödyllisiä kaatumisen palautustoimintoja. Älä koskaan epäröi ottaa tilannevedoksia tai määrittää kunnollisia tilannevedosten aikatauluja tarvittaessa.

Pakkaaminen: Sisäiset tilastot:

DDOS suorittaa deduplikoinnin inline, kun tiedot kirjoitetaan järjestelmään. Se seuraa sisäisen tieto-optimoinnin ja paikallisen pakkauksen vaikutuksia jokaisen kirjoituksen yhteydessä ja kerää tilastot tiedostotasolla. Tiedostokohtaiset inline-pakkaustilastot on koottu edelleen osoitteessa mtree tasolla ja järjestelmätasolla. Pakkausta mitataan kolmen numeron perusteella inline-tilastoissa:

• Kunkin kirjoituksen pituus: raw_bytes 
• The length of all unique segments: pre_lc_size
• Paikallisesti pakattujen yksilöllisten segmenttien pituus: post_lc_size

• • Yleinen pakkaus (g_comp)
    • On yhtä suuri kuin (raw_bytes/pre_lc_size) ja kuvastaa deduplikointisuhdetta
  • Paikallinen pakkaus (l_comp)
    • On yhtä suuri kuin (pre_lc_size/post_lc_size) ja kuvastaa paikallisen pakkausalgoritmin vaikutusta

Kertyneet sisäiset pakkaustilastot ovat osa DDOS:n tiedoston metatietoja, ja ne tallennetaan tiedostoon inode. DDOS tarjoaa työkaluja inline-pakkausten tarkistamiseen kaikilla kolmella tasolla; Tiedosto MTreeja koko järjestelmän laajuisesti. Ne on kuvattu yksityiskohtaisesti seuraavissa osissa.

Tiedostojen pakkaus:

• • Tiedostojen pakkaus voidaan tarkistaa "filesys show compression <path>" CLI-komento, joka raportoi tiedostoon tallennetut kertyneet pakkaustilastot inode.
  • Kun hakemisto on määritetty, kaikkien hakemistossa olevien tiedostojen sisäiset pakkaustilastot lasketaan yhteen ja raportoidaan.
  • CLI-lähdössä raw_bytes on merkitty "alkuperäisiksi tavuiksi", pre_lc_size on merkitty "maailmanlaajuisesti pakatuksi", post_lc_bytes on merkitty "paikallisesti pakatuksi". Muut yleiskustannukset raportoidaan "metatietoina". Nämä kaksi esimerkkiä on tallennettu DD-tuotantojärjestelmästä:

Esimerkki 1: Tiedoston sisäiset pakkaustilastot

filesys show compression /data/col1/main/dir1/file_1

Total files: 1;  bytes/storage_used: 7.1
        Logical Bytes:       53,687,091,200
       Original Bytes:       11,463,643,380
  Globally Compressed:        4,373,117,751
   Locally Compressed:        1,604,726,416
            Meta-data:           18,118,232

Esimerkki 2: Kaikkien hakemistossa olevien tiedostojen sisäiset pakkaustilastot, mukaan lukien kaikki alihakemistot

filesys show compression /data/col1/main/dir1 

Total files: 13;  bytes/storage_used: 7.1
        Logical Bytes:       53,693,219,809
       Original Bytes:       11,501,978,884
  Globally Compressed:        4,387,212,404
   Locally Compressed:        1,608,444,046
            Meta-data:           18,241,880

• • • Järjestelmä ilmoittaa yleisen inline-pakkaussuhteen yllä olevassa komentoriviliittymän tuloksessa muodossa "tavua/"storage_used.
    • Edellä esitettyjä tietoja on kuitenkin tulkittava huolellisesti, sillä ne voivat olla monista syistä harhaanjohtavia.
    • Yksi syy on se, että pre_lc_size ja post_lc_size tallennetaan tieto-operaatioiden käsittelyn yhteydessä.
    • Kun kyseiset segmentit alun perin lisännyt tiedosto poistetaan, jäljellä olevan tiedoston yksilöllisten datasegmenttien määrää on lisättävä.

Oletetaan esimerkiksi, että tiedoston mallitiedosto on varmuuskopioitu Data Domainiin ja että ensimmäisessä varmuuskopiossa tiedoston pakkaustiedot ovat pre_lc_size= 10 GiB, post_lc_size= 5 Gib.

• • • Oletetaan seuraavaksi, että tämän tiedoston tiedot ovat yksilöllisiä eikä tietoja jaeta minkään muun tiedoston kanssa.
    • Oletetaan edelleen tiedoston toisessa varmuuskopiossa, että tiedosto saa ihanteellisen deduplikoinnin siten, että molemmat pre_lc_size ja post_lc_size pitäisi olla nolla, koska kaikki tiedoston segmentit olivat jo olemassa järjestelmässä.
    • Kun ensimmäinen varmuuskopio poistetaan, tiedoston toisesta varmuuskopiosta tulee ainoa tiedosto, joka viittaa datasegmenttien 5 gigatavuun.
    • Tässä tapauksessa ihannetapauksessa pre_lc_size ja post_lc_size on päivitettävä nollasta 10 GiB:iin ja 5 GiB:iin.
    • Ei kuitenkaan ole mitään keinoa havaita, mille tiedostoille se pitäisi tehdä, joten olemassa olevien tiedostojen sisäiset pakkaustilastot jätetään ennalleen.

• • Toinen tekijä, joka vaikuttaa edellä mainittuihin lukuihin, on kumulatiiviset tilastot.
  • Kun tiedosto saa paljon korvauksia, on mahdotonta seurata, missä määrin kumulatiiviset tilastot vastaavat reaaliaikaisten tietojen käyttöönottoa käyttäviä kirjoituksia.
  • Siten pitkän ajan kuluessa sisäisiä pakkaustilastoja voidaan pitää vain heuristiikkana tietyn tiedoston pakkauksen karkeaksi arvioimiseksi.
  • Toinen korostamisen arvoinen seikka on, että tiedoston sisäistä pakkausta ei voida mitata mielivaltaisella aikavälillä.
  • Tiedostojen sisäiset pakkaustilastot ovat kumulatiivisia tuloksia ja kattavat kaikki tiedoston koskaan vastaanottamat kirjoitukset.
  • Kun tiedosto saa paljon korvauksia, raw_bytes voi olla paljon suurempi kuin tiedoston looginen koko. Harvoissa tiedostoissa tiedostokoot voivat olla suurempia kuin "alkuperäiset tavut".

MTree-pakkaus:

• • Tietyn puristus mtree voidaan tarkistaa "mtree show compression" (MSC) CLI-komento.
  • Inline-pakkaustilastojen absoluuttiset arvot ovat kumulatiivisia MTree.
  • Kun otetaan huomioon, että MTree voi olla useita vuosia pitkä, nämä arvot muuttuvat ajan myötä yhä vähemmän informatiivisiksi.
  • Tämän ongelman ratkaisemiseksi käytetään sisäisen pakkauksen tilastojen muutoksen määrää (deltaa) ja raportoidaan pakkaus vain tietyiltä aikaväleiltä.
  • Perusajatuksena on, että MTree Sisäiset pakkaustilastot dumpataan säännöllisesti lokiin.
  • Kun asiakas tekee MTree-pakkauskyselyn MSC -komennolla, lokia käytetään lukujen delta-arvojen laskemiseen pakkausraportointia varten.
  • Oletuksena MSC Raportoi pakkauksen viimeisten 7 päivän ja viimeisten 24 tunnin ajalta, mutta mikä tahansa kiinnostava ajanjakso voidaan määrittää.

Oletetaan havainnollistamiseksi, että loki on seuraava: MTree V:

3:00AM, raw_bytes=11000GB, pre_lc_size=100GB, post_lc_size=50GB 4:00AM, raw_bytes=12000GB, pre_lc_size=200GB, post_lc_size=100GB

Sitten puristus MTree Tämän tunnin A on:

g_comp = (12000-11000)/(200-100) = 10x
l_comp = (200-100)/(100-50) = 2x
overall compression ratio = (12000-11000)/(100-50) = 20x

Yllä oleva pakkaussuhteen laskenta ei tee mitään tietojoukon koon kanssa. Esimerkiksi yllä olevassa mtreessä voi olla vain 500 Gt loogisia tietoja.

• • MSC tukee "päivittäin" ja "päivittäin yksityiskohtaiset" vaihtoehtoja, samoin kuin "filesys show compression" komento.
  • Kun daily-asetus on määritetty, komento ilmoittaa päivittäisen pakkauksen kalenterin mukaisesti.
  • Se käyttää päivittäisiä delta-alueita raw_bytes ja post_lc_size laskeaksesi päivittäisen pakkaussuhteen.
  • Kun "daily-detailed" on määritetty, komento näyttää kaikki kolme deltaa ( raw_bytes, pre_lc_sizeja post_lc_size, vastaavasti) kullekin päivälle. Se laskee myös g_comp ja l_comp kokonaispuristuskertoimen rinnalla.

Näiden järjestelmien näytetulos on jäljempänä olevassa lisäyksessä .

Järjestelmän pakkaus:

• • Kun pakkaus raportoidaan MTrees ymmärretään, on yksinkertaista laajentaa käsite koko järjestelmään.
  • Järjestelmänlaajuinen pakkausinline-tilastojen kerääminen ja raportointi ovat täsmälleen samat kuin MTrees.
  • Ainoa ero on soveltamisala, koska yksi on tietyssä MTree, kun taas yksi on koko järjestelmän päällä.
  • Tulokset voidaan tarkistaa käyttämällä "filesys show compression" komento.
  • Esimerkki tästä on kohdassa 2.
  • Järjestelmän kompressio "viimeiset 7 päivää" ja "viimeiset 24 tuntia" ilmoitetaan tulososion kahdella viimeisellä rivillä FSC Lähtö.

Pilvitaso:

• DD:issä, joissa on otettu käyttöön pilvitaso, tallennustila on jaettu aktiiviseen tasoon ja pilvitasoon, jotka ovat kaksi itsenäistä deduplikointitoimialuetta.
• Käyttäjät voivat lisätä tietoja vain aktiiviselle tasolle.
• Myöhemmin DDOS-tiedonsiirtotoimintoja voidaan käyttää tietojen siirtämiseen aktiiviselta tasolta pilvitasolle.
• Siten tilan ja puristuksen mittaus ja raportointi hoidetaan itsenäisesti kullakin tasolla.
• Tiedostotasolla ei kuitenkaan tehdä eroa tason ja raportin sisäisten pakkaustilastojen mukaan, vaan ne ovat täsmälleen samat kuin kohdassa 3.1 kuvatut tiedot.

Deduplication:

Viimeinen korostettava aihe on joitakin deduplikoinnin ominaisuuksia, sillä monissa Data Domain -artikkeleissa sitä kutsutaan "globaaliksi pakkaukseksi".

Vaikka se sisältää sanan "pakkaus", se on täysin erilainen kuin perinteinen pakkauksen käsite, jota myös DDOS tarjoaa nimellä "paikallinen pakkaus".

• Paikallinen pakkaus pienentää datan kokoa käyttämällä tiettyä algoritmia (tietyntyyppiset tiedot eivät ole puristettavissa ja pakkausalgoritmien soveltaminen niihin voi hieman lisätä datan kokoa).
• Yleensä, kun algoritmi on päätetty, tiedot ovat pakkaussuhteen ainoa tekijä.
• Deduplikointi on kuitenkin erilainen - se ei ole paikallinen käsite, se on "globaali".
• Saapuvan datasegmentin deduplikointi poistetaan kaikista olemassa olevista datasegmenteistä verkkotunnuksessa, joka sisältää kaikki muiden kuin pilvipohjaisten Data Domain -järjestelmien tiedot.
• Itse datasegmentillä ei ole merkitystä deduplikointimenettelyssä.
• Käytännössä korkea deduplikointisuhde näkyy harvoin tietojoukon alkuperäisessä varmuuskopioinnissa. Ensimmäisissä varmuuskopioissa tietojen määrän väheneminen johtuu usein paikallisesta pakkaamisesta.
• Kun myöhemmät varmuuskopiot saapuvat Data Domainiin, deduplikointi osoittaa vahvuutensa ja siitä tulee hallitseva pakkaustekijä.
• Tieto-optimoinnin tehokkuus perustuu siihen, että tietojoukon muutosnopeus varmuuskopioinnista varmuuskopiointiin on alhainen. Tästä syystä tietojoukkoja, joilla on suuri muutosaste, ei voida hyvin poistaa.
• Kun varmuuskopiointisovellus lisää omia metatietopalojaan (joita Data Domain kutsuu markkereiksi) varmuuskopiokuviin suurella taajuudella, se ei myöskään välttämättä saa hyvää deduplikointisuhdetta. Merkkien käsittelytekniikkamme voivat auttaa joskus, mutta eivät aina.

Näiden havaintojen perusteella mitä odottaa:

• Ensimmäisillä varmuuskopioilla voidaan saavuttaa vain pieni järjestelmän tehokas pakkaussuhde, usein 2x tai 3x. Deduplikoinnilla on yleensä vähän mahdollisuuksia osoittaa vahvuutensa ensimmäisissä varmuuskopioissa.
• Lisäävässä varmuuskopioinnissa yleinen pakkaussuhde on pienempi kuin vastaavan täydellisen varmuuskopion pakkaussuhde. Tämä johtuu siitä, että välittömästi edeltävään varmuuskopioon verrattuna lisäävä varmuuskopiointi sisältää vain muutokset tai uudet tiedostot. Yleinen pakkaussuhde määräytyy inkrementaalisen varmuuskopion uusien tietojen prosenttiosuuden mukaan.
• Täydellisen varmuuskopioinnin (ei-alkuperäisten) deduplikointisuhde voi myös olla alhainen joissakin tilanteissa. Usein havaittuja skenaarioita ovat esimerkiksi seuraavat:
  • Suuri muutos varmuuskopioitavissa tiedoissa
  • Tietojoukkoa hallitsevat pienet tiedostot (alle 5 MiB)
  • Varmuuskopiointisovellukset lisäämällä paljon lähekkäin olevia merkkejä
  • Tietokannan varmuuskopiot, jotka ovat lisääviä tai käyttävät pientä lohkokokoa
  • Jos täydellisessä varmuuskopiossa havaitaan alhainen pakkaussuhde pienellä tiedonsiirtonopeudella, tarkista, päteekö jokin yllä olevista tapauksista vai tarvitaanko lisäanalyysiä.
• Myöhemmän varmuuskopiokuvan pakkaus ei aina ole parempi kuin alkuperäinen. Peräkkäisten varmuuskopioiden levykuvien deduplikointisuhde voi olla korkea, koska ensimmäiset ja aiemmat varmuuskopiokuvat ovat jo lisänneet suurimman osan tiedoista järjestelmään. Kun kaikki aikaisemmat varmuuskopiot poistetaan, varhaisimman olemassa olevan varmuuskopiokuvan yleinen ja paikallinen pakkaussuhde voi silti olla korkea, mutta tämä tarkoittaa vain sitä, että se sai hyvän deduplikoinnin järjestelmässä, ei mitään muuta. Kun poistetaan tiedosto, jolla on korkea yleinen ja paikallinen pakkaussuhde ja joka on tietyn tietojoukon viimeinen varmuuskopiotiedosto, se saattaa vapauttaa enemmän tilaa kuin pakkaussuhteesta johdettu koko.
• Saman tietojoukon pakkaussuhteita eri järjestelmissä ei voi verrata riippumatta siitä, miten tietojoukko lisätään kyseisiin järjestelmiin. Tämä johtuu siitä, että kukin järjestelmä on itsenäinen deduplikointitoimialue. Ei ole odotettavissa, että kaksi eri DD: tä saavat samat tai edes välttämättä samanlaiset pakkaussuhteet, vaikka niiden tietojoukot olisivat samat.

Yhteenveto:

• Pakkauksen mittaaminen on vaikeaa deduplikoiduissa tiedostojärjestelmissä, mutta vielä vaikeampaa se on log-rakenteisissa deduplikoiduissa tiedostojärjestelmissä.
• On ymmärrettävä, miten deduplikointi toimii ja miten pakkaustilastoja seurataan.
• Pakkaussuhteet ovat hyödyllistä tietoa tietyn järjestelmän käyttäytymisen ymmärtämiseksi.
• Järjestelmän tehokas puristussuhde on tärkein, luotettavin ja informatiivisin mittaus.
• Myös sisäiset pakkaustilastot voivat olla hyödyllisiä, mutta joissakin olosuhteissa ne saattavat olla vain heuristiikkaa.

Liite:

Näytteen tuotos "mtree show compression" Komento

• Oletetaan, että on olemassa MTree jossa on 254792,4 GiB tietoja. Se on saanut 4379,3 GiB uutta tietoa viimeisten 7 päivän aikana ja 78,4 GiB viimeisen 24 tunnin aikana (muut aikavälit voidaan määrittää).
• Päivittäinen (daily) -optio ilmoittaa pakkauksen inline-tilastot viimeisten 33 päivän ajalta.
• Kun "päivittäinen yksityiskohtainen" -vaihtoehto tarjotaan, kokonaispuristussuhteet tarkennetaan jakamalla ne yleisiin ja paikallisiin puristussuhteisiin.

pikanäppäimellä mtree Luettelon tulos:

mtree list /data/col1/main 

Name              Pre-Comp (GiB)   Status
---------------   --------------   ------
/data/col1/main         254792.4   RW
---------------   --------------   ------
 D    : Deleted
 Q    : Quota Defined
 RO   : Read Only
 RW   : Read Write
 RD   : Replication Destination
 IRH  : Retention-Lock Indefinite Retention Hold Enabled
 ARL  : Automatic-Retention-Lock Enabled
 RLGE : Retention-Lock Governance Enabled
 RLGD : Retention-Lock Governance Disabled
 RLCE : Retention-Lock Compliance Enabled
 M    : Mobile
 m    : Migratable

MSC (ei vaihtoehtoja):

mtree show compression /data/col1/main

From: 2023-09-07 12:00 To: 2023-09-14 12:00

                Pre-Comp   Post-Comp   Global-Comp   Local-Comp      Total-Comp
                   (GiB)       (GiB)        Factor       Factor          Factor
                                                                  (Reduction %)
-------------   --------   ---------   -----------   ----------   -------------
Written:
  Last 7 days     4379.3       883.2          3.4x         1.5x     5.0x (79.8)
  Last 24 hrs      784.6       162.1          3.3x         1.4x     4.8x (79.3)
-------------   --------   ---------   -----------   ----------   -------------

"Daily"-vaihtoehdolla:

mtree show compression /data/col1/main daily

From: 2023-08-12 12:00 To: 2023-09-14 12:00

  Sun     Mon     Tue     Wed     Thu     Fri     Sat   Weekly
-----   -----   -----   -----   -----   -----   -----   ------   -----------------
 -13-    -14-    -15-    -16-    -17-    -18-    -19-            Date
432.0   405.9   284.1   438.8   347.0   272.7   331.4   2511.8   Pre-Comp
 85.5    66.2    45.3    81.9    61.4    57.4    66.3    464.1   Post-Comp
 5.0x    6.1x    6.3x    5.4x    5.7x    4.7x    5.0x     5.4x   Total-Comp Factor

 -20-    -21-    -22-    -23-    -24-    -25-    -26-
478.0   387.8   450.2   533.1   386.0   258.4   393.6   2887.1
100.6    81.5   100.8   119.0    84.0    40.6    75.3    601.8
 4.8x    4.8x    4.5x    4.5x    4.6x    6.4x    5.2x     4.8x

 -27-    -28-    -29-    -30-    -31-     -1-     -2-
 27.6     1.0     0.4   470.7   467.3   517.7   641.9   2126.7
  4.9     0.2     0.1    83.9    92.3    89.8   140.1    411.2
 5.6x    5.6x    4.3x    5.6x    5.1x    5.8x    4.6x     5.2x

  -3-     -4-     -5-     -6-     -7-     -8-     -9-
539.6   495.0   652.8   658.7   537.1   398.7   305.5   3587.3 
110.8   108.0   139.4   137.0   111.5    78.3    48.3    733.3 
 4.9x    4.6x    4.7x    4.8x    4.8x    5.1x    6.3x     4.9x 

 -10-    -11-    -12-    -13-    -14-   
660.2   738.3   787.2   672.9   796.9                   3655.5
143.9   152.5   167.6   126.9   163.3                    754.2 
 4.6x    4.8x    4.7x    5.3x    4.9x                     4.8x 
-----   -----   -----   -----   -----   -----   -----   ------   -----------------
                 Pre-Comp   Post-Comp   Global-Comp   Local-Comp      Total-Comp
                    (GiB)       (GiB)        Factor       Factor          Factor
                                                                   (Reduction %)
--------------   --------   ---------   -----------   ----------   -------------
Written:
  Last 33 days    14768.3      2964.5          3.4x         1.5x     5.0x (79.9)
  Last 24 hrs       784.6       162.1          3.3x         1.4x     4.8x (79.3)
--------------   --------   ---------   -----------   ----------   -------------

Key:
       Pre-Comp = Data written before compression
       Post-Comp = Storage used after compression
       Global-Comp Factor = Pre-Comp / (Size after de-dupe)
       Local-Comp Factor = (Size after de-dupe) / Post-Comp
       Total-Comp Factor = Pre-Comp / Post-Comp
       Reduction % = ((Pre-Comp - Post-Comp) / Pre-Comp) * 100

"Daily-detailed" -vaihtoehdolla:

mtree show compression /data/col1/main daily-detailed 

From: 2023-08-12 12:00 To: 2023-09-14 12:00

  Sun     Mon     Tue     Wed     Thu    Fri     Sat    Weekly
-----   -----   -----   -----   -----   -----   -----   ------   -----------------
 -13-    -14-    -15-    -16-    -17-    -18-    -19-            Date
432.0   405.9   284.1   438.8   347.0   272.7   331.4   2511.8   Pre-Comp
 85.5    66.2    45.3    81.9    61.4    57.4    66.3    464.1   Post-Comp
 3.5x    4.1x    4.3x    3.6x    3.8x    3.3x    3.4x     3.7x   Global-Comp Factor
 1.4x    1.5x    1.5x    1.5x    1.5x    1.4x    1.5x     1.5x   Local-Comp Factor
 5.0x    6.1x    6.3x    5.4x    5.7x    4.7x    5.0x     5.4x   Total-Comp Factor
 80.2    83.7    84.1    81.3    82.3    78.9    80.0     81.5   Reduction %

 -20-    -21-    -22-    -23-    -24-    -25-    -26-
478.0   387.8   450.2   533.1   386.0   258.4   393.6   2887.1
100.6    81.5   100.8   119.0    84.0    40.6    75.3    601.8
 3.3x    3.3x    3.0x    3.0x    3.3x    4.1x    3.6x     3.3x 
 1.4x    1.5x    1.5x    1.5x    1.4x    1.5x    1.4x     1.5x 
 4.8x    4.8x    4.5x    4.5x    4.6x    6.4x    5.2x     4.8x
 79.0    79.0    77.6    77.7    78.2    84.3    80.9     79.2

 -27-    -28-    -29-    -30-    -31-    -1-     -2-
 27.6     1.0     0.4   470.7   467.3   517.7   641.9   2126.7
  4.9     0.2     0.1    83.9    92.3    89.8   140.1    411.2
 4.4x    3.7x    2.6x    3.8x    3.5x    3.9x    3.2x     3.5x 
 1.3x    1.5x    1.6x    1.5x    1.4x    1.5x    1.5x     1.5x
 5.6x    5.6x    4.3x    5.6x    5.1x    5.8x    4.6x     5.2x
 82.1    82.2    76.8    82.2    80.3    82.7    78.2     80.7

  -3-     -4-     -5-     -6-     -7-    -8-     -9-
539.6   495.0   652.8   658.7   537.1   398.7   305.5   3587.3 
110.8   108.0   139.4   137.0   111.5    78.3    48.3    733.3 
 3.4x    3.1x    3.2x    3.4x    3.3x    3.4x    4.1x     3.3x 
 1.4x    1.5x    1.5x    1.4x    1.4x    1.5x    1.6x     1.5x
 4.9x    4.6x    4.7x    4.8x    4.8x    5.1x    6.3x     4.9x 
 79.5    78.2    78.6    79.2    79.2    80.4    84.2     79.6

 -10-    -11-    -12-    -13-    -14-   
660.2   738.3   787.2   672.9   796.9                   3655.5
143.9   152.5   167.6   126.9   163.3                    754.2
 3.1x    3.4x    3.2x    3.7x    3.4x                      .3x 
 1.5x    1.4x    1.5x    1.4x    1.5x                     1.5x
 4.6x    4.8x    4.7x    5.3x    4.9x                     4.8x
 78.2    79.3    78.7    81.1    79.5                     79.4
-----   -----   -----   -----   -----   -----   -----   ------   -----------------
                 Pre-Comp   Post-Comp   Global-Comp   Local-Comp      Total-Comp
                    (GiB)       (GiB)        Factor       Factor          Factor
                                                                   (Reduction %)
--------------   --------   ---------   -----------   ----------   -------------
Written:
  Last 33 days    14768.3      2964.5          3.4x         1.5x     5.0x (79.9)
  Last 24 hrs       784.6       162.1          3.3x         1.4x     4.8x (79.3)
--------------   --------   ---------   -----------   ----------   -------------

Key:
       Pre-Comp = Data written before compression
       Post-Comp = Storage used after compression
       Global-Comp Factor = Pre-Comp / (Size after de-dupe)
       Local-Comp Factor = (Size after de-dupe) / Post-Comp
       Total-Comp Factor = Pre-Comp / Post-Comp
       Reduction % = ((Pre-Comp - Post-Comp) / Pre-Comp) * 100