Avamar: Concepten en training voor capaciteitsbeheer

Zie voor problemen met capaciteitsbeheer met betrekking tot Data Domain de sectie "Reclaiming storage on a full Data Domain system" in de Avamar and Data Domain System Integration Guide. De handleidingen die relevant zijn voor uw besturingsomgeving vindt u in De documentatie over Avamar vinden op de Dell Support website.

Doelstellingen van dit artikel:

• Vat de typen gegevens samen die zijn opgeslagen in de /data* partities.
• Introduceer het concept van "besturingssysteemcapaciteit" en vergelijk dit met het concept van "gebruikerscapaciteit" (soms ook wel "GSAN-capaciteit" genoemd.)
• Leg uit waarom Avamar niet mag worden uitgevoerd in de buurt van de limiet voor gebruikerscapaciteit.
• Maak een lijst van de factoren die bijdragen aan de overhead van het controlestation.
• Beschrijf hoe u het gebruik van datapartities kunt bewaken.
• Beschrijf de symptomen die optreden als de capaciteit van het besturingssysteem uit de hand loopt.
• Maak een lijst van typische oorzaken van de MSG_ERR_DISKFULL Bericht.
• Beschrijft de herstelmethoden die worden gebruikt wanneer de hoge capaciteit van het besturingssysteem van invloed is op de normale werking van het systeem.
• Beschrijf de symptomen die optreden als de gebruikerscapaciteit de limiet voor gebruikerscapaciteit overschrijdt.
• Bespreek hoe u kunt herstellen van een situatie met een hoge gebruikerscapaciteit.

In dit artikel wordt ervan uitgegaan dat de lezer bekend is met het gedeelte 'Capaciteit beheren' in de Avamar Operational Best Practices Guide. De handleidingen die relevant zijn voor uw besturingsomgeving vindt u in De documentatie over Avamar vinden op de Dell Support website. Veel voorkomende problemen die van invloed zijn op, of symptomen zijn van, een te hoge "Operating System Capacity"-symptomen zijn:

• Checkpointvalidatie (HFS Check) mislukt.
• Garbage collection wordt niet uitgevoerd en rapporteert met een MSG_ERR_DISKFULLte installeren.
• Fouten bij het maken van controlepunten.

Veelvoorkomende symptomen die nauw samenhangen met een te hoge "gebruikerscapaciteit" zijn:

• Back-ups mislukken.
• Inkomende replicatietaken mislukken.
• De beheerinterface toont het systeem in 'Admin'-modus tijdens het back-upvenster.

Zie het gedeelte "Oplossing"

Hoe worden data opgeslagen op de Avamar grid?

Avamar-capaciteitsbeheer betreft de data in de /data*-partities van alle Avamar-dataknooppunten. Dit bestaat uit:

• Gededupliceerde back-updata
• RAIN-pariteitsdata
• Overheadgegevens van controlepunten

Zowel de RAIN-pariteits- als checkpointdata zijn redundantielagen die naast RAID en replicatie beschikbaar zijn voor Avamar.

Er is ook vrije ruimte in de datapartities nodig om onderhoudstaken zoals garbage collection en asynchrone stripe crunching correct te laten verlopen.

Hieronder vindt u een grafische weergave van de fysieke storageruimte die beschikbaar is binnen de datapartities op de Avamar-storageknooppunten.

Hoe worden data opgeslagen in de datapartities?

In het bovenstaande diagram zien we een eenvoudige weergave van hoe de ruimte wordt gebruikt in de gegevenspartities.

De waarde 100% aan de linkerkant wordt gedefinieerd als de totale hoeveelheid fysieke ruimte die beschikbaar is voor het besturingssysteem in de datapartities.

Als een van de datapartities meer dan 85% van de totale ruimte in beslag neemt, kan garbage collection niet worden uitgevoerd.

De markering 100% gebruikerscapaciteit (alleen-lezenlimiet) geeft aan dat maximaal 65% van de totale ruimte in de datapartitie beschikbaar is voor opslag van gededupliceerde data. De ruimte onder deze markering 100% gebruikerscapaciteit is gelijk aan de waarde voor servergebruik die zichtbaar is in de gebruikersinterface van de beheerder. Als de hoeveelheid gededupliceerde data die is opgeslagen op een datapartitie op een knooppunt 65% bereikt, wordt het Avamar-systeem alleen-lezen en weigert het verdere back-updata.

We kunnen nu begrijpen dat de gebruiker vanuit de Avamar Administrator UI zicht heeft op de ruimte die back-ups hebben verbruikt, maar niet op de ruimte die wordt gebruikt in de datapartities van het besturingssysteem.

Waarom een Avamar-systeem niet moet worden uitgevoerd in de buurt van de limiet voor gebruikerscapaciteit.

De relatie tussen hoge "gebruikerscapaciteit" en overhead van checkpoints is dat naarmate een systeem steeds voller raakt, zelfs kleine stijgingen van back-updata kunnen leiden tot grote stijgingen van checkpointoverhead. Een volledige bespreking van waarom dit het geval is, valt buiten het bestek van dit artikel, maar het belangrijkste om te onthouden is:

• Hoe dichter een Avamar-systeem bij 100% gebruikerscapaciteit ligt, hoe minder capaciteit van het besturingssysteem beschikbaar is voor checkpoint-overhead.

Zoals we in het bovenstaande diagram kunnen zien, is de overhead van het controlepunt op een volledig systeem beperkt tot 20% van de totale ruimte voor het besturingssysteem in de datapartities.

Een Avamar-systeem kan alleen betrouwbaar werken op hoge niveaus van "User Capacity" als het aan de volgende criteria voldoet:

• Het systeem moet een laag percentage dagelijks gewijzigde gegevens hebben (niet hoger dan 1%).
• De capaciteit moet zich in een stabiele status bevinden (zoals beschreven in het gedeelte 'Capaciteit beheren' van de Avamar Operational Best Practices Guide). De handleidingen die relevant zijn voor uw besturingsomgeving vindt u hier: Avamar documentatie vinden op de Dell Support website.
• Onderhoudstaken zouden elke dag met succes moeten worden voltooid.

Als een van deze uitspraken verandert van waar naar onwaar, kan worden verwacht dat de overhead van het controlepunt geleidelijk stijgt of plotseling piekt en ernstige operationele problemen veroorzaakt.

Factoren die bijdragen aan de overhead van checkpoints:

De volgende factoren kunnen ervoor zorgen dat de overhead van checkpoints toeneemt.

• Asynchroon kraken van strepen (standaard ingeschakeld)
• Het aantal controlestations dat in het systeem is opgeslagen
• De validatie van het controlepunt wordt niet elke dag met succes voltooid.
• Hoe leeg strepen zijn wanneer de Avamar-server ze hergebruikt (wordt ernstiger bij hoger servergebruik)
• De dagelijkse wijzigingssnelheid voor back-ups<

Een systeembeheerder heeft een zekere mate van controle over deze factoren. Configuratie van asynchrone crunching is alleen voor support, maar beheerders kunnen overtollige checkpoints verwijderen, checkpointfouten onderzoeken en het servergebruik en de dagelijkse datawijzigingssnelheid beïnvloeden.

Het gebruik van datapartities controleren:

De juiste manier om het gebruik van de datapartitie van het besturingssysteem te bewaken is door de volgende Avamar-opdracht te gebruiken vanaf het Avamar Utility-knooppunt.

Bijvoorbeeld:

admin@utilitynode:~/>: avmaint nodelist | grep fs-percent
        fs-percent-full="7.8"
        fs-percent-full="6.3"
        fs-percent-full="6.4"
        fs-percent-full="6.4"
        fs-percent-full="7.6"
        fs-percent-full="6.2"
        fs-percent-full="6.1"
        fs-percent-full="6.6"
        fs-percent-full="7.8"
        fs-percent-full="6.4"
        fs-percent-full="6.5"
        fs-percent-full="6.8"

Deze uitvoer geeft u een waarheidsgetrouwe aflezing van het capaciteitsgebruik van het besturingssysteem. Op een raster waar gegevensknooppunten een bestandspool gebruiken, wordt de df Opdracht is niet zinvol omdat de stripes vooraf zijn toegewezen in de bestandspool en veel van de stripes mogelijk niet in gebruik zijn.

Wat gebeurt er als het capaciteitsgebruik van het besturingssysteem uit de hand loopt?

Vanuit het oogpunt van een gebruiker treedt de eerste indicatie dat het gebruik van de gegevenspartitie uit de hand loopt wanneer het boven de 85% stijgt.

Garbage collection kan niet meer worden uitgevoerd en mislukt met een MSG_ERR_DISKFULL Foutbericht.

Hier komen vaak misverstanden voor.
De gebruiker interpreteert vaak de MSG_ERR_DISKFULL Dit betekent dat het systeem geen ruimte meer heeft voor back-ups.

Deze interpretatie is niet juist, maar de gebruiker controleert meestal de waarde van het servergebruik in de Avamar Administrator UI en vindt de waarde acceptabel, bijvoorbeeld 60%.

De gebruiker kan proberen back-ups te verwijderen uit de Back-upbeheerinterface van de Avamar UI. Zelfs als het gebruikerscapaciteitsniveau hoog zou zijn, zou het verwijderen van back-ups de situatie niet verlichten, omdat garbage collection niet kan worden uitgevoerd en verlopen stukjes data niet van het systeem kan verwijderen.

• Als een systeem zowel een probleem met een hoge capaciteit van het besturingssysteem als een hoge gebruikerscapaciteit heeft, moet u zich eerst richten op het oplossen van het probleem met de hoge capaciteit van het besturingssysteem.

Bij een hoog capaciteitsgebruik van het besturingssysteem kan het systeem onvoldoende ruimte hebben om controlestations te maken.

Wat veroorzaakt het bericht MSG_ERR_DISKFULL?

De meest voorkomende oorzaak is een te hoge overhead van checkpoints. Typische oorzaken van hoge overhead bij checkpoints kunnen zijn:

• Validatie van controlepunten (HFScheck) is herhaaldelijk mislukt.
• HFScheck Falen heeft veel mogelijke hoofdoorzaken (abrupte annulering, softwarefout, enzovoort).
• Het systeem werkt te vol en heeft een hoge dagelijkse datawijzigingssnelheid.
• Het systeem heeft meer dataknooppunten nodig om de snelheid van de datawijziging te verwerken en de data op te slaan.
• Het systeem is geconfigureerd om een back-up te maken van meer data of clients dan waarvoor het was ontworpen.
• Er worden te veel checkpoint opgeslagen (Avamar slaat standaard twee checkpoints op, waarvan er één is gevalideerd).
• De systeembeheerder heeft extra controlepunten gemaakt.
• Onlangs is onderhoud uitgevoerd, maar de standaard checkpointretenties zijn niet hersteld.

Raadpleeg het volgende artikel voor hulp bij het oplossen MSR_ERR_DISKFULL situation: Avamar maintenance tasks fail with "MSG_ERR_DISKFULL" due to data partition operating system capacity >89%.

Acties om hoge capaciteit van het besturingssysteem te onderzoeken en te helpen verlichten.

1. Wanneer de laatste HFScheck is afgerond

admin@utilitynode:~/>: cplist
cp.20110114111419 Fri Jan 14 11:14:19 2011   valid rol ---  nodes   3/3 stripes   1131
cp.20110114194457 Fri Jan 14 19:44:57 2011   valid --- ---  nodes   3/3 stripes   1131

 

2. Controleer of HFScheck is uitgevoerd of dat het is mislukt.

Last hfscheck: finished Sat Jan 15, 11:07:17 2011 after 06m 41s >> checked 528 of 528 stripes (OK)

admin@utilitynode:~/>: dpnctl status
Identity added: /home/admin/.ssh/dpnid (/home/admin/.ssh/dpnid)
dpnctl: INFO: gsan status: ready
dpnctl: INFO: MCS status: up.
dpnctl: INFO: EMS status: up.
dpnctl: INFO: Backup scheduler status: up.
dpnctl: INFO: dtlt status: up.
dpnctl: INFO: Maintenance windows scheduler status: enabled.
dpnctl: INFO: Maintenance cron jobs status: enabled.
dpnctl: INFO: Unattended startup status: disabled.

Als de onderhoudsvensterplanner is 'uitgeschakeld', schakelt u deze in met de opdracht dpnctl start maint.

Zodra de HFScheck met succes is voltooid en het oudste controlepunt van het systeem is 'uitgerold', zou de capaciteit van het besturingssysteem aanzienlijk moeten afnemen.

Als de capaciteit van het besturingssysteem nog steeds te hoog is en garbage collection blijft mislukken met het MSG_ERR_DISKFULL-bericht, kan de hulp van Dell Support nodig zijn.

Anders, als de capaciteit van het besturingssysteem laag genoeg is om garbage collection toe te staan, werk dan aan het verlagen van de "User Capacity" en breng het cijfer voor "servergebruik" omlaag.

 

Acties om hoge gebruikerscapaciteit te verminderen:

In tegenstelling tot de capaciteit van het besturingssysteem worden de niveaus van de gebruikerscapaciteit gemakkelijker en rechtstreeks beïnvloed door de Avamar systeembeheerder.

1. Zorg ervoor dat garbage collection elke dag wordt uitgevoerd en niet wordt onderbroken door back-ups.

Dit is het meest cruciale punt, omdat zelfs een systeem van voldoende grootte snel een hoge gebruikerscapaciteit ervaart als de garbage collection niet regelmatig of betrouwbaar wordt uitgevoerd.

Zoals eerder weergegeven, controleert u of het onderhoudsvenster is ingeschakeld en gebruikt u de scripts capacity.sh en sched.sh om te controleren of garbage collection wordt uitgevoerd of data wordt verwijderd.

Vóór Avamar v7.x konden er geen back-ups worden uitgevoerd tijdens het "beperkingsvenster" van de garbage collection.

Met de functie Hash Referenced Bit Maps, die samen met de functie Avamar v7.x is geïntroduceerd, kunnen back-ups worden gemaakt tijdens het onderhoud van de garbage collection. Deze functie vereist dat deze "kaarten" ten minste 5 minuten "stille" tijd per dag moeten hebben waarin geen back-ups worden uitgevoerd, zodat ze kunnen worden gereset.

Inhoud over deze functie kan worden geraadpleegd via de koppeling naar artikel Avamar: Van Avamar v7 meldt Garbage Collection "skipped-hashes" die niet kunnen worden opgeschoond vanwege "Hash Referenced Bit Maps" wanneer de data in gebruik zijn.

2. Stop met het toevoegen van nieuwe clients aan het raster.

Zodra een Avamar-systeem bijna zijn capaciteit bereikt, moeten we onmiddellijk stoppen met het toevoegen van nieuwe clients om te voorkomen dat de situatie verslechtert.

Als u een ander Avamar-raster hebt dat op een lager servergebruiksniveau wordt uitgevoerd, kunt u overwegen nieuwe clients aan dat raster toe te voegen in plaats van dat de server vol raakt.

3. Ontdek welke clients de meeste opslagruimte gebruiken.

Om een capaciteitsprobleem aan te pakken, moeten we bepalen welke clients verantwoordelijk zijn voor het toevoegen van de meeste data aan het Avamar-systeem.

Het script capacity.sh (uitgevoerd vanaf de opdrachtregel van het Avamar hulpprogrammaknooppunt) kan ook worden gebruikt om te bepalen welke clients het hoogste wijzigingspercentage hebben.

Geregistreerde gebruikers van Dell kunnen de inhoud openen via de koppeling naar het artikel Avamar: Capaciteit beheren met het capacity.sh script voor meer informatie over het gebruik van het capacity.sh script.

Vaak blijkt dat de 'hongerigste' clients degenen zijn die een back-up maken van SQL-databases of e-mailservers, dus let hier vooral op.

4. Beoordeel het retentiebeleid opnieuw.

Nadat u clients met een hoog wijzigingspercentage hebt geïdentificeerd, moet u het retentiebeleid opnieuw beoordelen om te zien of dit beleid kan worden verlaagd om de storagevereisten tot een acceptabel niveau terug te brengen.

5. Clients migreren naar een alternatief Avamar-systeem.

Als er een ander Avamar-systeem beschikbaar is, overweeg dan de mogelijkheid om grote clients of clients met een hoge wijzigingssnelheid te migreren van systemen met een hoger naar een lager gebruikt systeem met behulp van de Avamar Client Manager-interface.

6. Oude back-ups verwijderen.

Als het gebruikerscapaciteitsniveau ernstig is (>90%), kan het nodig zijn om oude back-ups te laten verlopen via de Backup Management-interface of met de tool modify-snapups. 

Gebruikers van Dell kunnen de inhoud openen via de koppeling naar het artikel Avamar Capacity Management: Back-ups in bulk verwijderen of laten verlopen met de tool "modify-snapups".

Het verwijderen van back-ups verlaagt niet onmiddellijk het gebruiksniveau van de server. Wat het doet, is toestaan dat garbage collection begint met het verwijderen van de data de volgende keer dat garbage collection wordt uitgevoerd. Het verwijderen van oude back-ups is een tijdelijke oplossing. De back-ups worden in de komende dagen vervangen. Als back-ups worden verwijderd, is het essentieel om ook het retentiebeleid af te stemmen.

7. Bewaak datawijzigingen met behulp van capacity.sh.

Nadat back-ups zijn verwijderd en het bewaarbeleid is gewijzigd, houdt u de hoeveelheid data die op het systeem is gewijzigd nauwlettend in de gaten met behulp van het capacity.sh script. U zou moeten gaan zien dat de waarde van de gegevens "verwijderd" toeneemt en dat de waarde "Nettowijziging" negatief wordt. Uiteindelijk, als de overtollige data uit het systeem worden verwijderd, begint de "verwijderde" waarde terug te keren naar meer normale niveaus. Blijf de waarde "Verwijderd" in de gaten houden.

Als de nettowijzigingswaarde niet negatief wordt, controleert u het garbage collection-logboek om te zien hoe lang garbage collection wordt uitgevoerd en hoeveel werk deze binnen het onderhoudsvenster bereikt.

Gebruikers van Dell kunnen de inhoud openen via de koppeling naar het artikel Avamar: Capaciteit beheren met het capacity.sh script voor meer informatie over het gebruik van het capacity.sh script.

8. Het Avamar systeem uitbreiden

Vaak is het hoge gebruik van het Avamar systeem het gevolg van natuurlijke en verwachte datagroei. Er moet meer ruimte beschikbaar worden gemaakt om productieback-ups voort te zetten.

Hoe dit kan worden gedaan, hangt af van het type Avamar-systeem.

• Systemen met één knooppunt en Avamar Virtual Edition (AVE)-systemen

Deze kunnen niet worden uitgebreid. Stel een tweede, groter Avamar-systeem in gebruik en vraag Dell Professional Services om een systeemmigratie uit te voeren van het kleinere naar het grotere systeem. U kunt professionele services inschakelen via de Dell accountmanager.

Het nieuwe systeem kan een systeem met één knooppunt, AVE of meerdere knooppunten zijn als het meer opslagruimte biedt dan de bron.

• Systemen met meerdere knooppunten

Deze systemen zijn uit te breiden tot maximaal 16 dataknooppunten. Neem contact op met de Dell accountmanager voor meer informatie. Reguliere supportkanalen voegen geen knooppunten toe, dus moet er geen serviceaanvraag worden geopend om dit werk aan te vragen.

• Data Domain integreren

Het integreren van een Data Domain systeem als back-end storageapparaat is een handige manier om de beschikbare capaciteit uit te breiden voor clients die back-ups maken naar Avamar. Bespreek de mogelijkheden met uw Dell accountmanager.

Nuttige hulpmiddelen

• status.dpn
• capacity.sh
• Avalanche
• Overzichtsrapport DPN
• replcnt.sh
• Avamar Client Manager

Aanbevolen werkwijzen:

• Probeer te voorkomen dat het gebruik van de Avamar Server (gebruikerscapaciteit) hoger is dan 80%.
• Een lagere gebruikerscapaciteit biedt veerkracht tegen onverwachte veranderingen in de hoeveelheid data die wordt toegevoegd en kan beschermen tegen onbruikbaarheid van het systeem bij onverwachte storingen of kortstondige problemen met onderhoudstaken.
• Een Avamar-systeem met een gebruikerscapaciteit van meer dan 80% vereist een meer zorgvuldige controle door de systeembeheerder om ervoor te zorgen dat onderhoudstaken met succes worden voltooid en dat het systeem niet alleen-lezen wordt.