PowerScale: Én klynge i en SyncIQ-relasjon rapporterer mer brukt diskplass enn den andre klyngen.

Én PowerScale-klynge i en syncIQ-relasjon (kilde eller mål) har mer brukt diskplass enn den andre PowerScale-klyngen. Begge klyngene skal ha identisk brukt plass.

Eksempel, som vist med 'isi status' kommando:

Målklynge viser at 349T brukte harddisklagring (HDD):

Cluster Name: TARGET-POWERSCALE
Cluster Health: [ ATTN]
Data Reduction:     1.00 : 1
Storage Efficiency: 0.73 : 1
Cluster Storage:  HDD                 SSD Storage
Size:             417.2T (432.5T Raw) 5.7T (5.7T Raw)
VHS Size:         15.4T
Used:             348.6T (84%)        669.1G (11%)    ==================>
Avail:            68.6T (16%)         5.1T (89%)

                   Health  Throughput (bps)  HDD Storage      SSD Storage
ID |IP Address     |DASR |  In   Out  Total| Used / Size     |Used / Size
---+---------------+-----+-----+-----+-----+-----------------+-----------------
  9|1099.2.6      | OK  | 1.0M| 488k| 1.5M|87.2T/ 104T( 84%)| 167G/ 1.4T( 11%)
 10|10.99.2.7      | OK  | 820M| 4.2M| 824M|87.2T/ 104T( 84%)| 167G/ 1.4T( 11%)
 11|10.99.2.8      | OK  | 678M| 2.9M| 681M|87.2T/ 104T( 84%)| 167G/ 1.4T( 11%)
 12|10.99.2.9      | OK  |    0| 123k| 123k|87.1T/ 104T( 84%)| 167G/ 1.4T( 11%)
---+---------------+-----+-----+-----+-----+-----------------+-----------------
Cluster Totals:          | 1.5G| 7.7M| 1.5G| 349T/ 417T( 84%)| 669G/ 5.7T( 11%)

     Health Fields: D = Down, A = Attention, S = Smartfailed, R = Read-Only

Kilde har bare 286T brukt HDD-lagring:
 

Cluster Name: SOURCE-POWERSCALE
Cluster Health:     [ ATTN]
Data Reduction:     1.00 : 1
Storage Efficiency: 0.71 : 1
Cluster Storage:  HDD                 SSD Storage
Size:             417.2T (432.5T Raw) 5.7T (5.7T Raw)
VHS Size:         15.4T
Used:             285.5T (68%)        721.9G (12%)    ========>
Avail:            131.7T (32%)        5.0T (88%)

                   Health  Throughput (bps)  HDD Storage      SSD Storage
ID |IP Address     |DASR |  In   Out  Total| Used / Size     |Used / Size
---+---------------+-----+-----+-----+-----+-----------------+-----------------
  9|10.99.3.13     | OK  | 290M| 9.9M| 300M|71.4T/ 104T( 68%)| 180G/ 1.4T( 12%)
 10|10.99.3.11     | OK  | 324M| 832M| 1.2G|71.4T/ 104T( 68%)| 181G/ 1.4T( 12%)
 11|10.99.3.12     | OK  | 194M| 8.4M| 202M|71.4T/ 104T( 68%)| 181G/ 1.4T( 12%)
 12|10.99.3.10     | OK  | 1.9M| 2.0M| 3.8M|71.4T/ 104T( 68%)| 181G/ 1.4T( 12%)
---+---------------+-----+-----+-----+-----+-----------------+-----------------
Cluster Totals:          | 809M| 852M| 1.7G| 286T/ 417T( 68%)| 722G/ 5.7T( 12%)

Vanlige årsaker til forskjeller i mellomrom mellom klynger i et syncIQ-forhold er som følger:

--store systemfiler eller revisjonslogger som finnes i /ifs/.ifsvar (vanligst)
--forskjeller i øyeblikksbildestørrelse
--forskjeller i beskyttelsesnivåer
--Samle jobb som ikke kjører på en klynge, og dermed ikke frigjøre foreldreløse diskblokker.
Store støtterelaterte filer/mapper som bor innenfor /ifs/data/Isilon_Support

Forutsatt at alle syncIQ-jobber er oppdatert med replikering, kontrollerer du følgende:

1) Klyngen som bruker mer plass, har store systemfiler eller revisjonslogger som finnes innenfor /ifs/.ifsvar.

Kjør følgende på hver klynge fra en skjermøkt (siden kommandoen kan ta lang tid å returnere):
 

# du -sh /ifs/.ifsvar

Kjør den kommandoen på hver klynge.

PowerScale-støtte har sett at dette er synderen tidligere, spesielt på grunn av store revisjonslogger.

Sjekk ikonet /ifs/.ifsvar/audit katalog og følgende underkataloger,

 Where <nodeXXX> is the node ID (for example node001):/ifs/.ifsvar/audit/logs/.
 /ifs/.ifsvar/audit/logs/<nodeXXX>
/ifs/.ifsvar/audit/logs/<nodeXXX>/protocol

Hvis det er nødvendig, sletter du overvåkingsfilene ved hjelp av følgende artikkel:

KB 000167091Powerscale: Slik fjerner du filer for overvåkingslogg

2) Bekreft at det ikke er forskjeller i beskyttelsesnivået mellom de to klyngene.

Live cluster:
 

isi stat -p -q -v

Logger:
 

# cat <base log set>/local/isi_stat-p

Dell Technologies kan også kontrollere diskpools beskyttelsesnivåer med en intern kommando med Støttehjelp.

3) Bekreft at det ikke er noen stor forskjell med øyeblikksbildebruk mellom de to klyngene ved å kjøre følgende kommando på hver klynge:
 

# isi snapshot usage

4) Se etter store støtterelaterte filer/mapper på klyngen som rapporterer mer brukt plass /ifs/data/Isilon_Support:

# du -so /ifs/data/Isilon_Support 

5) Hvis den fortsatt sitter fast, er neste trinn å sjekke når Collect sist ble kjørt på hver klynge.

(Merk: Det er viktig å merke seg at 'MultiScan' ikke alltid kjører Collect-jobben). 

Denne Collect-jobben frigjør eventuelle foreldede diskblokker på klyngen og kan ofte være årsaken til at en klynge viser mer brukt diskplass enn den andre klyngen.  En rask måte å gjøre dette på er å sjekke /var/log/messages på nodene for siste gang Successfully Collect kjørte, for eksempel:

# grep Collect /var/log/messages|grep Succeed
# zgrep Collect /var/log/messages* 

 6) Hvis du fortsatt sitter fast, løp FSAnalyze jobb og bruk InsightIQ til å se hvilken mappe som tar opp mer plass på klyngen med mest brukt plass.