PowerScale: Ett kluster i en SyncIQ-relation rapporterar mer använt diskutrymme än det andra klustret.
Сводка: Den här artikeln förklarar varför ett kluster i en syncIQ-relation (källa eller mål) kan rapportera mer använt diskutrymme än det andra klustret. Båda klustren ska visa identiskt använt diskutrymme. SyncIQ-jobben är uppdaterade. ...
Симптомы
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) - Skillnader i storlek på ögonblicksbilder
- Skillnader i skyddsnivåer
- Insamlingsjobbet körs inte på ett kluster, vilket innebär att överblivna diskblock inte frigörs.
- Stora supportrelaterade filer/mappar som finns i
/ifs/data/Isilon_Support
Разрешение
Förutsatt att alla syncIQ-jobb är uppdaterade med replikering kontrollerar du följande:
- 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
- Bekräfta att det inte finns några skillnader i skyddsnivå mellan de två klustren.
Live-kluster:
isi stat -p -q -v
/log
# cat <base log set>/local/isi_stat-p
Dell Technologies kan också kontrollera diskpools skyddsnivåer med ett internt kommando med supporthjälp.
- Bekräfta att det inte är någon större skillnad med användning av ögonblicksbilder mellan de två klustren genom att köra följande kommando på varje kluster:
# isi snapshot usage
- I klustret som rapporterar mer använt utrymme kontrollerar du om det finns några stora supportrelaterade filer/mappar
/ifs/data/Isilon_Support:
# du -so /ifs/data/Isilon_Support
- Om den fortfarande har fastnat är nästa steg att kontrollera när Collect senast kördes i varje kluster.
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*
- Om enheten fortfarande sitter fast kör du
FSAnalyzejobb och använd InsightIQ för att se vilken mapp som tar upp mer utrymme i klustret med mer använt utrymme.
'isi stat heat' Kommandot på klustret som är mer fullständigt kan också ge några ledtrådar om var nya skrivningar sker.