Data Domain: En introduktion til langsigtet opbevaring/rensning på cloudniveau/affaldsindsamling på Data Domain Restorers (DDRs)

DDOS (Data Domain Operating System) 6.0 introducerer en ny funktion, der kaldes cloudopbevaring eller langsigtet opbevaring (LTR). Denne funktion gør det muligt at føje et andet niveau af objektbaseret storage, der leveres af en cloududbyder, til visse modeller af Data Domain Restorer (DDR) med en tilknyttet CLOUD_CAPACITY licens.

På systemer, der bruger LTR, skrives filer, der indtages af DDR, oprindeligt til det aktive niveau (lokalt tilsluttet lager). Dataflytningspolitikker/aldersgrænser konfigureres derefter pr. MTree-basis, således at visse filer, der kræver langvarig opbevaring, senere overføres fra det aktive til cloudniveauet af dataflytningsprocessen (en regelmæssigt planlagt opgave).

Filer på cloudniveauet kan slettes som normalt, men tilknyttet plads på cloud-/objektlager frigøres ikke umiddelbart til brug. Hvis du vil fjerne overflødige data fra clouden, skal cloudniveauet renses.

Cloudniveauets struktur:

Cloudniveauet er opdelt i "cloudenheder". Bemærk, at:

• Cloudniveauet kan indeholde op til to cloudenheder
• Hver cloud-enhed kan være så stor som den maksimalt understøttede aktive niveaustørrelse for den givne DDR-model
• Hver cloudenhed kan klargøres fra forskellige udbydere af objektstorage

For eksempel:

# cloudenhedsliste
Navn Profilstatus
----------------------- ------------ ------
B-enhed LTR-ECS-Ben Aktiv <=== ECS-udbyder
cloud-enhed-virtustream1 virtustream1 Aktiv <=== Virtustream-udbyder
----------------------- ------------ ------

Grundlæggende begreber inden for cloudrensning:

• Cloud-rensning fungerer kun mod en enkelt cloud-enhed under hver kørsel - for at bestemme den cloud-enhed, der rengøres, kan følgende meddelelse findes i DDFS-logfiler (/ddr/var/log/debug/ddfs.info) - i dette tilfælde renses cloud-unit-virtustream1-cloudenheden:

• Hvis et system har flere cloud-enheder konfigureret, vil cloud clean afrunde rensning af disse enheder, der forsøger at rense en enkelt enhed, hver gang cloud clean køres
• Cloud clean kan startes manuelt eller automatisk via en tidsplan - for at starte manuelt bruges følgende kommando:

• Active tier clean og cloud clean kan ikke køre parallelt (fordi begge bruger de samme hukommelsesstrukturer i DDFS)
• Hvis aktiv niveaurensning kører (startes enten manuelt eller via tidsplanen), og cloud clean forsøges startet, vil det medføre fejl, dvs.:

• Hvis cloud clean er startet automatisk (dvs. via tidsplanen), og active tier clean startes, afbrydes clean fra cloudenheden, så active tier clean kan køre. Dette angives af følgende i DDFS-logfiler:

• Hvis cloud clean er startet manuelt, og active forsøges startet, vil active tier clean ikke starte – cloud clean vil blive kørt til færdiggørelse, dvs.:

• En cloud-enhed skal have oplevet mindst 1 % data "churn" (dvs. >= 1 % af de data, der aktuelt er på cloudenheden, skal anses for at være overflødige og derfor aftagelige), for at cloud clean starter. Hvis dette ikke er tilfældet, vises følgende på kommandolinjen, hvis cloud clean startes manuelt:

• Hvis et system indeholder to cloud-enheder, og planlagt rensning af den første enhed mislykkes af en eller anden grund (f.eks. utilstrækkelig churn), vil clean automatisk forsøge at starte mod den anden enhed (dvs. der er ikke noget krav om at vente på den næste planlagte kørsel af cloud clean for den anden enhed, der skal rengøres)
• Cloud-rensning kan begrænses (svarende til aktiv niveaurensning) for at bestemme, hvilken handling der skal udføres, når systemet er under betydelig anden arbejdsbelastning (dvs. indtagelse/gendannelse/replikering).

Planlægning af rensning i skyen:

I DDOS 6.0 og senere er den måde, hvorpå clean på aktivt niveau planlægges, ikke ændret - som standard er clean på aktivt niveau planlagt til at køre en gang om ugen kl. 0600 tirsdag, dvs.:

# filesys clean show schedule
Filesystem cleaning er planlagt til at køre "Tue" på "0600".

Cloud-rydning er som standard planlagt til at køre efter hver 4. aktivering af planlagt aktiv niveaurensning. For at få vist tidsplanen for rensning i skyen skal følgende kommando bruges:

# cloudrensningsfrekvens vises
Rengøringsfrekvensen for Cloud-niveauet er indstillet til at køre efter hver 4 aktive oprydningscyklusser.

Som følge heraf startes cloud clean på et system med standardkonfiguration hver 4. uge - hvis systemet har to cloud-enheder, rengøres hver enhed en gang hver 8. uge.

For at ændre frekvensen for rensning i skyen kan følgende kommando bruges:

# Frekvens for rensning i cloudmiljø 2
Rensningsfrekvens for cloud-niveauer er indstillet til at køre efter hver 2. oprydningscyklus på det aktive niveau.

For at nulstille cloud clean til standardplanen for efter hver 4 aktive niveauer renses, kan følgende kommando bruges:

# cloud clean frequency reset
Cloud tier cleaning frequency nulstilles til standard (hver 4 clean functional cleaning cycles).

Bemærk, at tidsplanen for rensning i clouden ikke omfatter manuelt startede rene cyklusser på aktivt niveau. Som følge heraf vil Cloud Tier Clean på ovenstående system kun starte en gang hver 4. uge, selvom Active Tier Clean blev kørt manuelt hver dag.

Det er også muligt helt at deaktivere planlagt cloud clean ved hjælp af følgende kommando:

# cloud clean frekvens set never
Cloud tier cleaning frequency er indstillet til "never".

I dette tilfælde kører Cloud Clean kun, når den startes manuelt.

For at stoppe en aktuelt kørende cloud clean kan følgende kommando bruges:

# cloud clean stop

For at finde ud af, hvornår cloud clean sidst kørte, kan følgende kommando bruges:

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

Algoritme til rensning af cloud:

Cloudclean bruger den samme rene algoritme, som er konfigureret til det aktive niveau. I DDOS 6.0 (og nyere) er dette som standard perfekt fysisk affaldsindsamling (PPGC), men dette kan ændres til fysisk affaldsindsamling (PGC) via systemparametre.

Bemærk, at indsamling af fysisk affald ikke bør deaktiveres, da brug af den traditionelle/komplette rensningsalgoritme til rengøring af en cloudenhed kan resultere i DDFS-panik/genstart
Algoritmen, der bruges til cloudrensning, vises i DDFS-logfiler, når rensning starter, dvs.:

06/28 10:51:56.960 (TID 0x7fc5bccb2d50): GC: gc_start_intern:
Valgt algoritme: Fysisk rengøring <=== PPGC eller PGC
07/27 12:21:18.224 (tid 0x7f92b8cfe7e0): GC: gc_start_intern: Valgt algoritme: Fuld rengøring <=== Traditionel GC

Bemærk, at det ud fra ovenstående output ikke er muligt at skelne mellem PPGC eller PGC - den specifikke anvendte algoritme er tydelig på grund af antallet af faser, der køres af clean - generelt:

Traditionel/fuld GC: 10 faser
PGC: 12 faser
PPGC: 6 faser
For yderligere oplysninger om ændring af den rene algoritme, der bruges på et system, skal du kontakte din kontraherede supportudbyder

Forskelle mellem clean pipe-faserne på aktivt niveau og clean copy på cloudniveau: Kopieringsfasen af clean er den fase,

hvor overflødige data på en DDR fysisk fjernes/plads genvindes.
Bemærk, at der er forskelle mellem, hvordan kopieringsfasen fungerer i forhold til det aktive niveau og cloudniveauet:

Aktivt niveau:

• Data, der skrives til det aktive niveau af en DDR, er indeholdt i 4,5 Mb beholdere
• Som standard vil en beholder kun blive betragtet som "kopi" ved ren, hvis den indeholder <= 92% "live" (dvs. aktivt refererede) data
• De levende data ekstraheres fra containeren og skrives til en ny beholder (sammen med live-data fra andre kopierede containere) i slutningen af filsystemet
• Diskindekser opdateres, så de afspejler den nye beholder med live-data
• Den oprindelige beholder (der indeholder både aktive og døde data) slettes derefter, og den underliggende diskplads gøres tilgængelig til brug

Cloud-niveau:

• Data, der skrives til cloudniveauet i en DDR, struktureres anderledes – i stedet for at blive placeret i 4,5 Mb beholdere skrives individuelle databidder (64 Kb komprimeringsområder) til cloudenheden (BEMÆRK: For DDOS 6.1.2.0 og nyere vil objekter, der er gemt i cloudenheden, være større, se Data Domain: Stor objektstørrelse til Cloud Tier for detaljer)
• I stedet for at udtrække dynamiske data fra et eksisterende komprimeringsområde og kopiere dette fremadrettet, vil cloud clean kun overveje komprimeringsområder, der udelukkende indeholder døde data til sletning

Denne forskel skyldes de iboende omkostninger, der er forbundet med at læse/skrive store mængder data på cloud storage, men det betyder, at en cloudenhed kan blive kunstigt fuld (dvs. indeholde et stort antal komprimeringsområder, som hver indeholder en meget lille mængde levende data, hvilket forhindrer deres fjernelse).

Hvis denne situation opstår, er det muligt at indstille systemparametre, der tvinger en 'defragmenteringsrensning' af skyenheden - dette kopierer live-data fremad fra eksisterende komprimeringsregioner for at konsolidere live data i så få komprimeringsområder som muligt, så der kan frigøres plads.

For yderligere oplysninger om at køre en 'defragmenteringsren' bedes du kontakte din kontraherede supportudbyder.