Data Domain Restorer och långsiktig lagring i molnet: Vanliga frågor och svar

Den här artikeln tar upp de vanligaste frågorna om konfiguration och användning av Data Domain Restorers (DDR) och långsiktig lagring (LTR) eller molnfunktionen.
 

Vad är LTR?

• En ny funktion som kallas LTR introducerades från och med Data Domain Operating System (DDOS) 6.0.
• LTR gör det möjligt för vissa modeller av DDR:er att migrera en delmängd av filer eller data till ett objekt eller molnlagring, en så kallad molnnivå, från en rad offentliga eller privata molnleverantörer som stöds.
• För att fysiskt migrera filer eller data till objektlagring körs en dataförflyttningsprocess på DDR.
• För att fysiskt frigöra redundanta data från molnnivån körs en rensningsprocess för molnnivån på DDR:en.
• LTR är en licensierad funktion och kräver en CLOUDTIER_CAPACITY license.
• LTR kräver viss lokal lagring för metadata på molnnivå.

Vilka DDR-system är LTR tillgängligt för?
Detta beror på vilken DDOS-version som är installerad tillsammans med systemmodelltypen. De flesta modeller har vissa maskinvarukrav som måste uppfyllas i förväg för att LTR ska konfigureras. Se hårdvaruinstallationsmanualen för de specifika modellerna tillsammans med DDOS-administrationsmanualen för kraven.

Vilken licens krävs för LTR?

• Eftersom LTR betraktas som en ny funktion från DDOS 6.x och senare krävs en e-licens. 
• Den typ av e-licens som krävs kallas för CLOUDTIER_CAPACITY license. Ett exempel på en CLOUDTIER_CAPACITY license är som följer:

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

Hur fungerar de olika nivåerna?

• Normala DDR:er (utan LTR-licens) har en enda nivå som kallas den aktiva nivån.
• Den aktiva nivån är den traditionella lagringsnivån på alla "standard"-DDR:er.
• LTR-system har en andra lagringsnivå som kallas molnnivå.

Den maximala storleken på varje nivå bestäms av de gränser som stöds för den angivna maskinvarukonfigurationen och DDOS-versionen. Se DDOS-administrationsmanualen och hårdvarumanualen för den specifika modellen i fråga.

Ett exempel på en LTR-konfiguration med två nivåer, en aktiv och en molnbaserad, visas nedan:   

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

Hur är en molnnivå strukturerad?

• En molnnivå består av:   
  • Lokalt lagrade metadata som lagras i ett hölje om en fysisk DDR används, eller en LUN eller enhet om DDVE används.
  • Objektlagringsproviders
• Båda ovanstående kombineras till en molnenhet.
• Om flera molnenheter har konfigurerats kan de dela lokalt lagrade metadata.
• Högst två molnenheter kan konfigureras per system. Varje molnenhet kan etableras från en annan objektlagringsprovider.
• Varje molnenhet kan vara lika stor som den maximala aktiva nivåstorleken som stöds för den angivna DDR-modellen. Mer information finns i DDOS-administrationsmanualen.

Vad händer under en typisk livscykel för säkerhetskopiering när LTR har konfigurerats?

• Alla data skrivs först till den aktiva nivån där de börjar åldras.
• Kortvariga data som når kvarhållningsperioden upphör att gälla/tas bort som vid en normal DDR.
• En delmängd av data som kräver långsiktig kvarhållning migreras dock ut till molnnivån.
• Filsystemet har ett enda namnområde på alla nivåer, så när en fil migreras till molnet ändras inte namnområdet och är därför någorlunda transparent för användaren eller säkerhetskopieringsprogrammet.
• För en fil som redan har migrerats till molnnivån når kvarhållningsperioden upphör den att gälla/tas bort precis som andra filer.
• Det utrymme som en fil använde på molnnivån frigörs inte omedelbart, i stället måste rensning av molnnivån köras.

Hur dedupliceras data mellan nivåer?

• Varje molnenhet är en fristående volym, vilket innebär att det är en fristående dedupliceringsenhet.
• Det innebär att data som skrivs till varje molnenhet bara kan dedupliceras mot data i samma molnenhet.

Vad är en placeringstid (så kallad ptime)?

• Filer och kataloger har olika tidsstämplar kopplade till sig.
• En fil eller katalog har till exempel en tid för skapande, senaste åtkomsttid och ändringstid.
• DDOS har förbättrat detta ytterligare för att även inkludera en placeringstid. Placeringstiden är det datum och den tid då filen migrerades från den aktiva nivån till molnnivån.
• Beroende på DDOS-versionen kan placeringstiden visas när du undersöker vilken nivå en fil finns på. Om filen har migrerats till molnnivån visas placeringstiden, till exempel:  

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 är det sista fältet i ovanstående utdata, även om det inte visar något fälthuvud.

Hur flyttas data från den aktiva nivån till molnnivån?

• En process som kallas dataförflyttning ansvarar för att undersöka filer i ett MTree som finns på den aktiva nivån.
• Dataflytt börjar med att skapa en ögonblicksbild av alla MTrees som konfigurerats för dataflytt.
• Varje fil har en ändringstid som lagrar den senaste gången en fil skrevs till.
• Om en fil tidigare har migrerats till molnnivån anges ytterligare ett tidsfält som kallas placeringstid. Placeringstiden lagrar datum och tid då filen migrerades till molnnivån. Om placeringstiden är inställd används denna istället för ändringstiden. Detta är för att undvika att en fil kontinuerligt migreras tillbaka till molnnivån om en fil återkallas (eftersom återkallande av en fil inte ändrar dess ändringstid).
• De ögonblicksbilder som skapas ovan korsas av dataförflyttning.
• Om filen som undersöks har nått ett definierat tröskelvärde, som anges av dataöverföringspolicyn för MTree i fråga, undersöks filen för att fastställa vilka data som finns i filen som måste migreras från den aktiva nivån till molnnivån. En policy för dataförflyttning anges per MTree.
• De unika segmenten för den valda filen skrivs eller kopieras till molnnivån. 
• När de unika segmenten har kopierats verifieras filen genom att de läses upp för att säkerställa att migreringen lyckades.
• När filen har verifierats uppdateras metadata för att återspegla att filen nu finns på molnnivån.
• Dataförflyttningsprocessen kan schemaläggas att köras med en viss frekvens eller kan initieras manuellt.

Vilka faser finns det när dataflytten startas och vilka åtgärder utförs varje fas?

• Det finns tre faser som är associerade med dataförflyttning: kopieringsfasen, verifieringsfasen och installationsfasen.
• Kopieringsfasen ansvarar för att identifiera segment som måste kopieras till molnet och sedan migrera dessa segment till molnet.
• När kopieringsfasen startar är det moln- eller objektlagring, och den används när kopieringsfasen kopierar de identifierade segmenten från den aktiva nivån till molnnivån.
• Verifieringsfasen ansvarar för att säkerställa att en fils segment har migrerats till molnet.
• Installationsfasen ansvarar för att uppdatera metadata för filen som har migrerats för att visa att den nu finns på moln- eller objektlagring.
• Varje fil måste slutföra alla tre faserna för att dataflytten ska anses vara lyckad för filen. Därför finns filen kvar på den aktiva nivån tills installationsfasen har slutförts för en fil.

Vilka dataöverföringsprinciper är tillgängliga?

• Dataöverföringsprinciper kan vara något av följande:   
  • Åldersgräns: Om en filplacering eller ändringstid är större än det angivna åldersintervallet väljs den för migrering till molnnivån.
  • Åldersgrupp: Om en filplacering eller ändringstid ligger inom ett visst intervall väljs den för migrering till molnnivån.
  • Programdefinierad: Säkerhetskopieringsprogrammet anger om en fil ska väljas för migrering till molnnivån.
• Policyer är ömsesidigt uteslutande, det vill säga en MTree kan bara ha en policy inställd i taget.

Hur kan en dataförflyttningspolicy ställas in på ett MTree?

• Kommandot nedan kan användas. Till exempel:   

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

Vilka dataförflyttningspolicyer har redan konfigurerats?

• Kommandot nedan innehåller en lista över vilka MTrees som har tilldelats dataöverföringspolicyer. Till exempel:   

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

Hur fungerar en apphanterad princip för dataförflyttning?

• Dataförflyttningspolicyn för MTree i fråga är inställd på apphanterad. Detta görs antingen manuellt eller så utför säkerhetskopieringsprogrammet detta med hjälp av Data Domain REST API-gränssnitt.
• Säkerhetskopieringsprogrammet måste vara LTR-medvetet.
• Säkerhetskopieringsprogrammet måste använda DD Boost och versionen av DD Boost måste vara LTR-medveten och kompatibel.
• Med hjälp av DD Boost-biblioteket/API:t ställer säkerhetskopieringsprogrammet in placeringstiden för filen som måste migreras till molnnivån till ett särskilt värde som anger att filen ska migreras till molnet nästa gång dataflytten körs.
• När dataförflyttning körs på Data Domain-systemet kontrolleras placeringstiden och om den är inställd på specialvärdet, som nämnts ovan, migreras filen till molnet.

Hur kan dataflytt startas manuellt?

• Kommandot nedan kan till exempel användas:   

data-movement start

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

Hur kan dataförflyttning övervakas?

• Kommandot nedan kan användas för att kontrollera status för dataflytt. Till exempel:   

data-movement status

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

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

• Om dataflytt körs kan kommandot nedan användas, till exempel:   

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

Hur kan dataförflyttningar stoppas?

• Kommandot nedan kan användas. Till exempel:   

data-movement stop 

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

Kan dataflytt köras till båda molnenheterna parallellt om det finns fler än en molnenhet?

• Nej. I princip kan dataflytt bara migrera data till en molnenhet i taget.

Hur är LTR konfigurerat?

• Det här är en översikt på hög nivå. Se den detaljerade processen i DDOS-administrationsmanualen.
• Lägg till lämplig CLOUDTIER_CAPACITY license.
• Ange systemlösenfrasen om den inte redan är angiven.
• Aktivera molnfunktionen.
• Lägg till metadatalagringen för molnnivån.
• Konfigurera en molnprofil eller profil för lämplig moln- eller objektlagringsleverantör.
• Lägg till en molnenhet.
• Konfigurera en dataförflyttningspolicy för MTree eller MTrees som kräver lagring av data i molnet.
• Starta dataflytt manuellt eller vänta tills en automatisk eller schemalagd dataflytt startar.

Kan en molnenhet tas bort? Om så är fallet, hur?

• Viktigt! Detta förstör alla data som finns på molnenheten, därför är data oåterkalleliga, så fortsätt med försiktighet.
• Se avsnittet "Hur kontrollerar en användare vilken nivå en fil finns på" i det här kunskapsbasdokumentet för att förstå vilka filer som finns på molnenheten som ska tas bort.
• Dessa filer bör antingen tas bort om de inte längre behövs eller återkallas till den aktiva nivån om de måste behållas.
• Om filer måste sparas ska du kontrollera att alla filer återkallas innan du fortsätter.
• Det ska inte finnas några filer kvar på molnenheten som tas bort.
• Återställ alla dataöverföringspolicyer för MTree eller MTrees som använder den här molnenheten.
• Inaktivera filsystemet.
• Ta bort molnenheten. Detta markerar molnenheten i ett DELETE_PENDING tillstånd, som är som avsett.
• Aktivera filsystemet.
• När filsystemet har startats börjar det asynkront ta bort alla objekt i molnet eller objektlagringsprovidern som användes av den här molnenheten. När alla objekt har tagits bort tas även de bucketar som molnenheten använde bort. Om det finns många objekt kan molnenheten vara i ett DELETE_PENDING tillstånd under en längre tid.
• När alla objekt och bucketar har tagits bort försvinner molnenheten från molnenhetslistan.

Vad händer om det inte går att ta bort en molnenhet på grund av att objektlagringen inte längre är tillgänglig eller på grund av ett anslutningsproblem?

• Kontakta Dells support om du behöver ytterligare hjälp.

Kan LTR och Extended Retention (ER) konfigureras på samma system?

• Nej. ER och LTR är ömsesidigt uteslutande funktioner.

Hur frigörs eller rensas data från molnnivån?

• Detta fungerar på ett liknande sätt som filer som finns på den aktiva nivån
• När en fil når kvarhållningsperioden tas den bort från filsystemets namnområde.
• Rensning på molnnivå är schemalagd att köras. Som standard körs rensning på molnnivå efter var fjärde rensningssession på aktiv nivå.
• För att rensning av molnnivå ska köras måste molnenheten som rensas ha minst 1 % överflödiga eller rensningsbara data för att kunna starta. Det beror på att all molnnätverkstrafik kan vara debiterbar, så DDR försöker begränsa nätverkstrafiken där det är möjligt.
• Molnnivån körs med standardvärdet 50 % rensningsbegränsning.
• Både schemat för rensning av molnnivå och rensningsbegränsningen kan ändras.
• Rensning på aktiv nivå och molnnivå kan inte köras parallellt.
• Om automatisk eller schemalagd rensning av molnnivå körs föregrips den av rensning på aktiv nivå.
• Om en manuell rensning av molnnivå initieras kan rensning av aktiv nivå inte starta förrän rensning av molnnivå har slutförts.
• Om en molnnivå har två molnenheter rensas endast en molnenhet per schemalagd eller automatisk rensning av molnnivå. Molnenheterna används på ett resursallokeringssätt ur ett molnnivårensningsperspektiv. När det finns två molnenheter är det ett krav att ange vilken molnenhet som ska rensas när den körs från kommandoraden (cloud clean start <unit-name>)
• Om en molnnivårensning inte startar på en molnenhet, till exempel om den aktuella molnenheten inte har tillräckligt med rensningsbara data för att anse att det är värt besväret, försöker systemet automatiskt rensa från nästa molnenhet.
• Mer information om rensning av molnnivå finns i följande artikel Data Domain: En introduktion till långsiktig kvarhållning, rensning av molnnivå och skräpinsamling på Data Domain Restorers (DDR)

Hur startas en manuell rensning av molnnivån?

• Kommandot nedan kan användas. Till exempel:   

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.

Hur kan en molnnivårensning övervakas?

• Kommandot nedan kan användas för att kontrollera om molnrensning körs. Till exempel:   

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.

• Om cloud clean körs kan det övervakas med hjälp av kommandot nedan:

cloud clean watch

Kan rensning på aktiv nivå köras samtidigt med rensning på molnnivå?

• Nej. Både rensning av aktiv nivå och rensning av molnnivå använder samma gemensamma interna delade datastrukturer som kräver exklusiv åtkomst.

Hur kan ett schema för rensning av molnnivå visas eller ändras?

• Kommandot nedan kan användas för att visa det aktuella molnrensningsschemat. Till exempel:   

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.

• Kommandot nedan används för att ändra ett schema. Till exempel:  

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.

Hur kan begränsningen för rensning av molnnivå ändras eller visas?

• Som standard är begränsningen för rensning av molnnivå inställd på 50 %. Kommandot nedan kan användas för att återställa det till standardbegränsningsprocenten.

cloud clean throttle reset

• Kommandot nedan kan användas för att visa den aktuella molnrensningsbegränsningen. Till exempel:   

cloud clean throttle show

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

• Kommandot nedan kan användas för att ändra rensningsreglaget. Till exempel:   

cloud clean throttle set <value> 

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

Vad styr begränsningen för rensning av molnnivå?

• Begränsningen för rensning av molnnivå fungerar på ett liknande sätt som begränsningen för rensning på aktiv nivå, eftersom begränsningen begränsar de I/O- och CPU-resurser som rensningen på molnnivån kan använda.
• Det stryper inte nätverksöverföringen.

Varför frigör/tar rensning av molnnivå inte bort så många objekt som förväntat?

• Städning betraktas alltid som en uppskattning. Se följande KB-artiklar som beskriver aspekter kring det här ämnet eftersom de även gäller för data som finns på molnnivån:  

• Utöver detta finns det ytterligare specifik information om hur molnnivån implementeras.
• Olika metoder har implementerats för att begränsa mängden nätverkstrafik till en moln- eller objektlagringsleverantör eftersom detta kan medföra tillhörande kostnader.
• Som nämnts ovan krävs minst 1 % dataomsättning för att rensningen ska kunna köras.
• När filsystemet bläddras igenom för att söka efter filer som uppfyller dataförflyttningsprincipen undersöks endast lokala kopior av metadata.
• Alla segment som finns i moln- eller objektlagring och som endast innehåller användardata markeras för asynkron borttagning.
• Alla segment som innehåller minst ett live-segment hoppas över eftersom DDOS inte vill kombinera små mängder data på grund av den nätverkstrafik som ingår.

Hur tar en användare reda på vilken nivå en fil finns på?

• Använd kommandot nedan för ett exempel på utdata som genereras av det här kommandot:  

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äsas eller nås direkt efter att den har migrerats till molnnivån?

• Detta beror på vilken version av DDOS som används tillsammans med molnleverantören:   

• Det går att återställa filer direkt utan att först behöva återkalla en fil. Detta kallas funktionen "direktåterställning" och är begränsat till ECS som moln- eller objektleverantör.
• Mer information om "direktåterställning" från Avamar finns i informationsdokumentet "Avamar Granular or File Level Restore from Data Domain Cloud Tier".
• Funktionen Avamar GLR/FLR (Direct Restore) kräver minst en kombination av Avamar 18.1 eller DDOS 6.1 med ECS som molnleverantör. 

• En fil måste återkallas först. Det innebär att data migreras tillbaka från molnnivån till den aktiva nivån.
• Filen måste återkallas från molnnivån till den aktiva nivån med hjälp av data-movement recall kommandot för att tillåta läsning från en fil eller ändring av en fil som finns på molnnivån.
• Alla försök att läsa eller ändra en fil som finns på molnnivån resulterar i att ett I/O-fel returneras till den som försöker läsa filen som är säkerhetskopieringsprogrammet om filen inte återkallas först.
• Vissa molnmedvetna säkerhetskopieringsprogram kan initiera filåterkallelser, annars måste filerna återkallas manuellt.
• Sedan DDOS 7.7+:
  • Med direkt återställning kan icke-integrerade program läsa filer direkt från molnnivån utan att gå via den aktiva nivån.
  • Viktiga överväganden när du väljer att använda direkt återställning är:
  • Direkt återställning kräver inget integrerat program och är transparent för icke-integrerade program.
  • Läsning från molnnivån kräver inte att du först kopierar till den aktiva nivån.
  • Histogram och statistik är tillgängliga för att spåra direkta läsningar från molnnivån.
  • Direkt återställning stöds endast för AWS- och ECS-molnleverantörer .
  • Program upplever svarstider på molnnivå.
  • Läsning direkt från molnnivån är inte bandbreddsoptimerad.

Hur många filer kan återkallas parallellt?

• DDOS 6.0 stöder fyra filer som ska köas och återkallas parallellt.
• DDOS 6.1 stöder 1 000 filer som ska köas och 4 filer i återkallningskön som ska återkallas parallellt.

Enligt Data Domain Admin Guide 7.9:

• System med 256 GB minne eller mer kan hämta upp till 16 filer samtidigt.
• System med mindre än 256 GB minne kan hämta upp till åtta filer samtidigt.
• DDVE-instanser kan hämta upp till fyra filer samtidigt.

Hur kan en fil återkallas?

• En fil kan hämtas med hjälp av kommandot nedan. Till exempel:   

data-movement recall path <path-name> 

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

Hur kan alla filer i ett MTree återkallas?

• Beroende på DDOS-version kan alla filer i molnet hämtas genom att ett enda kommando körs, till exempel nedan:   

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

• Mer information finns i "Dell DDOS Command Reference Guide" för din DDOS-version

Hur kan en återkallningsåtgärd övervakas?

• En återkallningsåtgärd kan övervakas med hjälp av kommandot nedan eller om en specifik fil krävs. Till exempel:   

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 

Återkallas filen från molnnivån till den aktiva nivån om du byter namn på en fil?

• Nej. Om en fil byter namn finns den kvar på den aktuella nivån.

Vilka molnleverantörer stöds?

•  Beroende på vilken DDOS-version som används stöder DDOS följande molnleverantörer:   
• Amazon Web Services (AWS).
• Microsoft Azure-moln
• Dell Elastic Cloud Storage (ECS)
• Virtustream
• Mer information finns i DDOS-administrationsmanualen.

Stöds kryptering på molnnivån och måste den vara licensierad?

• Ja, kryptering stöds på molnnivån. Detta kräver ingen extra licens, till skillnad från kryptering på aktiv nivå.
• Detta kan konfigureras när molnfunktionen aktiveras eller ändras efter. 
• I skrivande stund stöds endast den inbäddade nyckelhanteraren för kryptering på molnnivå och endast en krypteringsalgoritm kan användas för LTR-system i hela systemet.

Vilka bucketar skapas i molnleverantörens objektlager?

• DDOS skapar tre buckets
• Bucketarna slutar med strängen:

'-d0'

'-c0' 

'-m0'

• Bucketen som slutar med strängen "-d0" används för datasegment.
• Bucketen som slutar med strängen "-c0" används för konfigurationsdata.
• Bucketen som slutar med strängen "-m0" används för metadata.
• Före DDOS 6.1 används endast bucketslutet "-d0" när tre buckets skapas. Alla tre hinkarna behövs dock, så se till att de inte tas bort.

Går det att använda befintliga bucketnamn som har skapats tidigare?

• Nej, det är inte möjligt.

Utöver maskinvarukraven, finns det några andra obligatoriska krav som behövs innan du konfigurerar LTR?

• Ja
• Om ECS används är en lastbalanserare ett obligatoriskt krav. Utan lastbalanserare kommunicerar Data Domain med ECS på en enda nod och kopplas bort när flera begäranden görs.
• Ett 1 Gb-nätverk mellan DDR och molnleverantören

Krävs certifikat och i så fall vilka certifikat ska användas?

• Detta beror på vilket objekt eller molnleverantör som används och även konfigurationen.
• AWS, Virtustream eller Azure kräver ett certifikat. Mer information finns i DDOS-administrationsmanualen.
• Om ECS har konfigurerats med en http-slutpunkt krävs inget certifikat.
• Om ECS har konfigurerats med en https-slutpunkt krävs ett certifikat. Eftersom en lastbalanserare är ett obligatoriskt krav kommer det certifikat som krävs från lånebalanseringssystemet i stället för ECS-systemet. Kontakta din lastbalanseringsprovider för mer information.
• När du importerar certifikatet måste det vara i PEM-format. Vissa leverantörer tillhandahåller inte certifikatet i PEM-format, så det måste konverteras innan det importeras.

Vilka replikeringstopologier stöds?

• Samlingsreplikering stöds _inte _.
• Katalogreplikering stöds, men det kan endast användas av MTree '/data/col1/backup', men detta MTree stöder inte dataförflyttning.
• MTree-replikering stöds fullt ut.
• MFR- eller VSR-replikering stöds fullt ut.

Vad ska du tänka på när du konfigurerar/initierar/initierar om replikeringen i ett system som redan har LTR konfigurerat?

• Källsystemet tar en ögonblicksbild av MTree (den här ögonblicksbilden innehåller information om filer på aktiva nivåer och molnnivåer).
• Källsystemet replikerar ögonblicksbilden till målsystemets aktiva nivå.
• Först när ögonblicksbilden har replikerats helt exponeras den på målsystemet (då filer blir tillgängliga i målsystemets filsystemnamnområde).
• Först när filer har exponerats kan dataflytt köras på målet (förutsatt att det är konfigurerat för LTR).
• Om destinationens aktiva nivå inte är tillräckligt stor för att hålla en fullständig ögonblicksbild från källan, exponeras ögonblicksbilden aldrig och replikeringen kan inte slutföra initieringen.

Vad ska du tänka på om du konfigurerar MFR- eller VSR-replikering i ett system som redan har LTR konfigurerat?

• Om data som redan har migrerats till molnnivån på en käll-DDR måste replikeras, återkallas den automatiskt från molnleverantören till den aktiva nivån innan de kan skickas över nätverket.
• Att återkalla filer från molnnivån till den aktiva nivån kan medföra en kostnad eller fördröjning.

Varför återspeglar inte Data Domains kommandoutdata för "file system show space" den verkliga storleken på molnet eller objektlagringen?

• På grund av det naturliga sätt som moln- eller objektlagring fungerar på har ett Data Domain-system inget sätt att fråga efter den fysiska storleken på en molnenhet eftersom detta kan ses som till synes oändligt.
• DDOS var dock tvunget att utveckla ett sätt att visa aktuell användnings-/dedupliceringsstatistik ur ett DDOS-perspektiv.
• Därför används en av två metoder:

1. Storleken på molnnivån är beroende av CLOUDTIER_CAPACITY license
2. Storleken på molnnivån visas som en multipel av aktiva nivåenhetsstorlekar för den modelltypen beroende på hur många molnenheter som har konfigurerats. Mer information om storlekar på aktiva nivåer finns i installationsguiden för maskinvara för den aktuella modellen.

Hur kan filsystemet startas om en molnenhet inte är tillgänglig?

• Kontrollera att filsystemet är avaktiverat.
• Inaktivera molnenheten som inte är tillgänglig med kommandot nedan:

cloud unit disable <cloud unit name>

• Aktivera filsystemet.

Hur kan en molnenhet aktiveras om den är inaktiverad?

• Kontrollera att filsystemet är avaktiverat.
• Aktivera molnenheten med kommandot nedan:

cloud unit enable <cloud unit name>

• Aktivera filsystemet.

Varför finns det fortfarande filer i filsystemet som finns på en molnenhet som har tagits bort?

•  Om filer inte togs bort från ett MTree innan en molnenhet togs bort fortsätter filerna att finnas i filsystemets namnområde.
• Därför visar filplatsrapporten att filerna är en del av en borttagen molnenhet. Till exempel:  

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

• Filerna kan fortfarande ses i filsystemets namnområde genom åtkomst till en CIFS/NFS-resurs för detta MTree.
• Filerna är dock inte läsbara eftersom molnenheten där de fanns har tagits bort.
• Därför är det enda alternativet att ta bort dessa filer eftersom deras data som de refererade till inte längre finns.

Går det att ändra protokollslutpunkt eller portar för en ECS- eller S3-leverantör av flexibla moln när en molnenhet har skapats?

• Detta kan till exempel krävas om du ändrar från http till https eller omvänt migrerar till en ny lastbalanserare.
• I skrivande stund finns det inget sätt för en Data Domain-administratör att utföra den här ändringen. Den här funktionen övervägs för en framtida DDOS-version.
• Detta kan dock utföras av supporten eller teknikerna.
• Filsystemet måste inaktiveras för att du ska kunna utföra den här ändringen.
• Om detta är nödvändigt utförs all konfiguration utanför Data Domain-systemet först eftersom när detta har ändrats, när filsystemet aktiveras, förväntar det sig att kunna kommunicera med det uppdaterade protokollet eller porten och läsa bucketar eller objekt som det gjorde tidigare.