Data Domain-besturingssysteem biedt geen ondersteuning voor proactieve herverdeling van data over storage na uitbreiding van de capaciteit van het Data Domain-bestandssysteem

Zoals bij veel storagearrays kan de capaciteit van de meeste modellen Data Domain Restorer (DDR) worden vergroot door externe storagebehuizingshelfs (ES30, DS60) aan het systeem toe te voegen en vervolgens het Data Domain File System (DDFS) uit te breiden naar deze behuizingsplanken. Wanneer dit is uitgevoerd:

• Nieuwe behuizingsplanken zijn fysiek bevestigd (bekabeld ingeschakeld)
• Het Data Domain Operating System (DDOS) scant storage opnieuw om vast te stellen of er nieuwe behuizingsplanken zijn
• Deze nieuwe behuizingsplanken worden vervolgens toegevoegd aan een opslaglaag binnen de DDR (de actieve laag of een specifieke archiefeenheid)
• Deze laag kan vervolgens online worden uitgebreid zonder dat DDFS hoeft te worden onderbroken
• Alle nieuwe data die naar die storagelaag worden geschreven, worden over bestaande en nieuwe planken geschreven
• Data op bestaande planken worden echter niet opnieuw gebalanceerd over nieuwe behuizingsrekken

Om dit verder uit te leggen:

• Binnen DDOS is de eenheid van datastorage een 4,5 Mb 'container'
• Terwijl ze worden gemaakt, worden 4,5 Mb-containers op een round robin-manier over alle planken van de behuizingen in de corresponderende laagarchiefeenheid geschreven
• Wanneer extra behuizingsplanken worden toegevoegd aan een archiefeenheid op een laag, begint DDFS met het schrijven van nieuwe 4,5 Mb-containers naar deze behuizingen naast bestaande behuizingen (de nieuwe behuizingen worden opgenomen wanneer round robin-container schrijft)
• DDOS doet echter geen specifieke poging (of biedt geen specifieke functionaliteit) om bestaande containers in de laag te migreren van bestaande naar nieuwe plankenbehuizingen

Dit betekent dat de toevoeging van plankbehuizingen ervoor kan zorgen dat data 'onevenwichtig' raken in de aangesloten storage. Bijvoorbeeld:

• Een DDR heeft in eerste instantie één behuizing in de actieve laag die voor 90% vol is
• Er wordt een extra behuizing toegevoegd aan de actieve laag en DDFS wordt uitgebreid naar deze behuizing
• Schrijfbewerkingen van nieuw aangemaakte 4,5 Mb containers zijn nu round robin over de bestaande en nieuwe behuizingen
• Hierdoor heeft de bestaande behuizing weinig vrije ruimte, terwijl de nieuw toegevoegde behuizing bijna leeg is

In dit scenario kunnen veel storage-arrays een beheerder in staat stellen om gegevens opnieuw in evenwicht te brengen over gekoppelde behuizingen, waarbij sommige gegevens proactief kunnen worden gemigreerd van bestaande behuizingen naar nieuw toegevoegde behuizingen om ervoor te zorgen dat de gebruikte capaciteit van alle behuizingen ongeveer gelijk is). Houd er echter rekening mee dat DDOS deze functionaliteit NIET biedt en vanwege het ontwerp van DDFS niet vereist is, omdat herverdeling van data op natuurlijke wijze in de loop van de tijd plaatsvindt.

Herverdeling van gegevens wordt uitgevoerd door twee bewerkingen:

• Vuilnisophaal schoonmaken
• Reparatie van de plaats

Elk van deze bewerkingen en hoe ze ervoor zorgen dat gegevens automatisch opnieuw in evenwicht worden gebracht, worden hieronder in meer detail besproken.

Vuilnisophaal schoonmaken

Het opschonen van garbage collection (GC) is een geplande activiteit die regelmatig wordt uitgevoerd op een DDR (standaard één keer per week op de actieve laag en, ervan uitgaande dat het vrijmaken van ruimte is ingeschakeld, indien nodig voor archiefeenheden). Wanneer het wordt uitgevoerd:

• Identificeert welke fysieke data binnen de archiefeenheid van de laag 'live' zijn (gebruikt door een of meer bestanden in het bestandssysteem of objecten zoals snapshots) of 'dood' (waar geen enkele object naar verwijst en dus overbodig is voor het systeem)
• Bepaalt de containers van 4,5 MB die het grootste deel van de 'dode' data bevatten in de archiefeenheid van de laag
• Leest deze containers van 4,5 MB en extraheert alle 'live' gegevens die ze bevatten - dit wordt vervolgens 'doorgestuurd' naar nieuw gemaakte containers van 4,5 MB die over alle planken in de archiefeenheid van de laag worden geschreven
• Verwijdert de oude 4,5 Mb-containers, waardoor de dode data die ze bevatten worden verwijderd en onderliggende ruimte op de schijf wordt vrijgemaakt voor hergebruik

Wanneer GC wordt uitgevoerd op een systeem met enige vorm van dataonbalans, wordt verwacht dat de meeste oude data (en dus de meeste dode data) op oudere plankbehuizingen binnen de laagarchiefeenheid worden bewaard. Als gevolg hiervan bevinden de meeste containers die worden gelezen, gekopieerd en verwijderd, zich op oudere plankbehuizingen. De nieuw gecreëerde containers zijn echter geschreven in een round robin-formaat tussen alle planken in de laag. Als gevolg hiervan bevindt de meeste ruimte die door GC wordt vrijgemaakt zich op oudere planken, terwijl nieuw verbruikte ruimte zich in alle schappen bevindt.

Als eenvoudig voorbeeld:

• De actieve laag van een DDR bevat twee planken: de eerste plank bevat 10000 containers van 4,5 MB, terwijl de tweede plank 100 containers van 4,5 MB bevat (voor elke container op de tweede plank zijn er 100 containers op de eerste plank)
• GC voert en kopieert doorgestuurde data van 5000 containers op de eerste plank
• Live data binnen deze 5000 containers zorgt ervoor dat er 1000 nieuwe 4,5 Mb containers worden gemaakt
• Deze 1000 nieuwe 4,5 Mb containers zijn over beide planken geschreven
• Zodra GC is voltooid, bevat de eerste plank dus 5500 containers van 4,5 MB, terwijl de tweede plank 600 containers bevat (voor elke container op de tweede plank zijn er ongeveer negen containers op de eerste plank)
• In een enkele run van GC is de onbalans van containers tussen de eerste en tweede plank met een factor 10 verminderd - dit zal naar verwachting verder worden verminderd tijdens volgende runs van GC, wat betekent dat de gegevens in de loop van de tijd op natuurlijke wijze opnieuw in de schappen worden gebalanceerd

Reparatie van de plaats:

Wanneer een bestand naar een DDR wordt geschreven, vinden de volgende bewerkingen op hoog niveau plaats:

• Het bestand wordt opgesplitst in logische blokken (segmenten genoemd) van 4-12 Kb groot
• Elk segment wordt gecontroleerd om te zien of het al bestaat op de schijf binnen de laag waarnaar het bestand wordt geschreven
• Als het segment al bestaat, zijn het dubbele gegevens en wordt het segment in het nieuw geschreven bestand vervangen door een aanwijzer naar bestaande gegevens op de schijf
• Als het segment niet bestaat, zijn het unieke gegevens en worden daarom verpakt in een nieuwe 4,5 Mb-container en naar schijf geschreven

Alle bestanden hebben het concept van 'lokaliteit', hoe sequentieel de gegevenssegmenten waarnaar door dat bestand wordt verwezen, op schijf op de DDR staan. Het is duidelijk dat bestanden met een hoge deduplicatieratio (die een grote hoeveelheid dubbele data bevatten) waarschijnlijk een slechtere lokalisatie hebben dan een uniek bestand, omdat wanneer hun data worden opgenomen, worden vervangen door verwijzingen naar bestaande data die mogelijk verspreid zijn over containers/schijven binnen de corresponderende archiefeenheid.

Om goede leesprestaties van gegevens op een DDR te bereiken, is het nodig dat het bestand een goede 'lokaliteit' heeft (de gegevens zijn relatief sequentieel op schijf), zodat DDFS-algoritmen optimaal kunnen functioneren. Houd er ook rekening mee dat DDFS ervan uitgaat dat het bestand dat het meest waarschijnlijk wordt gelezen (voor herstel of replicatie), de laatste kopie van een bepaalde back-up is. Als gevolg hiervan wordt voor bepaalde soorten data (zoals virtuele kunststoffen) een proces genaamd 'locality repair' uitgevoerd om de locatie van nieuw geschreven bestandsdata te 'optimaliseren'. Wanneer uitgevoerd, lokalisatiereparatie:

• Onderzoek de gegevens waarnaar in het bestand wordt verwezen en zoek naar secties waar de gegevens niet opeenvolgend zijn op de schijf (geeft een slechte locatie weer)
• Lees deze niet-sequentiële data van de schijf en schrijf deze opnieuw sequentieel (als dubbele data) naar nieuw gemaakte 4,5 Mb containers

Er wordt dan verwacht dat de oude (niet-sequentiële) kopie van dubbele gegevens tijdens de volgende GC-run als 'dood' wordt geïdentificeerd en uit het systeem wordt verwijderd. Als gevolg daarvan:

• Op systemen met een onevenwichtige data wordt verwacht dat de meeste oude niet-sequentiële data op oude, meer volledig gevulde behuizingsplanken staan
• Wanneer deze gegevens opeenvolgend worden herschreven als dubbele gegevens, worden ze in nieuwe containers van 4,5 MB geplaatst die round robin zijn voor alle behuizingen in de bijbehorende laag
• Als gevolg hiervan bestaat het grootste deel van de 'dode' (oude dubbele gegevens) die door lokaliteitsreparatie zijn gemaakt, op oude, meer volbezette planken
• Wanneer GC wordt uitgevoerd, wordt het merendeel van de 'dode' data vervolgens gevonden op oude, meer volledig gevulde schappen en verwijderd (ruimte vrijgemaakt op deze planken) zoals hierboven beschreven

Conclusie

Als gevolg hiervan kan een DDR door normaal gebruik van de functionaliteit voor reparatie en opschoning (Locality Repair and Cleaning) in de loop van de tijd op transparante wijze gegevens in de schappen opnieuw in evenwicht brengen. Dit gebeurt zonder extra input van beheerders en betekent dat er geen speciale functionaliteit voor dataherbalancering nodig is, zoals soms wordt gezien op andere storagearrays. Om de snelheid waarmee herbalancering plaatsvindt te verhogen, is het daarom noodzakelijk om:

• Verhoog de snelheid waarmee data 'churns' op de DDR
• Verhoog de hoeveelheid data die lokaal wordt gerepareerd op de DDR

Als u een van deze opties verder wilt bespreken, neemt u contact op met uw gecontracteerde supportprovider met vermelding van de details van dit artikel.