Data Domain: Een inleiding tot langdurig bewaren/opschonen van cloudlagen/garbage collection op DDR's (Data Domain Restorers)

Data Domain Operating System (DDOS) 6.0 introduceert een nieuwe functie die bekend staat als cloudretentie of langdurige retentie (LTR). Met deze functie kan een tweede laag objectgebaseerde storagelaag die is ingericht door een cloudprovider worden toegevoegd aan bepaalde modellen van Data Domain Restorer (DDR) met een bijbehorende CLOUD_CAPACITY-licentie.

Op systemen die LTR gebruiken, worden bestanden die door de DDR worden opgenomen, in eerste instantie naar de actieve laag (lokaal gekoppelde storage) geschreven. Beleidsregels/leeftijdsdrempels voor dataverplaatsing worden vervolgens per mtree geconfigureerd, zodat bepaalde bestanden die langdurig bewaren vereisen, later worden gemigreerd van de actieve naar de cloudlaag door het dataverplaatsingsproces (een regelmatig geplande taak).

Bestanden in de cloudlaag kunnen zoals normaal worden verwijderd, maar de bijbehorende ruimte in de cloud/objectstorage wordt niet onmiddellijk vrijgemaakt voor gebruik. Als u overtollige data uit de cloud wilt verwijderen, moet de cloudlaag worden opgeschoond.

Structuur van de cloudlaag:

De cloudlaag is onderverdeeld in 'cloud units'. Let op:

• De cloudlaag kan maximaal twee cloudeenheden bevatten
• Elke cloudeenheid kan zo groot zijn als de maximale grootte van het ondersteunde actieve niveau voor het opgegeven DDR-model
• Elke cloudeenheid kan worden ingericht door een andere objectstorageprovider

Bijvoorbeeld:# cloud unit list
Name Profile Status
----------------------- ------------ ------
B-unit LTR-ECS-Ben Actief <=== ECS provider
cloud-unit-virtustream1 virtustream1 Actief <=== Virtustream provider
----------------------- ------------ ------

Basisconcepten van cloud cleaning:

• Cloud cleaning werkt alleen tegen een enkele cloudeenheid tijdens elke run - om te bepalen welke cloudunit wordt opgeschoond, is de volgende melding te vinden in DDFS logs (/ddr/var/log/debug/ddfs.info) - in dit geval wordt de cloud-unit-virtustream1 cloud unit opgeschoond:

• Als een systeem meerdere cloudeenheden heeft geconfigureerd, zal cloud clean een round robin-opschoning van deze eenheden uitvoeren, waarbij wordt geprobeerd een enkele eenheid op te schonen telkens wanneer cloud clean wordt uitgevoerd
• Cloud clean kan handmatig of automatisch via een schema worden gestart - om handmatig te starten wordt de volgende opdracht gebruikt:

• Het opschonen van de actieve laag en het opschonen van de cloud kunnen niet parallel worden uitgevoerd (omdat beide dezelfde geheugenstructuren gebruiken binnen DDFS)
• Als actieve laagopschoning wordt uitgevoerd (handmatig of via het schema gestart) en er wordt geprobeerd om cloudopschoning te starten, zal er een fout optreden, d.w.z.:

• Als het opschonen van de cloud automatisch is gestart (d.w.z. via het schema) en het opschonen van de actieve laag is gestart, wordt het opschonen van de cloudeenheid afgebroken om de opschoning van de actieve laag uit te voeren. Dit wordt aangegeven door het volgende in DDFS-logboeken:

• Als cloudopschoning handmatig is gestart en er wordt geprobeerd om active tier clean te starten, wordt het opschonen van de actieve laag niet gestart - cloudclean wordt overgelaten om te worden uitgevoerd tot voltooiing, d.w.z.:

• Een cloudeenheid moet minimaal 1% dataverloop hebben ervaren (d.w.z. >= 1% van de data die momenteel op de cloudeenheid staan, moet als overbodig en dus verwijderbaar worden beschouwd) voordat cloudopschoning kan worden gestart. Als dit niet het geval is, wordt het volgende weergegeven op de opdrachtregel als cloud clean handmatig wordt gestart:

• Als een systeem twee cloudeenheden bevat en het geplande opschonen van de eerste eenheid om de een of andere reden mislukt (bijvoorbeeld onvoldoende verloop), dan zal clean automatisch proberen te starten tegen de tweede eenheid (d.w.z. er is geen vereiste om te wachten op de volgende geplande run van cloudclean om de tweede eenheid op te schonen)
• Cloud clean kan worden beperkt (vergelijkbaar met active tier clean) om te bepalen welke actie moet worden ondernomen wanneer het systeem onder significante andere workloads staat (d.w.z. opnemen/herstellen/replicatie).

Cloudopschoning plannen:

In DDOS 6.0 en hoger is de manier waarop de opschoning van de actieve laag is gepland niet gewijzigd - standaard wordt de opschoning van de actieve laag gepland om één keer per week om 0600 op dinsdag uit te voeren, d.w.z.:

# filesys clean show schedule
Het opschonen van het bestandssysteem is gepland om "Tue" uit te voeren om 0600.

Cloudopschoning is standaard gepland om uit te voeren na elke 4e aanroep van de geplande opschoning van de actieve laag. Om het cloud clean-schema weer te geven, moet de volgende opdracht worden gebruikt:

# cloud clean frequency show Cloud tier cleaning frequency is
ingesteld om te worden uitgevoerd na elke 4 actieve tier cleaning cycles.

Als gevolg hiervan wordt op een systeem met standaardconfiguratie elke 4 weken gestart met cloudopschonen. Als het systeem twee cloudeenheden heeft, wordt elke eenheid eens in de 8 weken opgeschoond.

Als u de opschoonfrequentie van de cloud wilt wijzigen, kan de volgende opdracht worden gebruikt:

# cloud clean frequency set 2
Cloud tier cleaning frequency is ingesteld om te worden uitgevoerd na elke 2 actieve cleaning tier-opschooncycli.

Om cloud clean te resetten naar het standaardschema van na elke 4 actieve tieropschoning, kan de volgende opdracht worden gebruikt:

# cloud clean frequency reset Cloud tier cleaning frequency is
reset to default (every 4 active tier cleaning cycles).

Houd er rekening mee dat het cloudopschoonschema geen handmatig gestarte opschooncycli van actieve lagen omvat. Als gevolg hiervan zou op het bovenstaande systeem, zelfs als het opschonen van de actieve laag elke dag handmatig zou worden uitgevoerd, slechts eens in de 4 weken beginnen.

Het is ook mogelijk om geplande cloudopschoning volledig uit te schakelen met de volgende opdracht:

# cloud clean frequency set never
Cloud tier cleaning frequency is ingesteld op "never".

In dit geval wordt cloud clean alleen uitgevoerd wanneer deze handmatig wordt gestart.

Om een momenteel actieve cloud clean te stoppen, kan de volgende opdracht worden gebruikt:

# cloud clean stop

Om te bepalen wanneer cloud clean voor het laatst is uitgevoerd, kan de volgende opdracht worden gebruikt:

# cloud clean status
Cloud tier cleaning finished at 2016/08/01 20:54:43.

Algoritme voor cloudopschoning:

Cloud clean gebruikt hetzelfde opschoonalgoritme als geconfigureerd voor de actieve laag. In DDOS 6.0 (en hoger) is dit standaard ingesteld op Perfect Physical Garbage Collection (PPGC), maar dit kan worden gewijzigd in Physical Garbage Collection (PGC) via systeemparameters.

Houd er rekening mee dat fysieke garbage collection niet moet worden uitgeschakeld, omdat het gebruik van het traditionele/volledige opschoningsalgoritme om een cloudeenheid op te schonen kan leiden tot een DDFS-paniek/herstart

Het algoritme dat wordt gebruikt voor cloudopschoning wordt weergegeven in DDFS-logboeken wanneer het opschonen begint, d.w.z.:
06/28 10:51:56.960 (tid 0x7fc5bccb2d50): gc: gc_start_intern
: Algoritme geselecteerd: Fysieke reiniging <=== PPGC of PGC
07/27 12:21:18.224 (tid 0x7f92b8cfe7e0): gc: gc_start_intern: Algoritme geselecteerd: Volledige reiniging <=== Traditionele GC

Merk op dat het op basis van de bovenstaande uitvoer niet mogelijk is om onderscheid te maken tussen PPGC of PGC - het specifieke algoritme dat wordt gebruikt is duidelijk vanwege het aantal fasen dat door clean wordt uitgevoerd - in het algemeen:

Traditional/full GC: 10 fasen
PGC: 12 fasen
PPGC: 6 fasen
Neem voor meer informatie over het wijzigen van het opschoonalgoritme dat op een systeem wordt gebruikt, contact op met uw gecontracteerde supportprovider

Verschillen tussen opschoonfasen van de actieve laag en opschoonfasen van de cloudlaag:

De opschoonfase van de kopieerfase is de fase waarin overtollige data op een DDR fysiek wordt verwijderd/ruimte wordt vrijgemaakt.
Houd er rekening mee dat er verschillen zijn tussen de manier waarop de kopieerfase werkt ten opzichte van de actieve en cloudlagen:

Actieve laag:

• Data die naar de actieve laag van een DDR worden geschreven, bevinden zich in containers van 4,5 MB
• Standaard komt een container alleen in aanmerking voor 'kopie' door clean als deze = 92% 'live' (d.w.z. actief gerefereerde) data bevat <
• De live-gegevens worden uit de container geëxtraheerd en naar een nieuwe container geschreven (samen met live-gegevens van andere gekopieerde containers) aan het einde van het bestandssysteem
• Indexces op schijf worden bijgewerkt om de nieuwe container weer te geven die de live-gegevens bevat
• De oorspronkelijke container (die zowel levende als dode gegevens bevat) wordt vervolgens verwijderd en onderliggende schijfruimte wordt beschikbaar gemaakt voor gebruik

Cloudlaag:

• Data die naar de cloudlaag van een DDR worden geschreven, zijn anders gestructureerd - in plaats van in containers van 4,5 MB te worden geplaatst, worden afzonderlijke brokken data (compressieregio's van 64 Kb) naar de cloudeenheid geschreven (OPMERKING: voor DDOS 6.1.2.0 en hoger zijn objecten die zijn opgeslagen in de cloudeenheideenheid groter, zie Data Domain: Grote objectgrootte voor cloudlaag voor meer informatie)
• In plaats van live data uit een bestaand compressiegebied te extraheren en deze naar voren te kopiëren, zal cloud clean alleen compressieregio's in overweging nemen die alleen dode data bevatten voor verwijdering

Dit verschil is te wijten aan de inherente kosten die gemoeid zijn met het lezen/schrijven van grote hoeveelheden gegevens op cloudopslag, maar het betekent wel dat een cloudeenheid kunstmatig vol kan raken (d.w.z. een groot aantal compressiegebieden kan bevatten, die elk een zeer kleine hoeveelheid live gegevens bevatten, waardoor ze niet kunnen worden verwijderd).

Als deze situatie zich voordoet, is het mogelijk om systeemparameters in te stellen die een 'defragmentatie-opschoning' van de cloudeenheid afdwingen - hierdoor worden live gegevens van bestaande compressieregio's gekopieerd om live-gegevens in zo min mogelijk compressieregio's te consolideren, waardoor ruimte kan worden vrijgemaakt.

Neem voor meer informatie over het uitvoeren van een 'defragmentatieopschoning' contact op met uw gecontracteerde supportprovider.