Avamar: Inzicht in het verschil tussen servergebruik en het gebruik van fysieke ruimte op dataknooppunten

De hoeveelheid ruimte die wordt verbruikt in de fysieke datapartities van het Avamar-storageknooppunt is hoog, terwijl het cijfer "Servergebruik" relatief laag is.

Voorbeeld:
De Avamar server meldt dat deze 9,2% van de beschikbare ruimte voor back-updata verbruikt:

De Avamar-datapartities vertonen een hoger ruimtegebruik:

De reden hiervoor is dat de Avamar 'Server utilization'-waarde niet wordt berekend op basis van de hoeveelheid ruimte die wordt verbruikt in de fysieke partities.

De fysieke "/data" partities bevatten stripes, die in wezen containers zijn voor back-upgegevens.

De gebruikswaarde van de Avamar server (ook bekend als gebruikerscapaciteit of GSAN-capaciteit) wordt gemeten op basis van hoe vol deze stripe-containers zijn.

Zodra stripe-containers zijn gemaakt, blijven ze voor altijd op het Avamar-raster en worden ze indien nodig gerecycled. Als een Avamar grid ooit een hoge capaciteit bereikt, gebruiken de bestaande stripe-containers tot 65% van de totale ruimte van de datapartities.

Dit blijft zo, zelfs als een grote hoeveelheid back-updata wordt verwijderd en de waarde "servergebruik" daalt.

Dit is bedoeld en normaal gedrag.

Meer informatie:
Op een nieuw geïmplementeerd Avamar-raster wordt de /data Partities bevatten slechts enkele strepen (datacontainers). Zowel het servergebruik als de ruimte die wordt verbruikt in de /data Partities rapporteren lage waarden.

Na verloop van tijd, als stripes worden gevuld met back-updata, worden er nieuwe stripes gemaakt in de /data Partities. Het ruimteverbruik van de /data Partities stijgen. Dit gaat door totdat het raster vooraf bepaalde 'veilige' limieten bereikt die zijn ingesteld door de Avamar-server en de MCS.

Standaard is de hoeveelheid ruimte in de datapartities die door stripe-containers wordt verbruikt 65%. Soms kan de waarde variëren, bijvoorbeeld wanneer het raster:

• Heeft aangepaste limieten toegepast als gevolg van licentiebeperkingen (de limieten zijn lager)
• Is geconfigureerd met versleuteling in rust (de limieten zijn lager)
• Is geconfigureerd met aangepaste capaciteitslimieten voor metadata (de limieten zijn iets hoger)

De reden voor de bovengenoemde "veilige" limieten is om ervoor te zorgen dat de /data Scheidingswanden hebben voldoende vrije ruimte voor onderhoudsactiviteiten.

Hieronder ziet u een grafiek die dit illustreert:

100%   "---------------------" <-- 100% /data partition capacity
       " Reserved for        "
       " maintenance         "
       " activity overhead   "
       "                     "
       "                     "
65%    "---------------------" <-- 100% Server Utilization value
       " Commonality         "     (visible in the Admin GUI)
       " factored data       "     
       " & RAIN parity       "     
       " data                "     
       "                     "
       "                     "
       "                     "
       "                     "
0%     "---------------------"

Het gedrag van de besturingssysteem- en Avamar-servercapaciteit wordt in meer detail besproken in het volgende artikel: Avamar: Concepten en training voor capaciteitsbeheer

Avamar geïntegreerd met Data Domain:
op Avamar-rasters die zijn geïntegreerd met Data Domain, schrijven back-ups die naar Data Domain worden verzonden slechts een kleine hoeveelheid data naar Avamar. Dit staat bekend als metadata. De metadata bevinden zich in samengestelde strepen en nemen relatief weinig ruimte in beslag in vergelijking met clientback-ups die zijn opgeslagen op Avamar.

In bepaalde scenario's, waarbij metadataparameters zijn 'afgestemd' door technische support, kan het percentage van de ruimte dat wordt verbruikt door 'cur' op een Avamar-raster hoger zijn dan 65%.

Andere punten om op te merken:RAIN/
Pariteitsgegevens:
In het volgende artikel wordt beschreven waarom het servergebruik altijd het ruimtegebruik van pariteitsstripes omvat, zelfs nadat alle back-ups zijn verwijderd: Avamar geeft tot ~30% gebruik weer, zelfs nadat alle back-ups zijn verwijderd en afval is verzameld