Data Domain: En innføring i langsiktig oppbevaring / rengjøring av nettskynivåer / søppelhenting på Data Domain Restorers (DDR-er)

Data Domain Operating System (DDOS) 6.0 introduserer en ny funksjon kjent som skyoppbevaring eller langsiktig oppbevaring (LTR). Denne funksjonen gjør at et andre nivå av objektbasert lagring klargjort av en nettskyleverandør kan legges til visse modeller av Data Domain Restorer (DDR) med en tilknyttet CLOUD_CAPACITY-lisens.

På systemer som bruker LTR-filer, blir inntatt av DDR først skrevet til det aktive nivået (lokalt tilkoblet lagring). Dataflyttingspolicyer/aldersterskler konfigureres deretter per tree, slik at enkelte filer som krever langsiktig oppbevaring, senere overføres fra det aktive til skynivået av dataflyttingsprosessen (en regelmessig planlagt oppgave).

Filer i skynivået kan slettes som normalt, men tilknyttet plass på nettsky-/objektlagring gjenvinnes ikke umiddelbart for bruk. Hvis du vil fjerne superflousdata fra skyen, må skynivået rengjøres.

Strukturen til skynivået:

Skynivået er delt inn i «skyenheter». Vær oppmerksom på at:

• Skynivået kan inneholde opptil to skyenheter
• Hver skyenhet kan være så stor som den maksimalt støttede aktive nivåstørrelsen for den gitte DDR-modellen
• Hver skyenhet kan klargjøres fra en annen leverandør av objektlagring

For eksempel:

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

Basic concepts of cloud cleaning:

• Cloud rengjøring opererer bare mot en enkelt skyenhet under hver kjøring - for å bestemme skyenheten som blir renset, finner du følgende melding i DDFS-logger (/ddr/var/log/debug/ddfs.info) - i dette tilfellet blir sky-enhet-virtustream1-skyenheten rengjort:

• Hvis et system har flere skyenheter konfigurert, vil skyrengjøring runde robin-rensing av disse enhetene og forsøke å rengjøre en enkelt enhet hver gang skyrensing kjøres
• Cloud clean kan startes manuelt eller automatisk via en tidsplan - for å starte manuelt brukes følgende kommando:

• Active Tier Clean og Cloud Clean kan ikke kjøre parallelt (på grunn av at begge bruker de samme minnestrukturene i DDFS)
• Hvis aktiv nivårensing kjører (startet enten manuelt eller via tidsplanen) og skyrensing forsøkes startet, vil det feile, dvs.:

• Hvis skyrensing har blitt startet automatisk (dvs. via tidsplanen) og aktiv nivårensing startes, blir skyenhetsrensing avbrutt for å tillate aktiv nivårensing å kjøre. Dette indikeres av følgende i DDFS-logger::

• Hvis skyrensing har blitt startet manuelt og aktivt forsøkes startet, vil ikke aktiv nivårensing starte - skyrensing vil bli igjen for å fullføre fullføring, dvs.:

• En skyenhet må ha opplevd minst 1% datafrafall (dvs. >= 1% av dataene som for øyeblikket er på skyenheten må anses å være superflous og derfor flyttbare) for at skyrensing skal starte. Hvis dette ikke er tilfelle, vises følgende på kommandolinjen hvis skyrensing startes manuelt:

• Hvis et system inneholder to skyenheter og planlagt rengjøring av den første enheten mislykkes av en eller annen grunn (for eksempel utilstrekkelig churn), vil rengjøringen automatisk forsøke å starte mot den andre enheten (dvs. det er ikke noe krav om å vente på neste planlagte kjøring av skyrensing for den andre enheten som skal rengjøres)
• Nettskyrensing kan begrenses (ligner på aktiv nivårensing) for å bestemme hvilke tiltak som skal iverksettes når systemet er under betydelig annen arbeidsbelastning (dvs. inntak/gjenoppretting/replikering).

Planlegging av skyrensing:

I DDOS 6.0 og senere er måten aktiv nivårengjøring er planlagt på ikke endret - som standard er aktiv nivårengjøring planlagt å kjøre en gang i uken kl 0600 på tirsdag, dvs.:

# filesys clean show tidsplan
Filesystem rengjøring er planlagt å kjøre "Tir" på "0600".

Opprydding i nettskyen er som standard planlagt å kjøre etter hver fjerde aktivering av planlagt rengjøring av aktivt nivå. For å vise tidsplanen for opprydding i nettskyen skal følgende kommando brukes:

# Hyppighet
for rydding av skyen Hyppighet for opprydding av nettskynivå er satt til å kjøre etter hver 4 aktive rengjøringssyklus.

Som et resultat, på et system med standardkonfigurasjon, vil cloud clean startes hver 4. uke - hvis systemet har to skyenheter, vil hver enhet bli rengjort en gang hver 8. uke.

For å endre skyens oppryddingsfrekvens kan følgende kommando brukes:

# Frekvenssett for opprydding i skyen 2
Rengjøringsfrekvens for nettskynivå er satt til å kjøre etter hver 2 aktive rengjøringssykluser.

For å tilbakestille Cloud Clean til standardplanen på etter hver 4 aktive tier rens, kan følgende kommando brukes:

# Cloud Clean Frequency Reset
Hyppighet for rengjøring av skynivå tilbakestilles til standard (hver fjerde aktive rengjøringssyklus).

Vær oppmerksom på at planen for opprydding i skyen ikke inkluderer manuelt startede aktive oppryddingssykluser for aktivt nivå. Som et resultat av dette, vil implementering av sporingsnivået bare starte én gang hver 4. uke selv om aktiv nivårengjøring ble kjørt manuelt hver eneste dag.

Det er også mulig å deaktivere planlagt skyrensing fullstendig ved å bruke følgende kommando:

# Cloud clean frequency set never
Cloud tier cleaning frequency is set to "never".

I dette tilfellet vil Cloud Clean bare kjøre når den startes manuelt.

For å stoppe en skyrensing som for øyeblikket kjører, kan følgende kommando brukes:

# Cloud clean stop

For å bestemme når cloud clean sist kjørte, kan følgende kommando brukes:

# Cloud clean status
Cloud tier cleaning ferdig på 2016/08/01 20:54:43.

Algoritme for rent nettsky:

Rengjøring i nettskyen bruker den samme rene algoritmen som er konfigurert for det aktive nivået. I DDOS 6.0 (og nyere) gjelder dette som standard perfekt fysisk søppelrydding (PPGC), men dette kan endres til fysisk søppelhenting (PGC) via systemparametere.

Merk at fysisk søppelhenting ikke bør deaktiveres, da bruk av den tradisjonelle/fullstendige rengjøringsalgoritmen til å rengjøre en skyenhet kan føre til DDFS-panikk/omstart

Algoritmen som brukes til skyrensing vises i DDFS-logger når ren starter, dvs.:
06/28 10:51:56.960 (tid 0x7fc5bccb2d50): GC: gc_start_intern
: Algoritme valgt: Fysisk rengjøring <=== PPGC eller PGC
07/27 12:21:18.224 (tid 0x7f92b8cfe7e0): GC: gc_start_intern: Algoritme valgt: Full rengjøring <=== Tradisjonell GC

Merk at fra ovennevnte utgang er det ikke mulig å skille mellom PPGC eller PGC - den spesifikke algoritmen som brukes er tydelig på grunn av antall faser som kjøres av ren - generelt:

Tradisjonell / full GC: 10 faser
PGC: 12 faser
PPGC: 6 faser
Hvis du vil ha mer informasjon om hvordan du endrer den rene algoritmen som brukes på et system, kan du kontakte den kontraktfestede kundestøtteleverandøren

Forskjeller mellom fasene for rensing på aktivt nivå og rengjøring av skynivå:

Kopieringsfasen for opprydding er fasen der superflousdata på en DDR fysisk fjernes/plassen gjenvinnes.
Vær oppmerksom på at det er forskjeller mellom hvordan kopieringsfasen fungerer mot det aktive nivået og skynivået:

Aktiv-nivået:

• Data som skrives til det aktive nivået av en DDR, finnes i beholdere på 4,5 Mb
• Som standard vil en beholder bare bli vurdert for "kopi" av ren hvis den inneholder <= 92% "live" (dvs. aktivt referert) data
• De aktive dataene blir trukket ut fra beholderen og skrevet til en ny beholder (sammen med live data fra andre kopierte beholdere) på slutten av filsystemet
• På disken oppdateres indeksene for å gjenspeile den nye beholderen som inneholder aktive data
• Den opprinnelige beholderen (som inneholder både aktive og døde data) blir deretter slettet, og underliggende diskplass gjort tilgjengelig for bruk

Nettskynivå:

• Data som skrives til skynivået til en DDR, er strukturert på en annen måte – i stedet for å plasseres i beholdere på 4,5 MB, skrives individuelle biter av data (komprimeringsområder på 64 kB) til skyenheten (MERK: For DDOS 6.1.2.0 og nyere vil objekter som er lagret i skyenhetsenheten, bli større, se Data Domain: Stor objektstørrelse for nettskynivå for mer informasjon)
• I stedet for å trekke ut live data fra et eksisterende komprimeringsområde og kopiere dette fremover, vil cloud clean bare vurdere komprimeringsregioner som inneholder utelukkende døde data for sletting

Denne forskjellen skyldes den iboende kostnaden som er involvert i lesing / skriving av store mengder data på skylagring, men det betyr at en skyenhet kan bli kunstig full (dvs. inneholde et stort antall komprimeringsregioner, som hver inneholder en svært liten mengde levende data som forhindrer fjerning).

Hvis denne situasjonen oppstår, er det mulig å sette systemparametere som tvinger en "defragmentering renere" av skyenheten - dette vil kopiere videresende live data fra eksisterende komprimeringsregioner for å konsolidere live data i så få komprimeringsregioner som mulig, slik at plass kan frigjøres.

Hvis du vil ha mer informasjon om hvordan du kjører en "rengjøring av defragmentering", kan du kontakte den avtalte støtteleverandøren.