Data Domain Restorer ja pitkäaikainen säilytys pilvessä: Usein kysyttyjä kysymyksiä

Tässä artikkelissa käsitellään usein kysyttyjä kysymyksiä, jotka koskevat DDR (Data Domain Restorers) -restauroijien (Long-Term Retention (LTR) tai Cloud -ominaisuuden määritystä ja käyttöä.
 

Mikä on LTR?

• Uusi LTR-ominaisuus otettiin käyttöön Data Domain Operating System (DDOS) 6.0 -versiosta alkaen.
• LTR:n avulla tietyt DDR-mallit voivat siirtää osan tiedostoista tai tiedoista objektiin tai pilvitallennustilaan, jota kutsutaan pilvitasoksi, useista tuetuista julkisista tai yksityisistä pilvipalveluntarjoajista.
• Jotta tiedostot tai tiedot voidaan siirtää fyysisesti objektisäilöön, DDR:ssä suoritetaan tiedonsiirtoprosessi.
• Jotta vikasietoiset tiedot voidaan vapauttaa fyysisesti pilvitasolta, DDR:ssä suoritetaan pilvitason puhdistus.
• LTR on lisensoitu ominaisuus, joka edellyttää CLOUDTIER_CAPACITY license.
• LTR edellyttää jonkin verran paikallista tallennustilaa pilvitason metatietoja varten.

Mille DDR-järjestelmille LTR on saatavana?
Tämä riippuu asennetusta DDOS-versiosta ja järjestelmän mallityypistä. Useimmissa malleissa on tiettyjä laitteistovaatimuksia, jotka on täytettävä etukäteen, jotta LTR voidaan määrittää. Katso vaatimukset mallikohtaisesta laitteiston asennusoppaasta sekä DDOS-hallintaoppaasta.

Mikä lisenssi vaaditaan LTR: ään?

• Koska LTR on DDOS 6.x:n ja uudempien uusi ominaisuus, tarvitaan e-lisenssi. 
• Vaadittavaa e-lisenssityyppiä kutsutaan a CLOUDTIER_CAPACITY license. Esimerkki CLOUDTIER_CAPACITY license on seuraava:

Capacity licenses:
##   Feature              Shelf Model   Capacity     Mode        Expiration Date
--   ------------------   -----------   ----------   ---------   ---------------
1    CLOUDTIER-CAPACITY   n/a           136.42 TiB   permanent   n/a
--   ------------------   -----------   ----------   ---------   ---------------

Miten eri tasot toimivat?

• Normaaleissa DDR-tiedostoissa (ilman LTR-lisenssiä) on yksi taso, jota kutsutaan aktiiviseksi tasoksi.
• Aktiivinen taso on kaikkien "vakiomallisten" DDR-laitteiden perinteinen tallennustaso.
• LTR-järjestelmissä on toinen tallennustaso, joka tunnetaan pilvitasona.

Kunkin tason enimmäiskoko määräytyy laitteistokokoonpanon ja DDOS-version tuettujen rajoitusten mukaan. Katso DDOS:n hallintaoppaasta ja kyseisen mallin laitteisto-oppaasta.

Alla on esimerkki kaksitasoisesta, yhdestä aktiivisesta ja yhdestä pilven LTR-kokoonpanosta:   

Active Tier:
Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   --------   --------   ---------   ----   --------------
/data: pre-comp           -    36674.6           -      -                -
/data: post-comp    65460.3      585.4     64874.8     1%              0.1
/ddvar                 29.5       24.7         3.3    88%                -
/ddvar/core            31.5        1.1        28.8     4%                -
----------------   --------   --------   ---------   ----   --------------

Cloud Tier
Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB
----------------   --------   --------   ---------   ----   -------------
/data: pre-comp           -       33.1           -      -               -
/data: post-comp      912.2       42.3       869.9     5%             4.1
----------------   --------   --------   ---------   ----   -------------

Total:
Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB
----------------   --------   --------   ---------   ----   -------------
/data: pre-comp           -    36674.6           -      -               -
/data: post-comp    65460.3      585.4     64874.8     1%             0.1
/ddvar                 29.5       24.7         3.3    88%               -
/ddvar/core            31.5        1.1        28.8     4%               -
----------------   --------   --------   ---------   ----   -------------

Miten pilvitaso on rakennettu?

• Pilvitaso koostuu seuraavista:   
  • Paikalliset metatiedot, jotka tallennetaan koteloon, jos käytetään fyysistä DDR:ää, tai LUNiin tai laitteeseen, jos DDVE:tä käytetään.
  • Objektien tallennuspalvelut
• Molemmat edellä mainitut yhdistetään pilviyksiköksi.
• Jos määritetään useita pilviyksiköitä, ne voivat jakaa paikallisesti säilytetyt metatiedot.
• Järjestelmää kohden voidaan määrittää enintään kaksi pilviyksikköä. Jokainen pilviyksikkö voidaan valmistella eri objektitallennuspalvelusta.
• Kunkin pilviyksikön koko voi olla yhtä suuri kuin tietyn DDR-mallin tukema aktiivisen tason enimmäiskoko. Katso lisätietoja DDOS:n hallintaoppaasta.

Mitä tapahtuu tyypillisen varmuuskopioinnin elinkaaren aikana, kun LTR määritetään?

• Kaikki tiedot kirjoitetaan aluksi aktiiviselle tasolle, jossa se alkaa ikääntyä.
• Lyhytikäiset tiedot, joiden säilytysaika on saavutettu, vanhenevat / poistetaan kuten tavallisessa DDR: ssä.
• Pitkäaikaista säilytystä edellyttävä tietojen alijoukko siirretään kuitenkin pilvitasolle.
• Tiedostojärjestelmä ylläpitää yhtä nimitilaa kaikilla tasoilla, joten kun tiedosto siirretään pilveen, nimitila ei muutu ja on sellaisenaan kohtuullisen läpinäkyvä käyttäjälle tai varmuuskopiosovellukselle.
• Jos pilvitasolle jo siirretyn tiedoston säilytysaika ylittyy, se vanhenee tai poistetaan muiden tiedostojen tavoin.
• Tiedoston pilvitasolla käyttämää tilaa ei vapauteta välittömästi, vaan pilvitason puhdistus on suoritettava.

Miten tietojen kaksoiskappaleet poistetaan tasojen välillä?

• Jokainen pilviyksikkö on itsenäinen taltio, mikä tarkoittaa, että se on itsenäinen deduplikointiyksikkö.
• Tämän seurauksena kuhunkin pilviyksikköön kirjoitetut tiedot voidaan poistaa vain saman pilviyksikön tietojen kaksoiskappaleista.

Mikä on sijoitusaika (tunnetaan nimellä ptime)?

• Tiedostoihin ja hakemistoihin liittyy erilaisia aikaleimoja.
• Esimerkiksi tiedostolla tai hakemistolla on luontiaika, viimeinen käyttöaika ja muokkausaika.
• DDOS on parantanut tätä entisestään sisällyttämällä myös sijoitusajan. Sijoitusaika on päivämäärä ja aika, jolloin tiedosto siirtyi aktiiviselta tasolta pilvitasolle.
• DDOS-versiosta riippuen sijoitusaika näkyy, kun tutkitaan, millä tasolla tiedosto sijaitsee. Jos tiedosto on siirtynyt pilvitasolle, sijoitusaika näytetään, esimerkiksi:  

sysadmin@dd4500 # filesys report generate file-location
--------------------------------      ---------------------------
File Name                             Location(Unit Name)
--------------------------------      ---------------------------
/data/col1/mtree1/random-data-file-4        cloudunit2           Tue Sep 5 10:17:00 2017
/data/col1/mtree1/random-data-file-5        cloudunit2           Tue Sep 12 15:52:23 2017
/data/col1/mtree1/random-data-file-6        cloudunit2           Tue Sep 13 09:42:55 2017

• ptime on edellä mainitun tuloksen viimeinen kenttä, vaikka se ei näytä kentän otsikkoa.

Miten tiedot siirtyvät aktiiviselta tasolta pilvitasolle?

• Tietojen siirtämiseksi kutsuttu prosessi on vastuussa aktiivisella tasolla sijaitsevien MTree-tiedostojen tutkimisesta.
• Tiedonsiirto aloitetaan luomalla tilannevedos kaikista MTreeistä, jotka on määritetty tiedonsiirtoa varten.
• Jokaisella tiedostolla on muokkausaika, joka tallentaa tiedoston viimeisen kirjoitusajan.
• Jos tiedosto on aiemmin siirretty pilvitasolle, määritetään ylimääräinen aikakenttä, jota kutsutaan sijoitusajaksi. Sijoitteluaika tallentaa päivämäärän ja kellonajan, jolloin tiedosto siirrettiin pilvitasolle. Jos sijoitusaika on asetettu, sitä käytetään muokkausajan sijasta. Näin vältetään tiedoston jatkuva siirtäminen takaisin pilvitasolle, jos tiedosto kutsutaan takaisin (koska tiedoston peruuttaminen ei muuta sen muokkausaikaa).
• Tietojen siirto käy läpi edellä luodut tilannevedokset.
• Jos tutkittava tiedosto on saavuttanut määritellyn kynnysarvon, joka on asetettu kyseiselle MTree-tiedonsiirtokäytännölle, tiedosto tutkitaan sen selvittämiseksi, mitä tiedoston sisältämiä tietoja on siirrettävä aktiiviselta tasolta pilvitasolle. MTree-kohtainen tiedonsiirtokäytäntö määritetään.
• Valitun tiedoston yksilölliset segmentit kirjoitetaan tai kopioidaan pilvitasolle. 
• Kun yksilölliset segmentit on kopioitu, tiedosto tarkistetaan lukemalla ne takaisin, jotta siirto varmistaa, että siirto onnistui.
• Kun tiedosto on vahvistettu, metatiedot päivitetään vastaamaan sitä, että tiedosto sijaitsee nyt pilvitasolla.
• Tiedonsiirtoprosessi voidaan ajoittaa suoritettavaksi tietyllä taajuudella tai se voidaan käynnistää manuaalisesti.

Kun tiedonsiirto aloitetaan, mitä vaiheita on olemassa ja mitä toimintoja kukin vaihe suorittaa?

• Tietojen siirtämiseen liittyy kolme vaihetta: kopiointivaihe, tarkistusvaihe ja asennusvaihe.
• Kopiointivaiheessa tunnistetaan segmentit, jotka on kopioitava pilveen, ja siirretään sitten nämä segmentit pilveen.
• Kun kopiointivaihe alkaa, se on pilvi- tai objektitallennus, ja kopiointivaiheessa kopioidaan tunnistetut segmentit aktiiviselta tasolta pilvitasolle.
• Vahvistusvaihe on vastuussa sen varmistamisesta, että tiedoston segmentit siirrettiin onnistuneesti pilveen.
• Asennusvaihe vastaa siirrettyyn tiedostoon liittyvien metatietojen päivittämisestä osoittamaan, että se sijaitsee nyt pilvi- tai objektitallennustilassa.
• Jokaisen tiedoston on suoritettava kaikki kolme vaihetta, jotta tietojen siirto voidaan katsoa onnistuneeksi kyseisen tiedoston osalta. Tämän vuoksi tiedosto pysyy aktiivisella tasolla, kunnes tiedoston asennusvaihe on valmis.

Mitä tiedonsiirtokäytäntöjä on käytettävissä?

• Tiedonsiirtokäytännöt voivat olla seuraavia:   
  • Ikäraja: Jos tiedostojen sijoitus- tai muokkausaika on määritettyä ikäryhmää pidempi, se valitaan siirrettäväksi pilvitasolle.
  • Ikäryhmä: Jos tiedoston sijoitus- tai muokkausaika osuu tietylle alueelle, se siirretään pilvitasolle.
  • Sovelluksen määritelmä: Varmuuskopiointisovellus määrittää, valitaanko tiedosto siirrettäväksi pilvitasolle.
• Politiikat ovat toisensa poissulkevia, toisin sanoen MTreellä voi olla vain yksi käytäntö kerrallaan.

Miten tiedonsiirtokäytäntö voidaan asettaa MTreelle?

• Voit käyttää alla olevaa komentoa. Esimerkki:   

data-movement policy set <policy name> <policy type values> totier cloud cloud-unit <cloud unit name> mtrees <mtree list>

sysadmin@dd4500 # data-movement policy set age-threshold 14 to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1
sysadmin@dd4500 # data-movement policy set age-range min-age 14 max-age 100 to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1
sysadmin@dd4500 # data-movement policy set app-managed to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1

Mitä tiedonsiirtokäytäntöjä on jo määritetty?

• Alla olevassa komennossa on luettelo MTreeistä, joille on määritetty tiedonsiirtokäytäntöjä. Esimerkki:   

data-movement policy show

sysadmin@dd4500 # data-movement policy show
Mtree               Target(Tier/Unit Name)   Policy      Value      
-----------------   ----------------------   ---------   -----------
/data/col1/mtree1   Cloud/cloudunit1         age-range   14-100 days
-----------------   ----------------------   ---------   -----------

Miten sovelluksen hallitsema tiedonsiirtokäytäntö toimii?

• Kyseisen MTreen tiedonsiirtokäytännöksi on määritetty app-managed. Tämä tehdään joko manuaalisesti tai varmuuskopiointisovellus tekee sen Data Domain REST API -käyttöliittymän kautta.
• Varmuuskopiointisovelluksen on oltava LTR-tietoinen.
• Varmuuskopiointisovelluksen on käytettävä DD Boostia ja DD Boost -version on oltava LTR-tietoinen ja yhteensopiva.
• DD Boost -kirjaston/ohjelmointirajapinnan avulla varmuuskopiointisovellus määrittää pilvitasolle siirrettävän tiedoston sijoitusajaksi erityisarvon, joka ilmaisee, että kun seuraavan kerran tiedonsiirto suoritetaan, tiedosto siirretään pilveen.
• Kun tiedonsiirto suoritetaan Data Domain -järjestelmässä, sijoitusaika tarkistetaan, ja jos se on asetettu erityisarvoon, kuten edellä mainittiin, tiedosto siirretään pilveen.

Miten tietojen siirto voidaan käynnistää manuaalisesti?

• Alla olevaa komentoa voidaan käyttää esimerkiksi:   

data-movement start

sysadmin@dd4500 # data-movement start
Data-movement started.

Miten tiedonsiirtoa voidaan valvoa?

• Alla olevaa komentoa voidaan käyttää tietojen siirron tilan tarkistamiseen. Esimerkki:   

data-movement status

sysadmin@dd4500 # data-movement status
Data-movement to cloud tier:
----------------------------
Data-movement is initializing..

Data-movement recall:
---------------------
No recall operations found. 

• Jos tiedonsiirto on käynnissä, voidaan käyttää alla olevaa komentoa, esimerkiksi:   

data-movement watch 

sysadmin@dd4500 # data-movement watch
Data-movement: phase 1 of 3 (copying)
   92% complete; time: phase  0:08:04, total  0:08:14
      Copied (post-comp): 3.35 GiB, (pre-comp): 3.29 GiB,B,
      Files copied: 7, Files verified: 3, Files installed: 3

Miten tiedonsiirto voidaan pysäyttää?

• Voit käyttää alla olevaa komentoa. Esimerkki:   

data-movement stop 

sysadmin@dd4500 # data-movement stop
Data-movement stop initiated. Run the status command to check its status.

Jos pilviyksiköitä on enemmän kuin yksi, voiko tiedonsiirto suorittaa molempiin pilviyksiköihin rinnakkain?

• Ei. Pohjimmiltaan tietojen siirtäminen voi siirtää tietoja vain yhteen pilviyksikköön kerrallaan.

Miten LTR määritetään?

• Tämä on korkean tason yleiskatsaus, katso yksityiskohtainen prosessi DDOS:n hallintaoppaasta.
• Lisää sopiva CLOUDTIER_CAPACITY license.
• Jos sitä ei ole jo määritetty, määritä järjestelmän salasana.
• Ota pilviominaisuus käyttöön.
• Lisää pilvitason metatietojen tallennustila.
• Pilviprofiilin tai -profiilin määritys sopivalle pilvi- tai objektitallennustilan toimittajalle
• Lisää pilviyksikkö.
• Määritä tiedonsiirtokäytäntö MTree- tai MTree-järjestelmille, jotka edellyttävät tietojen tallentamista pilveen.
• Aloita tiedonsiirto manuaalisesti tai odota, että automaattinen tai ajoitettu tiedonsiirto alkaa.

Voiko pilviyksikön poistaa? Jos, niin miten?

• Huomio: Tämä tuhoaa kaikki pilviyksikössä olevat tiedot, joten tietoja ei voida palauttaa, joten toimi varoen.
• Katso tämän tietämyskannan asiakirjan osasta "Miten käyttäjä selvittää, millä tasolla tiedosto sijaitsee" tietoja siitä, mitkä tiedostot sijaitsevat poistettavassa pilviyksikössä.
• Nämä tiedostot on joko poistettava, jos niitä ei enää tarvita, tai palautettava aktiiviselle tasolle, jos ne on säilytettävä.
• Jos tiedostoja on säilytettävä, varmista, että kaikki tiedostot on palautettava, ennen kuin jatkat.
• Pilviyksikössä ei saa olla jäljellä poistettuja tiedostoja.
• Nollaa tätä pilviyksikköä käyttävien MTree- tai MTree-tiedonsiirtokäytäntöjen oletusasetukset.
• Poista tiedostojärjestelmä käytöstä.
• Poista pilviyksikkö. Tämä merkitsee pilviyksikön DELETE_PENDING tilaan, joka on suunnitellut.
• Ota tiedostojärjestelmä käyttöön.
• Kun tiedostojärjestelmä on käynnistynyt, se alkaa asynkronisesti poistaa kaikkia tämän pilviyksikön käyttämiä objekteja pilvestä tai objektien tallennuspalvelusta. Kun kaikki objektit on poistettu, myös tämän pilviyksikön käyttämät säilöt poistetaan. Jos objekteja on paljon, pilviyksikkö voi pysyä DELETE_PENDING tilassa pitkään.
• Kun kaikki objektit ja säilöt on poistettu, pilviyksikkö katoaa pilviyksikköluettelosta.

Mitä tapahtuu, jos pilviyksikön poistaminen epäonnistuu, koska objektitallennus ei ole enää käytettävissä tai siinä on yhteysongelma?

• Ota yhteys Dell-tukeen .

Voiko LTR ja Extended Retention (ER) määrittää samalle järjestelmälle?

• Ei. ER ja LTR ovat toisensa poissulkevia ominaisuuksia.

Miten tiedot vapautetaan tai puhdistetaan pilvitasolta?

• Tämä toimii samalla tavalla kuin aktiivisella tasolla olevat tiedostot
• Kun tiedoston säilytysaika päättyy, se poistetaan tiedostojärjestelmän nimitilasta.
• Pilvitason puhdistus on ajoitettu suoritettavaksi. Oletusarvoisesti pilvitason puhdistus suoritetaan neljän aktiivisen tason puhdistuksen jälkeen.
• Jotta pilvitason puhdistus voidaan suorittaa, puhdistettavassa pilviyksikössä on oltava vähintään 1% tarpeettomia tai puhdistettavissa olevia tietoja, jotta se voidaan aloittaa. Tämä johtuu siitä, että mikä tahansa pilviverkkoliikenne voi olla maksullista, joten DDR yrittää rajoittaa verkkoliikennettä mahdollisuuksien mukaan.
• Pilvitaso toimii oletusarvoisesti 50 %:n puhdistuskaasulla.
• Sekä pilvitason puhdistusaikataulua että puhdistuskaasua voidaan muuttaa.
• Aktiivisuustason ja pilvitason puhdistusta ei voi suorittaa rinnakkain.
• Jos automaattinen tai ajoitettu pilvitason puhdistus on käynnissä, aktiivinen tasojen puhdistus estää sen.
• Jos manuaalinen pilvitason puhdistus aloitetaan, aktiivisen tason puhdistusta ei voida aloittaa, ennen kuin pilvitason puhdistus on valmis.
• Jos pilvitasolla on kaksi pilviyksikköä, vain yksi pilviyksikkö puhdistetaan ajoitettua tai automaattista pilvitason puhdistusta kohden. Pilviyksikköä käytetään round-robin-tavalla pilvitason puhdistuksen näkökulmasta. Kun pilviyksiköitä on kaksi, on määritettävä puhdistettava pilviyksikkö, kun se suoritetaan komentoriviltä (pilven puhdistuksen käynnistysyksikön <nimi>)
• Jos pilvitason puhdistus ei käynnisty esimerkiksi pilviyksikössä, nykyisessä pilviyksikössä ei ole tarpeeksi puhdistettavia tietoja, jotta se olisi kannattavaa, järjestelmä yrittää automaattisesti puhdistaa seuraavasta pilviyksiköstä.
• Lisätietoja pilvitason puhdistuksesta on seuraavassa artikkelissa Data Domain: Johdanto pitkäaikaiseen säilytykseen, pilvitason puhdistukseen ja roskien keräämiseen Data Domain Restorersissa (DDR)

Miten manuaalinen pilvitason puhdistus aloitetaan?

• Voit käyttää alla olevaa komentoa. Esimerkki:   

cloud clean start <cloud unit> 

sysadmin@dd4500 # cloud clean start cloudunit2
Cloud tier cleaning started for cloud unit "cloudunit2". Use 'cloud clean watch' to monitor progress.

Miten pilvitason puhdistusta voidaan valvoa?

• Alla olevalla komennolla voit tarkistaa, onko pilvipuhdistus käynnissä. Esimerkki:   

cloud clean start <cloud unit> 

sysadmin@dd4500 # cloud clean status
Previous cloud tier cleaning attempt was unsuccessful.
 Failure reason:
cloud unit "cloudunit2" did not have sufficient cleanable data.
Cloud tier cleaning finished at 2017/03/15 12:16:06.

• Jos pilvipuhdistus on käynnissä, sitä voidaan valvoa alla olevalla komennolla:

cloud clean watch

Voiko aktiivisen tason puhdistuksen suorittaa samanaikaisesti pilvitason puhdistuksen kanssa?

• Ei. Sekä aktiivinen tasopuhdistus että pilvitason puhdistus käyttävät molemmat samoja yhteisiä sisäisiä jaettuja tietorakenteita, jotka edellyttävät yksinomaista pääsyä.

Miten pilvitason puhdistusaikataulu voidaan näyttää tai miten sitä voidaan muuttaa?

• Alla olevalla komennolla voidaan näyttää nykyinen pilvipuhdistusaikataulu. Esimerkki:   

cloud clean frequency show

sysadmin@dd4500 # cloud clean frequency show
Cloud tier cleaning frequency is set to run after every 4 active tier cleaning cycles.

• Alla olevaa komentoa käytetään aikataulun muuttamiseen. Esimerkki:  

cloud clean frequency set <value>

sysadmin@dd4500 # cloud clean frequency set 3
Cloud tier cleaning frequency is set to run after every 3 active tier cleaning cycles.

Miten pilvitason puhdistuskaasua voidaan muuttaa tai näyttää?

• Oletuksena pilvitason puhdistus kuristaa sen arvoksi on asetettu 50%. Alla olevalla komennolla se voidaan palauttaa oletuskaasuprosenttiin.

cloud clean throttle reset

• Alla olevaa komentoa voidaan käyttää nykyisen pilvipuhdistuskaasun näyttämiseen. Esimerkki:   

cloud clean throttle show

sysadmin@dd4500 # cloud clean throttle show
Cloud tier cleaning throttle is set to 28 percent

• Alla olevaa komentoa voidaan käyttää puhdistuskaasun muuttamiseen. Esimerkki:   

cloud clean throttle set <value> 

sysadmin@dd4500 # cloud clean throttle set 20
Cloud tier cleaning throttle set to 20 percent

Mitä pilvitason puhdistuskaasu ohjaa?

• Pilvitason puhdistuskaasu toimii samalla tavalla kuin aktiivisen tason puhdistuskaasu siinä mielessä, että kuristus rajoittaa I/O- ja CPU-resursseja, joita pilvitason puhdistus voi käyttää.
• Se ei rajoita verkon siirtoa.

Miksi pilvitason puhdistus ei vapauta/poista niin monta objektia kuin odotettiin?

• Siivousta pidetään aina arviona. Seuraavissa tietämyskannan artikkeleissa kuvataan tähän aiheeseen liittyviä näkökohtia, koska ne koskevat yhtä lailla pilvipalvelutasolla olevia tietoja:  

• Tämän lisäksi on muita erityisiä yksityiskohtia siitä, miten pilvitaso toteutetaan.
• Pilvi- tai objektitallennuspalvelujen tarjoajalle suuntautuvan verkkoliikenteen määrän rajoittamiseksi on toteutettu erilaisia menetelmiä, koska siihen voi liittyä kustannuksia.
• Kuten edellä mainittiin, puhdistuksen suorittamiseen tarvitaan vähintään 1 % tietojen vaihtuvuutta.
• Kun tiedostojärjestelmää siirretään etsimään tiedostoja, jotka täyttävät tiedonsiirtokäytännön, metatiedoista tutkitaan vain paikalliset kopiot.
• Kaikki pilvi- tai objektitallennuksessa olevat segmentit, joiden havaitaan sisältävän vain käyttäjädataa, merkitään asynkronisesti poistettaviksi.
• Kaikki segmentit, jotka sisältävät vähintään yhden live-segmentin, ohitetaan, koska DDOS ei halua yhdistää pieniä tietomääriä verkkoliikenteen vuoksi.

Miten käyttäjä voi selvittää, millä tasolla tiedosto sijaitsee?

• Katso alla olevasta komennosta esimerkki komennon tuloksesta:  

filesys report generate file-location

sysadmin@dd4500 # filesys report generate file-location
--------------------------------      ---------------------------
File Name                             Location(Unit Name)
--------------------------------      ---------------------------
/data/col1/mtree1/random-data-file-1        Active
/data/col1/mtree1/random-data-file-2        Active
/data/col1/mtree1/random-data-file-4        cloudunit2
/data/col1/mtree1/random-data-file-5        cloudunit2
/data/col1/mtree1/random-data-file-6        cloudunit2

Voiko tiedostoa lukea tai käyttää heti sen jälkeen, kun se on siirretty pilvitasolle?

• Tämä riippuu pilvipalveluntarjoajan kanssa käytössä olevasta DDOS-versiosta:   

• Tiedostojen suora palauttaminen on mahdollista ilman, että tiedostoa tarvitsee ensin palauttaa. Tätä kutsutaan suoraksi palautusominaisuudeksi, ja se rajoittuu ECS:ään pilvipalvelun tai objektin tarjoajana.
• Lisätietoja Avamarin suorasta palautuksesta on teknisessä raportissa Avamar Granular or File Level Restore from Data Domain Cloud Tier.
• Avamar GLR/FLR (Direct Restore) -ominaisuus edellyttää vähintään Avamar 18.1- tai DDOS 6.1 -yhdistelmää ECS:n ollessa pilvipalvelu. 

• Tiedosto on ensin palautettava. Toisin sanoen tiedot siirrettiin takaisin pilvitasolta aktiiviselle tasolle.
• Tiedosto on palautettava pilvitasolta aktiiviselle tasolle käyttämällä data-movement recall -komentoa, jotta kaikki tiedot voidaan lukea tiedostosta tai muokata pilvitasolla olevaa tiedostoa.
• Kaikki yritykset lukea tai muokata pilvitasolla olevaa tiedostoa johtavat I/O-virheen palauttamiseen sille, joka yrittää lukea varmuuskopiosovelluksena olevaa tiedostoa, jos tiedostoa ei vedetä takaisin ensin.
• Jotkin pilvitietoiset varmuuskopiointisovellukset voivat käynnistää tiedostojen takaisinkutsuja, muuten tiedostot on palautettava manuaalisesti.
• DDOS 7.7+:sta lähtien:
  • Suoran palautuksen avulla integroimattomat sovellukset voivat lukea tiedostoja suoraan pilvitasolta käymättä läpi aktiivista tasoa.
  • Suoran palautuksen valinnassa on otettava huomioon muun muassa seuraavat:
  • Suora palautus ei edellytä integroitua sovellusta, ja se on läpinäkyvä integroimattomille sovelluksille.
  • Pilvitasolta lukeminen ei edellytä kopiointia ensin aktiiviselle tasolle.
  • Histogrammit ja tilastot ovat käytettävissä suorien lukujen seuraamiseen pilvitasolta.
  • Suoraa palautusta tuetaan vain AWS - ja ECS-pilvipalveluissa .
  • Sovellukset kokevat pilvitason viiveen.
  • Suoraan pilvitasolta lukemista ei ole optimoitu kaistanleveyttä.

Kuinka monta tiedostoa voidaan palauttaa rinnakkain?

• DDOS 6.0 tukee neljää tiedostoa, jotka asetetaan jonoon ja palautetaan rinnakkain.
• DDOS 6.1 tukee 1000 jonossa olevaa tiedostoa ja 4 palautusjonossa olevaa tiedostoa, jotka voidaan palauttaa rinnakkain.

Data Domain Admin Guide 7.9 -oppaan mukaan:

• Järjestelmät, joissa on vähintään 256 Gt muistia, voivat palauttaa jopa 16 tiedostoa kerralla.
• Järjestelmät, joissa on alle 256 Gt muistia, voivat palauttaa enintään kahdeksan tiedostoa kerralla.
• DDVE-esiintymät voivat palauttaa enintään neljä tiedostoa kerralla.

Miten tiedosto voidaan peruuttaa?

• Tiedosto voidaan palauttaa käyttämällä alla olevaa komentoa. Esimerkki:   

data-movement recall path <path-name> 

sysadmin@dd4500 # data-movement recall path /data/col1/mtree1/file1

Miten kaikki MTreen tiedostot voidaan palauttaa?

• DDOS-version mukaan kaikki Cloudin tiedostot voidaan palauttaa suorittamalla yksi alla oleva komento:   

sysadmin@dd4500 # data-movement recall mtree /data/col1/mtree1

• Lisätietoja on DDOS-version Dell DDOS Command Reference Guide -oppaassa

Miten takaisinveto-operaatiota voidaan valvoa?

• Takaisinvetotoimintoa voidaan valvoa alla olevalla komennolla tai jos tarvitaan tietty tiedosto. Esimerkki:   

data-movement status path all

data-movement status path /data/col1/mtree/file1

sysadmin@dd4500 # data-movement status path /data/col1/mtree1/file1
Data-movement recall:
---------------------
Data-movement for  /data/col1/mtree1/file1 : phase 2 of 3
(Verifying)
80% complete; time: phase XX:XX:XX total XX:XX:XX
Copied (post-comp): XX XX, (pre-comp) XX XX 

Aiheuttaako tiedoston uudelleennimeäminen tiedoston palauttamisen pilvitasolta aktiiviselle tasolle?

• Ei. Jos tiedosto nimetään uudelleen, se pysyy nykyisellä tasollaan.

Mitä pilvipalvelujen tarjoajia tuetaan?

•  Käytössä olevan DDOS-version mukaan DDOS tukee seuraavia pilvipalveluntarjoajia:   
• Amazon Web Services (AWS).
• Microsoft Azure -pilvi
• Dell Elastic Cloud Storage (ECS)
• Virtustream
• Katso lisätietoja DDOS:n hallintaoppaasta.

Tuetaanko salausta pilvitasolla ja onko se lisensoitava?

• Kyllä, salausta tuetaan pilvitasolla. Tämä ei vaadi lisälisenssiä, toisin kuin aktiivinen tason salaus.
• Tämä voidaan määrittää, kun pilviominaisuus otetaan käyttöön tai sitä muokataan sen jälkeen. 
• Tätä kirjoitettaessa vain sulautettua avainhallintaa tuetaan pilvitason salauksessa ja vain yhtä salausalgoritmia voidaan käyttää LTR-järjestelmän laajuisesti.

Mitä säilöjä pilvipalveluntarjoajien objektisäilöön luodaan?

• DDOS luo kolme säilöä
• Kauhat päättyvät merkkijonoon:

'-d0'

'-c0' 

'-m0'

• Säilöä, jonka lopussa on merkkijono '-d0', käytetään tietosegmenteissä.
• Säilöä, jonka lopussa on merkkijono '-c0', käytetään määritystietoihin.
• Säilöä, jonka lopussa on merkkijono '-m0', käytetään metatietoina.
• Ennen DDOS 6.1:tä säilöjä luotiin kolme, mutta käytössä on vain säilön loppuosa -d0. Kaikkia kolmea ämpäriä tarvitaan kuitenkin, joten varmista, että niitä ei poisteta.

Voiko aiemmin luotuja säilöjen nimiä käyttää?

• Ei, tämä ei ole mahdollista.

Tarvitaanko laitteistovaatimusten lisäksi muita pakollisia vaatimuksia ennen LTR:n määrittämistä?

• Kyllä
• Jos käytetään ECS:ää, kuormituksentasaus on pakollinen vaatimus. Ilman kuormituksentasausta Data Domain kommunikoi ECS:n kanssa yhdessä solmussa ja katkaisee yhteyden, kun useita pyyntöjä on tehty.
• 1Gb-verkko DDR:n ja pilvipalveluntarjoajan välillä

Tarvitaanko varmenteita ja jos tarvitaan, mitä varmenteita tulisi käyttää?

• Tämä riippuu käytettävästä objektista tai pilvipalvelun tarjoajasta sekä kokoonpanosta.
• AWS, Virtustream tai Azure vaatii varmenteen. Katso lisätietoja DDOS:n hallintaoppaasta.
• Jos ECS määritetään käyttäen http-päätepistettä, varmennetta ei tarvita.
• Jos ECS määritetään käyttäen https-päätepistettä, tarvitaan varmenne. Koska kuormituksentasaus on pakollinen vaatimus, vaadittu todistus on lainantasausjärjestelmästä ECS-järjestelmän sijaan. Pyydä lisätietoja kuormituksentasauksen tarjoajalta.
• Sertifikaattia tuotaessa sen on oltava PEM-muodossa. Jotkin palveluntarjoajat eivät toimita varmennetta PEM-muodossa, joten se on muunnettava ennen tuontia.

Mitä replikointitopologioita tuetaan?

• Kokoelman replikointia _ei_ tueta.
• Hakemiston replikointia tuetaan, mutta sitä voi käyttää vain '/data/col1/backup' MTree, mutta tämä MTree ei tue tietojen siirtoa.
• MTree-replikointia tuetaan täysin.
• MFR- tai VSR-replikointia tuetaan täysin.

Mitä on otettava huomioon, kun replikointia määritetään/alustetaan/alustetaan uudelleen järjestelmässä, johon LTR on jo määritetty?

• Lähdejärjestelmä ottaa tilannevedoksen MTreestä (tämä tilannevedos sisältää tietoja aktiivisten ja pilvitasojen tiedostoista).
• Lähdejärjestelmä replikoi tilannevedoksen kohdejärjestelmän aktiiviselle tasolle.
• Vasta kun tilannevedos on replikoitu kokonaan, se näkyy kohdejärjestelmässä (jolloin tiedostot tulevat saataville kohdejärjestelmän tiedostojärjestelmän nimitilaan).
• Vasta sen jälkeen, kun tiedostot on paljastettu, tietoja voidaan siirtää määränpäässä (olettaen, että se on määritetty LTR: lle).
• Jos kohteiden aktiivinen taso ei ole tarpeeksi suuri täydellisen tilannevedoksen toimittamiseen lähteestä, tilannevedosta ei koskaan näytetä eikä replikointia voida suorittaa alustusta loppuun.

Mitä tulisi ottaa huomioon, jos määritetään MFR- tai VSR-replikointi järjestelmässä, jossa LTR on jo määritetty?

• Jos lähde-DDR:n pilvitasolle jo siirretyt tiedot on replikoitava, se palauttaa automaattisesti pilvipalveluntarjoajalta aktiiviselle tasolle, ennen kuin se voidaan lähettää verkon kautta.
• Tiedostojen palauttaminen pilvitasolta aktiiviselle tasolle voi aiheuttaa kustannuksia tai viivettä.

Miksi Data Domainin tiedostojärjestelmä näyttää tilaa -komennon tulos ei vastaa pilvi- tai objektitallennustilan todellista kokoa?

• Pilvi- tai objektitallennuksen luontaisen toimintatavan vuoksi Data Domain -järjestelmällä ei ole mitään keinoa kysellä pilvilaitteen fyysistä kokoa, koska sitä voidaan pitää näennäisesti äärettömänä.
• DDOS:n oli kuitenkin kehitettävä tapa näyttää nykyiset käyttö-/deduplikointitilastot DDOS:n näkökulmasta.
• Siksi käytetään yhtä kahdesta lähestymistavasta:

1. Pilvitason koko määräytyy CLOUDTIER_CAPACITY license
2. Pilvitason koko näytetään kyseisen mallityypin aktiivisten tasoyksiköiden koon kerrannaisina sen mukaan, kuinka monta pilviyksikköä on määritetty. Katso lisätietoja aktiivisten tasojen koosta kyseisen mallin laitteiston asennusoppaasta.

Miten tiedostojärjestelmä voidaan käynnistää, jos pilviyksikkö ei ole käytettävissä?

• Varmista, että tiedostojärjestelmä on poistettu käytöstä.
• Poista käytöstä pilviyksikkö, joka ei ole käytettävissä, seuraavalla komennolla:

cloud unit disable <cloud unit name>

• Ota tiedostojärjestelmä käyttöön.

Jos pilviyksikkö on poistettu käytöstä, miten se voidaan ottaa käyttöön?

• Varmista, että tiedostojärjestelmä on poistettu käytöstä.
• Ota pilviyksikkö käyttöön seuraavalla komennolla:

cloud unit enable <cloud unit name>

• Ota tiedostojärjestelmä käyttöön.

Miksi tiedostojärjestelmässä on edelleen tiedostoja, jotka sijaitsevat poistetussa pilviyksikössä?

•  Jos tiedostoja ei poistettu MTreestä ennen pilviyksikön poistamista, tiedostot ovat edelleen tiedostojärjestelmien nimitilassa.
• Näin ollen tiedostojen sijaintiraportti osoittaa, että tiedostot ovat osa poistettua pilviyksikköä. Esimerkki:  

sysadmin@dd4500 # filesys report generate file-location
--------------------------------      ---------------------------
File Name                             Location(Unit Name)
--------------------------------      ---------------------------
/data/col1/mtree1/random-data-file-3  Deleted cloud-unit
/data/col1/mtree1/random-data-file-4  Deleted cloud-unit

• Tiedostot näkyvät edelleen tiedostojärjestelmän nimitilassa käyttämällä tämän MTreen jaettua CIFS/NFS-resurssia.
• Tiedostot eivät kuitenkaan ole luettavissa, koska pilviyksikkö, jossa ne sijaitsivat, on poistettu.
• Siksi ainoa vaihtoehto on poistaa nämä tiedostot, koska niiden viittaamia tietoja ei enää ole.

Voiko ECS- tai S3 Flexible -pilvipalveluntarjoajan protokollan päätepistettä tai portteja muuttaa pilviyksikön luomisen jälkeen?

• Tämä saattaa olla tarpeen esimerkiksi, jos vaihdat http: stä https: ään tai päinvastoin, siirryt uuteen kuormituksentasaukseen.
• Tätä kirjoitettaessa Data Domain -järjestelmänvalvoja ei voi mitenkään suorittaa tätä muutosta. Tätä toimintoa harkitaan tulevassa DDOS-julkaisuversiossa.
• Tämä voidaan kuitenkin suorittaa tuella tai suunnittelulla.
• Tiedostojärjestelmä on poistettava käytöstä, jotta tämän muutoksen voi tehdä.
• Tarvittaessa kaikki Data Domain -järjestelmän ulkopuoliset määritykset tehdään ensin, koska kun tämä muutos tehdään ja kun tiedostojärjestelmä on otettu käyttöön, se odottaa pystyvänsä viestimään päivitetyn protokollan tai portin avulla ja lukemaan säilöjä tai objekteja kuten aiemmin.