Data Domain Restorer og langsigtet opbevaring i clouden: Ofte stillede spørgsmål

Denne artikel omhandler de hyppigst stillede spørgsmål vedrørende konfiguration og brug af Data Domain Restorers (DDRs) og Long-Term Retention (LTR) eller Cloud-funktionen.
 

Hvad er LTR?

• En ny funktion kaldet LTR blev introduceret startende med Data Domain Operating System (DDOS) 6.0.
• LTR gør det muligt for visse modeller af DDR'er at migrere et undersæt af filer eller data til et objekt eller et cloudlager, også kaldet et cloudniveau, fra en række understøttede offentlige eller private cloud-udbydere.
• Hvis du vil overføre filer eller data fysisk til objektstorage, køres en dataflytningsproces på DDR.
• For fysisk at frigøre overflødige data fra cloudniveauet køres en proces til rensning på cloudniveau på DDR.
• LTR er en licenseret funktion og kræver en CLOUDTIER_CAPACITY license.
• LTR kræver noget lokal storage til metadata på cloudniveau.

Hvilke DDR-systemer fås LTR til?
Dette afhænger af den DDOS-version, der er installeret sammen med systemmodeltypen. De fleste modeller har visse hardwarekrav, der skal opfyldes på forhånd, for at LTR kan konfigureres. Se hardwareinstallationsvejledningen for de specifikke modeller samt DDOS-administrationsvejledningen for kravene.

Hvilken licens kræves til LTR?

• Da LTR betragtes som en ny funktion fra DDOS 6.x og nyere, kræves der en e-licens. 
• Den type e-licens, der kræves, kaldes en CLOUDTIER_CAPACITY license. Et eksempel på en CLOUDTIER_CAPACITY license er som følger:

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

Hvordan fungerer de forskellige niveauer?

• Normale DDR'er (uden en LTR-licens) har et enkelt niveau, der kaldes det aktive niveau.
• Det aktive niveau er det traditionelle lagerniveau på alle "standard" DDR'er.
• LTR-systemer har et sekundært storageniveau, der kaldes et cloudniveau.

Den maksimale størrelse af hvert niveau dikteres af de understøttede grænser for den givne hardwarekonfiguration og DDOS-version. Se DDOS-administrationsvejledningen og hardwarevejledningen for den pågældende specifikke model.

Nedenfor vises et eksempel på en tostrenget, en aktiv og en cloud-LTR-konfiguration:   

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%               -
----------------   --------   --------   ---------   ----   -------------

Hvordan er et cloudniveau struktureret?

• Et cloudniveau består af:   
  • Lokalt opbevarede metadata, gemt i et kabinet, hvis der bruges en fysisk DDR, eller en LUN eller enhed, hvis der bruges DDVE.
  • Udbydere af objektstorage
• Begge ovenstående er kombineret til en skyenhed.
• Hvis der er konfigureret flere cloudenheder, kan de dele de lokalt opbevarede metadata.
• Der kan maksimalt konfigureres to cloud-enheder pr. system. Hver cloudenhed kan klargøres fra forskellige udbydere af objektstorage.
• Hver cloud-enhed kan være så stor som den maksimale understøttede aktive niveaustørrelse for den givne DDR-model. Se DDOS-administrationsvejledningen for at få flere oplysninger.

Hvad sker der i løbet af en typisk backuplivscyklus, når LTR konfigureres?

• Alle data skrives oprindeligt til det aktive niveau, hvor de begynder at ældes.
• Kortlivede data, der når opbevaringsperioden, udløber/slettes som på en normal DDR.
• Et undersæt af data, der kræver langsigtet opbevaring, migreres imidlertid ud til cloudniveauet.
• Filsystemet opretholder et enkelt navneområde på tværs af alle niveauer, så når en fil migreres til skyen, ændres navneområdet ikke, og det er som sådan rimeligt gennemsigtigt for brugeren eller sikkerhedskopieringsprogrammet.
• For en fil, der allerede er migreret til skyniveauet, når opbevaringsperioden, udløber/slettes den som enhver anden fil.
• Den plads, som en fil brugte i cloudniveauet, frigøres ikke med det samme, men skal i stedet køres rensning på cloudniveau.

Hvordan deduplikeres data mellem niveauer?

• Hver cloudenhed er en selvstændig diskenhed, hvilket betyder, at den er en selvstændig deduplikeringsenhed.
• Derfor kan data, der skrives til hver cloudenhed, kun deduplikeres i forhold til data i den samme cloudenhed.

Hvad er en placeringstid (kendt som ptime)?

• Filer og mapper har forskellige tidsstempler tilknyttet.
• For eksempel har en fil eller mappe et oprettelsestidspunkt, sidste adgangstidspunkt og ændringstid.
• DDOS har forbedret dette yderligere til også at omfatte en placeringstid. Placeringstidspunktet er den dato og det klokkeslæt, hvor filen blev migreret fra det aktive niveau til cloudniveauet.
• Afhængigt af DDOS-versionen kan placeringstiden ses, når du undersøger, hvilket niveau en fil er placeret på. Hvis filen er migreret til cloudniveauet, vises placeringstidspunktet, f.eks.:  

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 er det sidste felt i ovenstående output, selvom det ikke viser en feltoverskrift.

Hvordan flyttes data fra det aktive niveau til cloudniveauet?

• En proces kaldet dataflytning er ansvarlig for at undersøge filer i et MTree, der findes på det aktive niveau.
• Dataflytning starter med at oprette et øjebliksbillede af alle MTrees, der er konfigureret til dataflytning.
• Hver fil har en ændringstid, der gemmer sidste gang en fil blev skrevet til.
• Hvis en fil tidligere er migreret til cloudniveauet, angives et ekstra tidsfelt, der kaldes et placeringstidspunkt. Placeringstidspunktet gemmer den dato og det klokkeslæt, hvor filen blev migreret til cloudniveauet. Hvis placeringstiden er indstillet, bruges dette i stedet for ændringstiden. Dette er for at undgå, at en fil konstant migreres tilbage til cloudniveauet, hvis en fil tilbagekaldes (da tilbagekaldelse af en fil ikke ændrer dens ændringstid).
• De snapshots, der er oprettet ovenfor, krydses af dataflytning.
• Hvis den fil, der undersøges, har nået en defineret tærskelværdi som fastsat i dataflytningspolitikken for det pågældende MTree, undersøges filen for at fastslå, hvilke data i filen der skal migreres fra det aktive niveau til cloudniveauet. Der er angivet en dataflytningspolitik pr. MTree.
• De entydige segmenter for den valgte fil skrives eller kopieres til cloudniveauet. 
• Når de unikke segmenter er kopieret, bekræftes filen ved at læse dem op for at sikre, at migreringen lykkedes.
• Når filen er blevet bekræftet, opdateres metadataene, så de afspejler, at filen nu befinder sig på cloudniveauet.
• Dataflytningsprocessen kan planlægges til at køre med en bestemt frekvens eller kan startes manuelt.

Når dataflytning startes, hvilke faser er der, og hvilke handlinger udfører hver fase?

• Der er tre faser forbundet med dataflytning, kopieringsfasen, bekræftelsesfasen og installationsfasen.
• Kopieringsfasen er ansvarlig for at identificere segmenter, der skal kopieres til skyen, og derefter migrere disse segmenter til skyen.
• Når kopieringsfasen starter, er det sky- eller objektlagring, og den bruges, da kopieringsfasen kopierer de segmenter, der er identificeret fra det aktive niveau til cloudniveauet.
• Bekræftelsesfasen er ansvarlig for at sikre, at en fils segmenter blev migreret til skyen.
• Installationsfasen er ansvarlig for opdatering af metadataene vedrørende fil, der blev migreret, for at vise, at den nu ligger på sky- eller objektlagring.
• Hver fil skal fuldføre alle tre faser, for at dataflytning kan anses for vellykket for den pågældende fil. Indtil installationsfasen er fuldført for en fil, forbliver filen derfor på det aktive niveau.

Hvilke dataflytningspolitikker er tilgængelige?

• Dataflytningspolitikker kan være en af følgende:   
  • Aldersgrænse: Hvis en filplacering eller ændringstid er længere end den angivne aldersgruppe, vælges den til migrering til cloudniveauet.
  • Aldersgruppe: Hvis en filplacering eller ændringstid falder inden for et bestemt interval, vælges den til migrering til cloudniveauet.
  • Definition af anvendelse: Programmet til sikkerhedskopiering angiver, om en fil skal vælges til migrering til cloudniveauet.
• Politikker udelukker hinanden, dvs. et MTree kan kun have én politik angivet ad gangen.

Hvordan kan en dataflytningspolitik indstilles på et MTree?

• Kommandoen nedenfor kan bruges. F.eks.:   

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

Hvilke dataflytningspolitikker er allerede konfigureret?

• Kommandoen nedenfor viser en liste over, hvilke MTrees der har fået tildelt politikker for dataflytning. F.eks.:   

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
-----------------   ----------------------   ---------   -----------

Hvordan fungerer en appadministreret dataflytningspolitik?

• Dataflytningspolitikken for det pågældende MTree er indstillet til app-administreret. Dette gøres enten manuelt, eller sikkerhedskopieringsprogrammet udfører dette ved hjælp af Data Domain REST API-grænsefladen.
• Sikkerhedskopieringsprogrammet skal være LTR-opmærksomt.
• Sikkerhedskopieringsprogrammet skal bruge DD Boost, og versionen af DD Boost skal være LTR-kompatibel og kompatibel.
• Ved hjælp af DD Boost-biblioteket/-API'en angiver sikkerhedskopieringsprogrammet placeringstiden for den fil, der skal migreres til cloudniveauet, til en særlig værdi, der angiver, at næste gang dataflytning køres, skal filen migreres til clouden.
• Når dataflytning kører på Data Domain-systemet, kontrolleres placeringstiden, og hvis den er indstillet til specialværdien, som nævnt ovenfor, migrerer den filen til skyen.

Hvordan kan dataflytning startes manuelt?

• Kommandoen nedenfor kan bruges, for eksempel:   

data-movement start

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

Hvordan kan dataflytning overvåges?

• Kommandoen nedenfor kan bruges til at kontrollere status for dataflytning. F.eks.:   

data-movement status

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

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

• Hvis dataflytning kører, kan kommandoen nedenfor bruges, for eksempel:   

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

Hvordan kan dataflytning stoppes?

• Kommandoen nedenfor kan bruges. F.eks.:   

data-movement stop 

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

Hvis der er mere end én cloudenhed, kan dataflytning så køre parallelt til begge cloudenheder?

• Nej. Grundlæggende kan dataflytning kun migrere data til én cloudenhed ad gangen.

Hvordan konfigureres LTR?

• Dette er en oversigt på højt niveau, se den detaljerede proces i DDOS-administrationsvejledningen.
• Tilføj det relevante CLOUDTIER_CAPACITY license.
• Angiv systemets adgangsudtryk, hvis det ikke allerede er angivet.
• Aktivér cloud-funktionen.
• Tilføj metadatalageret for cloudniveauet.
• Konfigurer en cloudprofil eller -profil for den relevante leverandør af cloud- eller objektstorage.
• Tilføj en cloudenhed.
• Konfigurer en dataflytningspolitik for MTree eller MTrees, der kræver lagring af data i cloudmiljøet.
• Start dataflytning manuelt, eller vent på, at en automatisk eller planlagt dataflytning starter.

Kan en cloudenhed slettes? Hvis ja, hvordan?

• Advarsel: Dette ødelægger alle data, der opbevares på skyenheden, og dataene kan derfor ikke gendannes, så fortsæt med forsigtighed.
• Se afsnittet i dette knowledge base-dokument med titlen "Hvordan finder en bruger ud af, hvilket niveau en fil er placeret på" for at forstå, hvilke filer der findes på den cloudenhed, der skal slettes.
• Disse filer skal enten slettes, hvis de ikke længere er nødvendige, eller kaldes tilbage til det aktive niveau, hvis de skal bevares.
• Hvis filer skal gemmes, skal du sørge for, at alle filer tilbagekaldes, før du fortsætter.
• Der bør ikke være nogen filer tilbage på cloudenheden, som slettes.
• Nulstil eventuelle dataflytningspolitikker for det MTree eller de MTrees, der bruger denne cloudenhed.
• Deaktiver filsystemet.
• Slet cloudenheden. Dette markerer skyenheden i en DELETE_PENDING tilstand, som er som designet.
• Aktivér filsystemet.
• Når filsystemet er startet, begynder det asynkront at slette alle objekter i skyen eller objektlagringsudbyderen, der blev brugt af denne skyenhed. Når alle objekterne er slettet, slettes de buckets, som denne cloudenhed brugte, også. Hvis der er mange objekter, kan cloudenheden forblive i en DELETE_PENDING tilstand i længere tid.
• Når alle objekter og buckets er blevet fjernet, forsvinder cloudenheden fra listen over cloudenheder.

Hvad sker der, hvis en cloudenhed ikke slettes, fordi objektlageret ikke længere er tilgængeligt, eller der er et forbindelsesproblem?

• Kontakt Dell Support for at få yderligere hjælp.

Kan LTR og udvidet fastholdelse (ER) konfigureres på det samme system?

• Nej. ER og LTR udelukker hinanden.

Hvordan frigøres eller renses data fra cloudniveauet?

• Dette fungerer på samme måde som filer, der findes på det aktive niveau
• Når en fil når opbevaringsperioden, slettes den fra filsystemets navneområde.
• Cloudniveaurensning er planlagt til at køre. Som standard køres rensning på cloudniveau efter hver fjerde aktive niveaurensningssession.
• For at oprydning på Cloud Tier kan køre, skal den cloudenhed, der rengøres, have mindst 1 % overflødige eller rengørbare data for at starte. Dette skyldes, at enhver cloud-netværkstrafik kan blive opkrævet, så DDR forsøger at begrænse netværkstrafikken, hvor det er muligt.
• Cloudniveauet kører som standard med 50 % rensningsbegrænsning.
• Både planen for rengøring på cloudniveau og rengøringsbegrænsningen kan ændres.
• Rensning på aktivt niveau og på cloudniveau kan ikke køre parallelt.
• Hvis der kører automatisk eller planlagt rensning på Cloud Tier, tilsidesættes det af aktiv niveaurensning.
• Hvis der påbegyndes en manuel rensning på cloudniveau, kan den aktive niveaurensning ikke starte, før rensningen på cloudniveau er fuldført.
• Hvis et cloudniveau har to cloudenheder, renses der kun én cloudenhed pr. planlagt eller automatisk rensning på cloudniveau. Cloud-enhederne betjenes på en round-robin måde fra et cloud-tier-rengøringsperspektiv. Når der er to cloudenheder, er det et krav at angive den cloudenhed, der skal renses, når der køres fra kommandolinjen (navn på cloud clean start <unit)>
• Hvis en rensning på et cloudniveau ikke starter på en cloudenhed, f.eks. fordi den aktuelle cloudenhed ikke har nok data, der kan renses, til at det kan anses for at være umagen værd, forsøger systemet automatisk at rydde op fra den næste cloudenhed.
• Du kan finde flere oplysninger om rensning på Cloud Tier i følgende artikel Data Domain: En introduktion til langsigtet opbevaring, rensning på cloudniveau og affaldsindsamling på Data Domain Restorers (DDRs)

Hvordan kommer en manuel rengøring på cloudniveau i gang?

• Kommandoen nedenfor kan bruges. F.eks.:   

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.

Hvordan kan en rensning på cloudniveau overvåges?

• Kommandoen nedenfor kan bruges til at kontrollere, om cloudrensning kører. F.eks.:   

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.

• Hvis cloud clean kører, kan det overvåges ved hjælp af kommandoen nedenfor:

cloud clean watch

Kan aktiv niveaurensning køre samtidig med rensning på cloudniveau?

• Nej. Både aktiv niveaurensning og rensning på cloudniveau bruger begge de samme fælles interne delte datastrukturer, som kræver eksklusiv adgang.

Hvordan kan en plan for rensning på cloudniveau vises eller ændres?

• Kommandoen nedenfor kan bruges til at vise den aktuelle plan for rensning i skyen. F.eks.:   

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.

• Kommandoen nedenfor bruges til at ændre en tidsplan. F.eks.:  

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.

Hvordan kan gashåndtaget til rensning på cloudniveau ændres eller vises?

• Som standard er gashåndtaget for rengøring på cloudniveau den er indstillet til 50 %. Kommandoen nedenfor kan bruges til at nulstille den til standardgasprocenten.

cloud clean throttle reset

• Kommandoen nedenfor kan bruges til at vise den aktuelle skyrensningsgas. F.eks.:   

cloud clean throttle show

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

• Kommandoen nedenfor kan bruges til at ændre rengøringsgashåndtaget. F.eks.:   

cloud clean throttle set <value> 

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

Hvad styrer gasspjældet til rengøring af skyniveau?

• Begrænsningen til rensning på cloudniveau fungerer på samme måde som den aktive niveaurensningsbegrænsning, idet begrænsningen begrænser de I/O- og CPU-ressourcer, som rensning på cloudniveau kan bruge.
• Det begrænser ikke netværksoverførslen.

Hvorfor frigør/sletter rensning på cloudniveau ikke så mange objekter som forventet?

• Rengøring betragtes altid som et skøn. Se følgende videnbaseartikler, der beskriver aspekter omkring dette emne, da de også gælder for data, der findes på cloudniveauet:  

• Derudover er der yderligere specifikke detaljer om, hvordan cloudniveauet implementeres.
• Forskellige metoder er blevet implementeret for at begrænse mængden af netværkstrafik til en cloud- eller objektlagringsudbyder, da dette kan medføre tilknyttede omkostninger.
• Som nævnt ovenfor kræves mindst 1% af dataafgang for at ren kan køre.
• Når filsystemet gennemløbes for at søge efter filer, der overholder dataflytningspolitikken, undersøges kun lokale kopier af metadataene.
• Alle segmenter, der opbevares på sky- eller objektlager, og som viser sig kun at indeholde brugerdata, markeres til asynkron sletning.
• Alle segmenter, der indeholder mindst ét live-segment, springes over, fordi DDOS ikke ønsker at kombinere små mængder data på grund af den involverede netværkstrafik.

Hvordan finder en bruger ud af, hvilket niveau en fil er placeret på?

• Brug kommandoen nedenfor for at få et eksempel på det output, der genereres af denne kommando:  

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

Kan en fil læses eller åbnes direkte, efter at den er blevet migreret til cloudniveauet?

• Dette afhænger af den version af DDOS, der bruges sammen med cloud-udbyderen:   

• Direkte gendannelse af filer er mulig uden først at skulle tilbagekalde en fil. Dette er kendt som funktionen 'direkte gendannelse' og er begrænset til ECS som sky- eller objektudbyder.
• Du kan finde flere oplysninger om "direkte gendannelse" fra Avatar i hvidbogen "Detaljeret gendannelse på Avamar- eller filniveauniveau fra Data Domain Cloud Tier".
• Avamar GLR/FLR-funktionen (direkte gendannelse) kræver som minimum en kombination af Avamar 18.1 eller DDOS 6.1 med ECS som cloududbyder. 

• En fil skal først tilbagekaldes. Det vil sige, at dataene migreres tilbage fra cloudniveauet til det aktive niveau.
• Filen skal tilbagekaldes fra cloudniveauet til det aktive niveau ved hjælp af kommandoen til tilbagekaldelse af data for at tillade læsning fra en fil eller ændring af en fil, der findes på cloudniveauet.
• Ethvert forsøg på at læse eller ændre en fil, der er placeret på Cloud Tier, resulterer i, at der returneres en I/O-fejl til den, der forsøger at læse den fil, som er sikkerhedskopieringsprogrammet, hvis filen ikke tilbagekaldes først.
• Nogle cloud-baserede sikkerhedskopieringsprogrammer kan starte filtilbagekaldelser, ellers skal filer tilbagekaldes manuelt.
• Siden DDOS 7.7+:
  • Direkte gendannelse gør det muligt for ikke-integrerede programmer at læse filer direkte fra Cloud Tier uden at gå gennem Active Tier.
  • De vigtigste overvejelser, når du vælger at bruge direkte gendannelse, omfatter:
  • Direkte gendannelse kræver ikke et integreret program og er transparent for ikke-integrerede programmer.
  • Læsning fra cloudniveauet kræver ikke, at du først kopierer til det aktive niveau.
  • Histogrammer og statistikker er tilgængelige til sporing af direkte læsninger fra cloudniveauet.
  • Direkte gendannelse understøttes kun for AWS - og ECS-cloududbydere .
  • Programmer oplever ventetid på cloudniveau.
  • Læsning direkte fra cloud-niveauet er ikke båndbreddeoptimeret.

Hvor mange filer kan tilbagekaldes parallelt?

• DDOS 6.0 understøtter fire filer, der skal sættes i kø og tilbagekaldes parallelt.
• DDOS 6.1 understøtter 1000 filer, der skal sættes i kø, og 4 filer i tilbagekaldelseskøen, der skal tilbagekaldes parallelt.

I henhold til Data Domain Admin Guide 7.9:

• Systemer med 256 GB hukommelse eller mere kan tilbagekalde op til 16 filer ad gangen.
• Systemer med mindre end 256 GB hukommelse kan tilbagekalde op til otte filer ad gangen.
• DDVE-forekomster kan tilbagekalde op til fire filer ad gangen.

Hvordan kan en fil tilbagekaldes?

• En fil kan tilbagekaldes ved hjælp af kommandoen nedenfor. F.eks.:   

data-movement recall path <path-name> 

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

Hvordan kan alle filerne i et MTree tilbagekaldes?

• Afhængigt af DDOS-versionen kan alle filerne i skyen tilbagekaldes ved at køre en enkelt kommando som nedenfor:   

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

• Se "Dell DDOS Command Reference Guide" for din DDOS-version for at få flere oplysninger

Hvordan kan en tilbagekaldelsesoperation overvåges?

• En tilbagekaldelse kan overvåges ved hjælp af kommandoen nedenfor, eller hvis en bestemt fil er påkrævet. F.eks.:   

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 

Medfører omdøbning af en fil, at filen tilbagekaldes fra cloudniveauet til det aktive niveau?

• Nej. Hvis en fil omdøbes, forbliver den på sit nuværende niveau.

Hvilke cloududbydere understøttes?

•  Afhængigt af den anvendte DDOS-version understøtter DDOS følgende cloud-udbydere:   
• Amazon Web Services (AWS).
• Microsoft Azure-cloud
• Dell Elastic Cloud Storage (ECS)
• Virtustream
• Se DDOS-administrationsvejledningen for at få flere oplysninger.

Understøttes kryptering på cloudniveauet, og skal det licenseres?

• Ja, kryptering understøttes på cloudniveauet. Dette kræver ikke en ekstra licens i modsætning til kryptering på aktivt niveau.
• Dette kan konfigureres, når skyfunktionen aktiveres eller ændres efter. 
• I skrivende stund er det kun den integrerede nøglehåndtering, der understøttes til kryptering på cloudniveau, og kun én krypteringsalgoritme kan bruges til LTR-systemet bredt.

Hvilke buckets oprettes i cloud-udbyderens objektlager?

• DDOS opretter tre buckets
• Spandene slutter med snoren:

'-d0'

'-c0' 

'-m0'

• Den bucket, der slutter med strengen '-d0', bruges til datasegmenter.
• Spanden, der slutter med strengen '-c0', bruges til konfigurationsdata.
• Spanden, der slutter med strengen '-m0', bruges til metadata.
• Før DDOS 6.1 bruges kun den bucket, der slutter '-d0', mens der oprettes tre bucket. Alle tre spande er dog nødvendige, så sørg for, at de ikke fjernes.

Er det muligt at bruge eksisterende bucketnavne, der tidligere blev oprettet?

• Nej, det er ikke muligt.

Ud over hardwarekravene er der så andre obligatoriske krav, der er nødvendige, før LTR konfigureres?

• Ja
• Hvis ECS anvendes, er en belastningsbalancer et obligatorisk krav. Uden en Load Balancer kommunikerer Data Domain med ECS på en enkelt node og afbryder forbindelsen, når der foretages flere anmodninger.
• Et 1 GB netværk mellem DDR og cloud-udbyderen

Er certifikater påkrævet, og i bekræftende fald, hvilke certifikater skal anvendes?

• Dette afhænger af det objekt eller den cloud-udbyder, der bruges, og også konfigurationen.
• AWS, Virtustream eller Azure kræver et certifikat. Se DDOS-administrationsvejledningen for at få flere oplysninger.
• Hvis ECS er konfigureret ved hjælp af et http-slutpunkt, kræves der ikke et certifikat.
• Hvis ECS konfigureres ved hjælp af et https-slutpunkt, kræves der et certifikat. Da en belastningsbalancer er et obligatorisk krav, er det krævede certifikat fra lånebalancesystemet snarere end ECS-systemet. Kontakt din Load Balancer-udbyder for at få yderligere oplysninger.
• Når du importerer certifikatet, skal det være i PEM-format. Nogle udbydere leverer ikke certifikatet i PEM-formatet, så det skal konverteres inden import.

Hvilke replikeringstopologier understøttes?

• Samlingsreplikering understøttes _ikke_ .
• Biblioteksreplikering understøttes, men den kan kun bruges af MTree '/data/col1/backup', men dette MTree understøtter ikke dataflytning.
• Replikering af MTree understøttes fuldt ud.
• MFR- eller VSR-replikering understøttes fuldt ud.

Hvad skal man overveje, når man konfigurerer/initialiserer/geninitialiserer replikering på et system, hvor der allerede er konfigureret LTR?

• Kildesystemet tager et snapshot af MTree (dette snapshot indeholder oplysninger om filer på aktive niveauer og cloudniveauer).
• Kildesystemet replikerer snapshottet til det aktive niveau i destinationssystemet.
• Først når snapshottet er replikeret helt, vises det på destinationssystemet (hvorefter filer bliver tilgængelige i destinationssystemets filnavneområde).
• Først efter at filer er eksponeret, kan dataflytning køres på destinationen (forudsat at den er konfigureret til LTR).
• Det betyder, at hvis destinationsniveauet Active Tier ikke er stort nok til at indeholde et komplet snapshot fra kilden, vises snapshottet aldrig, og replikering kan ikke fuldføre initialiseringen.

Hvad skal overvejes, hvis MFR- eller VSR-replikering konfigureres på et system, hvor LTR allerede er konfigureret?

• Hvis data, der allerede er migreret til cloudniveauet på en kilde-DDR, skal replikeres, tilbagekaldes de automatisk fra cloududbyderen til det aktive niveau, før de kan sendes over netværket.
• Tilbagekaldelse af filer fra cloudniveauet til det aktive niveau kan medføre omkostninger eller forsinkelser.

Hvorfor afspejler Data Domain-kommandooutputtet "filsystem vis plads" ikke den sande størrelse af clouden eller objektlageret?

• På grund af den iboende måde, cloud- eller objektstorage fungerer på, har et Data Domain-system ingen mulighed for at forespørge på den fysiske størrelse på en cloudenhed, da denne kan anses for at være tilsyneladende uendelig.
• DDOS var imidlertid nødt til at udvikle en måde at vise aktuelle brugs-/deduplikeringsstatistikker fra et DDOS-perspektiv.
• Derfor anvendes en af to tilgange:

1. Cloudniveauets størrelse tilpasses CLOUDTIER_CAPACITY license
2. Størrelsen på cloudniveauet vises som et multiplum af aktive niveauenhedsstørrelser for den pågældende modeltype, afhængigt af hvor mange cloudenheder der er konfigureret. Se hardwareinstallationsvejledningen til den pågældende model for at få flere oplysninger om aktive niveaustørrelser.

Hvordan kan filsystemet startes, hvis en cloudenhed ikke er tilgængelig?

• Sørg for, at filsystemet er deaktiveret.
• Deaktiver den cloudenhed, der ikke er tilgængelig, ved hjælp af kommandoen nedenfor:

cloud unit disable <cloud unit name>

• Aktivér filsystemet.

Hvis en cloudenhed er deaktiveret, hvordan kan den så aktiveres?

• Sørg for, at filsystemet er deaktiveret.
• Aktivér cloudenheden ved hjælp af kommandoen nedenfor:

cloud unit enable <cloud unit name>

• Aktivér filsystemet.

Hvorfor findes der stadig filer i filsystemet, der findes på en cloudenhed, der blev slettet?

•  Hvis filer ikke blev fjernet fra et MTree, før en cloudenhed blev slettet, findes filerne fortsat i filsystemnavneområdet.
• Som sådan viser filplaceringsrapporten, at filerne er en del af en slettet skyenhed. F.eks.:  

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

• Filerne kan stadig ses i filsystemets navneområde ved at åbne en CIFS/NFS-deling for dette MTree.
• Filerne kan dog ikke læses, fordi skyenheden, hvor de var placeret, er blevet slettet.
• Derfor er den eneste mulighed at slette disse filer, da deres data, de refererede til, ikke længere eksisterer.

Er det muligt at ændre protokolslutpunktet eller portene for en ECS- eller S3 fleksibel cloud-udbyder, efter at en cloudenhed er blevet oprettet?

• For eksempel kan dette være nødvendigt, hvis du skifter fra http til https eller omvendt migrerer til en ny belastningsbalancer.
• I skrivende stund kan en Data Domain-administrator ikke udføre denne ændring. Denne funktionalitet overvejes i en fremtidig DDOS-udgivelse.
• Dette kan dog udføres af support eller teknik.
• Filsystemet skal deaktiveres for at kunne udføre denne ændring.
• Hvis dette er nødvendigt, udføres al konfiguration uden for Data Domain-systemet først, for når dette er ændret, når filsystemet er aktiveret, forventer det at kunne kommunikere ved hjælp af den opdaterede protokol eller port og læse buckets eller objekter, som det gjorde tidligere.