Data Domain Restorers (DDR) -palautustyökalujen tiedostojen heikon deduplikoinnin ja pakkaussuhteen vianmääritys

Summary: Data Domain Restorers (DDR) -palautustyökalujen tiedostojen heikon deduplikoinnin ja pakkaussuhteen vianmääritys

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Symptoms

Data Domain Restorers (DDR) -palautustoiminnot on suunniteltu tallentamaan suuria määriä loogisia (valmiiksi koottuja) tietoja käyttämällä mahdollisimman vähän fyysistä (postcompressed) levytilaa. Käytössä on seuraavat:
  • Säilytettyjen tietojen optimointi, jotta voidaan poistaa päällekkäisiä tietolohkoja, jotka on jo tallennettu levylle DDR-muistissa, mutta jäljelle jää vain yksilöllisiä tietoja
  • Ainutlaatuisten tietojen pakkaus ennen kuin tiedot kirjoitetaan levylle fyysisesti.
DDR:n havaitsemien tietojen yleinen pakkaussuhde vaihtelee useisiin tekijöihin, kuten:
  • Käyttötapaus
  • Käytössä olevat tietotyypit
  • Varmuuskopiointisovelluksen kokoonpano
Optimaalisessa määrityksessä DDR:n pakkaussuhde on tavallisesti 10–20 kertaa suurempi (ja sen suhde voi toisinaan olla tätä suurempi). Vastaavasti joissakin ympäristöissä pakkausten kokonaissuhde voi olla tätä pienempi, mikä voi aiheuttaa seuraavat:
  • DDR käyttää nopeasti käytöstä poiston
  • Vaikutus varmuuskopioinnin, palauttamisen tai replikoinnin suorituskykyyn
  • DDR ei täytä asiakkaan odotuksia

Cause

Tässä artikkelissa käsitellään
  • Lyhyt yleiskatsaus DDR-muistin tietojen tieto-optimoinnista ja pakkauksesta
  • Järjestelmän ja yksittäisten tiedostojen pakkaussuhteen määrittäminen
  • Tekijät, jotka voivat heikentää pakkausten yleistä suhdetta

Resolution

Miten Data Domain Restorer ottaa käyttöön uusimmat tiedot?
  • Varmuuskopiointisovellus lähettää tietoja (eli tiedostoja) DDR-muistiin.
  • DDR jakaa nämä tiedostot 4–12 kt:n lohkoiksi – jokainen lohko katsotaan segmentiksi.
  • DDR luo kullekin segmentille yksilöivän tunnisteen (vastaa tarkistussummaa) segmentin sisältämien tietojen mukaan.
  • Tarkista uusien segmenttien sormenjäljet DDR:n levyindekseistä, onko DDR:ssä jo segmentti, jolla on sama sormenjälki.
  • Jos DDR:llä on jo segmentti, jossa on sama tunniste, juuri vastaanotetun tiedon vastaava segmentti on kaksoiskappale, joka voidaan hylätä (se on deduplikoitu).
  • Kun kaikki päällekkäiset segmentit on poistettu juuri saatetuista tiedoista, jäljelle jää vain yksilöllisiä tai uusia segmenttejä.
  • Nämä yksilölliset tai uudet segmentit ryhmitetään 128 kt:n pakkausalueiksi ja pakataan sitten (käyttämällä oletusarvoisesti lz-algoritmia ).
  • Pakatut pakkausalueet pakataan 4,5 Mb:n tallennuslaitteisiin, joita kutsutaan säilöiksi ja jotka kirjoitetaan sitten kiintolevylle.
Miten DDR seuraa, mitkä segmentit muodostavat tietyn tiedoston?

Uusimpien tietojen deduplikoinnin/pakkauksen lisäksi DDR luo kullekin nietylle tiedostolle segment tree -hakemiston. Tämä on käytännössä luettelo tiedostosta muodostavia segmentin sormenjälkiä. Jos DDR:n on luettava tiedosto myöhemmin uudelleen, toimi seuraavasti:
  • Selvitä tiedostojen segmenttihakemiston sijainti.
  • Lue segmenttihakemisto ja hae luettelo kaikista segmentin tunnisteista, jotka muodostavat luettavan tiedostoalueen.
  • Määritä levyn tiedoissa tietojen fyysinen sijainti (säilö).
  • Lue levyn säilöjen fyysisen segmentin tiedot.
  • Kokoa tiedosto uudelleen fyysisten segmenttien tietojen avulla.
Tiedostosegmenttipuita säilytetään myös levyllä 4,5 Mb:n säilöissä, ja ne edustavat suurinta osaa kustakin tiedoston metatietotiedostosta (käsitellään jäljempänä tässä artikkelissa).

Miten DDR-muistin kokonaispakkaussuhde voidaan määrittää?

DDR-muistin (ja pakkaussuhteen) yleinen käyttöaste näkyy filesys show space -komennolla. Esimerkki:

Active Tier:
Resource Size GiB Used GiB Avail GiB Use% Cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 115367.8 - -
/data: post-comp 679 4,2 6242,4 551,8 92 % 202,5
/ddvar 49,2 9,1 37,6 20 % -


---------------- -------- -------- --------- ---- -------------- tässä tapauksessa huomaamme, että:
  • DDR-muistissa olevat valmiiksi pakkaadut tai loogiset tiedot: 115367,8 Gt
  • Postcompressed tai fyysinen tila, jota käytetään DDR:ssä: 6242,4 Gt
  • Pakkausten kokonaissuhde on 11 5367,8 / 6 242,4 = 18,48 x
Filesys show compression -komennon tulos vahvistaa tiedot, käytetyn tilan ja pakkaussuhteen. Esimerkki:

                   Pre-Comp Post-Comp Global-Comp Local-Comp Total-Comp
(GiB) (GiB) Factor (
lyheneminen %)
---------------- -------- --------- ----------- ---------- -------------
Käytössä samanaikaisesti:*   115367.8 6242.4 - - 18,5x (94.6) <=== HUOMAUTUS
Kirjoitettu:                                                                          
  Edelliset 7 päivää 42214.7 1863.2 11.0x 2.1x 22,7x (95,6)
  Viimeiset 24 tuntia 4 924,8 274,0 8,8 x 2,0 x 18,0 x (94,4)
---------------- -------- --------- ----------- ---------- -------------


Overall utilization -kuvat DDR:stä lasketaan seuraavasti:
  • Esikoncompressed-tietoja yhteensä: Kaikkien DDR:n hallussa olevien tiedostojen valmiiksi pakkaaman (loogisen) koon summa.
  • Postcompressed-tietoja yhteensä: Levyn käytössä olevien säilöjen määrä kerrottuna 4,5 Mt:llä (yhden säilön koko).
  • Postcompressed-koko yhteensä: Luodun säilön enimmäismäärä järjestelmän vapaalle levytilalle.
Käytössä olevien säilöjen enimmäistilastot ovat saatavilla automaattisina tuena. Esimerkki:

Container set 73fcacadea763b48:b66f6a65133e6c73:
...
    attrs.psize = 4718592 <=== säilön koko tavuina
...
    attrs.max_containers = 1546057 <=== Suurin mahdollinen säiliö
attrs.free_containers = 125562 <=== tällä hetkellä vapaat säiliöt
attrs.used_containers = 1420495 <=== käytössä oleviin säiliöihin
...


Katso, että:
 
Postcomp size = 1546057 * 4718592 / 1024 / 1024 / 1024 = 6794.2 Gb
Postcomp used = 1420495 * 4718592 / 1024 / 1024 / 1024 = 6242,4 Gb

Miten yksittäisen tiedoston, hakemiston tai hakemistohakemiston deduplikointi- ja pakkaussuhteet voidaan määrittää?

Kun tiedostoa käytetään, DDR tallentaa tiedoston tilastotietoja, kuten:
  • Valmiiksi painetut (loogiset) tavut
  • Ainutlaatuisten segmenttien koko tieto-optimoinnin jälkeen
  • Ainutlaatuisten segmenttien koko tieto-optimoinnin ja pakkauksen jälkeen
  • Tiedoston metatietojen koko (niin segmenttipuu kuin hakemisto)
Näitä tilastotietoja voi luoda komennolla filesys show compression [path]. Voit esimerkiksi näyttää yhden tiedoston tilastotietoja:

SE@DDVE60_JF## filesys show compression /data/azure1/backup/testfile
Total files: 1;  tavua/storage_used: 2.9
Alkuperäiset tavut:        3,242,460,364
Maailmanlaajuisesti pakattu:        1,113,584,070
Paikallisesti pakattu:        1 130 871 915
metatietoa:            4 772 672


Koko hakemistohakemistohakemiston tilastotietojen raportointi:

SE@DDVE60_JF## filesys show compression /data/tiedosto1/backup
Total files: 3;  tavua/storage_used: 1.4
Alkuperäiset tavut:        7,554,284,280
Maailmanlaajuisesti pakattu:        5,425,407,986
Paikallisesti pakattu:        5 510 685 100
metatietoa:           23 263 692


Huomioi kuitenkin, että näiden tilastojen käyttöön liittyy muutamia huomioita:
  • Tiedot luodaan tiedoston tai tietojen poiston yhteydessä, ja tätä ei päivitetä. Koska DDR toimii, uusien tiedostojen määrä tai samoihin tietoihin viittaavien tiedostojen poistaminen jne. voi muuttaa sitä, miten tiedosto deduplikoi ajan myötä ja aiheuttaa näiden tietojen vanhenemisen.
  • Lisäksi jotkin DDR-muistin käyttötapaukset (kuten tiedoston pikakuvaus ja alkuperäisen tiedoston poistaminen) voivat johtaa vääristymiseen tai vääristymiseen.
Siksi nämä kuvat on hyvä pitää vain arviona.

Valmiiksi kootut tavut eivät välttämättä ole tiedoston valmiiksi koottuja/loogisia kokoja. Se on sen sijaan tiedostoon kirjoitettujen tavujen kokonaismäärä sen eliniän aikana. Siksi tietyissä ympäristöissä olemassa olevat tiedostot korvataan yleisesti (esimerkiksi virtuaalinauhakirjastotoiminnoilla), joten kuva voi olla suurempi kuin vastaavien tiedostojen looginen koko.

Voiko heikkolaatuisten tietojen käyttö heikentää pakkausten kokonaissuhdetta?

Kyllä: jotta DDR saavuttaa hyvän kokonaispakkaussuhteen nietyille tiedoille, tietojen deduplikoinnin ja pakkaamisen on onnistuttava. Tietoja on monenlaisia, jotka estävät tämän, kuten jäljempänä käsitellään:

Precompressed/pre-encrypted data:

Nämä tietotyypit ovat joko pakattuja tai salattuja työasemajärjestelmässä tai varmuuskopiointisovelluksessa. Se voi sisältää myös sovelluskohtaisia tiedostoja, jotka on pakattu tai salattu suunnitellusti (esimerkiksi mediatiedostot) ja tietokantatiedostoja, jotka ovat joko pakattuja tai salattuja tai upotetut binaariobjektit, kuten mediatiedostot.

Koska pakkaus- tai salausalgoritmi toimii suhteellisen pienenä muutoksen tiedoston taustatietoihin, tiedostossa on muutoksia. Asiakasohjelmassa voi esimerkiksi olla 100 Mt:n salattu tiedosto, jonka sisällä 10 Kt:n tietoja on muokattu. Tavallisesti tuloksena oleva tiedosto oli ennen muokkaamista ja sen jälkeen samanlainen kuin muutettu 10 Kt:n osa. Kun salausta käytetään, salausalgoritmi muuttaa tiedoston koko sisällön, vaikka vain 10 kt salaamatonta tietoa on muuttunut ennen muokkaamista ja sen jälkeen.

Kun kyseisiä tietoja muokataan säännöllisesti ja lähetetään säännöllisesti DDR-muistiin, tämä ripple out -ilmiö saa tiedoston jokaisen sukupolven ulkoasun poikkeamaan saman tiedoston aiemmista sukupolvista. Tämän seurauksena kukin sukupolvi sisältää yksilöllisen segmenttijoukon (ja segmentin sormenjäljet), joten sen deduplikointisuhde on heikko.

Huomaa myös, että esipakkaustiedostojen sijasta lz-algoritmi ei todennäköisesti pysty pakkaamaan segmentin tietoja enempää, joten tietoja ei voi pakata ennen kuin ne kirjoitetaan levylle.

Yleisenä ohjeena esikonpressio/esisalaus aiheuttaa seuraavat:
  • Valmiiksi salatut tiedot: Heikko deduplikointisuhde, mutta hyväksyttävä pakkaussuhde
  • Esipainetut tiedot: Heikko deduplikointisuhde ja heikko pakkaussuhde
Kun DDR käyttää samoja (muuttumattomia) valmiiksi pakattuja/esisalattuja tietoja useita kertoja, tietojen deduplikointisuhde paranee, koska pakkaus- tai salausalgoritmeista huolimatta kunkin varmuuskopion aikana havaitaan samankaltaisia segmenttejä (ja segmenttien sormenjälkiä).

Jos mahdollista, DDR-muistiin lähetettyjä tietoja ei saa salata tai pakata. Tämä voi edellyttää salauksen tai pakkauksen poistamista käytöstä loppuohjelmassa tai vastaavassa varmuuskopiointisovelluksessa.

Jos tarvitset apua tietyn varmuuskopion, asiakassovelluksen tai käyttöjärjestelmän salaus- tai pakkausasetusten tarkistamiseen, muokkaamiseen, ota yhteys asianmukaiseen tukipalveluun.

Mediatiedostot:

Tietyt tiedostotyypit sisältävät valmiiksi asennettuja tai valmiiksi salattuja tietoja. Esimerkki:
  • PDF-tiedostot
  • Tietyt äänitiedostot (mp3, wma, ogg jne.)
  • Videotiedostot (avi, mkv jne.)
  • Kuvatiedostot (kuten png, bmp, jpeg jne.)
  • Sovelluskohtaiset tiedostot (kuten Microsoft Office, Open Office ja Libre Office)
Tiedoston koodekki pakkaa tai salaa tiedostojen sisällä olevat tiedot, ja siksi ne aiheuttavat samat ongelmat, kun ne siirretään DDR-muistiin, kuten edellä on kuvattu esipainetuille tai valmiiksi salatuille tiedoille.

Erittäin yksilölliset tiedostot:

Jos deduplikointisuhde on hyvä, DDR näkee samat segmentit (ja segmenttien sormenjäljet) useita kertoja. Tietyt tietotyypit sisältävät kuitenkin vain yksilöllisiä tapahtumatietoja, jotka sisältävät suunnitellusti yksilöllisiä tietoja.

Jos nämä tiedostot lähetetään DDR-muistiin, varmuuskopion jokaisessa sukupolvessa on yksilöivä joukko segmenttejä tai segmenttien sormenjälkiä, minkä vuoksi tietojen optimointisuhde heikkenee.

Esimerkkejä tällaisista tiedostoista:
  • Tietokannan tapahtumalokit (esimerkiksi Oraclen arkistolokit).
  • Microsoft Exchange -tapahtumalokit
Ongelma voi johtua myös uuden työaseman ensimmäisestä varmuuskopioinnista DDR:ään (koska DDR ei ole aiemmin havainnnut tietoja, niitä vastaavat segmentit tai segmentin sormenjäljet ovat yksilöllisiä). Kun tulevat saman varmuuskopion sukupolvet lähetetään DDR-muistiin, varmuuskopioiden deduplikointisuhde kuitenkin paranee, koska kunkin uuden varmuuskopion segmenttejä on vähemmän. Tämän vuoksi juuri asennetun DDR-muistin deduplikoinnin tai pakkaussuhteen odotetaan kuluvan enimmäkseen uusien varmuuskopioiden yhteydessä, mutta paranevan ajan myötä.

Pienet tiedostot:

Pienet tiedostot aiheuttavat monenlaisia ongelmia kirjoitettaessa DDR-muistiin. Niitä ovat esimerkiksi seuraavat:
  • Metatietojen turpoaminen - DDR alkaa säilyttää odotettua suurempaa määrää tiedoston metatietoja kuin fyysiset tiedot.
  • Säilön heikko käyttö – Levyllä oleva 4,5 Mt:n säilö sisältää ainoastaan yhden tiedoston tiedot ( Data Domain Streamin tietolohkon asettelun tai SISL-arkkitehtuurin vuoksi) tämän asiakirjan kattavuuden ulkopuolella. Siksi esimerkiksi yhden 10 kt:n tiedoston varmuuskopiointi aiheuttaa sen, että tiedostoon kirjoitetaan vähintään yksi täysi 4,5 Mb:n säilö. Tämä voi tarkoittaa, että DDR käyttää näissä tiedostoissa merkittävästi enemmän postcompressed (fyysistä) tilaa kuin vastaava varmuuskopioitavien esipakottujen (loogisten) tietojen määrä, mikä puolestaan aiheuttaa negatiivisen kokonaispakkaussuhteen.
  • Heikko deduplikointisuhde – alle 4 kt:n tiedostot (DDR:n vanhin tuettu segmenttikoko) koostuvat yhdestä segmentistä, joka on pehmustettu 4 kt:iin. Kyseisiä segmenttejä ei optimoida, vaan ne kirjoitetaan suoraan levylle. Tämä voi aiheuttaa sen, että DDR:ään mahtuu useita saman segmentin kopioita (päällekkäisinä segmenteinä).
  • Heikko varmuuskopiointi, palautus tai puhdas suorituskyky - varmuuskopioinnissa, palautuksessa tai puhtaassa varmuuskopiointissa, palautuksessa tai puhtaassa käytössä on suuria kuormituksia siirrettäessä tiedostosta toiseen (koska käytettävä metatieto on kytkettävä).
Katso, että:
  • Pienten tiedostojen käytön vaikutukset puhtaaseen suorituskykyyn ovat jossain määrin heikentyneet, kun DDOS 5.5-versiossa ja sitä uudemmissa versioissa on lisätty fyysinen puhdistus tai roskienkeruu.
  • Puhdistus yrittää kumota säilön heikon käyttöasteen yhdistämällä tiedot vähäisellä käyttöasteella varustetuista säilöistä entistä tiiviimmin pakattuihin säilöihin kopiointivaiheessa.
  • Puhdistus yrittää poistaa liiallisia päällekkäisiä segmenttejä kopiointivaiheen aikana.
Edellä kuvatusta huolimatta on vältettävä suuri määrä pieniä tiedostoja tai kuormituksia, jotka koostuvat lähinnä pienistä tiedostoista. On parempi yhdistää suuri määrä pieniä tiedostoja yhteen pakkaamattomaan/salaamattomaan arkistoon ennen varmuuskopiointia kuin lähettää pienet tiedostot DDR:ään alkuperäiseen tilaansa. On esimerkiksi paljon parempi varmuuskopioida yksittäinen 10 Gb:n tiedosto, joka sisältää 1048576 yksittäisiä 10 Kb -tiedostoja, kuin kaikki yksittäiset 1048576 tiedostot.

Varmuuskopiointisovellusten liiallista multipleksausta:

Varmuuskopiointisovellukset voidaan määrittää selättämään tietoja varmuuskopiointilaitteeseen lähetettävien virtojen kautta eli tietovirroista (eli eri työasemista) lähetetään yhdessä virrassa varmuuskopiointilaitteeseen. Tätä toimintoa käytetään ensisijaisesti kirjoitettaessa fyysisiin nauhalaitteisiin seuraavasti:
  • Fyysinen nauhalaite tukee vain yhtä saapuvaa kirjoitusvirtaa.
  • Varmuuskopiointisovelluksen on säilytettävä riittävä siirtonopeus nauhalaitteessa, jotta nauha ei käynnisty, pysähtyy tai kelaa taaksepäin (eli komentorivikäyttö). Tämä on helpompaa, jos nauhalaitteeseen menevä virta sisältää useiden työasemien tietoja.
DDR-muistin tapauksessa tämä aiheuttaa sen, että yksi DDR-tiedosto sisältää tietoja useista työasemista, jotka on limitetty sattumanvaraiseen järjestykseen tai lohkokokoon. Tämä voi heikentää deduplikointisuhdetta, koska DDR ei välttämättä pysty havaitsemaan kunkin työaseman varmuuskopion kunkin sukupolven segmenttien kaksoiskappaleita oikein. Yleisesti ottaen mitä pienempi moninaisuusaste on, sitä huonompi vaikutus deduplikointisuhteeseen on.

Lisäksi palautus saattaa olla heikkoa, koska se palauttaa tietyt työasemat. DDR:n on luettava useita tiedostoja tai säilöjä, joissa suurin osa tiedostojen tai säilöjen tiedoista on ylimikronisia muiden työasemien varmuuskopioinnissa.

Varmuuskopiointisovellusten ei tarvitse käyttää multipleksausta kirjoitettaessa DDR-muistiin, koska DDR:t tukevat suurempaa saapuvan virran määrää kuin fyysiset nauhalaitteet, ja kukin virta voi kirjoittaa vaihtelevalla nopeudella. Siksi varmuuskopiointisovellusten multipleksointi on poistettava käytöstä. Jos multipleksien poistaminen käytöstä vaikuttaa varmuuskopioinnin suorituskykyyn, toimi seuraavasti:
  • CIFS:ää, NFS:ää tai OST:tä (DDBoost) käyttävien varmuuskopiointisovellusten kirjoitusvirtoja on lisättävä (jotta DDR:ään voidaan kirjoittaa lisää tiedostoja rinnakkain).
  • VTL:ää käyttävien ympäristöjen pitäisi lisätä asemia DDR-muistiin, koska kukin asema tukee rinnakkaista kirjoitusvirtaa.
Jos apua tarvitaan multipleksien poistamiseen käytöstä tai haluat keskustella tietyn varmuuskopiosovelluksen suositellusta multipleksointimäärityksestä, ota yhteys tukipalveluntarjoajaan, jonka kanssa olet tehnyt sopimuksen.

Varmuuskopiointisovellukset, joissa on liikaa nauhamerkkejä:

Jotkin varmuuskopiointisovellukset saattavat lisätä toistuvia tietorakenteita varmuuskopiointivirtaan, jota kutsutaan merkkivirraksi. Merkit eivät vastaa varmuuskopion fyysisiä tietoja, vaan varmuuskopiointisovellus käyttää niitä indeksointi- tai sijaintijärjestelmänä.

Joissakin tapauksissa merkintöjen lisääminen varmuuskopiovirtaan voi heikentää deduplikointisuhdetta, esimerkiksi:
  • Varmuuskopioinnin ensimmäisessä sukupolvessa käytettiin 12 kt tietoja, jotka olivat yhtenäisiä. DDR tunnisti tämän yhdeksi segmentiksi.
  • Varmuuskopioinnin toisessa sukupolvessa samat 12 kt tietoja jaetaan kuitenkin lisäämällä varmuuskopiomerkin, jota voi olla 6 kt tietoja, varmuuskopiomerkintä, 6 kt tietoja.
  • Siksi varmuuskopioinnin toisen sukupolven aikana luodut segmentit eivät vastaa varmuuskopion ensimmäisen sukupolven segmenttejä, joten ne eivät lovita oikein.
Tussien välilyönti on sitä huonompi, mitä suurempi vaikutus tieto-optimointisuhteeseen on (esimerkiksi varmuuskopiointisovellus, joka lisää merkkejä 32 kt:n välein, aiheuttaa enemmän ongelmia kuin se, että varmuuskopiointisovellus lisää merkinnät 1 Mt:n välein).

Ongelman voi välttää käyttämällä merkkitunnistustekniikkaa, jolla voidaan
  • Varmuuskopioinnin merkit, jotka voidaan poistaa läpinäkyvästi varmuuskopiovirrasta varmuuskopioinnin aikana.
  • Varmuuskopioinnin merkit, jotka lisätään uudelleen varmuuskopiovirtaan varmuuskopioinnin palautuksen yhteydessä
Tämä estää tietojen tai segmenttien pirstoutumisen varmuuskopiointimerkintöjen perusteella ja parantaa vastaavien varmuuskopioiden deduplikointisuhdetta.

Jotta tekniikkaa voidaan hyödyntää täysimääräisesti, on kuitenkin tärkeää, että DDR tunnistaa varmuuskopiovirrassa olevat merkinnät oikein. DDR etsii merkkejä marker type -asetuksen mukaan. Esimerkiksi:

SE@DDVE60_JF## filesys-asetuksen arvo

on -------------------------------- --------
...
Merkintä-tyyppi auto
...


-------------------------------- --------asetukseksi on määritettävä auto, sillä se mahdollistaa sen, että DDR vastaa automaattisesti yleisimpiä merkintätyyppejä. Jos järjestelmä syö tietoja vain yhdestä varmuuskopiointisovelluksesta, joka lisää merkkejä, tietyn merkintätyypin

eli#filesys-option set marker-type {auto | nw1 | cv1 | tsm1 | tsm2 | eti1 | fdr1 | hpdp1 | besr1 | ssrt1 | ism1 | bti1| none}

suorituskyky voi olla seuraava:
  • Tietyn merkintätyypin valitsemisesta saatava suorituskykyetu on todennäköisesti vähäinen.
  • Virheellisen merkintätyypin valitseminen voi lisätä varmuuskopiointi- tai palautustehon sekä deduplikointisuhteen heikkenemistä merkittävästi.
Siksi Data Domain suosittelee yleensä, että merkintätyypiksi jätetään auto. Jos haluat lisätietoja merkkityypin muuttamisesta, ota yhteys tukipalveluun, jonka kanssa olet tehnyt sopimuksen.

Jos järjestelmässä on tietoja sovelluksista, joissa käytetään varmuuskopiointimerkintöjä, mutta joita automaattinen merkintäkäsittelytekniikka (kuten BridgeHead-ohjelmiston tuotteet) ei tunnista, ota yhteys tuen tarjoajaan, joka voi määrittää DDR:n tarvitsemat asetukset, joilla voidaan tunnistaa seisontamerkki.

DDR vastaanottaa heikkolaatuisia tietoja:

Seuraavassa taulukossa on lueteltu yllä lueteltujen tietotyyppien odotetut deduplikointi- ja pakkaussuhteet. Luettelo ei ole tyhjentävä, ja tietyissä järjestelmissä näkyvien lukujen määrä voi tietenkin vaihdella DDR:n käyttämän kuormituksen tai tietojen vuoksi:
 
Yleinen pakkaus Paikallinen pakkaus Todennäköisesti syy
Matala (1 x 4 x) Matala (1 x – 1,5 x) Valmiiksi pakkaamattomat tai salatut tiedot
Matala (1 x 2 x) Korkea (>2 x) Ainutlaatuiset mutta pakattavat tiedot, kuten tietokanta-arkistoinnin lokit
Matala (2 x 5 x) Korkea (>1,5 x) Merkkejä, joita ei havaita, joiden tiedonsiirtonopeus on suuri tai jotka suoratoistavat multipleksausta
Korkea (>10 x) Matala (<1,5 x) Samojen pakattujen tai salattujen tietojen varmuuskopiointi Tämä on harvinaista.

Onko DDR-muistissa tiettyjä tekijöitä, jotka voivat vaikuttaa kokonais-deduplikointisuhteeseen?

Kyllä – Tietyt tekijät voivat aiheuttaa sen, että vanhat/superflitoriset tiedot säilyvät levyllä DDR-muistissa, mikä lisää postcompressed (fyysinen) -levytilaa ja laskee pakkaussuhdetta. Näitä tekijöitä käsitellään jäljempänä.

Tiedostojärjestelmän säännöllisen puhdistamisen epäonnistuminen:

Tiedostojen puhdistaminen on ainut tapa poistaa levyltä vanhoja/ylikuormitettuja tietoja, joita DDR-muistin tiedostot eivät enää viittaa. Tämän seurauksena käyttäjä voi poistaa järjestelmästä useita tiedostoja (mikä aiheuttaa esipakkauskäyttöasteen heikkenemisen), mutta ei suorita testiä puhtaana (jolloin postcompressed/fyysinen käyttöaste on suuri). Tämä johtaa pakkaussuhteen pienenemiseen.

Data Domain suosittelee, että ajoitetaan puhdas suoritus säännöllisin välein seuraavasti:
  • Normaali DDR: Kerran viikossa
  • DDR, jossa käytetään laajennettua säilytystä: Kahden viikon välein
Puhdistusta ei saa tehdä yli kerran viikossa, koska se voi aiheuttaa levyn tietojen pirstoutumisongelmia, jotka ilmenevät heikkona palautuksen/replikoinnin suorituskykynä.

Liiallisia vanhoja tilannevedoksia järjestelmässä:

DDR:t voivat luoda mTree-tilannevedoksia, jotka edustavat mTreen sisältöä tilannevedoksen luontihetkellä. Huomioi kuitenkin, että vanhojen tilannevedosten jättäminen järjestelmään voi lisätä postcompressed-arvoa / fyysistä käyttöastetta, mikä aiheuttaa pakkaussuhteen pienentymisen. Esimerkki:
  • Olemassa on mTree, joka sisältää useita tiedostoja (joten valmiiksi pakkaamisen käyttöaste on suuri).
  • MTreestä luodaan tilannevedos.
  • Monet tiedostot poistetaan (mikä aiheuttaa esikohdistetun käytön katkeamisen).
  • Tiedostojen puhdistaminen suoritetaan. Huomioi kuitenkin, että kiintolevyn vähimmäistila vapautuu, koska poistettujen tiedostojen kopio jää mtree-tilannevedokseen, joten kyseisten tiedostojen viittaamia tietoja ei voi poistaa levyltä.
  • Siksi postcompressed/physical utilization on edelleen suuri
Data Domain suosittelee, että mTree-tilannevedoksia (esimerkiksi palautusta tahattomista tietojen poistosta) hallitaan automaattisten tilannevedosaikataulujen avulla siten, että tilannevedoksia luodaan säännöllisin välein määritetyn vanhenemisjakson ajan (tilannevedoksen automaattiseen poistoon kuluva aika). Lisäksi vanhenemisjakson on oltava mahdollisimman lyhyt (se voi kuitenkin riippua tilannevedosten käyttötapauksesta tai näiden tilannevedosten tarjoamasta suojauksesta). Tämä estää vanhojen tilannevedosten kertymisen pitkäksi ajaksi.

Lisätietoja tilannevedosten ja tilannevedosaikataulujen käyttämisestä on seuraavassa artikkelissa: Data Domain - tilannevedosaikataulujen

hallintaLiiallinen replikoinnin viive:

Alkuperäinen Data Domain -replikointi seuraa replikointilokin tai mTree-tilannevedosten avulla (replikointityypistä riippuen), mitkä tiedostot tai tiedot odottavat replikointia etä-DDR:ään. Replikoinnin viive on käsite, jonka mukaan replikointi jää jälkeen lähde-DDR-muistin muutoksista. Tämä voi johtua esimerkiksi seuraavista tekijöistä:
  • Replikointikontekstit poistetaan käytöstä
  • Verkon kaistanleveys DDR:ien välillä ei riitä
  • Toistuvat verkkoyhteyden katkeamiset.
Replikoinnin suuri viive voi aiheuttaa sen, että replikointiloki sisältää edelleen viittauksia tiedostoihin, jotka on poistettu lähteen DDR-muistista tai vanhoista tai vanhentuneesta mTree-tilannevedoksista lähde- ja kohde-DDR-tiedostoista. Kuten edellä on kuvattu, näiden tilannevedosten (tai replikointilokin) tietoja ei voi poistaa fyysisesti DDR-muistin levyltä, vaikka vastaavat tiedostot olisi poistettu järjestelmästä. DDR-muistin postpainike tai fyysinen käyttöaste voi kasvaa, mikä johtaa deeduplikointisuhteen heikkenemiseen.

Jos DDR:t ovat peräisin suuresta käyttöasteesta, ja sen uskotaan johtuvan replikoinnin viiveestä, ota yhteys sopimuksen ulkopuoliseen tuen tarjoajaan avun saamiseksi.

Onko DDR-muistissa kokoonpanomuutoksia tai tiettyjä tekijöitä, jotka voivat lisätä pakkausten kokonaissuhdetta?

Kyllä: jos poistat tai käsittelet tässä asiakirjassa aiemmin käsiteltyjä ongelmia, DDR:n pitäisi näyttää pakkaussuhteen paraneminen ajan myötä. DDR-muistissa on myös useita tekijöitä tai työkuormia, jotka voivat lisätä deduplikointisuhdetta. Niihin liittyvät yleensä seuraavat:
  • DDR-muistin tiedostojen käyttämän kiintolevytilan vähentäminen (esimerkiksi DDR:n käyttämän pakkausalgoritmin tehon lisääminen)
  • Lisätä yhtäkkiä DDR:ään valmiiksi asennettujen (loogisten) tietojen määrää ilman, että postcompressed/physical utilization -arvo kasvaa vastaavasti.
Pakkausalgoritmin muuttaminen:

DDRs-pakkaustiedot kirjoitetaan oletusarvoisesti levylle lz-algoritmilla . Kuten aiemmin mainittiin, lz :n käyttö on suhteellisen vähäistä pakkausta tai pakkaamista varten tarvittavan suorittimen osalta, mutta tietojen koon pienentäminen on kohtuullista.

Pakkausalgoritmin tehoa voidaan lisätä, jotta postcompressed- tai kiintolevyn käyttöastetta voidaan säästää entistä enemmän (mikä puolestaan parantaa pakkausten yleistä suhdetta). Tuetut pakkausalgoritmit ovat tehokkuusjärjestyksessä (pienestä korkeaan):
  • Lz
  • gzfast
  • Gz
Algoritmien yleinen vertailu on seuraava:
  • lz verrattuna gzfastin pakkaus on ~15 % parempi ja käyttää kaksi kertaa enemmän suoritinta.
  • lz on gz:iin verrattuna pakkausta ~30 % parempi ja käyttää 5 kertaa enemmän suoritinta.
  • gzfast verrattuna gz:n pakkaus on ~10–15 % parempi.
Pakkaus voidaan myös poistaa kokonaan käytöstä (määritetään algoritmi ei mitään), mutta sitä ei tueta käytettäväksi asiakkaan järjestelmissä ja se on tarkoitettu ainoastaan sisäiseen testaukseen.

Edellä olevan taulukon mukaan pakkausalgoritmi on sitä suurempi, mitä enemmän suoritinta tarvitaan tietojen pakkaamiseen tai purkamiseen. Tämän vuoksi entistä aggressiivisempaan algoritmiin on tehtävä muutoksia vain järjestelmissä, jotka ladataan kevyesti normaalissa kuormituksessa. Jos algoritmia muutetaan erittäin kuormitetussa järjestelmässä, varmuuskopiointi tai palautus saattaa heikentyä merkittävästi ja tiedostojärjestelmä saattaa aiheuttaa panic-häiriön tai uudelleenkäynnistyksen (mikä aiheuttaa DDR-muistin katkoksen).

Lisätietoja pakkaustyypin muuttamisesta on seuraavassa artikkelissa: Data Domain -järjestelmä ja puhdistamisen vaikutukset GZ-pakkaukseen

muuntamiseenPakkausalgoritmin muuttamisen mahdollisen vaikutuksen vuoksi suositellaan, että asiakkaat haluavat keskustella muutoksesta tarkemmin tämän sopimuksen allisen tuen tarjoajan kanssa ennen jatkamista.

Tiedostojärjestelmän nopea valinta:

DDR:ien ansiosta tiedostojärjestelmän fastcopy-komennolla voi kopioida tiedoston (tai hakemistohakemiston) nopeasti. Toiminto luo tiedoston kloonaamalla olemassa olevan tiedoston (tai tiedostoryhmän) metatiedot niin, että vaikka uudet tiedostot eivät ole fyysisesti yhteydessä alkuperäiseen tiedostoon, ne viittaavat täsmälleen samoihin levyn tietoihin kuin alkuperäinen tiedosto. Tämä tarkoittaa, että alkuperäisen tiedoston koosta riippumatta uusi tiedosto kuluttaa vain vähän tilaa levyllä (koska se deduplikoi täydellisesti olemassa olevia tietoja).

Tämä johtuu siitä, että kun tiedostojärjestelmän Fastcopy-toimintoa käytetään, DDR:n valmiiksi pakkaama (looginen) tietokoko kasvaa nopeasti, mutta DDR:n postcompressed/physical utilization -arvo pysyy staattisena.

Esimerkiksi seuraava DDR on käytössä seuraavasti (se ilmaisee pakkaussuhteen kokonaisuudessaan ~1,8x):

Active Tier:
Resource Size GiB Used GiB Avail GiB Use% Cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 12.0 - -
/data: post-comp 71.5 6.8 64.7 10% 0.0
/ddvar 49.2 1.1 45,6 2 % -
/ddvar/core 158.5 0.2 150.2 0 % -
---------------- -------- -------- --------- ---- --------------


Se sisältää suuren tiedoston (/data/lync1/backup/testfile):

!!! DDVE60_JF TIETOSI OVAT VAARASSA !!! # ls -al /data/azure1/backup/testfile-rw-r
--r-- 1 root root 3221225472 29.7.20 /data/azure1/backup/testfile


Tiedosto on nopea kopioitu useita kertoja:

sysadmin@DDVE60_JF# filesys fastcopy source /data/tiedosto1/backup/testfile destination /data/azure1/backup/testfile_copy1
sysadmin@DDVE60_JF# filesys fastcopy source /data /azure1/backup/testfile destination /data/azure1/backup/testfile_copy2
sysadmin@DDVE60_JF# filesys fastcopy source /data/azure1/backup/testfile destination /data/azure1/backup/testfile_copy3


Tämä lisää esikonpressoitua käyttöastetta pakkaamisen jälkeisessä käytössä: Active Tier:


Resource Size GiB Used GiB Avail GiB Use% Cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 21.0 - -
/data: post-comp 71.5 6.8 64.7 10% 0.0
/ddvar 49.2 1.1 45,6 2 % -
/ddvar/core 158.5 0.2 150,2 0 % -
---------------- -------- -------- --------- ---- --------------


As tuloksena DDR:n pakkaussuhde on nyt ~3,1x.

Kuten edellä on mainittu, kopioiden pakkaustilastot osoittavat, että ne lokit toimivat täydellisesti:

sysadmin@DDVE60_JF# filesys show compression /data/data/azure1/backup/testfile_copy1
Total files: 1;  tavua/storage_used: 21331976.1
Alkuperäiset tavut:        3,242,460,364
Maailmanlaajuisesti pakattu:                    0
Paikallisesti pakattu:                    0
metatietoa:                  152


Pikakopiointitoiminnolla ei voi parantaa pakkausten yleistä suhdetta vähentämällä DDR:n fyysistä käyttöastetta. Se voi kuitenkin aiheuttaa suuren kokonaispakkaussuhteen (erityisesti ympäristöissä, joissa käytetään runsaasti pikakopiointia, kuten Avamar 6.x).

Affected Products

Data Domain

Products

Data Domain
Article Properties
Article Number: 000064270
Article Type: Solution
Last Modified: 16 Dec 2024
Version:  5
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.