PowerScale: Ett kluster i en SyncIQ-relation rapporterar mer använt diskutrymme än det andra klustret.

Ett PowerScale-kluster i en syncIQ-relation (källa eller mål) har mer använt diskutrymme än det andra PowerScale-klustret. Båda klustren ska ha identiskt använt utrymme.

Exempel, som visas med 'isi status' kommando:

Målklustret visar att 349T-hårddisklagring (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

Källan har endast 286T använd 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%)

Vanliga orsaker till skillnader i utrymme mellan kluster i en syncIQ-relation är följande:

--stora systemfiler eller granskningsloggar som finns i /ifs/.ifsvar (vanligast)
--differences in snapshot size
--differences in protection levels
--Collect job körs inte på ett kluster, vilket inte frigör överblivna diskblock.
--stora supportrelaterade filer/mappar som bor i /ifs/data/Isilon_Support

Förutsatt att alla syncIQ-jobb är uppdaterade med replikering kontrollerar du följande:

1) Det är ofta så att klustret som använder mer utrymme har stora systemfiler eller granskningsloggar som finns i /ifs/.ifsvar. – Herr talman,

Kör följande från en skärmsession (eftersom kommandot kan ta lång tid att returnera) i varje kluster:
 

# du -sh /ifs/.ifsvar

Kör kommandot i varje kluster.

PowerScale-support har sett att detta är boven i dramat tidigare, särskilt på grund av stora granskningsloggar.

Kontrollera /ifs/.ifsvar/audit katalogen och följande 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

Om det behövs tar du bort granskningsfilerna genom att följa artikeln:

KB 000167091Powerscale: Så här tar du bort granskningsloggfiler

2) Bekräfta att det inte finns några skillnader i skyddsnivån mellan de två klustren.

Live-kluster:
 

isi stat -p -q -v

Loggar:
 

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

Dell Technologies kan också kontrollera diskpools skyddsnivåer med ett internt kommando med supporthjälp.

3) Bekräfta att det inte är någon större skillnad mellan de två klustren när det gäller användning av ögonblicksbilder genom att köra följande kommando på varje kluster:
 

# isi snapshot usage

4) I klustret som rapporterar mer använt utrymme kontrollerar du om det finns några stora supportrelaterade filer/mappar i /ifs/data/Isilon_Support:

# du -so /ifs/data/Isilon_Support 

5) Om det fortfarande har fastnat är nästa steg att kontrollera när Collect senast kördes i varje kluster.

(Obs: Det är viktigt att notera att "MultiScan" inte alltid kör insamlingsjobbet). 

Det här insamlingsjobbet frigör inaktuella diskblock i klustret och kan ofta vara orsaken till varför ett kluster visar mer använt diskutrymme än det andra klustret.  Ett snabbt sätt att göra detta är att kontrollera /var/log/messages på noderna för senaste gången Insamlingen kördes, till exempel:

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

 6) Om den fortfarande sitter fast, spring FSAnalyze jobb och använd InsightIQ för att se vilken mapp som tar upp mer utrymme i klustret med mer använt utrymme.