Data Domain: Een overzicht van de fases (GC)-fasen van het data Domain File System (DDFS) schoon/garbage-collectie

Het data Domain File System (DDFS) is niet hetzelfde als een groot aantal veelvoorkomende bestandssysteem implementaties. als een bestand wordt verwijderd uit de bestandssysteem ruimte die door dat bestand wordt gebruikt, niet onmiddellijk beschikbaar is voor hergebruik. De reden hiervoor is dat de data Domain Restorer (DDR) niet onmiddellijk weet of de gegevens waarnaar wordt verwezen door het verwijderde bestand ook worden gedupliceerd met andere bestanden en dat het veilig is om die gegevens te verwijderen.

Het opschonen (ook wel garbagecollection/GC genoemd) is het proces waarmee een DDR:

• Bepaalt welke gegevens op schijf overbodig zijn (waarnaar wordt verwezen door objecten zoals bestanden of momentopnamen)
• Fysiek verwijdert overbodige gegevens die de onderliggende schijfruimte beschikbaar maken voor hergebruik (bijv. ingestie van nieuwe gegevens)

Opschonen/GC wordt doorgaans met regelmatige intervallen uitgevoerd (het start op 6am elke dinsdag) en kan zijn:

• Lang uitgevoerd
• Rekenbaar duur

Let op dat er geen andere manier is dan door het uitvoeren van schone/GC waarin de gegevens kunnen worden verwijderd/ruimte die fysiek is vrijgemaakt op een Data Domain-Restorer (d.w.z. er zijn geen snelkoppelingen waarmee dit proces kan worden versneld).

In dit artikel worden schone/GC-details beschreven:

• De fasen die normaal opschonen worden uitgevoerd
• De verschillende clean-algoritmen die worden gebruikt in verschillende versies van DDOS

Geen

Elke keer dat schonen/GC wordt uitgevoerd, heeft het twee hoofddoelen-in het DDR-een beknopt overzicht van hoe dit gebeurt, is het volgende te vinden:

• Clean/GC inventariseert de inhoud van het DDFS-bestandssysteem dat zoekt naar objecten zoals bestanden, momentopnamen en replicatielogboeken die op dit moment op het systeem aanwezig zijn.
• Vervolgens worden alle fysieke gegevens op schijf vastgesteld waarnaar door deze objecten wordt verwezen.
• Gegevens die actief zijn, worden ' live ' genoemd en kunnen niet worden verwijderd uit het DDR anders zijn de objecten die verwijzen naar deze gegevens beschadigd raken (ze kunnen niet meer worden gelezen als de onderliggende gegevens waarvan ze afhankelijk zijn, zijn niet meer op schijf aanwezig)
• Gegevens die niet actief worden genoemd door een willekeurig object, worden ' dood ' genoemd en zijn overbodig-deze gegevens kunnen veilig uit het systeem worden verwijderd.
• Alle gegevens op een DDR worden verpakt in objecten van 4,5 MB in de vorm van containers.
• Via inventarisatie opschonen/GC kan bepalen welke containers van 4,5 MB dode gegevens bevatten en de hoeveelheid dode gegevens in elke
• Standaard worden bij opschonen/GC 4,5 MB-containers geselecteerd > 8% dode gegevens voor de verwerking.

In de tweede plaats moeten inactieve gegevens worden verwijderd van de DDR-een korte uitleg over de wijze waarop dit wordt gedaan:

• Containers die zijn geselecteerd voor verwerking worden opnieuw gecontroleerd om te bevestigen dat ze een goede hoeveelheid gegevens bevatten
• Live gegevens worden uit deze containers geëxtraheerd en naar nieuwe 4,5 MB-containers aan het eind van het bestandssysteem geschreven.
• Zodra dit is voltooid, worden de geselecteerde containers (inclusief de dode gegevens die zich daarin bevinden) verwijderd van de schijf fysiek vrijmaken van de schijfruimte

Het schone proces wordt gesplitst in een aantal ' fasen ', waarbij het totale aantal fases afhankelijk zijn van:

• De versie van DDOS die wordt gebruikt op de DDR (dus het schone algoritme dat standaard wordt gebruikt door die versie van DDOS)
• De configuratie/inhoud van het systeem

Over het algemeen is het proces om ' inactieve ' gegevens te vinden en het selecteren van bijbehorende containers over een aantal fasen te voorspannen, terwijl het verwijderen van de dode data plaatsvindt in één fase genaamd ' Copy '. In bepaalde versies van DDOS worden bijvoorbeeld de volgende nieuwe fasen uitgevoerd:

1. Pre-enumeratie-de inhoud van het DDFS-bestandssysteem inventariseren
2. Voor samenvoegen-een DDFS-samenvoeging uitvoeren om ervoor te zorgen dat het nieuwste exemplaar van indexgegevens naar de schijf wordt geleegd.
3. Pre-filter-Bepaal of er dubbele gegevens zijn in het DDFS-bestandssysteem en indien dit zo is
4. Pre-Select-bepaalt welke 4,5 MB-containers moeten worden ' verwerkt ' door te reinigen
5. Copy-fysiek Haal live-gegevens uit geselecteerde containers, schrijf dit naar nieuwe containers en verwijder geselecteerde containers.
6. Samenvatting-overzichts vectoren opnieuw opbouwen (die worden gebruikt als optimalisatie tijdens de ingestie van nieuwe gegevens)

In de bovenstaande voorbeeld 1-4 fasen wordt gebruikt om te bepalen waar de gegevens op de DDR staan ("enumeratie fasen" genoemd in de rest van dit document), terwijl fase 5 (kopie) wordt gebruikt om deze gegevens fysiek te verwijderen.

Let op: er wordt geen ruimte fysiek vrijgemaakt op het systeem totdat clean/GC de kopieerfase bereikt. Het kan zijn dat er een aanzienlijke vertraging is tussen schone start en de ruimte die begint te worden vrijgemaakt (omdat het inventarisatieproces de eerste keer wordt uitgevoerd op voltooiing). Voor deze reden moet u niet de mogelijkheid hebben om 100% vol te vullen voordat schonen/GC wordt gestart.

Inventarisatie fasen zijn duur in termen van CPU-gebruik (d.w.z. ze zijn doorgaans CPU-gebonden), terwijl de kopieerfase duur is in termen van CPU en I/O (dit zijn doorgaans CPU en I/O-gebonden). Kortom, het is echter mogelijk te zeggen dat:

• De totale lengte van de inventarisatie fasen hangt af van de hoeveelheid gegevens op de DDR die moet worden geïnventariseerd.
• De totale lengte van de kopieerfase hangt af van de hoeveelheid onbestelbare gegevens op de DDR die moeten worden verwijderd en hoe ' gefragmenteerd ' moet worden dat de gegevens op schijf (worden beschreven).

Het aantal of de functionaliteit van inventarisatie fasen hangt af van de versie van DDOS die op een DDR wordt gebruikt.

DDOS 5,4 (en ouder)-volledig schoon algoritme: Voert 6 of 10 fasen uit (zie hierboven):

• De inhoud van het DDFS-bestandssysteem wordt op de voorgrond weergeven (dit is bijvoorbeeld het bestand System-Centr).
• DDFS detecteert alle bestanden op het DDR en scant vervolgens elk bestand op zijn beurt om te bepalen aan welke gegevens door dat bestand wordt verwezen.
• Hierdoor kan clean/GC bepalen welke gegevens op de schijf ' live ' zijn.

DDOS 5,5 (en later)-fysiek clean algoritme (PGC): Voert 7-of 12-fasen uit:

• De inhoud van de DDFS wordt onderaan genummerd (d.w.z. niet meer afzonderlijke bestanden)
• DDFS detecteert bestandssysteem-metagegevens die verwijzen naar fysieke gegevens op schijf en scant de metadata om te bepalen van welke gegevens wordt verwezen
• Hierdoor kan clean/GC bepalen welke gegevens op de schijf ' live ' zijn.
• Dit wordt verwezenlijkt door toevoeging van een ' analyse '-fase (het aantal keren verhogen van de fase over het volledige verruimings algoritme)
• In de meeste gevallen zal de totale duur van fysiek schonen echter korter zijn dan volledig reinigen voor hetzelfde systeem (ondanks meerdere afzonderlijke fasen).

DDOS 6,0 (en later)-perfect fysiek clean algoritme (PPGC):

• Dit is slechts een optimalisering van het fysiek opschonings algoritme en wordt verder behandeld.

Merk op dat DDOS is overgeschakeld van het volledige overbodige algoritme tot het fysiek opschonings algoritme om de schaalbaarheid en prestaties van het inventarisatieproces te verbeteren-vanwege de belangrijkste aard van het volledige verruimings algoritme dat niet goed op de Ddr's is geschaald met:

• Een groot aantal kleine bestanden (zoals de context schakelaar bij het verplaatsen van de inventarisatie van een bestand naar het volgende was duur/langzaam)
• Hoge de-duplicatie ratio (als meerdere bestanden waarnaar dezelfde fysieke gegevens verwijzen, zodat dezelfde gegevens meerdere keren werden opgesomd)

Ddr's-schakelaar automatisch van volledig naar fysieke clean-algoritmen wanneer u een upgrade uitvoert van DDOS 5,4 (of eerder) naar 5,5 (of later). De enige uitzondering hierop is systemen die zijn geconfigureerd met uitgebreide Bewaar mogelijkheden, waarbij de inhoud van het DDFS-bestandssysteem moet worden gecontroleerd op ' spanning '-bestanden voordat de fysieke opschoning kan worden ingeschakeld-een bespreking van dit proces valt buiten het bereik van dit document. deze controle wordt niet meer uitgevoerd na de upgrade en fysiek opschonen is ingeschakeld na voltooiing van deze controle zonder hand

Vergelijkbare Ddr's schakelen van fysiek naar perfecte fysieke opschonings algoritmen automatisch bij een upgrade van DDOS 5. x naar 6,0 (of later). Houd er echter rekening mee dat de perfecte fysieke overbodige algoritme indexen nodig hebben om de indeling "index 2,0" te hebben voordat deze kan worden gebruikt. Let op:

• De indeling "index 2,0" is geïntroduceerd bij DDOS 5,5 (alle bestandssystemen die op 5,5 of later zijn gemaakt, zullen al gebruik maken van index 2,0)
• Het bestandssysteem dat op 5,4 of eerder is gemaakt, heeft in eerste instantie indexen in de index 1,0-indeling. Na upgrade naar DDOS 5,5 (of later) de indexen zullen worden geconverteerd naar de index 2,0 indeling-conversie gebeurt elke keer dat een schone start wordt uitgevoerd, zodat het tot 2 jaar kan duren (indien een schone uitvoering wekelijks wordt uitgevoerd) om indexen volledig te converteren naar de 2,0-indeling.

Ddr's waarop DDOS 5,4 (of eerder) wordt uitgevoerd en die daarna zijn geüpgraded naar DDOS 5,5 (of later) kunnen worden gedwongen om indexen te converteren naar de index 2,0-indeling met één keer ' index Rebuild '. Houd er echter rekening mee dat een herbouw van een index een periode van inactief moet zijn terwijl de indexen fysiek opnieuw worden opgebouwd-deze bewerking duurt doorgaans 2-8 uur om te voltooien, afhankelijk van de grootte/hoeveelheid gegevens op de DDR. Neem contact op met uw gecontracteerde support provider als u wilt bespreken over het uitvoeren van een index opnieuw samenstellen.

Zoals hierboven vermeld, ongeacht of het Clean/GC-algoritme gebruikt kan worden, is het mogelijk dat een variabel aantal fasen vereist is, bijvoorbeeld omdat de volledige verouderde algoritme 6 of 10 fasen vereist. De reden hiervoor is dat:

• Wanneer DDFS wordt gestart, wordt een vaste hoeveelheid geheugen gereserveerd die wordt gebruikt door schone/GC
• In deze geheugen opschonen/GC worden gegevensstructuren gemaakt om de resultaten van de inventarisatie te beschrijven (d.w.z. waar live VS-dode gegevens bestaan op schijf)
• Wanneer een DDR een relatief kleine hoeveelheid gegevens bevat, kan de gehele inhoud van het DDFS-bestandssysteem in dit geheugengebied worden beschreven.
• Op veel systemen is dit echter niet mogelijk en is dit geheugengebied uitgeput voordat de gehele inhoud van het DDFS-bestandssysteem werd geïnventariseerd.
• Het resultaat van deze systemen is "sample", waarmee het aantal vereiste schone fasen wordt vergroot.

Wanneer een steekproef wordt gebruikt, zal schone/GC-software het volgende doen:

• Voer een monster controle van de inventarisatie uit voor het hele bestandssysteem-Let op: deze inventarisatie is niet "complete" (geen volledige informatie over elk onderdeel van het bestandssysteem), maar bevat in plaats daarvan informatie over de verschillende onderdelen van het bestandssysteem.
• Gebruik deze bemonsterings informatie om te bepalen welk deel van het DDFS-bestandssysteem het meest geschikt is voor het uitvoeren van een schone/GC-bewerking (d.w.z. welk deel van het bestandssysteem de beste teruggave zou geven in de ruimte die wordt vrijgemaakt als deze is gereinigd)
• Voer een tweede ronde van volledige inventarisatie uit met betrekking tot het geselecteerde deel van het bestandssysteem waarvan de inhoud nu volledig kan worden beschreven in het geheugen dat is gereserveerd voor GC.

De bemonstering wordt automatisch ingeschakeld tijdens opschonen/GC, indien vereist echter:

• Een toename van het aantal fasen dat moet worden uitgevoerd door schonen/GC
• Een bijbehorende toename van totale duur van schone/GC

Voorafgaand aan DDOS 6,0 de meeste van Ddr's monster nemen tijdens opschonen/GC (tenzij ze een relatief kleine data set bevatten). Het perfecte fysieke schone algoritme omvat echter verschillende optimalisaties om de hoeveelheid geheugen te verminderen die nodig is voor schone/GC bij het inventariseren van gegevens binnen het bestandssysteem. Dit betekent dat veel systemen die worden uitgevoerd tijdens het opschonen/GC op DDOS 5. x niet langer monsters hoeven te nemen op DDOS 6,0-dit vermindert het aantal fasen die worden uitgevoerd door schonen en veroorzaakt een afname in de totale hoeveelheid schone uitvoer (d.w.z. verbetering van schone prestaties).

Er is geen informatie beschikbaar om direct te bepalen dat een systeem is overgeschakeld van het fysieke schone algoritme naar het perfecte fysieke schone algoritme, anders dan:

• Tijdens het uitvoeren van de fysieke opschoning van het systeem op DDOS 5,5-5,7 werd 12 fasen uitgevoerd tijdens het schoonmaken.
• Na het uitvoeren van een upgrade van het systeem naar DDOS 6,0 (of later) worden tijdens het schoonmaken slechts 7 fasen uitgevoerd

Als een systeem met DDOS 6,0 nog steeds een steekproef moet uitvoeren, wordt deze automatisch ingeschakeld tijdens het schoonmaken en zal het terugkeren naar het uitvoeren van 12 fasen tijdens het schoonmaken.

Ongeacht het schone algoritme gebruikt de kopieerfase (waar niet-actieve gegevens fysiek uit de systeembestanden worden verwijderd) op dezelfde manier in alle releases. De prestaties van de kopieerfase zijn in het algemeen afhankelijk van het volgende:

• De hoeveelheid dode gegevens die moet worden verwijderd
• De ' fragmentatie ' van deze dode gegevens (bijv. hoe het over de schijf wordt verspreid)

Zoals hierboven is beschreven, kunt u 4,5 MB selecteren die dode gegevens bevatten, alle Live-gegevens uit die containers uitpakken en die dynamische gegevens naar nieuwe containers schrijven en de oorspronkelijk geselecteerde containers verwijderen. In de volgende voorbeelden wordt beschreven waarom het fragmentatie van dode data belangrijk is:

voorbeeld 1:

• Er zijn 10 containers geselecteerd voor kopie (45Mb totaalgegevens)
• Alle indien deze containers geen Live gegevens bevatten (d.w.z. de gegevens die ze bevatten, zijn volledig niet-verwijzing/onbestelbaar)
• Als resultaat Kopieer hoeft u deze containers alleen te markeren als verwijderd voor vrije 45Mb fysieke ruimte op schijf

Voorbeeld 2:

• 100-containers zijn geselecteerd om te worden gekopieerd (450Mb totaalgegevens)
• Elk van deze containers bevat 90% live data/10% dode gegevens
• Voor het verwerken van deze containers kopieert u het volgende:

Een aanzienlijk hoger bedrag van I/O en CPU is vereist voor het uitvoeren van de kopie die wordt beschreven in voorbeeld 2 in vergelijking met die in voorbeeld 1, zodat het aanzienlijk langer duurt om 45Mb fysieke ruimte op schijf te vrijmaken in dit voorbeeld.

Gebruikers hebben over het algemeen geen controle over de ' fragmentatie ' van ongebruikte gegevens op de schijf op een DDR omdat dit heel veel is, is afhankelijk van het gebruik van het systeem of het type gegevens dat naar het systeem wordt geschreven. Houd er echter rekening mee dat deze clean/GC wel statistieken onderhoudt waarmee de ' fragmentatie ' van dode data tijdens de kopieerfase wordt vastgesteld (waardoor een gebruiker daarom kan bepalen of deze fragmentatie een mogelijk langdurige kopieerfase kan verklaren). Dergelijke statistieken van de laatste fase van schonen/GC worden verzameld in de ondersteunings periodes. Hieronder ziet u een voorbeeld van een kopieerfase waarbij dode data tamelijk aaneengesloten zijn (d.w.z. het merendeel van de containers die worden aangemerkt voor kopieën die voornamelijk dode gegevens worden opgeslagen):

percentage van de actieve gegevens in gekopieerde bestanden:              3,6% 4,3%

Omgekeerd toont een kopieerfase waar dode data is gefragmenteerd (d.w.z. het merendeel van de containers die zijn geselecteerd voor het plaatsen van gegevens in het leven gehouden Live gegevens):

percentage van de actieve gegevens in gekopieerd:             70,9% 71,5%

Zoals hierboven is beschreven moet schonen/GC relatief veel meer werk in het tweede scenario hebben om fysiek vrije ruimte te maken op het DDR waardoor de doorvoer van de kopieerfase wordt verkleind.

De doorvoer van een kopieerfase kan ook worden beïnvloed door:

• Het gebruik van codering: Gegevens moeten mogelijk worden gedecodeerd/opnieuw versleuteld tijdens de kopie die de benodigde hoeveelheid CPU aanzienlijk vergroot.
• Het gebruik van optimalisering van de bandbreedte: Containers moeten mogelijk informatie over de schets moeten worden gegenereerd tijdens het exemplaar, waardoor ook een aanzienlijke stijging van de vereiste hoeveelheid CPU veroorzaakt

Houd er rekening mee dat als de optimalisering van de bandbreedte en/of de versleuteling onlangs alle bestaande containers heeft ingeschakeld (ongeacht of deze al dan niet zijn geselecteerd voor kopie) en/of schets informatie moet worden gegenereerd tijdens latere reiniging-dit kan tot gevolg hebben dat de Clean bewerking (vooral de kopieerfase) aanzienlijk langer duurt dan normaal.

Meer opmerkingen over het controleren/wijzigen van een schone planning en beperking zijn beschikbaar in het volgende KB-artikel: https://support.emc.com/kb/306100-

Opmerking u ziet dat:

• In normale omstandigheden moet u de planning opschonen in de meeste tijdstippen waarop de data op schijf te reinigen zullen zijn. Dit kan leiden tot buitensporige ' gefragmenteerde ' (d.w.z. een slechte ruimtelijke lokale positie) die kan leiden tot slechte Lees-en replicatie/gegevensverplaatsing.
• Schone beperking heeft geen invloed op de totale hoeveelheid CPU en I/O-bandbreedte die door clean (schonen) wordt gebruikt en regelt hoe gevoelig schonen op het systeem is. Bijvoorbeeld:

• De standaardinstelling voor schone vertraging is ingesteld op 50-het is de verantwoordelijkheid van de gebruiker om de uitvoering van Clean met verschillende beperkingsinstellingen te testen, terwijl het DDR een normale werklast verkrijgt om te bepalen of het de volgende mogelijkheden biedt:

• Houd er rekening mee dat een langdurige schone reiniging niet noodzakelijkerwijs een probleem is, zo lang:

• Het systeem dat uitgebreide Bewaar functionaliteit gebruikt moet zo worden geconfigureerd dat:

• Volledige informatie van de meest recente opschoning is opgenomen in de ondersteunings-en informatie gegevens: