Avamar: Virkemåte og teori for sikkerhetskopieringsytelse

Formålet med denne artikkelen er å beskrive hva som skjer under en Avamar-sikkerhetskopiering, med fokus på å hjelpe leseren med å forstå virkemåten til sikkerhetskopieringsytelse.

Denne artikkelen er en følgesvenn til følgende artikler:

• Avamar: Feilsøking ved treg ytelse ved sikkerhetskopiering
• Avamar: Justerer sikkerhetskopier for å fullføre raskt

Hva skjer under en Avamar-sikkerhetskopiering?

Den avtar backup prosess:

1) Laster filen og hash cache filer inn 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) Oppretter VSS-øyeblikksbilder (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 alle filer definert av datasettet For alle filer i kildedatasettet
tar avtar tar hele banen og kombinerer den med de statlignende metadataene for å beregne en hash for å identifisere filen unikt.

Hvis du vil ha mer informasjon, kan du se Avamar: Hva skjer når avtar leser en fil under filskanningsfasen.

4) Sammenlign beregnede hasher med hashene i de lokale klientbufferne Avtar slår opp filens hash i filbufferen

. Den sjekker om den er ny eller om den har blitt endret siden forrige sikkerhetskopi.

Hvis filhurtigbufferoppslaget lykkes, finnes filen og er uendret.

Hvis oppslaget mislykkes, er filen ny eller endret. Den må leses og behandles.

Hvis du vil ha mer informasjon, kan du se Avamar-klient – Hva må endres før avtar anser en fil for å ha blitt endret?

5) Behandle nye og endrede filer For alle nye eller endrede filer

avtar må:

• Les hele filen
• Del den opp i biter av variabel størrelse
• Komprimer hver del
• Beregn en hash for hver del

6) Kontroller om det mangler hasher på Avamar-serveren.

Avtar sender data for eventuelle manglende hash-koder over nettverket til Avamar-serveren for å kontrollere om de allerede finnes. Disse er kjent som 'ispresent' forespørsler.

7) Data skrives til Avamar-serveren (og eventuelt Data Domain). 

Hvis du vil ha en mer detaljert arbeidsflyt, kan du se den vedlagte Avtarprocess.pdf.


Oversikt over en Avamar-sikkerhetskopi fra et ytelsesperspektiv:

Ved å ta de ovennevnte stadiene deler vi dem inn i "faser" som har størst innvirkning på sikkerhetskopieringsytelse:

Fase 0. Opprett VSS-øyeblikksbilder.

Volume Shadowcopy Service (VSS) oppretter øyeblikksbilder av volumer som er angitt i kildedatasettet. Programmer kan fortsette å skrive til volumet mens sikkerhetskopieringen kjører.
Avamar sikkerhetskopierer det skrivebeskyttede "fryste" øyeblikksbildet av volumet i stedet for det skrivbare volumet. Dette sikrer at den har et konsekvent sett med data å sikkerhetskopiere.

VSS-øyeblikksbilder tar sekunder å fullføre. Hvis en klient opplever VSS-problemer, kan denne forsinkelsen eller forhindre at sikkerhetskopieringen fortsetter.

Fase 1. Fase for filskanning. Avtar-prosessen statistikk alle filer i måldatasettet

For klienter med millioner av filer kan denne fasen være den mest tidkrevende.
Databasedata inneholder få, større filer, så filskanningsfasen tar lite tid. Databaseklienter bruker vanligvis tiden sin i fase #2.

For en klient med roterende disker i RAID 5-konfigurasjon er filskanneytelsen på ~1 million filer per time vanlig. Dette varierer fra 300.000 til 3 millioner per time. Det avhenger av klientmiljøet og egenskapene til dataene som sikkerhetskopieres.

Fra v7.3 kan Linux-klienter som sikkerhetskopierer til Data Domain, dra nytte av Linux Fast Incremental-funksjonaliteten (LFI). Dette unngår å skanne hele datasettet hver gang sikkerhetskopien kjører.

Kritiske ressurser: Tilfeldig søk ytelse på disken der sikkerhetskopidataene er lagret.

Fase 2. Avtar leser endrede filer og deretter biter, komprimerer og hasher dataene.

Mye beregning skjer i denne fasen. For hver endret eller ny fil deler avtar den opp i små biter. Den komprimerer hver del og beregner en hash som et "fingeravtrykk" for å identifisere biten.

Filer i sikkerhetskopier av databaser er ofte store og har en tendens til å endres daglig. Avtar bruker mesteparten av tiden sin i denne fasen. Det beste er å bruke offisielle Avamar-pluginmoduler for å sikre at databasen håndteres effektivt, ved hjelp av trinnvis funksjonalitet for sikkerhetskopiering, transaksjonslogger og så videre.

Vanlig filbehandlingsytelse er rundt 100 GB per time, men kan variere opptil 300 GB per time. Dette er miljøavhengig.

Kritiske ressurser: Klientdisk og CPU

For LAN-sikkerhetskopieringer der det ikke er noen flaskehalser ved sending av data til Avamar-serveren, tar fase #1 og #2 mest tid.

I diagrammet nedenfor må du vurdere at mengden areal i stolpene i grafen tilsvarer hvor lang tid sikkerhetskopieringen tar. Endrede filer kan drastisk øke mengden tid som kreves, spesielt hvis disse filene er store.

For filsystemdatasett kan du forvente ~0-3% av filene daglig.

Avtar må "stat()" hver fil som endres ved å utføre to I / O-operasjoner, en for å sjekke filattributtene, en annen for sikkerhetsattributtene.

For å oppnå den ytelsestesten for skanning som er på én ~1 million filer/time for sikkerhetskopiering av filsystemer, krever gjennomsnittlig to millioner søkeoperasjoner per time, eller 600 søkeoperasjoner per sekund.

Eksempel: Hvis en sikkerhetskopi har en endringsfrekvens på 3 %, krever 97 av 100 filer to disker for å finne ut om de er endret. De resterende tre som ble endret, må skannes, deles, komprimeres og hashes.

Dette tar bare hensyn til filskanningsfasen og tar ikke hensyn til I/O-ressurser som kreves for å behandle filer som ble endret.
Jo mer data i de endrede filene, jo mer arbeid er nødvendig for å fullføre sikkerhetskopien.

Fase 3. Kontrollere hash-disker på Avamar-serveren

Fase #1 og #2 produserer hashes som peker på elementer i sikkerhetskopien. Disse elementene kan være unike filbiter, filsystemer eller hele sikkerhetskopier.

Hashene skrives til klientbufferfilene og sammenlignes med hashene på Avamar-serveren for å sjekke om nye data må legges til. Dette gjelder uansett om en Avamar-server eller Data Domain er mållagringen.

Hash-sammenligninger mellom Avamar-klienten og serveren er vanligvis raske. De skal ikke flaskehalser sikkerhetskopien hvis Avamar-serveren er det.

• Sunn
• Under vanlige belastningsnivåer
• Plassert på samme LAN-segment som klienten

Siden hashene bare er 20 byte store, påvirkes denne fasen mer av nettverksventetid enn nettverksbåndbredde. Når hash-koden ankommer Avamar-serveren, bestemmer den generelle belastningen og den tilfeldige søkeytelsen til datanodenes diskdelsystem hvor raskt hash-koden hentes, og sammenlignes med hash-koden som sendes av klienten.

Kritiske ressurser: Svartid for nettverksresponstid og Avamar-datanode for tilfeldig søk etter ytelse.

Den tilfeldige søkeytelsen til en fysisk Avamar-vekt med antall og størrelsen på datanoder. AVE-systemer fungerer dårligere, sammenlignbart med et enkelt nodesystem.

Fase 4. Sende den nye delen over nettverket til Avamar-serveren eller Data Domain

Når en klient sender en ny, unik del (opptil 64 KB i størrelse) til serveren, er ytelsen hovedsakelig avhengig av nettverksbåndbredden. Dette påvirker hovedsakelig WAN-baserte klienter som genererer en stor mengde endrede data hver dag. Det kan også påvirke de som opererer over overbelastede nettverksforbindelser. 

Nedenfor finner du skjemaer som viser dataflyten der en klient sender data til et Avamar-system og til et integrert Avamar Data Domain-system.






Kritiske ressurser: Nettverksbåndbredde mellom klient og server

fase 5. Data som skrives til Avamar-serveren eller Data Domain

Sikkerhetskopierte data må skrives til Avamar-serveren eller Data Domain-systemet.

Kritiske ressurser: Avamar-serverdisk skriveytelse og generell innlasting.