Avamar: Gedrag en theorie van back-upprestaties

Het doel van dit artikel is om te beschrijven wat er gebeurt tijdens een Avamar-back-up met de focus op het helpen van de lezer om het gedrag van back-upprestaties te begrijpen.

Dit artikel is een aanvulling op de volgende artikelen:

• Avamar: Trage back-upprestaties oplossen
• Avamar: Back-ups afstemmen om ze snel te voltooien

Wat gebeurt er tijdens een Avamar back-up?

Het avtar-back-upproces:

1) Laadt het bestand en de hash cache-bestanden in het geheugen

2017-06-09 23:00:25 avtar Info <5586>: Loading cache files from C:\Program Files\avs\var
2017-06-09 23:00:25 avtar Info <8650>: Opening filename cache file 'C:\Program Files\avs\var\f_cache2.dat'
2017-06-09 23:00:25 avtar Info <5573>: - Loaded filename cache file (6,532,792 bytes)
2017-06-09 23:00:26 avtar Info <8650>: Opening hash cache file 'C:\Program Files\avs\var\p_cache.dat'
2017-06-09 23:00:28 avtar Info <5573>: - Loaded hash cache file (402,653,728 bytes)
2017-06-09 23:01:01 avtar Info <6426>: Done loading cache files

2) Maakt VSS-snapshots (op Windows):

2017-06-09 23:04:32 avtar Info <19008>: Obtaining available VSS providers
2017-06-09 23:04:32 avtar Info <8776>: Freezing volumes now...
2017-06-09 23:04:32 avtar Info <8780>: Creating the shadow copy set (DoSnapshotSet) ... 
2017-06-09 23:14:33 avtar Info <8781>: Shadow copy set successfully created.
2017-06-09 23:14:34 avtar Info <6074>: VSS snapshot set creation successful

3) Loopt alle bestanden die door de dataset zijn gedefinieerd Voor alle bestanden binnen de brondataset
neemt avtar het volledige pad en combineert het met de stat-achtige metadata om een hash te berekenen om het bestand uniek te identificeren.

Zie Avamar voor meer informatie: Wat gebeurt er als avtar een bestand leest tijdens de bestandsscanfase.

4) Vergelijk berekende hashes met die in de lokale clientcaches Avtar

zoekt de hash van het bestand op in de bestandscache. Het controleert of het nieuw is of dat het is gewijzigd sinds de vorige back-up.

Als het opzoeken van de bestandscache slaagt, bestaat het bestand en is het ongewijzigd.

Als het opzoeken mislukt, is het bestand nieuw of gewijzigd. Het moet worden gelezen en verwerkt.

Voor meer details, zie Avamar client - Wat moet er veranderen voordat avtar een bestand als gewijzigd beschouwt?

5) Verwerk nieuwe en gewijzigde bestanden

Voor elk nieuw of gewijzigd bestand moet avtar :

• Lees het hele bestand
• Verdeel het in brokken van variabele grootte
• Comprimeer elk blok
• Bereken een hash voor elke chunk

6) Controleer of ontbrekende hashes aanwezig zijn op de Avamar server.

Avtar stuurt gegevens voor ontbrekende hashes via het netwerk naar de Avamar-server om te controleren of ze al bestaan. Deze staan bekend als 'ispresent'-verzoeken.

7) Data worden geschreven naar de Avamar Server (en indien van toepassing, Data Domain). 

Zie de bijgevoegde Avtarprocess.pdf voor een meer gedetailleerde workflow.


Overzicht van een Avamar back-up vanuit een prestatieperspectief:

Door de bovenstaande fasen te nemen, splitsen we ze op in 'fasen' die de grootste impact hebben op de back-upprestaties:

Fase 0. VSS-snapshots maken.

De Volume Shadowcopy Service (VSS) maakt snapshots van volumes die zijn opgegeven in de brondataset. Applicaties kunnen naar het volume blijven schrijven terwijl de back-up wordt uitgevoerd.
Avamar maakt een back-up van de alleen-lezen 'bevroren' snapshot van het volume in plaats van het beschrijfbare volume. Dit zorgt ervoor dat er een consistente set gegevens is om een back-up van te maken.

VSS-snapshots nemen enkele seconden in beslag. Als een client VSS-problemen ondervindt, zorgt dit ervoor dat de back-up wordt vertraagd of verhinderd.

Fase 1. Fase van bestandsscan. Het avtar-proces stelt alle bestanden in de doeldataset

vastVoor klanten met miljoenen bestanden kan deze fase het meest tijdrovend zijn.
Databasegegevens bevatten weinig, grotere bestanden, dus de bestandsscanfase neemt weinig tijd in beslag. Databaseclients verbruiken doorgaans hun tijd tijdens fase #2.

Voor een client met roterende schijven in RAID 5-configuratie zijn bestandsscanprestaties van ~1 miljoen bestanden per uur standaard. Dit varieert van 300.000 tot 3 miljoen per uur. Dit hangt af van de clientomgeving en de kenmerken van de data waarvan een back-up wordt gemaakt.

Vanaf v7.3 kunnen Linux-clients die een back-up maken van Data Domain profiteren van Linux Fast Incremental (LFI)-functionaliteit. Dit voorkomt dat elke keer dat de back-up wordt uitgevoerd, de hele dataset wordt gescand.

Kritieke bronnen: willekeurige zoekprestaties van de schijf waarop de back-updata zijn opgeslagen.

Fase 2. Avtar leest gewijzigde bestanden en splitst, comprimeert en hasht de gegevens vervolgens.

In deze fase vindt veel rekenwerk plaats. Voor elk gewijzigd of nieuw bestand breekt avtar het in kleine stukjes. Het comprimeert elke chunk en berekent een hash als een 'vingerafdruk' om de chunk te identificeren.

Bestanden in databaseback-ups zijn vaak groot en worden vaak dagelijks gewijzigd. Avtar brengt het grootste deel van zijn tijd door in deze fase. Het is het beste om officiële Avamar-databaseplug-ins te gebruiken om ervoor te zorgen dat de database efficiënt wordt verwerkt, waarbij gebruik wordt gemaakt van incrementele back-upfunctionaliteit, transactielogboeken, enzovoort.

De standaardprestaties voor bestandsverwerking liggen rond de 100 GB per uur, maar kunnen variëren tot 300 GB per uur. Dit is omgevingsafhankelijk.

Essentiële resources: Clientschijf en CPU

Voor LAN-back-ups waarbij er geen knelpunten zijn bij het verzenden van data naar de Avamar server, nemen fase #1 en #2 de meeste tijd in beslag.

Bedenk in de volgende grafiek dat de hoeveelheid oppervlakte in de staven van de grafiek overeenkomt met hoe lang de back-up duurt. Gewijzigde bestanden kunnen de benodigde tijd drastisch verlengen, vooral als die bestanden groot zijn.

Verwacht voor datasets van het bestandssysteem dat ~0-3% van de bestanden dagelijks verandert.

Avtar moet elk bestand dat verandert 'stat()' door twee I/O-bewerkingen uit te voeren, één om de bestandsattributen te controleren, een andere voor de beveiligingsattributen.

Om de benchmarkprestaties van de scansnelheid van één ~1 miljoen bestanden/uur voor back-ups van het bestandssysteem te bereiken, vereist avtar ongeveer twee miljoen zoekbewerkingen per uur, of 600 zoekbewerkingen per seconde.

Bijvoorbeeld: Als een back-up een wijzigingspercentage van 3% heeft, moeten 97 van de 100 bestanden twee schijven zoeken om te bepalen of ze zijn gewijzigd. De overige drie die wel zijn veranderd, moeten worden gescand, in stukjes gesneden, gecomprimeerd en gehasht.

Hierbij wordt alleen rekening gehouden met de bestandsscanfase en wordt geen rekening gehouden met I/O-resources die nodig zijn voor het verwerken van gewijzigde bestanden.
Hoe meer gegevens zich in de gewijzigde bestanden bevinden, des te meer werk er nodig is om de back-up te maken.

Fase 3. Het bestaan van hashes op de Avamar-server

controlerenFasen #1 en #2 produceren hashes die verwijzen naar elementen van de back-up. Deze elementen kunnen unieke bestandsblokken, bestandssystemen of volledige back-ups zijn.

De hashes worden naar de cachebestanden van de client geschreven en vergeleken met de hashes op de Avamar-server om te controleren of er nieuwe data moeten worden toegevoegd. Dit geldt ongeacht of een Avamar server of Data Domain de doelstorage is.

Hasj-vergelijkingen tussen Avamar-client en server zijn doorgaans snel. Ze mogen de back-up niet belemmeren als de Avamar-server dat is;

• Gezonde
• Onder normale belastingsniveaus
• Bevindt zich op hetzelfde LAN-segment als de client

Aangezien de hashes slechts 20 bytes groot zijn, wordt deze fase meer beïnvloed door netwerklatentie dan door netwerkbandbreedte. Wanneer de hash aankomt op de Avamar-server, bepalen de algemene belasting en de willekeurige zoekprestaties van het schijfsubsysteem van de dataknooppunten hoe snel de hash wordt opgehaald en vergeleken met de hash die door de client wordt verzonden.

Essentiële resources: Reactietijd van het netwerk en prestaties van willekeurig zoeken naar Avamar-dataknooppunten.

De willekeurige zoekprestaties van een fysieke Avamar-schaal met het aantal en de grootte van dataknooppunten. AVE-systemen presteren minder goed, vergelijkbaar met een systeem met één knooppunt.

Fase 4. Het nieuwe segment via het netwerk naar de Avamar-server of Data Domain

verzendenWanneer een client een nieuw, uniek segment (maximaal 64 kB groot) naar de server stuurt, zijn de prestaties voornamelijk afhankelijk van de netwerkbandbreedte. Dit treft vooral WAN-gebaseerde clients die elke dag een grote hoeveelheid gewijzigde gegevens genereren. Het kan ook gevolgen hebben voor degenen die werken via overbelaste netwerkverbindingen. 

Hieronder vindt u schema's die de datastroom weergeven waarbij een client data verzendt naar een Avamar-systeem en naar een geïntegreerd Avamar - Data Domain-systeem.






Essentiële resources: Netwerkbandbreedte tussen client en server

Fase 5. Data geschreven naar Avamar server of Data Domain

Back-updata moeten naar de Avamar-server of het Data Domain-systeem worden geschreven.

Essentiële resources: Schrijfprestaties en algemene belasting van Avamar-serverschijven.