Data Domain: En introduktion till långsiktig lagring/rensning på molnnivå/skräpinsamling på Data Domain Restorers (DDR)

Data Domain Operating System (DDOS) 6.0 introducerar en ny funktion som kallas molnlagring eller långsiktig lagring (LTR). Den här funktionen gör det möjligt att lägga till en andra nivå av objektbaserad lagring som tillhandahålls av en molnleverantör i vissa modeller av Data Domain Restorer (DDR) med en associerad CLOUD_CAPACITY licens.

På system som använder LTR skrivs filer som matas in av DDR initialt till den aktiva nivån (lokalt ansluten lagring). Dataförflyttningspolicyer/ålderströsklar konfigureras sedan per mtree så att vissa filer som kräver långsiktig lagring senare migreras från den aktiva nivån till molnnivån genom dataförflyttningsprocessen (en regelbundet schemalagd aktivitet).

Filer på molnnivån kan tas bort som vanligt, men associerat utrymme på moln-/objektlagring frigörs inte omedelbart för användning. Om du vill ta bort överflödiga data från molnet måste molnnivån rensas.

Molnnivåns struktur:

Molnnivån är indelad i "molnenheter". Observera följande:

• Molnnivån kan innehålla upp till två molnenheter
• Varje molnenhet kan vara lika stor som den maximala aktiva nivåstorleken som stöds för den angivna DDR-modellen
• Varje molnenhet kan etableras från en annan objektlagringsprovider

Till exempel:

# molnenhetslista
Namn Profilstatus
----------------------- ------------ ------
B-enhet LTR-ECS-Ben Aktiv <=== ECS-leverantör
cloud-unit-virtustream1 virtustream1 Active <=== Virtustream-leverantör
----------------------- ------------ ------

Grundläggande begrepp för molnrensning:

• Molnrensning fungerar endast mot en enda molnenhet under varje körning – för att fastställa vilken molnenhet som rensas finns följande meddelande i DDFS-loggar (/ddr/var/log/debug/ddfs.info) – i det här fallet rensas molnenheten cloud-unit-virtustream1:

• Om ett system har flera molnenheter konfigurerade kommer molnrensning att ge resursallokering av dessa enheter och försöka rensa en enda enhet varje gång molnrensning körs
• Cloud clean kan startas manuellt eller automatiskt via ett schema - för att starta manuellt används följande kommando:

• Active tier clean och cloud clean kan inte köras parallellt (på grund av att båda använder samma minnesstrukturer i DDFS)
• Om rensning av aktiv nivå körs (startas antingen manuellt eller via dess schema) och molnrensning försöker startas kommer det att fela, dvs.:

• Om molnrensning har startats automatiskt (dvs. via dess schema) och rensning av aktiv nivå startas, kommer rensning av molnenhet att avbrytas så att rensning av aktiv nivå kan köras. Detta indikeras av följande i DDFS-loggar:

• Om cloud clean har startats manuellt och man försöker starta active tier clean kommer active tier clean inte att starta – cloud clean får köras tills det är klart, dvs.:

• En molnenhet måste ha upplevt minst 1 % dataomsättning (dvs. >= 1 % av de data som för närvarande finns på molnenheten måste anses vara överflödiga och därför flyttbara) för att molnrensningen ska starta. Om så inte är fallet kommer följande att visas på kommandoraden om cloud clean startas manuellt:

• Om ett system innehåller två molnenheter och schemalagd rensning av den första enheten misslyckas av någon anledning (till exempel otillräcklig omsättning) kommer rensningen automatiskt att försöka starta mot den andra enheten (dvs. det finns inget krav på att vänta på nästa schemalagda körning av molnrensning för att den andra enheten ska rensas)
• Cloud Clean kan begränsas (liknande rensning på aktiv nivå) för att avgöra vilka åtgärder som ska vidtas när systemet är under betydande annan arbetsbelastning (t.ex. intag/återställning/replikering).

Schemaläggning av molnrensning:

I DDOS 6.0 och senare har det sätt på vilket rensning av aktiv nivå schemaläggs inte ändrats – som standard är rensning av aktiv nivå schemalagd att köras en gång i veckan kl. 0600 på tisdagar, d.v.s.:# filesys clean show schedule
Rensning av filsystemet är schemalagd att köras "tis" kl. 0600".



Cloud Clean är som standard schemalagd att köras efter var 4:e anrop av schemalagd rensning av active tier. För att visa molnrensningsschemat ska följande kommando användas:

# molnrensningsfrekvens show
Rensningsfrekvens för molnnivå är inställd på att köras efter var 4:e aktiva nivårensningscykel.

Som ett resultat, på ett system med standardkonfiguration, kommer molnrensning att startas var 4:e vecka - om systemet har två molnenheter kommer varje enhet att rensas en gång var 8:e vecka.

Om du vill ändra molnrensningsfrekvensen kan följande kommando användas:

# molnrensningsfrekvens inställd på 2
Rensningsfrekvens på molnnivå är inställd på att köras efter var 2:e aktiv nivårensningscykel.

För att återställa molnrensning till standardschemat efter var 4:e aktiva nivårensning kan följande kommando användas:

# Återställning
av molnrensningsfrekvens Rensningsfrekvens för molnnivå återställs till standard (var 4:e aktiv nivårensningscykel).

Observera att molnrensningsschemat inte inkluderar manuellt startade rensningscykler på aktiv nivå. Som ett resultat, på ovanstående system, även om aktiv nivårensning kördes manuellt varje dag, skulle molnnivårensning bara starta en gång var 4:e vecka.

Det är också möjligt att helt inaktivera schemalagd molnrensning med följande kommando:

# molnrensningsfrekvens inställd aldrig
Molnnivårensningsfrekvensen är inställd på "aldrig".

I det här fallet körs molnrensningen endast när den startas manuellt.

För att stoppa en molnrensning som körs kan följande kommando användas:

# molnrensning stopp

För att avgöra när molnrensning senast kördes kan följande kommando användas:

# molnrensningsstatus
Molnnivårensning slutförd 2016/08/01 20:54:43.

Molnrensningsalgoritm:

Cloud Clean använder samma rensningsalgoritm som konfigurerats för den aktiva nivån. I DDOS 6.0 (och senare) används som standard perfekt fysisk skräpinsamling (PPGC), men detta kan ändras till fysisk skräpinsamling (PGC) via systemparametrar.

Observera att fysisk skräpinsamling inte ska inaktiveras eftersom användning av den traditionella/fullständiga rensningsalgoritmen för att rensa en molnenhet kan resultera i DDFS-panik/omstart

Algoritmen som används för molnrensning visas i DDFS-loggar när rensningen startar, dvs.:
06/28 10:51:56.960 (tid 0x7fc5bccb2d50): gc: gc_start_intern
: Vald algoritm: Fysisk rengöring <=== PPGC eller PGC
07/27 12:21:18.224 (tid 0x7f92b8cfe7e0): gc: gc_start_intern: Vald algoritm: Fullständig rengöring <=== Traditionell GC

Observera att det från ovanstående utdata inte är möjligt att skilja mellan PPGC eller PGC - den specifika algoritmen som används är uppenbar på grund av antalet faser som körs av clean - i allmänhet:

Traditionell/fullständig GC: 10 faser
PGC: 12 faser
PPGC: 6 faser
Om du vill ha mer information om hur du ändrar rensningsalgoritmen som används på ett system kontaktar du din kontrakterade supportleverantör

. Skillnader mellan rensningsfaserna på aktiv nivå och ren kopia på molnnivå:

Kopieringsfasen av rensning är den fas där överflödiga data på en DDR tas bort fysiskt/utrymme frigörs.
Observera att det finns skillnader mellan hur kopieringsfasen fungerar mot den aktiva nivån och molnnivån:

Aktiv nivå:

• Data som skrivs till den aktiva nivån för en DDR finns i behållare på 4,5 Mb
• Som standard övervägs en behållare endast för "kopia" av ren om den innehåller <= 92 % "live" (d.v.s. aktivt refererade) data
• Livedata extraheras från containern och skrivs till en ny container (tillsammans med livedata från andra kopierade containrar) i slutet av filsystemet
• På disk-index uppdateras för att återspegla den nya containern som innehåller livedata
• Den ursprungliga behållaren (som innehåller både aktiva och döda data) tas sedan bort och underliggande diskutrymme görs tillgängligt för användning

Molnnivå:

• Data som skrivs till molnnivån i en DDR struktureras på ett annat sätt – istället för att placeras i containrar på 4,5 Mb skrivs enskilda datasegment (komprimeringsregioner på 64 Kb) till molnenheten (OBS! för DDOS 6.1.2.0 och senare kommer objekt som lagras i molnenhetsenheten att vara större, se Data Domain: Stor objektstorlek för molnnivå för mer information)
• I stället för att extrahera livedata från ett befintligt komprimeringsområde och kopiera detta framåt, kommer Cloud Clean endast att överväga komprimeringsregioner som endast innehåller döda data för borttagning

Denna skillnad beror på den inneboende kostnaden för att läsa/skriva stora mängder data på molnlagring, men det innebär att en molnenhet kan bli artificiellt full (dvs. innehålla ett stort antal komprimeringsregioner, som var och en innehåller en mycket liten mängd livedata, vilket förhindrar att de tas bort).

Om den här situationen uppstår är det möjligt att ställa in systemparametrar som tvingar fram en "defragmenteringsrensning" av molnenheten - detta kommer att kopiera vidarebefordra livedata från befintliga komprimeringsregioner för att konsolidera livedata i så få komprimeringsregioner som möjligt, vilket gör att utrymme kan frigöras.

Om du vill ha mer information om hur du kör en "defragmenteringsrensning" kontaktar du din kontrakterade supportleverantör.