Avamar-prosesser for plassgjenvinning – del 1: Datasanering

Denne artikkelen er den første i en serie som dokumenterer hvordan Avamar resirkulerer plass, både i GSAN og på harddiskene.

• Avamar-prosesser for plassgjenvinning – del 1: Datasanering 
• Avamar-prosesser for plassgjenvinning – del 2: Knaser 
• Avamar-prosesser for tilbakestilling av plass – del 3:  Fjern kontrollpunktprosessen (RMCP) 

Den gjeldende implementeringen av datasanering ble innført sammen med Avamar v7.0, og designet har forblitt stort sett uendret.

Hva gjør datasanering?

Datasanering er den første fasen i prosessen der Avamar tar tilbake plassen som ble brukt til å lagre sikkerhetskopieringsdata.

Den opererer på markørkatalogen og frigjør plass i GSAN ved å fjerne databiter som ikke lenger refereres til av noen sikkerhetskopi:

• Data sies å være «definert» hvis de kan slås opp i indeksen.
• Data henvises til hvis det finnes som en del av en sikkerhetskopi (som er hash-nummeret finnes i bruker regnskapssystemet, komposittstriper eller katalogelementer).

Plass som gjenvinnes av datasanering, kan ikke brukes på nytt før den har kjørt. Dlling kjører umiddelbart etter at den daglige planlagte datasaneringen er fullført. Se Avamar-prosesser for tilbakestilling av plass – del 2: Srødm.


Når kjører datasanering?

• Vedlikeholdsplanlegger eller, mer spesifikt, datasanering er deaktivert. Utdataene fra status.dpn for å bekrefte dette.
• Operativsystemkapasiteten er over disknogc-verdien (som kan være 86 % til 89 %).
  • Se Avamar-vedlikeholdsoppgaver mislykkes med "MSG_ERR_DISKFULL" på grunn av datapartisjon av OS-kapasitet >på 85 %
• Problemer med tidssynkronisering mellom Avamar-noder.
  • Se Avamar – symptomkode 4202 – ødelagt datasanering med feil MSG_ERR_BADTIMESYNC 
• Indeksstriper deles opp.
  • Se Avamar – datasanering mislykkes med MSG_ERR_TRYAGAINLATER
• Bitkart med hash-referanse kan ikke tilbakestilles.
  • Se Avamar v7 og nyere – Datasanering rapporterer "skipped-hashes" som ikke kan renses på grunn av "Hash Referenced Bit Maps" når dataene er i bruk

Slik fungerer datasanering

Trinn 1 – Bygge tabellen over referanseantall (TORC):

Datasanering leser oppføringer i brukerens regnskapssystem, komposittstripene og katalogelementer for å bygge en tabell over referanseantall (TORC).
I TORC registrerer datasanering alle hasher på systemet, og hvor mange ganger hver hash er referert til.

Trinn 2 – Lese indeksene:
Når TORC er fullført, laster hver node et delsett av de individuelle indeksstripene i minnet. Antallet leste striper defineres av gccount-parameteren . For hver hash som er definert i indeksen, vil datasanering slå opp hash-nummeret i TORC for å kontrollere om det er referanse.

• Hvis hash-koden finnes i både indeksen og TORC, er det ingenting å gjøre. Hver hash i TORC har et referanseantall på minst 1, så hash-koden er både definert og referert til.
• Hvis hash-koden finnes i indeksen, men ikke i TORC, er hash-koden definert, men ikke referert til, og kan derfor fjernes.

Merk: Hvis hash fantes i TORC, men ikke i indeksen, ville dette være en dataintegritetsfeil (hash som er referert til, men ikke definert).  Dette resulterer i en feil med hfscheck.

Trinn 3 – Fjern ikke-aktiverte hash-koder:
Som vi tidligere noterte, er hash-koder som ikke er nevnt, ikke en del av en sikkerhetskopi, så de kan derfor trygt fjernes fra Avamar. For å gjøre dette kan du hente søppel:

1. Fjerner oppføringen i indeksen.
2. Nuller ut oppføringen for hash-koden i Chunk Header Descriptor (CHD). CHD definerer hvor individuelle biter er inne i stripebeholderen.

Avamar har merket området som hash-nummeret opptar som tomt. Av hensyn til ytelse og kapasitet slettes ikke dataene på dette stadiet.

Trinn 4 – Oppdater TORC:
Hvis delen som fjernet datasanering var en kompositt, må TORC oppdateres.
Hvis vi ser tilbake på trinn 1, inkluderer referanseantallet i TORC referanser laget av komposittstriper, som inneholder komposittbiter.
Siden en sammensatt del ble fjernet, kan vi avslå referanseantallet i TORC med én for eventuelle hashe som det refereres til av den sammensatte delen.
Datasanering gjør dette ved å lese i komposittet, for å se hvilke hashes den refererer til, og deretter oppdatere TORC.

Trinn 5 – Les neste sett med indekser:
Datasanering fjerner det forrige settet med indeksstriper fra minnet, og laster deretter inn et nytt sett.
Trinn 2, 3 og 4 gjentas for disse nye indeksstripene.
Når alle indeksstripene er lest, fjernes

alle databiter (kjent som "atombiter" i TORC som har 0 referanser (takket være trinn 4).Trinn 6 – Start et nytt pass:
Når alle indeksene er lest, starter datasaneringen et nytt pass.
Alle indeksstripene leses på nytt, på jakt etter data som ikke lenger refereres til, takket være tidligere bestått.

Dette er nødvendig fordi hash-koder ikke leses i en logisk rekkefølge, men i rekkefølgen de er lagret i indeksene.
Datasanering er ikke sikkert for å finne hasher i optimal rekkefølge. En hash-kode kan fortsatt refereres til til slutten av bestått.

To passeringer av datasanering kan komfortabelt opprettholde en "steady-state"-kapasitet i de fleste Avamar-servermiljøer.
Datasanering utføres til den går tom for tid, eller et pass fullføres uten å fjerne data.

Manuell datasanering

Mikroadministrering av en Avamar-server må ikke være nødvendig. Planleggeren er ment å automatisere kjøringen av vedlikeholdsoppgaver. Hvis Avamar-kapasiteten er høy, kan du se veiledningen for beste praksis for Avamar-drift og Avamar: Kapasitetsstyringskonsepter og opplæring.

I sjeldne tilfeller kan kjøring av datasanering bidra til å løse akutte problemer der GSAN -brukerkapasiteten er så høy at systemet går i skrivebeskyttet modus. 
I slike tilfeller kjøres datasanering manuelt for å få ned kapasitetsnivået til like under den skrivebeskyttede terskelen. Dette gjør at sikkerhetskopieringsvinduet kan kjøres.
Automatisert datasanering kan fortsette å fungere som normalt.

Avamar-støtte bør undersøke situasjonen fullstendig og forstå situasjonen før manuell datasanering vurderes.
Det er aldri riktig å be om at support kjører manuell datasanering på et system uten godkjenning fra en L2-kundestøttetekniker etter en slik undersøkelse.
Se Avamar – Om bruk av manuell datasanering.