Data Domain Restorer en bewaren op lange termijn in de cloud: Veelgestelde vragen

In dit artikel worden de meest gestelde vragen behandeld over de configuratie en het gebruik van DDR's (Data Domain Restorers) en langdurige retentie (LTR) of de cloudfunctie.
 

Wat is LTR?

• Met ingang van Data Domain Operating System (DDOS) 6.0 is een nieuwe functie met de naam LTR geïntroduceerd.
• Met LTR kunnen bepaalde modellen DDR's een subset van bestanden of data migreren naar een object of cloudstorage, ook wel een cloudlaag genoemd, van een reeks ondersteunde public of private cloudproviders.
• Om bestanden of data fysiek te migreren naar objectstorage, wordt een dataverplaatsingsproces uitgevoerd op de DDR.
• Om redundante data fysiek vrij te maken van de cloudlaag, wordt een cloudlaagreinigingsproces uitgevoerd op de DDR.
• LTR is een gelicentieerde functie en vereist een CLOUDTIER_CAPACITY license.
• LTR vereist enige lokale storage voor metadata van cloudlagen.

Voor welke DDR-systemen is LTR beschikbaar?
Dit is afhankelijk van de DDOS versie die samen met het systeemmodeltype is geïnstalleerd. De meeste modellen hebben bepaalde hardwarevereisten waaraan vooraf moet worden voldaan om LTR te kunnen configureren. Zie de hardware-installatiehandleiding voor de specifieke modellen samen met de DDOS-beheerhandleiding voor de vereisten.

Welke licentie is vereist voor LTR?

• Aangezien LTR wordt beschouwd als een nieuwe functie van DDOS 6.x en hoger, is een e-licentie vereist. 
• Het type e-licentie dat vereist is, wordt een CLOUDTIER_CAPACITY license. Een voorbeeld van een CLOUDTIER_CAPACITY license is als volgt:

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

Hoe werken de verschillende niveaus?

• Normale DDR's (zonder een LTR-licentie) hebben één laag die bekend staat als de actieve laag.
• De actieve laag is de traditionele opslaglaag op alle 'standaard' DDR's.
• LTR-systemen hebben een tweede storagelaag, ook wel een cloudlaag genoemd.

De maximale grootte van elke laag wordt bepaald door de ondersteunde limieten voor de opgegeven hardwareconfiguratie en DDOS-versie. Raadpleeg de DDOS-beheerhandleiding en de hardwarehandleiding voor het specifieke model in kwestie.

Hieronder ziet u een voorbeeld van een LTR-configuratie met twee lagen, één actieve en één cloud:   

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

Hoe is een cloudlaag gestructureerd?

• Een cloudlaag bestaat uit:   
  • Lokaal bewaarde metadata, opgeslagen op een behuizing als een fysieke DDR wordt gebruikt, of een LUN of apparaat als DDVE wordt gebruikt.
  • Aanbieders van objectstorage
• Beide bovenstaande opties worden gecombineerd tot een cloudeenheid.
• Als er meerdere cloudeenheden zijn geconfigureerd, kunnen deze de lokaal bewaarde metadata delen.
• Er kunnen maximaal twee cloudunits per systeem worden geconfigureerd. Elke cloudeenheid kan worden ingericht door een andere objectstorageprovider.
• Elke cloudeenheid kan zo groot zijn als de maximale grootte van het ondersteunde actieve niveau voor het betreffende DDR-model. Raadpleeg de DDOS-beheerhandleiding voor meer informatie.

Wat gebeurt er tijdens een typische back-uplevenscyclus wanneer LTR is geconfigureerd?

• Alle data worden in eerste instantie naar het actieve niveau geschreven waar ze beginnen te verouderen.
• Kortlevende gegevens die de bewaarperiode bereiken, worden net als bij een normale DDR verlopen/verwijderd.
• Een subset van data die langdurig bewaren vereisen, wordt echter gemigreerd naar de cloudlaag.
• Het bestandssysteem onderhoudt één namespace voor alle lagen, dus wanneer een bestand naar de cloud migreert, verandert de namespace niet en is deze als zodanig redelijk transparant voor de gebruiker of back-uptoepassing.
• Wanneer een bestand dat al naar de cloudlaag is gemigreerd, de retentieperiode bereikt, wordt het net als elk ander bestand verlopen/verwijderd.
• De ruimte die een bestand gebruikte in de cloudlaag wordt niet onmiddellijk teruggewonnen, in plaats daarvan moet de cloudlaag worden opgeschoond.

Hoe worden data gededupliceerd tussen lagen?

• Elke cloudeenheid is een standalone volume, wat betekent dat het een zelfstandige deduplicatie-eenheid is.
• Als gevolg hiervan kunnen data die naar elke cloudeenheid worden geschreven alleen worden gededupliceerd met data in dezelfde cloudeenheid.

Wat is een plaatsingstijd (ook wel ptime genoemd)?

• Aan bestanden en mappen zijn verschillende tijdstempels gekoppeld.
• Een bestand of map heeft bijvoorbeeld een aanmaaktijd, een laatste toegangstijd en een wijzigingstijd.
• DDOS heeft dit verder verbeterd door ook een plaatsingstijd op te nemen. De plaatsingstijd is de datum en tijd waarop het bestand is gemigreerd van de actieve laag naar de cloudlaag.
• Afhankelijk van de DDOS-versie kan de plaatsingstijd worden bekeken wanneer wordt onderzocht op welke laag een bestand zich bevindt. Als het bestand is gemigreerd naar de cloudlaag, wordt de plaatsingstijd weergegeven, bijvoorbeeld:  

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 is het laatste veld in de bovenstaande uitvoer, hoewel er geen veldheader wordt weergegeven.

Hoe worden data verplaatst van de actieve laag naar de cloudlaag?

• Een proces dat dataverplaatsing wordt genoemd, is verantwoordelijk voor het onderzoeken van bestanden binnen een MTree die zich in de actieve laag bevinden.
• Dataverplaatsing begint met het maken van een snapshot van alle MTrees die zijn geconfigureerd voor dataverplaatsing.
• Elk bestand heeft een wijzigingstijd die de laatste keer dat een bestand is geschreven opslaat.
• Als een bestand eerder naar de cloudlaag is gemigreerd, wordt een extra tijdveld ingesteld dat plaatsingstijd wordt genoemd. In de plaatsingstijd worden de datum en tijd opgeslagen waarop het bestand naar de cloudlaag is gemigreerd. Als de plaatsingstijd is ingesteld, wordt deze gebruikt in plaats van de wijzigingstijd. Dit is om te voorkomen dat een bestand voortdurend wordt teruggemigreerd naar de cloudlaag als een bestand wordt teruggehaald (omdat het terughalen van een bestand de wijzigingstijd niet verandert).
• De snapshots die hierboven zijn gemaakt, worden doorkruist door dataverplaatsing.
• Als het onderzochte bestand een bepaalde drempelwaarde heeft bereikt, zoals vastgesteld door het beleid inzake gegevensverplaatsing voor de MTree in kwestie, wordt het bestand onderzocht om vast te stellen welke gegevens in dat bestand moeten migreren van de actieve laag naar de cloudlaag. Per MTree wordt een beleid voor dataverplaatsing ingesteld.
• De unieke segmenten voor het geselecteerde bestand worden geschreven of gekopieerd naar de cloudlaag. 
• Nadat de unieke segmenten zijn gekopieerd, wordt het bestand geverifieerd door ze terug te lezen om er zeker van te zijn dat de migratie is geslaagd.
• Nadat het bestand is geverifieerd, worden de metadata bijgewerkt om aan te geven dat het bestand zich nu op de cloudlaag bevindt.
• Het dataverplaatsingsproces kan worden gepland om met een bepaalde frequentie te worden uitgevoerd of kan handmatig worden gestart.

Wanneer dataverplaatsing wordt gestart, welke fasen zijn er dan en welke acties voert elke fase uit?

• Er zijn drie fasen verbonden aan dataverplaatsing: de kopieerfase, de verificatiefase en de installatiefase.
• De kopieerfase is verantwoordelijk voor het identificeren van segmenten die naar de cloud moeten worden gekopieerd en vervolgens het migreren van deze segmenten naar de cloud.
• Zodra de kopieerfase begint, is het cloud- of objectopslag en wordt deze gebruikt als de kopieerfase om de geïdentificeerde segmenten van de actieve laag naar de cloudlaag te kopiëren.
• De verificatiefase is verantwoordelijk om ervoor te zorgen dat de segmenten van een bestand met succes naar de cloud zijn gemigreerd.
• De installatiefase is verantwoordelijk voor het bijwerken van de metadata met betrekking tot het bestand dat is gemigreerd, om aan te geven dat het zich nu in de cloud of objectstorage bevindt.
• Elk bestand moet alle drie de fasen voltooien om ervoor te zorgen dat de gegevensverplaatsing voor dat bestand als succesvol wordt beschouwd. Daarom blijft het bestand in de actieve laag totdat de installatiefase voor een bestand is voltooid.

Welk beleid voor dataverplaatsing is beschikbaar?

• Het beleid voor dataverplaatsing kan een van de volgende zijn:   
  • Leeftijdsdrempel: Als de plaatsings- of wijzigingstijd van een bestand langer is dan de ingestelde leeftijdscategorie, wordt het geselecteerd voor migratie naar de cloudlaag.
  • Leeftijdsgroep: Als de plaatsings- of wijzigingstijd van een bestand binnen een bepaald bereik valt, wordt het geselecteerd voor migratie naar de cloudlaag.
  • Applicatiedefinitie: De back-upapplicatie geeft aan of er een bestand moet worden geselecteerd voor migratie naar de cloudlaag.
• Beleidsregels sluiten elkaar uit, dat wil zeggen dat een MTree slechts één beleid tegelijk kan hebben.

Hoe kan een beleid voor gegevensverplaatsing worden ingesteld op een MTree?

• De onderstaande opdracht kan worden gebruikt. Bijvoorbeeld:   

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

Welk beleid voor dataverplaatsing is al geconfigureerd?

• De onderstaande opdracht biedt een lijst van aan MTrees toegewezen beleid voor dataverplaatsing. Bijvoorbeeld:   

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

Hoe werkt een door de app beheerd beleid voor gegevensverplaatsing?

• Het beleid voor dataverplaatsing voor de betreffende MTree is ingesteld op app-managed. Dit wordt handmatig gedaan of de back-upapplicatie voert dit uit met behulp van de Data Domain REST API-interface.
• De back-upapplicatie moet LTR-aware zijn.
• De back-upapplicatie moet DD Boost gebruiken en de versie van DD Boost moet LTR-bewust en compatibel zijn.
• Met behulp van de DD Boost-bibliotheek/API stelt de back-upapplicatie de plaatsingstijd in voor het bestand dat moet worden gemigreerd naar de cloudlaag is ingesteld op een speciale waarde die aangeeft dat de volgende keer dat dataverplaatsing wordt uitgevoerd, het bestand naar de cloud moet worden gemigreerd.
• Wanneer dataverplaatsing wordt uitgevoerd op het Data Domain systeem, wordt de plaatsingstijd gecontroleerd en als deze is ingesteld op de speciale waarde, zoals hierboven vermeld, wordt het bestand naar de cloud gemigreerd.

Hoe kan de verplaatsing van gegevens handmatig worden gestart?

• De onderstaande opdracht kan bijvoorbeeld worden gebruikt:   

data-movement start

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

Hoe kan de verplaatsing van data worden gemonitord?

• De onderstaande opdracht kan worden gebruikt om de status van dataverplaatsing te controleren. Bijvoorbeeld:   

data-movement status

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

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

• Als er data movement wordt uitgevoerd, kan de onderstaande opdracht worden gebruikt, bijvoorbeeld:   

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

Hoe kan dataverplaatsing worden gestopt?

• De onderstaande opdracht kan worden gebruikt. Bijvoorbeeld:   

data-movement stop 

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

Als er meer dan één cloudeenheid is, kan dataverplaatsing dan parallel naar beide cloudeenheden worden uitgevoerd?

• Nee. In wezen kan dataverplaatsing slechts naar één cloudeenheid tegelijk worden gemigreerd.

Hoe wordt LTR geconfigureerd?

• Dit is een overzicht op hoog niveau, zie het gedetailleerde proces in de DDOS-beheerhandleiding.
• Voeg de juiste CLOUDTIER_CAPACITY license.
• Stel de systeemwachtwoordzin in als deze nog niet is ingesteld.
• Schakel de cloudfunctie in.
• Voeg de metadataopslag voor de cloudlaag toe.
• Configureer een cloudprofiel of -profiel voor de juiste cloud- of objectstorageleverancier.
• Voeg een cloudeenheid toe.
• Configureer een beleid voor gegevensverplaatsing voor de MTree of MTrees waarvoor gegevens in de cloud moeten worden opgeslagen.
• Start de gegevensverplaatsing handmatig of wacht tot een automatische of geplande gegevensverplaatsing wordt gestart.

Kan een cloudeenheid worden verwijderd? Zo ja, hoe?

• Let op: Dit vernietigt alle data op de cloudeenheid, waardoor de data niet kunnen worden hersteld, dus ga voorzichtig te werk.
• Zie de sectie in dit Knowledge Base-document met de titel "Hoe weet een gebruiker op welke laag een bestand zich bevindt" om te begrijpen welke bestanden zich bevinden op de cloudeenheid die wordt verwijderd.
• Deze bestanden moeten worden verwijderd als ze niet langer nodig zijn, of worden teruggeroepen naar de actieve laag als ze moeten worden bewaard.
• Als bestanden moeten worden bewaard, zorg er dan voor dat alle bestanden zijn teruggehaald voordat u verdergaat.
• Er mogen geen bestanden op de cloudeenheid achterblijven die worden verwijderd.
• Reset alle beleidsregels voor dataverplaatsing voor de MTree of MTrees die deze cloudeenheid gebruiken.
• Schakel het bestandssysteem uit.
• Verwijder de cloudeenheid. Dit markeert de cloudeenheid in een DELETE_PENDING staat, die is zoals ontworpen.
• Schakel het bestandssysteem in.
• Zodra het bestandssysteem is gestart, begint het asynchroon met het verwijderen van alle objecten in de cloud of objectstorageprovider die door deze cloudeenheid werden gebruikt. Zodra alle objecten zijn verwijderd, worden de buckets die deze cloudeenheid heeft gebruikt, ook verwijderd. Als er veel objecten zijn, kan de cloudeenheid gedurende langere tijd in een DELETE_PENDING status blijven.
• Zodra alle objecten en buckets met succes zijn verwijderd, verdwijnt de cloudeenheid uit de lijst met cloudeenheden.

Wat gebeurt er als een cloudeenheid niet kan worden verwijderd omdat de objectstorage niet meer beschikbaar is of als er een connectiviteitsprobleem is?

• Neem contact op met Dell Support voor verdere hulp.

Kunnen LTR en Extended Retention (ER) op hetzelfde systeem worden geconfigureerd?

• Nee. ER en LTR sluiten elkaar uit.

Hoe worden data vrijgemaakt of opgeschoond uit de cloudlaag?

• Dit werkt op een vergelijkbare manier als bestanden op de actieve laag
• Zodra een bestand de retentieperiode heeft bereikt, wordt het verwijderd uit de naamruimte van het bestandssysteem.
• Het opschonen van cloudlagen is gepland om te worden uitgevoerd. Standaard wordt het opschonen van de cloudlaag uitgevoerd na elke vier actieve opschoonsessies.
• Om het opschonen van cloudlagen te kunnen uitvoeren, moet de cloudeenheid die wordt opgeschoond ten minste 1% overbodige of opschoonbare data bevatten om te kunnen beginnen. Dit komt omdat elk netwerkverkeer in de cloud in rekening kan worden gebracht, dus de DDR probeert het netwerkverkeer waar mogelijk te beperken.
• Cloud tier wordt uitgevoerd met een standaardinstelling van 50% opschoningsbeperking.
• Zowel het schema voor het opschonen van de cloudlaag als de opschoningsbeperking kunnen worden gewijzigd.
• Het opschonen van actieve lagen en cloudlagen kan niet parallel worden uitgevoerd.
• Als automatische of geplande cloudlaagopschoning wordt uitgevoerd, wordt dit voorkomen door actieve laagopschoning.
• Als een handmatige opschoning van de cloudlaag wordt gestart, kan de opschoning van de actieve laag pas worden gestart nadat het opschonen van de cloudlaag is voltooid.
• Als een cloudlaag twee cloudeenheden heeft, wordt slechts één cloudeenheid opgeschoond per geplande of automatische cloudlaagopschoning. De cloud unit's worden op een round-robin-manier bediend vanuit het perspectief van het opschonen van cloudlagen. Wanneer er twee cloudeenheden zijn, is het een vereiste om de cloudeenheid op te geven die moet worden opgeschoond wanneer deze wordt uitgevoerd vanaf de opdrachtregel (naam> cloudschone starteenheid<)
• Als het opschonen van een cloudniveau niet begint op een cloudeenheid, bijvoorbeeld omdat de huidige cloudeenheid niet genoeg wisbare gegevens heeft om het de moeite waard te achten, probeert het systeem automatisch op te schonen vanaf de volgende cloudeenheid.
• Zie het volgende artikel Data Domain voor meer informatie over het opschonen van cloudlagen: Een inleiding tot langdurig bewaren, opschonen van cloudlagen en garbage collection op DDR's (Data Domain Restorers)

Hoe wordt een handmatige opschoning van de cloudlaag gestart?

• De onderstaande opdracht kan worden gebruikt. Bijvoorbeeld:   

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.

Hoe kan een opschoning van een cloudlaag worden gecontroleerd?

• De onderstaande opdracht kan worden gebruikt om te controleren of cloud cleaning wordt uitgevoerd. Bijvoorbeeld:   

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.

• Als cloud clean wordt uitgevoerd, kan dit worden gecontroleerd met behulp van de onderstaande opdracht:

cloud clean watch

Kan het opschonen van actieve lagen gelijktijdig worden uitgevoerd met het opschonen van cloudlagen?

• Nee. Zowel het opschonen van de actieve laag als het opschonen van de cloudlaag maken beide gebruik van dezelfde gemeenschappelijke interne gedeelde datastructuren waarvoor exclusieve toegang vereist is.

Hoe kan een schema voor het opschonen van cloudlagen worden weergegeven of gewijzigd?

• De onderstaande opdracht kan worden gebruikt om het huidige cloudopschoonschema weer te geven. Bijvoorbeeld:   

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.

• De onderstaande opdracht wordt gebruikt om een planning te wijzigen. Bijvoorbeeld:  

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.

Hoe kan de beperking voor het opschonen van cloudlagen worden gewijzigd of weergegeven?

• Standaard is de beperking voor het opschonen van cloudlagen ingesteld op 50%. De onderstaande opdracht kan worden gebruikt om het terug te zetten naar het standaard gaskleppercentage.

cloud clean throttle reset

• De onderstaande opdracht kan worden gebruikt om de huidige cloudopschoningslimiet weer te geven. Bijvoorbeeld:   

cloud clean throttle show

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

• Het onderstaande commando kan worden gebruikt om de reinigingsgashendel te wijzigen. Bijvoorbeeld:   

cloud clean throttle set <value> 

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

Wat regelt de beperking voor het opschonen van cloudlagen?

• De throttle voor het opschonen van cloudlagen werkt op dezelfde manier als de actieve tieropschoningsthrottle, in die zin dat throttling de I/O- en CPU-bronnen beperkt die de cloudtieropschoning kan gebruiken.
• De netwerkoverdracht wordt niet afgeremd.

Waarom worden er niet zoveel objecten vrijgemaakt/verwijderd als verwacht bij het opschonen van de cloudlaag?

• Schoonmaak wordt altijd als een schatting beschouwd. Zie de volgende KB-artikelen waarin aspecten rond dit onderwerp worden beschreven, aangezien ze ook van toepassing zijn op data die zich op de cloudlaag bevinden:  

• Daarnaast zijn er verdere specifieke details met betrekking tot de manier waarop de cloudlaag wordt geïmplementeerd.
• Er zijn verschillende methoden geïmplementeerd om de hoeveelheid netwerkverkeer naar een cloud- of objectopslagprovider te beperken, omdat dit kosten met zich mee kan brengen.
• Zoals hierboven vermeld, is minimaal 1% gegevensverloop vereist om clean te kunnen uitvoeren.
• Wanneer het bestandssysteem wordt doorzocht om te zoeken naar bestanden die voldoen aan het beleid voor gegevensverplaatsing, worden alleen lokale kopieën van de metadata onderzocht.
• Alle segmenten in cloud- of objectstorage die alleen gebruikersdata blijken te bevatten, zijn gemarkeerd voor asynchrone verwijdering.
• Segmenten die ten minste één live segment bevatten, worden overgeslagen omdat DDOS geen kleine hoeveelheden data wil combineren vanwege het netwerkverkeer dat ermee gemoeid is.

Hoe weet een gebruiker op welke laag een bestand zich bevindt?

• Gebruik de onderstaande opdracht voor een voorbeeld van de uitvoer die door deze opdracht wordt gegenereerd:  

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 een bestand direct worden gelezen of geopend nadat het is gemigreerd naar de cloudlaag?

• Dit is afhankelijk van de versie van DDOS die samen met de cloudprovider wordt gebruikt:   

• Het direct terugzetten van bestanden is mogelijk zonder dat u eerst een bestand hoeft terug te halen. Dit staat bekend als de functie 'direct herstel' en is beperkt tot ECS als cloud- of objectprovider.
• Raadpleeg voor meer informatie over "direct herstel" van Avamar de whitepaper "Avamar Granular or File Level Restore from Data Domain Cloud Tier".
• De functie Avamar GLR/FLR (Direct Restore) vereist een minimale combinatie van Avamar 18.1 of DDOS 6.1 met ECS als cloudprovider. 

• Een bestand moet eerst worden opgehaald. Dat wil zeggen dat de data terug zijn gemigreerd van de cloudlaag naar de actieve laag.
• Het bestand moet worden teruggehaald van de cloudlaag naar de actieve laag met behulp van de opdracht voor het terugroepen van gegevens verplaatsen om elk bestand te kunnen lezen of wijzigingen aan te brengen in een bestand dat zich op de cloudlaag bevindt.
• Elke poging om een bestand op de cloudlaag te lezen of te wijzigen, resulteert in een I/O-fout die wordt geretourneerd aan degene die het bestand probeert te lezen dat de back-upapplicatie is als het bestand niet eerst wordt opgehaald.
• Sommige cloudbewuste back-upapplicaties kunnen het terugroepen van bestanden initiëren, anders moeten bestanden handmatig worden teruggehaald.
• Sinds DDOS 7.7+:
  • Met Direct Restore kunnen niet-geïntegreerde applicaties bestanden rechtstreeks vanuit de cloudlaag lezen zonder de actieve laag te hoeven doorlopen.
  • Belangrijke overwegingen bij de keuze voor direct herstel zijn onder meer:
  • Direct herstel vereist geen geïntegreerde applicatie en is transparant voor niet-geïntegreerde applicaties.
  • Voor het lezen van de cloudlaag hoeft u niet eerst naar de actieve laag te kopiëren.
  • Histogrammen en statistieken zijn beschikbaar voor het bijhouden van directe lezingen vanuit de cloudlaag.
  • Direct herstel wordt alleen ondersteund voor AWS- en ECS-cloudproviders .
  • Applicaties ervaren latentie in de cloudlaag.
  • Het rechtstreeks lezen vanuit de cloudlaag is niet geoptimaliseerd voor bandbreedte.

Hoeveel bestanden kunnen parallel worden opgeroepen?

• DDOS 6.0 ondersteunt vier bestanden die in de wachtrij moeten worden geplaatst en parallel moeten worden opgeroepen.
• DDOS 6.1 ondersteunt 1000 bestanden die in de wachtrij moeten worden geplaatst en 4 bestanden in de terugroepwachtrij die parallel moeten worden opgeroepen.

Volgens Data Domain Admin Guide 7.9:

• Systemen met 256 GB geheugen of meer kunnen maximaal 16 bestanden tegelijk oproepen.
• Systemen met minder dan 256 GB geheugen kunnen maximaal acht bestanden tegelijk oproepen.
• DDVE-instanties kunnen maximaal vier bestanden tegelijk ophalen.

Hoe kan een dossier worden opgehaald?

• Een bestand kan worden opgeroepen met behulp van de onderstaande opdracht. Bijvoorbeeld:   

data-movement recall path <path-name> 

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

Hoe kunnen alle bestanden in een MTree worden opgeroepen?

• Afhankelijk van de DDOS-versie kunnen alle bestanden in Cloud worden teruggeroepen door één opdracht uit te voeren, zoals hieronder:   

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

• Raadpleeg de Dell DDOS Command Reference Guide voor uw DDOS-versie voor meer informatie

Hoe kan een terugroepactie worden gemonitord?

• Een terugroepactie kan worden gecontroleerd met behulp van de onderstaande opdracht of als een specifiek bestand vereist is. Bijvoorbeeld:   

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 

Leidt het hernoemen van een bestand ertoe dat het bestand wordt teruggeroepen van de cloudlaag naar de actieve laag?

• Nee. Als de naam van een bestand wordt gewijzigd, blijft het op het huidige niveau staan.

Welke cloudproviders worden ondersteund?

•  Afhankelijk van de DDOS-versie die wordt gebruikt, ondersteunt DDOS de volgende cloudproviders:   
• Amazon Web Services (AWS).
• Microsoft Azure Cloud
• Dell Elastic Cloud Storage (ECS)
• Virtustream
• Raadpleeg de DDOS-beheerhandleiding voor meer informatie.

Wordt versleuteling ondersteund op de cloudlaag en moet deze worden gelicentieerd?

• Ja, versleuteling wordt ondersteund op de cloudlaag. Hiervoor is geen extra licentie vereist, in tegenstelling tot versleuteling van de actieve laag.
• Dit kan worden geconfigureerd wanneer de cloudfunctie daarna wordt ingeschakeld of gewijzigd. 
• Op het moment van schrijven wordt alleen de geïntegreerde sleutelmanager ondersteund voor versleuteling van cloudlagen en kan er slechts één versleutelingsalgoritme worden gebruikt voor LTR in het hele systeem.

Welke buckets worden gemaakt in het objectarchief van cloudproviders?

• DDOS maakt drie buckets
• De emmers eindigen met het touwtje:

'-d0'

'-c0' 

'-m0'

• De bucket die eindigt op de tekenreeks '-d0' wordt gebruikt voor gegevenssegmenten.
• De bucket die eindigt op de tekenreeks '-c0' wordt gebruikt voor configuratiegegevens.
• De bucket die eindigt met de string '-m0' wordt gebruikt voor metadata.
• Voorafgaand aan DDOS 6.1 worden er weliswaar drie buckets gemaakt, maar wordt alleen de bucket gebruikt die eindigt op '-d0'. Alle drie de emmers zijn echter nodig, dus zorg ervoor dat ze niet worden verwijderd.

Is het mogelijk om bestaande bucketnamen te gebruiken die eerder zijn gemaakt?

• Nee, dit is niet mogelijk.

Zijn er, naast de hardwarevereisten, nog andere verplichte vereisten die nodig zijn voordat de LTR wordt geconfigureerd?

• Ja
• Als ECS wordt gebruikt, is een load balancer een verplichte vereiste. Zonder een Load Balancer communiceert Data Domain met ECS op één knooppunt en wordt de verbinding verbroken zodra er meerdere aanvragen zijn gedaan.
• Een netwerk van 1 Gb tussen de DDR en de cloudprovider

Zijn certificaten vereist en zo ja, welke certificaten moeten worden gebruikt?

• Dit hangt af van het object of de cloudprovider die wordt gebruikt en ook van de configuratie.
• Voor AWS, Virtustream of Azure is een certificaat vereist. Raadpleeg de DDOS-beheerhandleiding voor meer informatie.
• Als ECS is geconfigureerd met een http-eindpunt, is geen certificaat vereist.
• Als ECS is geconfigureerd met een https-eindpunt, is een certificaat vereist. Aangezien een load balancer een verplichte vereiste is, is het vereiste certificaat afkomstig van het loan balancer-systeem in plaats van het ECS-systeem. Neem contact op met uw load balancer-provider voor meer informatie.
• Wanneer u het certificaat importeert, moet het de PEM-indeling hebben. Sommige providers leveren het certificaat niet in de PEM-indeling, dus moet het worden geconverteerd voordat het kan worden geïmporteerd.

Welke replicatietopologieën worden ondersteund?

• Verzamelingsreplicatie wordt _niet_ ondersteund.
• Directoryreplicatie wordt ondersteund, maar kan alleen worden gebruikt door de MTree '/data/col1/backup', maar deze MTree biedt geen ondersteuning voor dataverplaatsing.
• MTree-replicatie wordt volledig ondersteund.
• MFR- of VSR-replicatie wordt volledig ondersteund.

Waar moet rekening mee worden gehouden bij het configureren/initialiseren/opnieuw initialiseren van replicatie op een systeem waarop al LTR is geconfigureerd?

• Het bronsysteem maakt een snapshot van de MTree (deze snapshot bevat details van bestanden op actieve en cloudlagen).
• Het bronsysteem repliceert de snapshot naar de actieve laag van het doelsysteem.
• Pas wanneer de snapshot volledig is gerepliceerd, wordt deze weergegeven op het doelsysteem (op dat moment komen bestanden beschikbaar in de naamruimte van het bestandssysteem van het doelsysteem).
• Pas nadat bestanden beschikbaar zijn, kan dataverplaatsing worden uitgevoerd op de bestemming (ervan uitgaande dat deze is geconfigureerd voor LTR).
• Als de actieve laag van de bestemming niet groot genoeg is om een volledige snapshot van de bron te bevatten, wordt de snapshot nooit blootgesteld en kan de replicatie niet worden geïnitialiseerd.

Waar moet rekening mee worden gehouden als MFR- of VSR-replicatie wordt geconfigureerd op een systeem waarop de LTR al is geconfigureerd?

• Als data die al zijn gemigreerd naar de cloudlaag op een bron-DDR moeten worden gerepliceerd, worden deze automatisch opgehaald van de cloudprovider naar de actieve laag voordat ze via het netwerk kunnen worden verzonden.
• Het terughalen van bestanden van de cloudlaag naar de actieve laag kan kosten of vertraging met zich meebrengen.

Waarom geeft de uitvoer van de Data Domain 'file system show space' niet de ware grootte van de cloud- of objectstorage weer?

• Vanwege de inherente manier waarop cloud- of objectstorage werkt, kan een Data Domain-systeem op geen enkele manier de fysieke grootte van een cloudapparaat opvragen, omdat dit als schijnbaar oneindig kan worden beschouwd.
• DDOS moest echter een manier ontwikkelen om de huidige gebruiks-/deduplicatiestatistieken weer te geven vanuit een DDOS-perspectief.
• Daarom wordt een van de volgende twee benaderingen gebruikt:

1. De grootte van de cloudlaag wordt gemeten door de CLOUDTIER_CAPACITY license
2. De grootte van de cloudlaag wordt weergegeven als een veelvoud van de grootte van actieve laageenheden voor dat modeltype, afhankelijk van het aantal cloudeenheden dat is geconfigureerd. Zie de hardware-installatiehandleiding voor het model in kwestie voor meer informatie over actieve laaggrootten.

Hoe kan het bestandssysteem worden gestart als een cloudeenheid niet beschikbaar is?

• Zorg ervoor dat het bestandssysteem is uitgeschakeld.
• Schakel de cloudeenheid die niet beschikbaar is uit met behulp van de onderstaande opdracht:

cloud unit disable <cloud unit name>

• Schakel het bestandssysteem in.

Als een cloudeenheid is uitgeschakeld, hoe kan deze dan worden ingeschakeld?

• Zorg ervoor dat het bestandssysteem is uitgeschakeld.
• Schakel de cloudeenheid in met behulp van de onderstaande opdracht:

cloud unit enable <cloud unit name>

• Schakel het bestandssysteem in.

Waarom bestaan er nog steeds bestanden in het bestandssysteem die zich op een cloudeenheid bevinden die is verwijderd?

•  Als bestanden niet uit een MTree zijn verwijderd voordat een cloudeenheid werd verwijderd, blijven de bestanden bestaan in de naamruimte van het bestandssysteem.
• In het bestandslocatierapport wordt dan ook weergegeven dat de bestanden deel uitmaken van een verwijderde cloudeenheid. Bijvoorbeeld:  

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

• De bestanden kunnen nog steeds worden bekeken in de naamruimte van het bestandssysteem door een CIFS/NFS-share voor deze MTree te openen.
• De bestanden zijn echter niet leesbaar omdat de cloudeenheid waarin ze zich bevonden, is verwijderd.
• Daarom is de enige optie om deze bestanden te verwijderen, omdat de gegevens waarnaar ze verwijzen niet langer bestaan.

Is het mogelijk om het protocoleindpunt of de poorten voor een ECS of S3 Flexible cloudprovider te wijzigen nadat een cloudeenheid is gemaakt?

• Dit kan bijvoorbeeld nodig zijn als u overstapt van http naar https of omgekeerd, migreert naar een nieuwe load balancer.
• Op het moment van schrijven kan een Data Domain-administrator deze wijziging op geen enkele manier uitvoeren. Deze functionaliteit wordt overwogen voor een toekomstige DDOS-release.
• Dit kan echter worden uitgevoerd door support of engineering.
• Het bestandssysteem moet worden uitgeschakeld om deze wijziging uit te voeren.
• Als dit nodig is, worden eerst alle configuraties buiten het Data Domain-systeem uitgevoerd. Als dit eenmaal is gewijzigd, verwacht het bestandssysteem te kunnen communiceren met behulp van het bijgewerkte protocol of de bijgewerkte poort en de buckets of objecten te lezen zoals voorheen het deed.