Avamar: Een replicatiepaar toont verschillende niveaus van capaciteitsgebruik. Hoe de oorzaken te onderzoeken.

Oorzaken en mogelijke redenen voor de verschillen tussen de waarden 'servergebruik':

Logische of fysieke verschillen tussen de rasters:

• Een ander aantal gegevensknooppunten op de bron- en doelrasters.
• De gegevensknooppunten van elk raster hebben verschillende schijfconfiguraties.
• Voldoende evenwichtige verdeling van stripes over de dataknooppunten binnen elk systeem (tot op 2%)
• Storage- en pariteitsvereisten verschillen tussen Avamar-versies. Er kan een verschil in het gebruik worden waargenomen als de versies van de bron- en doelsoftware verschillen.
• Het alleen-lezen-niveau van de Avamar-server kan verschillen tussen de twee rasters.   
• Het ene raster kan worden geconfigureerd voor RAIN-pariteit, terwijl het andere dat niet kan.

Replicatieconfiguratie:

• Voor back-ups die naar het doelsysteem worden gerepliceerd, kan een ander bewaarbeleid gelden dan voor de bron. Bekijk de expiredelta-markering voor meer informatie. Het kan ook zijn dat de gerepliceerde back-ups slechts een bepaalde tijdspanne bestrijken. Bijvoorbeeld de laatste 4 weken aan back-ups vanaf de bron.
• Replicatie kan worden geconfigureerd om slechts een subset van clients van het bronsysteem naar het doelsysteem te repliceren. Controleer of de instellingen "include" of "exclude" worden gebruikt.
• Clients en de bijbehorende back-ups zijn mogelijk verwijderd van het bronsysteem. Het verwijderen van een client of van back-ups op de bron verwijdert niet dezelfde back-ups van het doelsysteem. De back-ups blijven op het doel totdat ze verlopen volgens hun bewaarinstellingen.
• Bewaarbeleid kan worden gewijzigd voor back-ups of clients op het bronsysteem. De wijziging in het bewaarbeleid is alleen van invloed op nieuwe back-ups. Nieuwe back-ups worden gerepliceerd naar het doel en voldoen aan het bijgewerkte bewaarbeleid. Voor back-ups die al op het doel aanwezig zijn, blijft het bewaarbeleid behouden dat op hen werd toegepast toen ze werden gerepliceerd.

Vorige activiteit voor capaciteitsbeheer:

• Het is niet ongebruikelijk dat klanten merken dat een van de Avamar-replicatiepaarsystemen de capaciteit nadert en vervolgens actie ondernemen om de capaciteit te verminderen. Een Avamar-replicatiepaar bestaat uit twee onafhankelijk beheerde systemen. Als acties op het ene systeem worden uitgevoerd, moeten ze ook op het andere systeem worden uitgevoerd. 
• Als back-ups worden verwijderd of retenties op het bronsysteem worden verminderd, moeten identieke wijzigingen worden aangebracht op het doel. De beste manier om de capaciteit op deze manier te beheren is met het script modify-snapups. Dit kan op beide Avamar-servers worden uitgevoerd met dezelfde opties voor back-upwijziging of -verwijdering.  

Afwijkende stripe-structuur (bijvoorbeeld meer pariteitsstrepen op één systeem):

• Omdat twee Avamar-systemen onafhankelijk van elkaar zijn, kunnen ze verschillende stripe-structuren hebben. Systemen met meerdere knooppunten kunnen verschillen vertonen vanwege het gebruik van pariteitsstrepen om data te beschermen. Afhankelijk van hun capaciteitsgeschiedenis bevatten twee systemen met meerdere knooppunten dezelfde back-ups, maar het ene systeem kan een hoger aantal pariteitsstrepen hebben dan het andere.
• Net als bij gewone stripes blijft er altijd een pariteitsstrip op het systeem staan nadat deze is gemaakt. In tegenstelling tot gewone strepen neemt deze altijd een vaste hoeveelheid ruimte in beslag binnen de Avamar Server. Dit is zelfs het geval als de safe-stripes van hun pariteitsgroep geen gegevens bevatten. Garbage collection heeft geen effect op dit gedrag.
• Een replicatiedoelsysteem wordt indirect beschermd tegen grote capaciteitsproblemen op een replicatiebron. De situatie kan zich echter op beide computers voordoen als een van de systemen slecht wordt beheerd vanuit capaciteitsperspectief.
• Gerelateerd artikel: Avamar geeft tot ~30% gebruik weer, zelfs nadat alle back-ups zijn verwijderd en afval is verzameld

Back-ups die nog in MC_DELETED zijn:

• Een zeldzaam scenario om rekening mee te houden is dat een client op de bron wordt verwijderd, maar de back-ups worden bewaard. Dit kan ertoe leiden dat de bron een hoger gebruik heeft dan het doel waarbij de back-ups naar verwachting op natuurlijke wijze verlopen. Met behulp van het script dump_root_hashes.rb met de optie backupcompare kunt u op dit scenario controleren.

Data op doelsysteem van niet-gerepliceerde back-ups:

• Als het systeem in *slechts één richting* repliceert, controleert u op het doel of er geen clients bestaan buiten /REPLICATE en MC_SYSTEM.

Ander gedrag:

• Replicatietaken kunnen niet op betrouwbare wijze worden uitgevoerd. Data die naar het doel worden verzonden, kunnen meerdere dagen 'achterblijven' op de bron.
• Beide systemen bevatten dezelfde hoeveelheid gededupliceerde data, maar de hoeveelheid pariteitsoverhead voor elk systeem is verschillend. Dit gebeurt in het volgende scenario: 
  • Een Avamar-bronsysteem is bijna vol. 
  • Veel back-ups worden van het bronsysteem verwijderd om het capaciteitsniveau te verlagen. 
  • Replicatie van de gededupliceerde data vindt vervolgens plaats van bron naar doel. 
  • De hoeveelheid gededupliceerde data is op beide systemen hetzelfde.
  • Het bronsysteem slaat in eerste instantie meer pariteitsoverhead op dan het doel.
• Bij replicatie worden geen fysieke strepen gekopieerd van het bron- naar het doelraster. In plaats daarvan mag het doelraster zelf bepalen waar stroken en brokken gegevens worden opgeslagen.
• Soms kunnen doel-Avamar-systemen data efficiënter opslaan dan een bronraster waar oorspronkelijk een back-up van de data wordt gemaakt.

Begrijp de replicatieomgeving:

• Noteer de volledige hostnaam van het Avamar-raster van de bron.
• Onderzoek de replicatieconfiguratie van de betrokken systemen om te begrijpen welke systemen welke data repliceren en waarheen. 
  • Het kan helpen om een schema van de omgeving te tekenen als het ingewikkelder is dan replicatie van de ene Avamar-server naar de andere.
• Als de bron integreert met Data Domain (DD), controleert u of de zorg van de klant betrekking heeft op back-ups die zijn gerepliceerd tussen DD-apparaten.
• Noteer de volledige hostnaam van het doel-Avamar-raster en alle bijbehorende DD-apparaten die gerepliceerde back-ups ontvangen.

Controleer de algehele status en situatie van het netwerk:

• Voer het proactieve controlescript uit op beide rasters en verkrijg een kopie van hc_results.txt en beoordeling om de algehele situatie met het systeem te begrijpen. 

Hoe ernstig is het capaciteitsverschil?

• De klant moet een screenshot verstrekken van waar hij naar kijkt, waardoor hij denkt dat er een verschil in capaciteitsverbruik is tussen bron en doel.
• Als het capaciteitsverschil minder dan 5% bedraagt, is er geen reden tot ongerustheid.
• Controleer de Avamar Administrator UI voor inzicht in de niveaus van Avamar servercapaciteit en (als Data Domain is geïntegreerd) metadatacapaciteit.
• Houd er rekening mee hoe de weergave van de UI-capaciteit werkt (besproken in Avamar UI-dashboard in v7.2 en toont later metadatagebruik in plaats van Avamar-gebruik).
• Voer de volgende opdracht uit op beide systemen. De waarde voor servergebruik geeft een totale waarde van de capaciteitsniveaus van de Avamar server (maar niet van Data Domain):

admin@utility:~/>: mccli server show-prop | grep "utilization"

Server utilization               3.7%

Controleer of de hardware op beide rasters hetzelfde is:

• Het heeft alleen zin om capaciteitsverschillen voor "soortgelijke" systemen te vergelijken. 
• Noteer met behulp van de proactieve controle-uitvoer het type knooppunten dat in het systeem aanwezig is.
• De volgende opdracht toont een totaal aantal, grootte van en ruimteverbruik op de fysieke knooppunten:

admin@utility:~/>: mccli server show-prop | grep "Capacity\|capacity\|nodes"

Total capacity                   23.3 TB
Capacity used                    858.5 GB
Number of nodes                  3

• Deze uitvoer maakt het gemakkelijk om het aantal en de grootte van de knooppunten in het systeem te bepalen. Ze zijn (23,3 / 3 = ~7,8 TB). 
• Het aantal en de grootte van de harde-schijfpartities op elk knooppunt moeten dit bevestigen.

admin@utility:~/>: mapall 'df -h' | grep data

(0.0) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.2 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   54G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   53G  1.8T   3% /data04
/dev/sde1       1.9T   52G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06
(0.1) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.3 'df -h'
/dev/sda3       1.8T   56G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   52G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   53G  1.8T   3% /data06
(0.2) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.4 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06

• Controleer met deze informatie het volgende:

Controleer de softwareversie en -configuratie:

• Gebruik de uitvoer van de opdracht status.dpn om de versie van Avamar te vergelijken die op elk systeem wordt uitgevoerd.
• Controleer bij systemen met meerdere knooppunten of beide zijn geconfigureerd met RAIN-pariteit per Avamar - Bepalen of een server RAIN of niet-RAIN is
• Controleer en vergelijk de capaciteitsgerelateerde Avamar-serverconfiguratieparameters van de twee systemen. Bijvoorbeeld:

admin@utility:~/>: avmaint config --ava | grep -i "capacity\|disk"

  disknocreate="90"
  disknocp="96"
  disknogc="85"
  disknoflush="94"
  diskwarning="50"
  diskreadonly="65"
  disknormaldelta="2"
  freespaceunbalancedisk0="20"
  diskfull="30"
  diskfulldelta="5"
  balancelocaldisks="false"

Controleer de streepbalans:

• Controleer de uitvoer van status.dpn en noteer het totale aantal stripes op elk dataknooppunt. Het aantal strepen staat tussen haakjes (bijvoorbeeld onl:xxx). 
• Er moet minder dan 2% verschil zijn tussen het totale aantal stripes op elk dataknooppunt.

Controleer of garbage collection correct werkt op beide systemen:

• Als garbage collection niet consistent en effectief wordt uitgevoerd, worden verlopen data niet verwijderd. Het systeem rapporteert een hoger capaciteitsgebruik dan verwacht. 
  • Zie het artikel GC-resolutiepad in de beperkte opmerkingen voor informatie.

Controleer of de replicatie is voltooid:

• Ervoor zorgen dat alle replicatietaken van bron tot doel met succes zijn voltooid. Als dit niet is gebeurd, kan het zijn dat er nog steeds gegevens van bron naar doel moeten worden gerepliceerd.

Controleer de replicatieconfiguratie:

• Controleer de replicatieconfiguratie (in de gebruikersinterface, CLI of logboeken) op een van de volgende vlaggen:

--before
--after
--include
--exclude

--expiredelta

--retention-types

--retention-types=none,daily,weekly,monthly,yearly

Controleer de opname- en verwijderingssnelheden van beide systemen:

• Voer proactive_check.pl--capacity uit op beide systemen en vergelijk de opnamesnelheden van zowel bron- als doelsystemen.
• Als het doel puur een doelsysteem is en ALLE back-ups van de bron ontvangt, moet de opnamesnelheid nauwkeurig overeenkomen met de opnamesnelheid van de bron.
• De kolommen Avamar NEW of DDR NEW geven aan hoeveel nieuwe data aan deze systemen wordt toegevoegd.
• Let ook goed op de kolommen "removed", "mins" en "pass" om inzicht te krijgen in het gedrag van garbage collection op beide systemen.
• Deze informatie geeft een duidelijk beeld van wat er op beide systemen gebeurt.
• Zie Avamar voor meer informatie over het interpreteren van de uitvoer: Capaciteit beheren met het script capacity.sh

Dump een lijst met back-ups die op elk systeem aanwezig zijn:

• Het dump_root_hashes.rb-script is een hulpprogramma waarmee het verschil in opgeslagen back-ups tussen een Avamar-bron en een doelsysteem kan worden vergeleken. Dit is zelfs mogelijk als de back-ups worden gehost op Data Domain-storage.   
• Zie Avamar: Avamar: Het dump_root_hashes.rb-script gebruiken om een lijst met clients en back-ups te genereren voor informatie over het downloaden van het hulpprogramma en gebruiksscenario's, inclusief het vergelijken van de inhoud van twee Avamar-systemen.
  • Voer het hulpprogramma uit. Controleer op inconsistenties in het aantal back-ups op alle clients. Let op verschillen van +/-2).  
• Zoals besproken in de sectie Oorzaken, leidt asymmetrisch capaciteitsbeheer tot verschillen tussen de twee systemen. Bekijk de uitvoer om te bepalen of dit het scenario kan zijn.
• Ook:
  • Controleer het doel op data op het doelsysteem van niet-gerepliceerde back-ups.
  • Controleer de bron op data die niet zijn gerepliceerd naar het doel.

Controleer op verschillende stripe-structuren (bijvoorbeeld meer pariteitsstrepen op één systeem):

• De twee Avamar-systemen zijn onafhankelijk van elkaar en kunnen verschillende stripestructuren hebben. Systemen met meerdere knooppunten kunnen verschillen vertonen vanwege het gebruik van pariteitsstrepen om data te beschermen. Afhankelijk van hun capaciteitsgeschiedenis bevatten twee systemen met meerdere knooppunten dezelfde back-ups, maar het ene systeem kan een hoger aantal pariteitsstrepen hebben dan het andere.  
• Net als bij gewone stripes blijft er een pariteitsstrip op het systeem nadat deze is gemaakt. In tegenstelling tot gewone stripes neemt deze altijd een vaste hoeveelheid ruimte in beslag binnen Avamar, zelfs als de safe-stripes van hun pariteitsgroep geen data bevatten. Garbage collection heeft geen effect op dit gedrag.
• Een replicatiedoelsysteem wordt indirect beschermd tegen grote capaciteitsproblemen op een replicatiebron. De situatie kan zich echter op beide computers voordoen als een van de systemen slecht wordt beheerd vanuit capaciteitsperspectief.
• Gerelateerd artikel:  Avamar geeft tot ~30% gebruik weer, zelfs nadat alle back-ups zijn verwijderd en afval is verzameld

Back-ups die nog in MC_DELETED zijn:

• Een zeldzaam scenario om rekening mee te houden is dat een client op de bron is verwijderd, maar de back-ups zijn bewaard. Hierdoor heeft de bron een hoger gebruik dan het doel waarbij de back-ups naar verwachting op natuurlijke wijze verlopen. Het gebruik van het dump_root_hashes.rb-script met de optie backupcompare zou moeten helpen bij het controleren op dit scenario.