Avamar: Replikoiva pari näyttää kapasiteetin käytön eri tasot. Kuinka tutkia syitä.

Syyt ja mahdolliset syyt "palvelimen käyttöasteen" arvojen eroihin:

Loogiset tai fyysiset erot verkkojen välillä:

• Eri määrä tietosolmuja lähde- ja kohderuudukoissa.
• Kunkin ruudukon datasolmuilla on erilaiset levykokoonpanot.
• Riittävän tasapainoinen raitojen jakautuminen kunkin järjestelmän datasolmujen välillä (2 %:n tarkkuudella)
• Tallennus- ja pariteettivaatimukset vaihtelevat Avamar-versioittain. Käytössä voi olla eroja, jos lähde- ja kohdeohjelmistoversiot poikkeavat toisistaan.
• Avamar-palvelimen levyn vain luku -taso saattaa vaihdella järjestelmien välillä.   
• Yksi ruudukko voidaan määrittää RAIN-pariteettia varten, kun taas toinen ei.

Replikoinnin määritys:

• Kohdejärjestelmään replikoiduilla varmuuskopioilla saattaa olla erilainen säilytyskäytäntö kuin lähteellä. Katso lisätietoja vanhentuneesta lipusta. Vaihtoehtoisesti replikoidut varmuuskopiot voivat kattaa vain tietyn ajanjakson. Esimerkiksi viimeiset 4 viikkoa varmuuskopioita lähteestä.
• Replikointi voidaan määrittää replikoimaan vain osa asiakkaista lähdejärjestelmästä kohdejärjestelmään. Tarkista, käytetäänkö "sisällytä"- tai "sulje" -asetuksia.
• Asiakkaat ja niihin liittyvät varmuuskopiot on ehkä poistettu lähdejärjestelmästä. Asiakkaan tai lähteen varmuuskopioiden poistaminen ei poista samoja varmuuskopioita kohdejärjestelmästä. Varmuuskopiot pysyvät kohteessa, kunnes ne vanhenevat säilytysasetusten mukaisesti.
• Lähdejärjestelmän varmuuskopioiden tai asiakkaiden säilytyskäytäntöjä voidaan muuttaa. Säilytyskäytäntöjen muutos vaikuttaa vain uusiin varmuuskopiointeihin. Uudet varmuuskopiot replikoidaan kohteeseen ja ne noudattavat päivitettyä säilytyskäytäntöä. Kohteessa jo olevat varmuuskopiot säilyttävät säilytyskäytännön, jota sovellettiin niihin replikointihetkellä.

Aiempi kapasiteetin hallintatoimi:

• Ei ole epätavallista, että asiakkaat huomaavat, että jokin Avamarin replikointiparijärjestelmistä lähestyy kapasiteettia, ja ryhtyvät sitten vähentämään kapasiteettia. Muista - Avamar-replikointipari koostuu kahdesta itsenäisesti hallitusta järjestelmästä. Jos toimet toteutetaan yhdessä järjestelmässä, ne on suoritettava myös toisessa. 
• Jos varmuuskopiot poistetaan tai säilytystä vähennetään lähdejärjestelmässä, kohteeseen on tehtävä samat muutokset. Paras tapa hallita kapasiteettia tällä tavalla on modify-snapups-komentosarja. Tämä voidaan suorittaa molemmissa Avamar-palvelimissa samoilla varmuuskopioinnin muokkaus- tai poistovaihtoehdoilla.  

Erilainen raitarakenne (esimerkiksi enemmän pariteettiraitoja yhdessä järjestelmässä):

• Koska Avamar on itsenäinen, sen rakenne voi olla erilainen. Monisolmujärjestelmissä voi esiintyä eroja, koska ne käyttävät pariteettiraitoja tietojen suojaamiseen. Kapasiteettihistoriansa mukaan kahdessa monisolmujärjestelmässä on samat varmuuskopiot, mutta toisessa voi olla enemmän pariteettiraitoja kuin toisessa.
• Kuten tavalliset raidat, kun ne on luotu, pariteettiraita jää aina järjestelmään. Toisin kuin tavalliset raidat, se vie aina kiinteän määrän tilaa Avamar-palvelimessa. Näin on, vaikka niiden pariteettiryhmän turvalliset raidat eivät sisältäisi tietoja. Roskien keräämisellä ei ole vaikutusta tähän käyttäytymiseen.
• Replikoinnin kohdejärjestelmä on epäsuorasti suojattu replikointilähteen suurilta kapasiteettiongelmilta. Tilanne voi kuitenkin syntyä kummalla tahansa koneella, jos toista niistä hallitaan huonosti kapasiteetin näkökulmasta.
• Aiheeseen liittyvä artikkeli: Avamarin käyttöaste on ~ 30 %, vaikka kaikki varmuuskopiot on poistettu ja roskat kerätty

Varmuuskopiot ovat edelleen MC_DELETED:

• Yksi harvinainen tilanne, josta kannattaa olla tietoinen, on tilanne, jossa asiakas poistetaan lähteestä, mutta sen varmuuskopiot säilytetään. Tämä voi johtaa siihen, että lähteen käyttöaste on kohdetta suurempi, jolloin varmuuskopioiden odotetaan vanhenevan luonnollisesti. dump_root_hashes.rb-komentosarjan käyttäminen backupcompare -vaihtoehdon kanssa auttaa tarkistamaan tämän tilanteen.

Kohdejärjestelmän tiedot replikoimattomista varmuuskopioista:

• Jos järjestelmä replikoituu *yhteen suuntaan*, tarkista kohteesta, ettei /REPLICATE- ja MC_SYSTEM:n ulkopuolisia asiakkaita ole.

Muut toiminnot:

• Replikointitöitä ei välttämättä tehdä täysin luotettavasti. Kohteeseen lähetetyt tiedot voivat "viivästyä" lähteestä useita päiviä.
• Molemmat järjestelmät sisältävät saman määrän deduplikoituja tietoja, mutta pariteettikustannusten määrä on erilainen. Tämä tapahtuu seuraavassa tilanteessa: 
  • Avamar-lähdejärjestelmä on lähes täynnä. 
  • Monet varmuuskopiot poistetaan lähdejärjestelmästä sen kapasiteettitason alentamiseksi. 
  • Deduplikoitujen tietojen replikointi tapahtuu sitten lähteestä kohteeseen. 
  • Deduplikoitujen tietojen määrä on sama molemmissa järjestelmissä.
  • Lähdejärjestelmä tallentaa aluksi enemmän pariteettikustannuksia kuin kohde.
• Replikointi ei kopioi fyysisiä raitoja lähdeverkosta kohdeverkkoon. Sen sijaan kohderuudukon annetaan määrittää itse, mihin nauhat ja tietopalat tallennetaan.
• Joskus kohde-Avamar-järjestelmät voivat tallentaa tietoja tehokkaammin kuin lähderuudukko, johon tiedot on alun perin varmuuskopioitu.

Tietoja replikointiympäristöstä:

• Merkitse muistiin Avamar-lähderuudukon koko isäntänimi.
• Tutki kyseisten järjestelmien replikointikonfiguraatiota ymmärtääksesi, mitkä järjestelmät replikoivat mitäkin tietoja ja mihin. 
  • Kaavion laatiminen ympäristöstä voi auttaa, jos se on jotain monimutkaisempaa kuin replikointi yhdestä Avamar-palvelimesta toiseen.
• Jos lähde integroituu Data Domainiin (DD), selvitä, liittyykö asiakkaan huolenaihe DD-laitteiden välillä replikoituihin varmuuskopioihin.
• Merkitse muistiin Avamar-kohderuudukon koko isäntänimi ja kaikki siihen liittyvät DD-laitteet, jotka vastaanottavat replikoituja varmuuskopioita.

Tarkista verkon yleinen kunto ja tilanne:

• Suorita ennakoiva tarkistuskomentosarja molemmissa ruudukoissa ja hanki kopio hc_results.txt ja tarkista, jotta ymmärrät järjestelmän kokonaistilanteen. 

Kuinka vakava kapasiteettiero on?

• Asiakkaan on toimitettava kuvakaappaus siitä, mitä hän katselee, mikä saa hänet uskomaan, että lähteen ja kohteen välillä on kapasiteetin kulutusero.
• Emme pidä syytä huoleen, jos kapasiteettiero on alle 5%.
• Tarkista Avamar Administrator -käyttöliittymästä Avamar-palvelinkapasiteetin tasot ja (jos Data Domain on integroitu) metatietokapasiteetti.
• Selvitä, miten käyttöliittymän kapasiteettinäyttö toimii (tästä on keskusteltu Avamar UI -koontinäytössä versiossa 7.2 ja uudemmissa näytetään metatietojen käyttö Avamar-käytön sijaan).
• Suorita seuraava komento molemmissa järjestelmissä. Palvelimen käyttöarvo ilmaisee Avamar-palvelimen (mutta ei Data Domainin) kapasiteettitasojen kokonaisarvon:

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

Server utilization               3.7%

Tarkista, että laitteisto on sama molemmissa ruudukoissa:

• On järkevää verrata vain "vastaavten" järjestelmien kapasiteettieroja. 
• Huomioi järjestelmässä olevien solmujen tyyppi ennakoivan tarkistustuloksen avulla.
• Seuraava komento näyttää fyysisten solmujen kokonaismäärän, koon ja tilankulutuksen:

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

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

• Tämän lähdön avulla on helppo määrittää järjestelmän solmujen lukumäärä ja koko. Ne ovat (23.3 / 3 = ~7.8 TB). 
• Kunkin solmun kiintolevyosioiden lukumäärän ja koon on vahvistettava tämä.

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

• Tarkista näiden tietojen avulla seuraavat asiat:

Tarkista ohjelmiston versio ja kokoonpano:

• Vertaa kussakin järjestelmässä käytössä olevaa Avamar-versiota status.dpn-komennon tuloksen perusteella.
• Varmista monisolmujärjestelmissä, että molemmissa järjestelmissä on RAIN-pariteetti Avamarin mukaan. Näin määrität, onko palvelin RAIN- vai ei-RAIN
• Tarkista ja vertaa kahden järjestelmän kapasiteettiin liittyviä Avamar-palvelinkokoonpanon parametreja. Esimerkki:

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"

Tarkista raidan tasapainotus:

• Tarkista status.dpn-tulos ja merkitse muistiin kunkin datasolmun raitojen kokonaismäärä. Raitojen lukumäärä on merkitty suluissa (esimerkiksi onl:xxx). 
• Kunkin datasolmun raitojen kokonaismäärän välillä pitäisi olla alle 2 %:n ero.

Tarkista, että roskien keräys on toiminut oikein molemmissa järjestelmissä:

• Jos roskien keräys ei toimi johdonmukaisesti ja tehokkaasti, se ei poista vanhentuneita tietoja. Järjestelmä ilmoittaa odotettua suuremmasta kapasiteetin käytöstä. 
  • Lisätietoja on rajoitettujen huomautusten GC-ratkaisupolkua koskevassa artikkelissa.

Varmista, että replikointi on valmis:

• Varmista, että kaikki replikointitehtävät lähteestä kohteeseen onnistuvat. Jos näin ei ole tapahtunut, voi olla, että tietoja on vielä kopioitava lähteestä kohteeseen.

Tarkista replikointimääritykset:

• Tarkista, onko replikointimäärityksissä (käyttöliittymässä, komentoriviliittymässä tai lokeissa) jokin seuraavista merkinnöistä:

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

--expiredelta

--retention-types

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

Tarkista molempien järjestelmien käsittely- ja poistonopeudet:

• Suorita proactive_check.pl -kapasiteetti molemmissa järjestelmissä ja vertaa sekä lähde- että kohdejärjestelmien käsittelynopeuksia.
• Jos kohde on puhtaasti kohdejärjestelmä ja vastaanottaa KAIKKI varmuuskopiot lähteestä, sen käsittelynopeuden tulisi seurata tarkasti lähteen nielemisnopeutta.
• Avamar NEW- tai DDR NEW -sarakkeissa näkyy, kuinka paljon kyseisiin järjestelmiin lisätään uutta tietoa.
• Kiinnitä myös erityistä huomiota sarakkeisiin "poistettu", "mins" ja "pass" ymmärtääksesi roskien keräyskäyttäytymistä molemmissa järjestelmissä.
• Nämä tiedot antavat selkeän kuvan siitä, mitä molemmissa järjestelmissä tapahtuu.
• Lisätietoja tulosteen tulkinnasta on kohdassa Avamar: Kapasiteetin hallinta capacity.sh komentosarjan avulla

Tyhjennä luettelo kussakin järjestelmässä olevista varmuuskopioista:

• dump_root_hashes.rb-komentosarja on apuohjelma, jonka avulla voit verrata Avamar-lähteen ja kohdejärjestelmän varmuuskopioiden eroja. Näin on myös silloin, kun varmuuskopioita isännöidään Data Domain -tallennustilassa.   
• Katso Avamar: Avamar: dump_root_hashes.rb-komentosarjan käyttäminen asiakas- ja varmuuskopioluettelon luomiseen Lisätietoja apuohjelman lataamisesta ja käyttötapauksista, mukaan lukien kahden Avamar-järjestelmän sisällön vertailu.
  • Suorita työkalu. Tarkista mahdolliset epäjohdonmukaisuudet kaikkien asiakkaiden varmuuskopioiden määrissä. Kiinnitä huomiota +/-2: n eroihin).  
• Kuten Syyt-osiossa todettiin, epäsymmetrinen kapasiteetin hallinta johtaa eroihin näiden kahden järjestelmän välillä. Tarkista tulos ja selvitä, voiko tämä olla skenaario.
• Myös:
  • Tarkista kohdejärjestelmän tiedot replikoimattomista varmuuskopioista.
  • Tarkista lähteestä tiedot, joita ei ole replikoitu kohteeseen.

Tarkista, onko raidallisia rakenteita (esimerkiksi enemmän pariteettiraitoja yhdessä järjestelmässä):

• Koska Avamar-järjestelmät ovat itsenäisiä, niiden raitarakenne voi olla erilainen. Monisolmujärjestelmissä voi esiintyä eroja, koska ne käyttävät pariteettiraitoja tietojen suojaamiseen. Kapasiteettihistoriansa mukaan kahdessa monisolmujärjestelmässä on samat varmuuskopiot, mutta toisessa voi olla enemmän pariteettiraitoja kuin toisessa.  
• Kuten tavalliset raidat, kun ne on luotu, järjestelmään jää pariteettiraita. Toisin kuin tavalliset raidat, ne vievät aina kiinteän määrän tilaa Avamarissa, vaikka niiden pariteettiryhmien turvalliset raidat eivät sisältäisi tietoja. Roskien keräämisellä ei ole vaikutusta tähän käyttäytymiseen.
• Replikoinnin kohdejärjestelmä on epäsuorasti suojattu replikointilähteen suurilta kapasiteettiongelmilta. Tilanne voi kuitenkin syntyä kummalla tahansa koneella, jos toista niistä hallitaan huonosti kapasiteetin näkökulmasta.
• Aiheeseen liittyvä artikkeli:  Avamarin käyttöaste on ~ 30 %, vaikka kaikki varmuuskopiot on poistettu ja roskat kerätty

Varmuuskopiot ovat edelleen MC_DELETED:

• Yksi harvinainen tilanne, josta kannattaa olla tietoinen, on tilanne, jossa asiakas poistettiin lähteestä, mutta sen varmuuskopiot säilytettiin. Tämä johtaa siihen, että lähteen käyttöaste on suurempi kuin kohteessa, jossa varmuuskopioiden odotetaan vanhenevan luonnollisesti. dump_root_hashes.rb-komentosarjan käyttäminen backupmatch-vaihtoehdon kanssa auttaa tarkistamaan tämän tilanteen.