Avamar: Beteende och teori för säkerhetskopieringsprestanda

Syftet med den här artikeln är att beskriva vad som händer under en Avamar-säkerhetskopiering med fokus på att hjälpa läsaren att förstå prestandabeteendet för säkerhetskopiering.

Den här artikeln är ett komplement till följande artiklar:

• Avamar: Felsöka långsam säkerhetskopiering
• Avamar: Finjustera säkerhetskopieringar så att de slutförs snabbt

Vad händer under en Avamar-säkerhetskopiering?

Avtar-säkerhetskopieringsprocessen:

1) Läser in fil- och hashcachefiler i minnet

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) Skapar 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 igenom alla filer som definieras av datauppsättningen
För alla filer i källdatauppsättningen tar avtar den fullständiga sökvägen och kombinerar den med stat-liknande metadata för att beräkna en hash för att unikt identifiera filen.

Mer information finns i Avamar: Vad händer när avtar läser en fil under filgenomsökningsfasen.

4) Jämför beräknade hashvärden med dem i de lokala klientcacherna Avtar letar upp filens hash i filcachen

. Den kontrollerar om den är ny eller om den har ändrats sedan föregående säkerhetskopiering.

Om sökningen efter filcachen lyckas finns filen och är oförändrad.

Om sökningen misslyckas är filen ny eller har ändrats. Den måste läsas och bearbetas.

Mer information finns i Avamar-klient – Vad måste ändras innan avtar anser att en fil har ändrats?

5) Bearbeta nya och ändrade filer För alla nya eller ändrade filer

måste avtar :

• Läs hela filen
• Dela upp den i bitar med variabel storlek
• Komprimera varje block
• Beräkna en hash för varje segment

6) Kontrollera om det saknas hashvärden på Avamar-servern.

Avtar skickar data om saknade hashvärden över nätverket till Avamar-servern för att kontrollera om de redan finns. Dessa kallas "ispresent"-begäranden.

7) Data skrivs till Avamar-servern (och i förekommande fall till Data Domain). 

Mer detaljerat arbetsflöde finns i bifogade Avtarprocess.pdf.


Översikt över en Avamar-säkerhetskopiering ur ett prestandaperspektiv:

När vi går igenom stegen ovan delar vi upp dem i "faser" som har störst inverkan på säkerhetskopieringsprestandan:

Fas 0. Skapa VSS-snapshots.

Tjänsten Volume Shadowcopy (VSS) skapar ögonblicksbilder av volymer som anges i källdatauppsättningen. Program kan fortsätta att skriva till volymen medan säkerhetskopieringen körs.
Avamar säkerhetskopierar den skrivskyddade "frysta" ögonblicksbilden av volymen i stället för den skrivbara volymen. Detta säkerställer att den har en konsekvent uppsättning data att säkerhetskopiera.

VSS-snapshots tar bara några sekunder att slutföra. Om en klient har VSS-problem kan det här fördröja eller förhindra att säkerhetskopieringen fortsätter.

Steg 1. Filgenomsökningsfas. Avtar-processen statistikerar alla filer i måldatauppsättningen

För klienter med miljontals filer kan den här fasen vara den mest tidskrävande.
Databasdata innehåller få, större filer, så filsökningsfasen tar lite tid. Databasklienter förbrukar vanligtvis sin tid under fas #2.

För en klient med rotationsdiskar i RAID 5-konfiguration är en filgenomsökningsprestanda på ~1 miljon filer per timme vanlig. Detta varierar från 300 000 till 3 miljoner per timme. Det beror på klientmiljön och egenskaperna hos de data som säkerhetskopieras.

Från v7.3 kan Linux-klienter som säkerhetskopierar till Data Domain dra nytta av Linux Fast Incremental-funktioner (LFI). På så sätt undviker du att genomsöka hela datauppsättningen varje gång säkerhetskopieringen körs.

Kritiska resurser: slumpmässig sökning av prestanda för disken där säkerhetskopierade data lagras.

Steg 2. Avtar läser ändrade filer och segmenterar, komprimerar och hashar sedan data.

En hel del beräkningar sker under den här fasen. För varje modifierad eller ny fil delar avtar upp den i små bitar. Den komprimerar varje segment och beräknar en hash som ett "fingeravtryck" för att identifiera segmentet.

Filer i databassäkerhetskopior är ofta stora och tenderar att ändras dagligen. Avtar tillbringar större delen av sin tid i denna fas. Det är bäst att använda officiella Avamar-databasinsticksprogram för att säkerställa att databasen hanteras effektivt genom inkrementell säkerhetskopiering, transaktionsloggar och så vidare.

Typiska prestanda för filbearbetning är cirka 100 GB per timme men kan variera upp till 300 GB per timme. Detta är miljöberoende.

Viktiga resurser: Klientdisk och CPU

För LAN-säkerhetskopiering där det inte finns några flaskhalsar när data skickas till Avamar-servern tar fas #1 och #2 längst tid.

I följande diagram bör du tänka på att mängden yta i diagrammets staplar motsvarar hur lång tid säkerhetskopieringen tar. Ändrade filer kan drastiskt öka den tid som krävs, särskilt om filerna är stora.

För filsystemdatauppsättningar kan du förvänta dig att ~0–3 % av filerna ändras dagligen.

Avtar måste "stat()" varje fil som ändras genom att utföra två I/O-åtgärder, en för att kontrollera filattributen och en annan för säkerhetsattributen.

För att uppnå prestanda för benchmark-genomsökningshastighet på en ~1 miljon filer/timme för säkerhetskopiering av filsystem kräver Avtar cirka två miljoner sökåtgärder per timme, eller 600 sökåtgärder per sekund.

Till exempel: Om en säkerhetskopia har en ändringshastighet på 3 % kräver 97 av 100 filer två disksökningsåtgärder för att identifiera om de har ändrats. De återstående tre som ändrades måste skannas, segmenteras, komprimeras och hashas.

Detta tar endast hänsyn till filgenomsökningsfasen och tar inte hänsyn till de I/O-resurser som krävs för bearbetning av filer som har ändrats.
Ju mer data i de ändrade filerna, desto mer arbete krävs för att slutföra säkerhetskopieringen.

Steg 3. Kontrollera förekomsten av hashvärden på Avamar-servern

Faserna #1 och #2 producerar hashvärden som pekar på element i säkerhetskopian. Dessa element kan vara unika filsegment, filsystem eller hela säkerhetskopior.

Hashvärdena skrivs till klientens cachefiler och jämförs med de hashvärden som finns på Avamar-servern för att kontrollera om några nya data behöver läggas till. Det gäller oavsett om en Avamar-server eller Data Domain är mållagring.

Hash-jämförelser mellan Avamar-klienten och -servern är vanligtvis snabba. De bör inte orsaka flaskhalsar i säkerhetskopian om Avamar-servern är det.

• Friska
• Under normala belastningsnivåer
• Finns på samma LAN-segment som klienten

Eftersom hashvärdena bara är 20 byte stora påverkas den här fasen mer av nätverksfördröjning än nätverksbandbredd. När hashvärdet anländer till Avamar-servern avgör den allmänna belastningen och prestandan för slumpmässig sökning i datanodernas diskundersystem hur snabbt hashen hämtas och jämförs med den som skickas av klienten.

Viktiga resurser: Svarstid för nätverk och slumpmässig sökning efter Avamar-datanod

.Prestanda för slumpmässig sökning för en fysisk Avamar-skala med antalet och storleken på datanoder. AVE-system presterar mindre bra, jämförbart med ett system med en nod.

Steg 4. Skicka det nya blocket över nätverket till Avamar-servern eller Data Domain

När en klient skickar ett nytt, unikt segment (upp till 64 kB i storlek) till servern beror prestandan främst på nätverksbandbredden. Detta påverkar främst WAN-baserade klienter som genererar en stor mängd ändrade data varje dag. Det kan också påverka dem som arbetar via överbelastade nätverkslänkar. 

Nedan finns scheman som visar dataflöde där en klient skickar data till ett Avamar-system och till ett Avamar – Data Domain-integrerat system.






Viktiga resurser: Nätverksbandbredd mellan klient och server

fas 5. Data som skrivs till Avamar-server eller Data Domain

Säkerhetskopierade data måste skrivas till Avamar-servern eller Data Domain-systemet.

Viktiga resurser: Avamar-serverns diskskrivprestanda och allmänna inläsning.