Avamar: Funktionsmåde og teori for backupydeevne

Formålet med denne artikel er at beskrive, hvad der sker under en Avamar-sikkerhedskopiering med fokus på at hjælpe læseren med at forstå backupydelsen.

Denne artikel er en ledsager til følgende artikler:

• Avamar: Fejlfinding af langsom sikkerhedskopiering
• Avamar: Finindstiller sikkerhedskopier til at blive gennemført hurtigt

Hvad sker der under en Avamar-sikkerhedskopiering?

Avtar-sikkerhedskopieringsprocessen:

1) Indlæser fil- og hash-cache-filer i hukommelsen

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) Opretter VSS-snapshots (på 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) Går i alle filer, der er defineret af datasættet For alle filer inden for kildedatasættet
tager avtar den fulde sti og kombinerer den med de stat-lignende metadata for at beregne en hash for entydigt at identificere filen.

For flere detaljer, se Avamar: Hvad sker der, når avtar læser en fil under filscanningsfasen.

4) Sammenlign beregnede hashes med dem i de lokale klientcacher

Avtar slår filens hash op i filcachen. Den kontrollerer, om den er ny, eller om den er blevet ændret siden den forrige sikkerhedskopiering.

Hvis filcacheopslaget lykkes, findes filen og er uændret.

Hvis opslaget mislykkes, er filen ny eller ændret. Det skal læses og behandles.

Du kan finde flere oplysninger under Avamar-klient – Hvad skal ændres, før avtar anser en fil for at være blevet ændret?

5) Behandl nye og ændrede filer

For enhver ny eller ændret fil skal avtar :

• Læs hele filen
• Opdel den i bidder af variabel størrelse
• Komprimer hver del
• Beregn en hashværdi for hver del

6) Kontrollér, om der mangler hashes på Avamar-serveren.

Avtar sender data for eventuelle manglende hashes over netværket til Avamar-serveren for at kontrollere, om de allerede findes. Disse kaldes »ispresent«-anmodninger.

7) Data skrives til Avamar Server (og hvis relevant, Data Domain). 

Du kan finde en mere detaljeret arbejdsgang i den vedhæftede Avtarprocess.pdf.


Oversigt over en Avamar-sikkerhedskopiering fra et ydeevneperspektiv:

Ved at tage ovenstående faser opdeler vi dem i 'faser', som har størst indflydelse på backupydelsen:

Fase 0. Opret VSS-snapshots.

Volume Shadowcopy Service (VSS) opretter snapshots af diskenheder, der er angivet i kildedatasættet. Programmer kan fortsætte med at skrive til diskenheden, mens sikkerhedskopien kører.
Avamar sikkerhedskopierer det skrivebeskyttede "fastfrosne" snapshot af diskenheden i stedet for den skrivbare diskenhed. Dette sikrer, at den har et ensartet sæt data, der skal sikkerhedskopieres.

VSS-snapshots tager sekunder at fuldføre. Hvis en klient oplever VSS-problemer, forsinker dette eller forhindrer sikkerhedskopieringen i at fortsætte.

Fase 1. Filscanningsfase. Avtar-processen statistikerer alle filer i måldatasættet

For klienter med millioner af filer kan denne fase være den mest tidskrævende.
Databasedata indeholder få, større filer, så filscanningsfasen tager lidt tid. Databaseklienter bruger typisk deres tid i fase #2.

For en klient med roterende diske i RAID 5-konfiguration er filscanningsydeevnen på ~1 million filer pr. time typisk. Dette varierer fra 300.000 til 3 millioner i timen. Det afhænger af klientmiljøet og egenskaberne ved de data, der sikkerhedskopieres.

Fra v7.3 kan Linux-klienter, der sikkerhedskopierer til Data Domain, drage fordel af Linux Fast Incremental-funktionalitet (LFI). Dermed undgår du at scanne hele datasættet, hver gang sikkerhedskopien kører.

Kritiske ressourcer: Ydeevne for tilfældig søgning på den disk, hvor sikkerhedskopidataene er gemt.

Fase 2. Avtar læser ændrede filer og klumper, komprimerer og hasher derefter dataene.

Der sker meget beregning i denne fase. For hver ændret eller ny fil bryder avtar den i små bidder. Det komprimerer hver klump og beregner en hash som et 'fingeraftryk' for at identificere klumpen.

Filer i databasesikkerhedskopier er ofte store og har tendens til at ændre sig dagligt. Avtar bruger det meste af sin tid i denne fase. Det er bedst at bruge officielle Avamar-database-plugins for at sikre, at databasen håndteres effektivt ved at udnytte trinvis sikkerhedskopieringsfunktionalitet, transaktionslogfiler og så videre.

Den typiske filbehandlingsydeevne er omkring 100 GB i timen, men kan variere op til 300 GB i timen. Dette afhænger af miljøet.

Kritiske ressourcer: Klientdisk og CPU

Ved LAN-sikkerhedskopieringer, hvor der ikke er flaskehalse ved afsendelse af data til Avamar-serveren, tager fase #1 og #2 mest tid.

I følgende diagram skal du overveje, at mængden af areal i søjlerne i grafen svarer til, hvor lang tid sikkerhedskopien tager. Ændrede filer kan drastisk øge den krævede tid, især hvis disse filer er store.

For filsystemdatasæt kan du forvente, at ~0-3 % af filerne ændres dagligt.

Avtar skal 'stat()' hver fil, der ændres, ved at udføre to I/O-handlinger, en for at kontrollere filattributterne, en anden for sikkerhedsattributterne.

For at opnå benchmark-scanningshastigheden på en ~ 1 million filer / time for sikkerhedskopier af filsystemet kræver avtar cirka to millioner søgeoperationer i timen eller 600 søgeoperationer i sekundet.

F.eks.: Hvis en sikkerhedskopi har en ændringshastighed på 3 %, kræver 97 ud af 100 filer, at to diske søger handlinger for at identificere, om de er ændret. De resterende tre, der ændrede sig, skal scannes, klumpes, komprimeres og hashes.

Dette tager kun højde for filscanningsfasen og tager ikke højde for I/O-ressourcer, der kræves til behandling af filer, der blev ændret.
Jo flere data i de ændrede filer, jo mere arbejde er nødvendigt for at fuldføre sikkerhedskopieringen.

Fase 3. Kontrol af eksistensen af hashes på Avamar-serveren

Fase #1 og #2 producerer hashes, der peger på elementer i sikkerhedskopien. Disse elementer kan være unikke filbidder, filsystemer eller hele sikkerhedskopier.

Hash-værdierne skrives til klientcachefilerne og sammenlignes med de hashes, der findes på Avamar-serveren, for at kontrollere, om der skal tilføjes nye data. Dette gælder, uanset om det er en Avamar-server eller et Data Domain, der er mållageret.

Hash-sammenligninger mellem Avamar-klient og server er typisk hurtige. De bør ikke flaskehalse sikkerhedskopien, hvis Avamar-serveren er;

• Sund
• Under regelmæssige belastningsniveauer
• Placeret i samme LAN-segment som klienten

Da hashes kun er 20 bytes i størrelse, påvirkes denne fase mere af netværksforsinkelse end netværksbåndbredde. Når hashen ankommer til Avamar-serveren, bestemmer den generelle belastning og den tilfældige søgeydelse for datanodernes diskundersystem, hvor hurtigt hashen hentes og sammenlignes med den, der sendes af klienten.

Kritiske ressourcer: Netværkets svartid og Avamar-datanodens ydeevne for vilkårlig søgning.

Den vilkårlige søgeydeevne for en fysisk Avamar-skala med antallet af og størrelsen af datanoder. AVE-systemer fungerer mindre godt og kan sammenlignes med et system med en enkelt node.

Fase 4. Afsendelse af den nye del over netværket til Avamar-serveren eller Data Domain

Når en klient sender en ny, unik del (op til 64 KB i størrelse) til serveren, afhænger ydeevnen primært af netværksbåndbredden. Dette påvirker hovedsageligt WAN-baserede klienter, som genererer en stor mængde ændrede data hver dag. Det kan også påvirke dem, der kører over overbelastede netværksforbindelser. 

Nedenfor finder du skemaer, der viser dataflowet, hvor en klient sender data til et Avamar-system og til et integreret Avamar – Data Domain-system.






Kritiske ressourcer: Netværksbåndbredde mellem klient og server

Fase 5. Data skrevet til Avamar-serveren eller Data Domain

Sikkerhedskopieringsdata skal skrives til Avamar-serveren eller Data Domain-systemet.

Kritiske ressourcer: Avamar-serverdiskskrivningsydeevne og generel indlæsning.