Data Domain: DDR:ien (Data Domain Restorer) suuren tilan käyttöasteen tai käytettävissä olevan tilan puutteen ratkaiseminen

 

• Se on levyalue, jossa uudet tiedostot/tiedot ovat, ja useimmissa DDR:issä tiedostot säilyvät siellä, kunnes varmuuskopiointisovellus on merkinnyt ne vanhentuneiksi tai poistanut ne.
• DDR:issä, joihin on määritetty ER (Extended Retention) tai LTR (Long Term Retention), vanhat tiedostot voidaan siirtää ajoittain Active Tier -tasolta Archive- tai Cloud Tier -tasolle.
• Poistettujen tai siirrettyjen tiedostojen käyttämän Active Tier -tason tilan voi vapauttaa ainoastaan suorittamalla roskienkeruun/puhdistuksen (GC).

• Active Tier -tason vapaana oleva tila voi alkaa loppua, mikä aiheuttaa esimerkiksi seuraavia hälytyksiä ja viestejä:

• Jos Active Tier -taso täyttyy kokonaan, DDR:ään ei voida kirjoittaa uusia tietoja, mikä voi aiheuttaa varmuuskopiointien tai replikoinnin epäonnistumisen. Tässä tapauksessa näyttöön voi tulla seuraavanlaisia ilmoituksia:

• Joissakin tapauksissa Active Tier -tason täyttyminen voi aiheuttaa DDFS:n (Data Domain File System) siirtymisen vain luku -tilaan, jolloin olemassa olevia tiedostoja ei voi poistaa.

• selitetään, miksi Active Tier -taso voi täyttyä, ja
• kuvataan yksinkertaiset tarkistukset, joiden avulla voidaan selvittää Active Tier -tason korkean käyttöasteen syy, sekä vastaavat korjaustoimet.

• Tämä artikkeli ei ole tyhjentävä (eli joissakin tilanteissa DDR:n Active Tier -tason käyttöaste voi olla suuri tai se voi täyttyä syystä, jota ei mainita tässä artikkelissa), mutta se kattaa yleisimmät syyt ja ongelmat.
• Artikkelissa ei käsitellä Archive- ja Cloud Tier -tasojen korkeaa käyttöastetta.

  DDR:n Active Tier -käyttöaste voi olla odotettua suurempi monista syistä:

• Varmuuskopioinnin suorittava asiakassovellus ei ole merkinnyt varmuuskopiotiedostoja/tallennusjoukkoja vanhentuneiksi tai poistanut niitä oikein virheellisen säilytyskäytännön tai varmuuskopiointisovelluksen määrityksen vuoksi.
• Replikointiviiveestä johtuen suuri määrä vanhaa tietoa pidetään Active Tier -tasolla odottamassa replikointia.
• Active Tier -tasolle kirjoitettavien tietojen kokonaispakkaussuhde on odotettua pienempi.
• Järjestelmää ei ole mitoitettu oikein, eli se on liian pieni sille tallennettavalle tietomäärälle.
• Varmuuskopiot koostuvat suuresta määrästä erittäin pieniä tiedostoja – nämä tiedostot vievät paljon odotettua enemmän tilaa ensimmäisen kirjoituksen aikana, mutta tilan pitäisi vapautua puhdistuksen/roskienkeruun myötä.
• Tietosiirtoa ei suoriteta säännöllisesti järjestelmissä, joihin on määritetty ER/LTR. Tämän vuoksi vanhat tiedostot, jotka pitäisi siirtää Archive/Cloud Tier -tasoille, pysyvät Active Tier -tasolla.
• Puhdistusta/roskienkeruuta ei suoriteta säännöllisesti.
• DDR:ssä on liian suuria tai vanhoja mtree-tilannevedoksia, minkä vuoksi puhdistus ei voi vapauttaa poistettujen tiedostojen/tietojen viemää tilaa.

Vaihe 1 – määritä, onko Active Tier -tason puhdistus suoritettava

DDOS (Data Domain Operating System) pyrkii ylläpitämään Active Tier -tason laskuria nimeltä ”Cleanable GiB”. Tämä on arvio siitä, kuinka paljon fyysistä (post-comp) tilaa Active Tier -tasolla voitaisiin vapauttaa puhdistuksen/roskienkeruun avulla. Laskuri voidaan näyttää filesys show space- / df-komennoilla:
 
Jos

• Cleanable GiB -arvo on suuri tai
• DDFS on kokonaan täynnä (ja on siksi vain luku -tilassa)

puhdistus on suoritettava loppuun asti ennen muiden vaiheiden suorittamista. Puhdistus on käynnistettävä filesys clean start -komennolla seuraavasti:
 
Voit varmistaa filesys status -komennolla, että puhdistus on käynnistynyt odotetulla tavalla:
 
Huomioi:

• Jos puhdistus ei käynnisty, pyydä lisäapua ottamalla yhteyttä sopimuksen piiriin kuuluvaan tuen tarjoajaan. Se voi olla merkki siitä, että järjestelmässä on ilmennyt missing segment error -virhe, minkä vuoksi puhdistus on poistettu käytöstä.
• Jos puhdistus on jo käynnissä, seuraava viesti näytetään, kun se yritetään käynnistää:

• Active Tier -tason tilaa ei vapauteta ennen kuin puhdistus saavuttaa kopiointivaiheen (DDOS 5.4.x -versiossa ja vanhemmissa oletuksena vaihe 9, DDOS 5.5.x -versiossa ja uudemmissa vaihe 11). Lisätietoa puhdistuksessa käytetyistä vaiheista on artikkelissa https://support.emc.com/kb/446734.
• Puhdistus ei välttämättä vapauta Cleanable GiB -kohdassa ilmoitettua tilaa, koska kyseessä on arvio. Lisätietoa on artikkelissa https://support.emc.com/kb/485637.
• Puhdistus ei välttämättä vapauta kaikkea mahdollista tilaa yhdellä suorituskerralla. Tämä johtuu siitä, että erittäin suuria tietojoukkoja sisältävissä DDR:issä puhdistus käsittelee eniten tarpeettomia tietoja sisältävät tiedostojärjestelmän osat (jotta tilaa saadaan vapautettua suurin mahdollinen määrä puhdistuksen suorittamiseen käytetyssä ajassa). Joissakin tilanteissa puhdistus voi olla tarpeen suorittaa useita kertoja, jotta kaikki potentiaalinen tila saadaan vapautettua.
• Jos Cleanable GiB -arvo on erittäin suuri, se saattaa tarkoittaa, että puhdistusta ei ole suoritettu säännöllisesti. Tarkista, että puhdistusaikataulu on määritetty:

Kun puhdistus on valmis, suorita filesys show space- / df-komennot selvittääksesi, onko käyttöasteongelmat ratkaistu. Jos käyttöaste on edelleen suuri, jatka tässä artikkelissa olevien ohjeiden mukaan.

Vaihe 2 – tarkista, onko replikointiviive suuri suhteessa lähdetietojen replikointikontekstiin

Alkuperäinen Data Domain -replikointi perustuu ”replikointikonteksteihin”. Seuraavassa esimerkissä tietoja on replikoitava järjestelmien välillä:

• Replikointikontekstit luodaan lähde- ja kohdelaitteen DDR:iin.
• Kontekstit alustetaan.
• Kun alustus on valmis, replikointi lähettää ajoittain päivityksiä/deltoja lähteestä kohteeseen, jotta järjestelmien tiedot pysyvät synkronoituina.

Jos lähteen replikointikontekstissa on viivettä, se voi johtaa vanhojen tietojen säilyttämiseen lähdejärjestelmän levyllä (huomaa, että replikointikontekstien viive ei voi aiheuttaa liian suurta käyttöastetta kohdejärjestelmässä):

• Hakemistoreplikointikontekstit (käytetään, kun yksittäinen /data/col1/backup-kohdan hakemistopuu replikoidaan järjestelmien välillä):

•  Mtree-replikointikontekstit (käytetään, kun mikä tahansa muu mtree kuin /data/col1/backup replikoidaan järjestelmien välillä):

• Kokoelmareplikointikontekstit (käytetään, kun yhden DDR:n koko sisältö replikoidaan toiseen järjestelmään):

 Seuraavien ohjeiden avulla voit määrittää, onko replikointikonteksteissa viivettä:

• Määritä nykyisen järjestelmän isäntänimi:

• Määritä nykyisen järjestelmän päivämäärä/kellonaika:

• Näytä luettelona järjestelmässä määritetyt replikointikontekstit ja niiden synced as of time -synkronointiajat. Kiinnitä huomiota niihin konteksteihin, joissa ”destination” EI sisällä nykyisen järjestelmän isäntänimeä (mikä osoittaa, että nykyinen järjestelmä on lähde) ja synced as of time -arvo on huomattavan vanha:

Kontekstit, joissa nykyinen järjestelmä on lähde ja joissa näkyy merkittävää viivettä, tai kontekstit, joita ei enää tarvita, on purettava. Se voidaan tehdä suorittamalla seuraava komento lähde- ja kohdejärjestelmässä:
 
Esimerkiksi edellä esitetyt huomionarvoiset kontekstit voidaan purkaa suorittamalla seuraavat komennot lähteessä ja kohteessa:
 
Huomioi:

• Kun kontekstit on purettu, Active Tier -tason puhdistus on suoritettava, jotta Active Tier -tason potentiaalinen tila saadaan vapautettua.
• Jos mtree-replikointia käytetään, mtree-replikoinnin tilannevedokset voivat jäädä levylle kontekstien purkamisen jälkeen. Varmista, että tarpeettomat tilannevedokset merkitään vanhentuneiksi vaiheen 5 ohjeiden mukaisesti ennen puhdistuksen suorittamista.
• Jos lähde-/kohde-mtree on määritetty siirtämään tietoja Archive- tai Cloud Tier -tasoille, vastaavien mtree-replikointien kontekstien purkaminen on tehtävä harkiten, sillä kyseisiä konteksteja ei voida välttämättä luoda/alustaa myöhemmin uudelleen. Tämä johtuu siitä, että mtree-replikointikontekstin alustamisen yhteydessä lähdejärjestelmään luodaan mtree-tilannevedos, joka sisältää tiedot kaikista mtreen sisältämistä tiedostoista (tasosta riippumatta). Tämä tilannevedos replikoidaan sitten kokonaisuudessaan kohteen Active Tier -tasolle. Jos kohteen Active Tier -tasolla ei ole riittävästi vapaata tilaa kaikkia lähteen mtree-tietoja varten, alustamista ei voida suorittaa loppuun. Saat ongelmasta lisätietoa ottamalla yhteyttä sopimuksen piiriin kuuluvaan tuen tarjoajaan.
• Jos kokoelmareplikointikonteksti on purettu, kontekstia ei voida luoda uudelleen tai alustaa ennen kuin kohde-DDR:n DDFS-ilmentymä on tuhottu (kaikki järjestelmän tiedot menetetään). Tämän vuoksi myöhempi alustaminen voi vaatia huomattavasti aikaa ja verkon kaistanleveyttä, sillä kaikki lähteen tiedot on replikoitava fyysisesti uudelleen kohteeseen.

Vaihe 3 – tarkista, onko järjestelmässä tarpeettomia mtree-osioita

DDFS:n sisältö jaetaan loogisesti mtree-osioihin. On yleistä, että yksittäiset varmuuskopiointisovellukset/-asiakkaat kirjoittavat yksittäisiin mtree-osioihin. Jos varmuuskopiointisovellus on poistettu käytöstä, se ei voi enää kirjoittaa tietoja DDR:ään tai poistaa niitä, jolloin järjestelmään voi jäädä vanhoja/tarpeettomia mtree-osioita. Näiden mtree-osioiden tiedot vievät pysyvästi DDR:n levytilaa. Näin ollen tällaiset tarpeettomat mtreet kannattaa poistaa. Esimerkki:

• Hae luettelo järjestelmään mtree-osioista:

• Kaikki tarpeettomat mtreet on poistettava mtree delete -komennolla seuraavasti:

• Poistetun mtreen käyttämä levytila vapautetaan, kun Active Tier -tason puhdistuksen/roskienkeruu suoritetaan seuraavan kerran.

Huomioi:

• Jos mtree on mtree-replikoinnin kohde (eli sen tila mtree-luettelossa on RO/RD), vastaava replikointikonteksti on purettava ennen mtreen poistamista.
• Loogisina DDBoost-tallennusyksikköinä (LSU) tai virtuaalisina nauhakirjastoina (VTL) käytettäviä mtree-osiota ei välttämättä voida poistaa mtree delete -komennolla. Data Domain Administration Guide -oppaassa on lisätietoja tällaisten mtree-osioiden poistamisesta.
• Mtree-osioita, joihin on määritetty säilytyslukitus (tila on RLCE tai RLGE), ei voi poistaa. Sen sijaan mtreen yksittäisten tiedostojen säilytyslukitus on peruutettava ja ne on poistettava yksitellen. Lisätietoja on Data Domain Administration Guide -oppaassa.

Vaihe 4 – tarkista, onko järjestelmässä vanhoja/tarpeettomia mtree-tilannevedoksia

Data Domain -tilannevedos on tietyn hetken tilannevedos vastaavasta mtree-osiosta. Huomioi sen vuoksi seuraavat:

• Tilannevedos viittaa kaikkiin mtree-osiossa tilannevedoksen luontihetkellä oleviin tiedostoihin.
• Kun tilannevedos on olemassa, puhdistus ei voi vapauttaa tiedostojen levyllä käyttämää fyysistä tilaa, vaikka kyseiset tiedostot olisi siirretty/poistettu. Tietojen on pysyttävä järjestelmässä siltä varalta, että tilannevedoksessa olevaa tiedoston kopiota käytetään myöhemmin

Seuraavat toimenpiteet on tehtävä, jotta voidaan määrittää, onko missään mtree-osiossa vanhoja tai tarpeettomia tilannevedoksia:

• Hae järjestelmän mtree-luettelo vaiheen 3 mtree list -komennon avulla.
• Näytä luettelona kuhunkin mtreehen sisältyvät tilannevedokset käyttämällä snapshot list -komentoa:

• Jos tilannevedoksia on olemassa, käytä snapshot list mtree [mtreen nimi] -komennon tulosta määrittääksesi tilannevedokset, jotka täyttävät seuraavat ehdot:

• Jos tilannevedosten luettelokomento suoritetaan uudelleen, nämä tilannevedokset näkyvät nyt vanhentuneina (expired):

Huomioi:

• Ei ole mahdollista määrittää, kuin paljon levytilaa yksittäinen tilannevedos tai usean tilannevedoksen sarja vie. Tilannevedokseen liittyvä ”space”-arvo ilmaisee ainoastaan mtreen pakkaamista edeltävän (loogisen) koon tilannevedoksen luontihetkellä (edellä olevan tuloksen mukaisesti).
• Tilannevedoksia, joiden nimi on ”REPL-MTREE-AUTO-YYYY-MM-DD-HH-MM-SS”, hallitaan mtree-replikoinnilla, eikä niitä pitäisi joutua merkitsemään vanhentuneiksi manuaalisesti (replikointi merkitsee tilannevedokset vanhentuneiksi automaattisesti, kun niitä ei enää tarvita). Jos tällaiset tilannevedokset ovat erittäin vanhoja, se on merkki siitä, että vastaavan replikointikontekstin viive on todennäköisesti suuri (kuten vaiheessa 2 on kuvattu).
• Tilannevedokset, joiden nimi on ”REPL-MTREE-RESYNC-RESERVE-YYYY-MM-DD-HH-MM-SS”, on luotu mtree-replikoinnilla, kun mtree-replikointikonteksti on purettu. Niiden tarkoituksena on estää replikointitietojen täysi uudelleensynkronointi, jos purettu konteksti luodaan myöhemmin uudelleen (esimerkiksi silloin, kun konteksti on purettu vahingossa). Jos replikointia ei tehdä uudelleen, kontekstit voidaan merkitä vanhentuneiksi manuaalisesti edellä kuvatulla tavalla.
• Vanhentuneet tilannevedokset säilyvät järjestelmässä puhdistuksen/roskienkeruun seuraavaan suorituskertaan asti. Sen jälkeen ne poistetaan fyysisesti järjestelmästä ja snapshot list mtree [mtreen nimi] -komennon tuloksesta, jolloin puhdistus voi vapauttaa tilannevedosten käyttämän levytilan.

Vaihe 5 – tarkista, onko järjestelmässä odottamaton määrä vanhoja tiedostoja

DDR:n automaattinen tuki sisältää histogrammeja, jotka näyttävät DDR:llä olevat tiedostot iän mukaan. Esimerkki:
 
Tästä voi olla hyötyä, kun halutaan selvittää, onko järjestelmässä tiedostoja, joita varmuuskopiointisovellus ei ole merkinnyt vanhentuneiksi tai poistanut odotetulla tavalla. Jos edellä mainittuun järjestelmään on esimerkiksi kirjoittanut varmuuskopiointisovellus, jossa yhden tiedoston enimmäissäilytysaika on kuusi kuukautta, on selvää, ettei varmuuskopiointisovellus merkitse tiedostoja vanhentuneiksi tai poista niitä odotetusti, sillä DDR:ssä on noin 80 000 yli kuusi kuukautta vanhaa tiedostoa.

Huomioi:

• Tiedostojen merkitseminen vanhentuneiksi ja niiden poistaminen on varmuuskopiointisovelluksen vastuulla.
• DDR ei koskaan merkitse tiedostoja vanhentuneiksi tai poista niitä automaattisesti. Jos varmuuskopiointisovellus ei nimenomaisesti pyydä poistamaan tiedostoa, tiedosto säilyy DDR:ssä.

Tämän vuoksi varmuuskopiointisovelluksen myyjän tukitiimin on ensin tutkittava tämänkaltaiset ongelmat.

Tarvittaessa Data Domain -tuki voi antaa seuraavia lisäraportteja:

• kaikkien DDR:n tiedostojen nimi/muokkausaika ikäjärjestyksessä (jotta vanhojen tietojen nimet/sijainnit voidaan määrittää)
• Active/Archive/Cloud Tier -tasojen tiedostoikähistogrammit jaettuna eri raportteihin (jos ER-/LTR-ominaisuudet ovat käytössä).

Tee se seuraavasti:

• Kerää todisteet tämän asiakirjan Lisätietoja-osion sfs_dump-komennon käyttöä koskevien ohjeiden mukaisesti.
• Tee palvelupyyntö sopimuksen piiriin kuuluvalle tuen tarjoajalle.

Kun vanhat/tarpeettomat tiedostot on poistettu Active Tier -tasolta, puhdistus/roskienkeruu on suoritettava, jotta Active Tier -tason fyysinen tila voidaan vapauttaa.

Vaihe 6 – tarkista, onko järjestelmässä varmuuskopioita, jotka sisältävät useita pieniä tiedostoja

DDFS:n rakenteen vuoksi pienet tiedostot (käytännössä kaikki alle 10 Mt:n kokoiset tiedostot) voivat käyttää aluksi liikaa tilaa DDR:ään kirjoitettaessa. Tämä johtuu SISL (Stream Informed Segment Layout) -arkkitehtuurista, jossa pienet tiedostot käyttävät useita yksittäisiä 4,5 Mt:n levytilalohkoja. Esimerkiksi 4 kt:n tiedosto voi käyttää fyysistä levytilaa 9 Mt, kun se kirjoitetaan ensimmäistä kertaa.

Ylimääräinen tila vapautuu, kun puhdistus/roskienkeruu suoritetaan (pienten tiedostojen tiedot yhdistetään pienempään määrään 4,5 Mt:n lohkoja), mutta pienissä DDR-malleissa voi näkyä liian suuri käyttöaste ja täyttömäärä varmuuskopioinnin aikana.

Automaattiseen tukeen kuuluu histogrammeja, jotka näyttävät tiedostot koon mukaan. Esimerkki:
 
Jos varmuuskopiointi kirjoittaa erittäin suuria määriä pieniä tiedostoja, järjestelmän käyttöaste voi nousta hetkellisesti huomattavasti jokaisen puhdistuksen/roskienkeruun suorittamisen väillä. Tässä tapauksessa on suositeltavaa muuttaa varmuuskopiointimenetelmää siten, että kaikki pienet tiedostot sisällytetään yhteen suureen arkistoon (kuten tar-tiedostoon) ennen DDR:ään kirjoittamista. Huomaa, että tällaista arkistoa ei saa pakata tai salata, koska se heikentää tietojen pakkaussuhdetta / kaksoiskappaleiden poistosuhdetta.

Vaihe 7 – tarkista, onko kaksoiskappaleiden poistosuhde odotettua pienempi

DDR:n päätarkoitus on poistaa kaksoiskappaleet ja pakata laitteen käyttämät tiedot. Kaksoiskappaleiden poistosuhde / pakkaussuhde riippuu paljon järjestelmän käyttötarkoituksesta ja siinä olevien tietojen tyypistä. Monissa tapauksissa voidaan kuitenkin käyttää odotettua kokonaispakkaussuhdetta, joka perustuu esimerkiksi soveltuvuusselvitykseen. Järjestelmän nykyinen kokonaispakkaussuhde (ja samalla se, täyttääkö se odotukset) voidaan määrittää komennolla filesys show compression. Esimerkki:
 
Edellä olevassa esimerkissä järjestelmän Active Tier -tason kokonaispakkaussuhde on 65,3x, mikä on erittäin hyvä. Jos arvo kuitenkin osoittaa, että kokonaispakkaussuhde ei ole odotusten mukainen, lisätutkimukset voivat olla tarpeen. Huomaa, että odotettua alhaisemman pakkaussuhteen tutkiminen on monimutkaista ja se voi johtua useasta syystä. Lisätietoja on seuraavassa artikkelissa: https://support.emc.com/kb/487055

Vaihe 8 – tarkista, onko järjestelmä kokoelmareplikoinnin lähde

Jos kokoelmareplikointia käytetään ja lähdejärjestelmä on fyysisesti suurempi kuin kohdejärjestelmä, lähdejärjestelmän koko rajoitetaan keinotekoisesti vastaamaan kohteen kokoa (eli lähdelevyllä on alue, joka merkitään käyttökelvottomaksi). Se johtuu siitä, että kokoelmareplikointia käytettäessä kohteen on oltava lohkotason kopio lähteestä. Jos lähde on kuitenkin fyysisesti kohdetta suurempi, on mahdollista, että lähteeseen voidaan kirjoittaa tietoja, joita ei voida replikoida kohteeseen (koska se on jo täynnä). Tilanne voidaan välttää rajoittamalla lähteen koko kohdetta vastaavaksi.

• Tarkista vaiheen 2 komentojen avulla, onko järjestelmä kokoelmareplikoinnin lähde. Tee se suorittamalla replication status -komento ja tarkistamalla, onko luettelossa replikointikontekstia, jonka alussa lukee ”col://” (se ilmaisee, että kyseessä on kokoelmareplikointi) ja joka EI sisällä paikallisen järjestelmän isäntänimeä kohteessa (tämä tarkoittaa, että järjestelmän on oltava replikointikontekstin lähde).
• Jos järjestelmä on kokoelmareplikoinnin lähde, tarkista kunkin järjestelmän Active Tier -tason koko kirjautumalla kumpaankin järjestelmään ja suorittamalla molemmissa filesys show space -komento. Vertaa sitten niiden Active Tier -tasojen post-comp-kokoja.
• Jos lähde on huomattavasti kohdetta suurempi, sen Active Tier -tason kokoa rajoitetaan keinotekoisesti.
• Jotta lähteen koko tilaa voitaisiin käyttää tietojen tallettamiseen, seuraavat toimenpiteet on suoritettava:

Vaihe 9 – tarkista, suoritetaanko tietojen siirtäminen säännöllisesti

Jos DDR:ään on määritetty joko ER (Extended Retention) tai LTR (Long Term Retention), siihen on liitetty toisen tason tallennustila (Archive Tier ER:lle tai Cloud Tier LTR:lle). Tällöin tietojen siirtokäytännöt on määritetty todennäköisesti niin, että mtreen vanhat/muokkaamattomat tiedot siirretään pitkäaikaista säilytystä varten Active Tier -tasolta vaihtoehtoiselle tasolle, jolloin tiedostojen Active Tier -tasolla käyttämä fyysinen tila voidaan vapauttaa puhdistuksen/roskienkeruun avulla. Jos tietojen siirtokäytännöt on määritetty väärin tai jos tietojen siirtoa ei suoriteta säännöllisesti, vanhat tiedot pysyvät Active Tier -tasolla odotettua pidempään ja käyttävät levyn fyysistä tilaa.

• Suorita aluksi filesys show space -komento selvittääksesi, onko järjestelmä määritetty ER:ää vai LTR:ää varten, ja tarkistaaksesi, onko Archive- tai Cloud Tier -tasoja olemassa. Huomioi, että vaihtoehtoisten tallennustilatasojen koon on oltava yli 0 Gt.

• Jos järjestelmään on määritetty ER/LTR, tarkista mtree-osioiden tietojen siirtokäytännöt varmistaaksesi, että ne ovat odotetut ja määritetty niin, että vanhat tiedot siirretään vaihtoehtoiselle tallennustilatasolle:

• Jos järjestelmään on määritetty ER/LTR, tarkista, että tietojen siirto on aikataulutettu siirtämään Active Tier -tason tiedostot/tiedot säännöllisesti vaihtoehtoiseen tallennustilaan:

• Jos järjestelmään on määritetty ER/LTR, tarkista, milloin tiedot on siirretty viimeksi:

• Kun tietojen siirto on valmis, Active Tier -tason puhdistus tulee suorittaa (huomaa, että se voidaan määrittää käynnistymään automaattisesti tietojen siirtämisen jälkeen). Näin voidaan varmistaa, että siirrettyjen tiedostojen käyttämä Active Tier -tason tallennustila vapautetaan:

Vaihe 10 – lisää tallennustilaa Active Tier -tasolle

Jos kaikki edelliset vaiheet on suoritettu ja Active Tier -tason puhdistus on suoritettu loppuun mutta Active Tier -tason tila ei edelleenkään riitä, järjestelmää ei ole todennäköisesti mitoitettu oikein sille kohdistuvalle kuormitukselle. Tässä tapauksessa on tehtävä jokin seuraavista.

• Vähennä järjestelmään kohdistuvaa kuormitusta esimerkiksi seuraavilla tavoilla:

• Lisää tallennustilaa järjestelmän Active Tier -tasolle ja laajenna sen kokoa:

Data Domain -tuki voi luoda useita raportteja, joissa on esimerkiksi seuraavat tiedot:

• luettelo tietyn tason (esim. Active/Archive/Cloud) kaikista tiedostoista iän mukaan
• arvioitu koko ja pakkaussuhde mtree/major-hakemistopuun mukaan
• luettelo kaikista tietyn mtreen tiedostoista iän mukaan
• ja niin edelleen.

Tätä varten seuraavat tiedot on kerättävä:

• DDR:n uusi tukipaketti – lisätietoja on artikkelissa https://support.emc.com/kb/323283
• sfs_dump- tai sfs_dump -c-komennon tulos:

• Tiedostosijaintiraportti (vaaditaan, jos järjestelmä on määritetty ER:ää tai LTR:ää varten):

Jos tarvitset apua edellä mainittujen tietojen keräämisessä tai minkään vaiheen kanssa, ota yhteyttä sopimuksen piiriin kuuluvaan tuen tarjoajaan.