PowerScale: Один кластер у відносинах SyncIQ повідомляє про більший обсяг використаного дискового простору, ніж інший кластер.

Один кластер PowerScale у співвідношенні syncIQ (джерело або ціль) має більше використаного місця на диску, ніж інший кластер PowerScale. Обидва кластери мали б однаково використовувати простір

.Приклад, як видно з 'isi status' command:

Target cluster показує, що 349T використовував сховище жорсткого диска (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

Source має лише 286T використаного HDD:
 

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

Поширені причини різниці у просторі між кластерами у syncIQ-відносинах такі:

великі системні файли або журнали аудиту, які зберігаються всередині /ifs/.ifsvar (найпоширеніше)
--відмінності у розмірі
знімка — різниці в рівнях
захисту — завдання Collect не виконується на одному кластері, тому не звільняє блоки сироти дисків.
--великі файли/папки, пов'язані з підтримкою, що зберігаються всередині /ifs/data/Isilon_Support

Припускаючи, що всі завдання syncIQ оновлені з реплікацією, перевірте наступне:

1) Часто кластер, що використовує більше місця, має великі системні файли або журнали аудиту, які зберігаються всередині /ifs/.ifsvar.

У кожному кластері з екранної сесії (оскільки команда може довго повертатися) виконується наступне:
 

# du -sh /ifs/.ifsvar

Виконуйте цю команду на кожному кластері.

PowerScale Support раніше вважала це проблемою, особливо через великі журнали аудиту.

Перевірте /ifs/.ifsvar/audit Каталог та наступні підкаталоги,

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

За потреби видаліть файли аудиту за наступною статтею:

KB 000167091Powerscale: Як видалити файли журналу аудиту

2) підтвердити, що між двома кластерами немає відмінностей у рівні захисту.

Живий кластер:
 

isi stat -p -q -v

Журнали:
 

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

Dell Technologies також може перевірити diskpools рівні захисту з внутрішнім командуванням із підтримкою.

3) Підтвердити, що немає великої різниці у використанні знімків між двома кластерами, виконавши таку команду на кожному кластері:
 

# isi snapshot usage

4) У кластері, що повідомляє про більше використаного простору, перевірте наявність великих файлів/папок, пов'язаних із підтримкою, які знаходяться всередині /ifs/data/Isilon_Support:

# du -so /ifs/data/Isilon_Support 

5) Якщо все ще застрягла, наступний крок — перевірити, коли Collect був запущений востаннє на кожному кластері.

(Примітка: важливо зазначити, що «MultiScan» не завжди виконує завдання Collect). 

Це завдання Collect звільняє будь-які застарілі блоки дисків у кластері і часто може бути причиною того, що один кластер показує більше використаного місця на диску, ніж інший.  Один із швидких способів — перевірити /var/log/messages на вузлах востаннє Collect успішно працював, наприклад:

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

 6) Якщо все ще застрягла — біжіть FSAnalyze і використовуйте InsightIQ, щоб побачити, яка папка займає більше місця в кластері з більшим використанням місця.