PowerScale: Den ene klynge i en SyncIQ-relation rapporterer mere brugt diskplads end den anden klynge.

Den ene PowerScale-klynge i et syncIQ-forhold (kilde eller mål) har mere brugt diskplads end den anden PowerScale-klynge. Begge klynger skal have identisk brugt plads.

Eksempel, som det ses med 'isi status' command:

Target cluster viser, at 349T brugte harddisklager (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

Kilden har kun 286T brugt harddisklager:
 

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%)

Almindelige årsager til forskelle i mellemrum mellem klynger i et syncIQ-forhold er som følger:

--store systemfiler eller revisionslogfiler, der findes i /ifs/.ifsvar (mest almindelige)
--forskelle i snapshot-størrelse
--forskelle i beskyttelsesniveauer
--Indsamlingsjob kører ikke på én klynge og frigør således ikke forældreløse diskblokke.
- store supportrelaterede filer / mapper, der bor i /ifs/data/Isilon_Support

Hvis vi antager, at alle syncIQ-job er opdateret med replikering, skal du kontrollere følgende:

1) Det er ofte tilfældet, at klyngen, der bruger mere plads, har store systemfiler eller overvågningslogfiler, der findes i /ifs/.ifsvar.

Kør følgende på hver klynge fra en skærmsession (da kommandoen kan være lang tid om at returnere den):
 

# du -sh /ifs/.ifsvar

Kør denne kommando på hver klynge.

PowerScale-support har tidligere anset dette for at være synderen, især på grund af store revisionslogfiler.

Tjek /ifs/.ifsvar/audit adresseregister og følgende undermapper:

 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ødvendigt, kan du slette overvågningsfilerne ved hjælp af følgende artikel:

KB 000167091Powerscale: Sådan fjernes overvågningslogfiler

2) Bekræft, at der ikke er forskelle i beskyttelsesniveauet mellem de to klynger.

Liveklynge:
 

isi stat -p -q -v

Logfiler:
 

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

Dell Technologies kan også kontrollere diskpools beskyttelsesniveauer med en intern kommando med supportassistance.

3) Bekræft, at der ikke er nogen stor forskel på brugen af snapshots mellem de to klynger ved at køre følgende kommando på hver klynge:
 

# isi snapshot usage

4) Når klyngen rapporterer mere brugt plads, skal du kontrollere, om der er store supportrelaterede filer/mapper i /ifs/data/Isilon_Support:

# du -so /ifs/data/Isilon_Support 

5) Hvis den stadig sidder fast, er næste trin at kontrollere, hvornår Collect sidst blev kørt på hver klynge.

(Bemærk: Det er vigtigt at bemærke, at 'MultiScan' ikke altid kører Collect-jobbet). 

Dette Collect-job frigør forældede diskblokke på klyngen og kan ofte være årsagen til, at den ene klynge viser mere brugt diskplads end den anden klynge.  En hurtig måde at gøre dette på er at kontrollere /var/log/messages på noderne for sidste gang Collect kørte med succes, f.eks.:

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

 6) Hvis du stadig sidder fast, skal du løbe FSAnalyze job, og brug InsightIQ til at se, hvilken mappe der optager mest plads i klyngen med mere brugt plads.