Avamar space-genopvindingsprocesser – Del 2: Knasende

Hvad er "fornængende" i Avamar?

Garbage Collection identificerer data, som ikke længere henvises til af sikkerhedskopier.
Chunk-header-deskriptoren ændres for at angive, hvilke dele der skal slettes. Datastribene, som indeholder disse dele, er uændrede.
Fjernelsen af disse dele sker som en sideeffekt af lagringshandlingen.

Lagring er en Avamar-vedligeholdelseshandling, der ændrer garbage-opsamlede stripes for at gøre den ledige plads inden for disse stripes sammenhængende. 
Ved at manipulere stripes for at gøre deres ledige plads sammenhængende genbruger Avamar effektivt pladsen til indgående sikkerhedskopieringsdata.

Tænk på at narre på en lignende måde med den klassiske defragmentering af harddiske. 
Data skal flyttes fra et sted til et andet, så databeholderne kan genbruges mere effektivt.

Diskdefragmenteringsværktøjer flytter relaterede dataelementer til tilstødende dele af en roterende harddisk for at hurtigere sekventielle adgangstider.
Gendannelse flytter imidlertid data til bunden af stripe for at skabe plads til nye indgående dele.

Analogi:

Se en bus med en forreste dør og ingen udgangsdør. Personer (blokke) kommer ind i bussen ved hjælp af frontdækslet. 
Dette er en særlig bus, hvor man kun kan benytte Star Star Star 'beam me up Scotty'-teknologi. 
Bussen starter helt op. 
Når flere personer har afbildet sig, har bussen plads til mere hjælp.
Andre kan komme ind, før crowd er blevet flyttet væk fra slottet. Det vil sige "tændt" mod bussens bagside for at skabe plads i nærheden af frontdækslet.

Hvorfor er det vigtigt at forstå:

Vi diskuterer, hvad der sker, når sikkerhedskopieringsdata skrives til Avamar. Det forklarer, hvorfor det er vigtigt at arbejde.

Som forberedelse til accept af sikkerhedskopieringsdata vælger Avamar stripe på hver datanode, som har den mest sammenhængende ledige plads. Stripe er markeret som den aktive stripe. 
Eventuelle nye indgående sikkerhedskopieringsdata føjes til den aktive stripe. 
Når stripe bliver fuld, markeres den næste, mindst fulde stripe som den aktive stripe.

Tænk på et system, hvor der ikke er opstået tilstrækkelig opstart.
En "synlig" stripe (spildt, men endnu ikke i gang med at reparere), kan være relativt tom. 
Denne relativt tomme stripe ville ikke blive valgt som den aktive stripe, hvis der er en anden stripe, som har mere sammenhængende ledig plads. 

I diagrammet nedenfor er begge stripes i diagrammet blevet garbage indsamlet, men kun data stripe 2 er blevet forkølet,

Selvom data stripe 1 er tømt, har stripe 2 mere brugbar sammenhængende plads. 
Avamar vælger stripe 2 som den aktive stripe. 

Efterhånden som Avamar-lagerudnyttelsen øges, vælges den aktive stripe fra en gruppe af mere og mere fulde stripes.

Hvis lagringen er forsinket, er genbrug af stripes ineffektivt. 
Flere stripes er påkrævet for at registrere de indgående data for en gennemsnitlig dag, selvom den pågældende mængde data er uændrede. 
Brug af flere stripes til at registrere data resulterer i højere kontrolpunktomkostninger, end hvis stripes blev mere effektivt genbrugt.

Derfor skal du altid sikre, at Avamar har mulighed for at udføre tilstrækkelig klargøring regelmæssigt.

Hvordan fungerer opstart? 

Når systemet udfører arbejde på en stripe, er det:-

• Læser dataene fra stripe-filen i cur-mappen til hukommelsen.
• Bestemmer, hvilke dele der henvises til af afsnitsoverskrifterne.
• Omskriver stripe-filen og chunk header til disk. Stripe-filen udfyldes kun med elementer, der henvises til af chunk-overskriften.

Ændring af stripe-filen afbryder dens hårde link og øger filsystemudnyttelsen. 
Fra Avamar version 5.0 og nyere, forbliver stripes i deres fulde størrelse efter lagring. Dette hjælper med at undgå fragmentering af filsystemet over tid.

Hvornår opstår der kopiering?

Asynkron fort gøre - Standarden og den foretrukne metode til at udføre skræmning.

Asynkron post kører under den sidste del af "Blackout-vinduet", efter garbage collection får timeout, og kun under følgende omstændigheder;

• Hvis asynkroncruringsparameteren er indstillet til sand.
• Hvis der er uoprettelige stripes*.
• OG hvis vi ikke har nået vores mål eller daglige grænse*.
• OG hvis systemet er inaktivt* (ingen sikkerhedskopier eller anden vedligeholdelse i gang).
• Hvis systemet er skrivbart, og disknoflush ikke er nået.

Asynkron forstring er en preemptive-handling. 
Den bruger dedikeret tid og ressourcer til at forberede stripes foran sikkerhedskopieringsvinduet. 
Se det tilknyttede diagrams blackout-window.jpg, som illustrerer dette.

Hvor meget arbejde fungerer kraftigt?

Forudforberedte stripes til brug i blackout-vinduet gør det muligt for Avamar at downloade data så hurtigt som muligt i løbet af sikkerhedskopieringsplanen. 
Klargøring ændrer indholdet af en stripe. Masser af lagring forårsager store forskelle med de data, der er gemt i "cur"-mappen. 
Dette resulterer i øgede kontrolpunktomkostninger og højere forbrug af plads i datanodedata/ partitioner.

Avamar forudsiger, hvor mange stripes der skal forberedes for at imødekomme mængden af forventede indgående data for den næste dag. 
Beregningerne er baseret på det glidende gennemsnit af de foregående N-dage (hvor N f.eks. er op til 10 eller 14). 
Denne selvjusteringsmekanisme gør det muligt for Avamar at bestille blot nok stripes til, at sikkerhedskopieringer kan fungere optimalt uden at forårsage unødvendige mængder kontrolpunktsbelastninger. 

Vi kan nu forstå, at hvis systemets ændringshastighed pludselig øges, tager det Avamar flere dage gradvist at indføre en øget skræmningsgrænse.

Hvis asynkron klargøring ikke forbereder nok stripes, gøres dette ved at synkront blinke.

Synkront forunderligt:

Hvis asynkron forgrening ikke er i stand til at klargøre nok stripes, eller hvis asynkroncruringsparameteren er indstillet til falsk, kører den synkront med sikkerhedskopier. 
Denne tilstand af nedskræmning, også kaldet on-demand , kører efter behov og kører på en stripe, hvis den kan ses og forberedes til at blive en nodes aktive stripe.

Hvis du giver mulighed for at køre synkront med sikkerhedskopier, betyder det øget konkurrence om disk-I/O-ressourcer. 
På travle systemer kan det medføre, at sikkerhedskopieringsopgaver tager længere tid at udføre. 

Vi kan vælge at indstille Avamar til kun at udføre synkron synkronisering i situationer, hvor et system oplever høje kontrolpunktsbelastninger. Hvis dette er gjort, skal du oplyse kunden om, hvorfor vi mener, at det er nødvendigt, og forklare afvejlsen.

A oversigt over de to forunderlige tilstande:

Asynkrone skalere:

• Indstillingen for Avamar-serverparameter er asynccruring=true.
• Højere ydeevne for sikkerhedskopiering, hvis der er en normal dag med data, der er inkluderet.
• Højere kontrolpunktsbelastning.
• Standardfunktion.
• Kan deaktiveres for at hjælpe med lavere kontrolpunktsbelastninger i situationer med høj operativsystemkapacitet.

Synkront forunderligt:

• Indstillingen for Avamar-serverparameter er asynccruring=false
• Kører efter behov
• Lavere krav til kontrolpunktomkostninger
• Potentielt længere sikkerhedskopieringstider
• Ikke standarddriftstilstanden

Hvad kan forhindre, at asynkrone forunderlige fungerer?

 Konfigurationsparameteren asynccrufiing er falsk.

• Sikkerhedskopieringer er i gang
• Den daglige grænse er nået
• Serveren er skrivebeskyttet
• Serverens kørselsniveau er lavere end "admin"
• Stripe-konvertering er i gang
• Disknoflush-grænsen er nået
• Avamar-serveren, hvor den anvendes, kører hfscheck-forekomsten (kaldes nogle gange CGSAN)
• HFScheck starter