PowerScale : un cluster dans une relation SyncIQ signale plus d’espace disque utilisé que l’autre cluster.
Сводка: Cet article explique pourquoi un cluster dans une relation syncIQ (source ou cible) peut signaler plus d’espace disque utilisé que l’autre cluster. Les deux clusters doivent afficher l’espace disque utilisé de manière identique. Les tâches SyncIQ sont à jour. ...
Симптомы
Un cluster PowerScale dans une relation syncIQ (source ou cible) utilise plus d’espace disque que l’autre cluster PowerScale. Les deux clusters doivent disposer de l’espace utilisé de manière identique.
Par exemple, comme on l’a vu avec le 'isi status' commande :
Le cluster cible indique que le 349T utilisait le stockage sur disque dur (disque dur) :
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
La source ne dispose que d’un stockage sur disque dur de 286 To utilisé :
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%)
Причина
Les causes courantes des différences d’espace entre les clusters dans une relation syncIQ sont les suivantes :
--fichiers système volumineux ou journaux d’audit qui résident dans /ifs/.ifsvar (le plus courant)
--différences de taille
de snapshot--différences de niveaux
de protection--La tâche de collecte ne s’exécute pas sur un cluster, ce qui ne libère pas les blocs de disques orphelins.
--fichiers / dossiers volumineux liés au support vivant dans /ifs/data/Isilon_Support
Разрешение
En supposant que toutes les tâches syncIQ sont à jour avec la réplication, vérifiez les points suivants :
1) Il arrive souvent que le cluster qui utilise plus d’espace dispose de fichiers système volumineux ou de journaux d’audit qui résident dans /ifs/.ifsvar.
Sur chaque cluster, à partir d’une session d’écran (car la commande peut prendre beaucoup de temps à renvoyer), exécutez les opérations suivantes :
# du -sh /ifs/.ifsvar
Exécutez cette commande sur chaque cluster.
Le support PowerScale a déjà vu ce type de problème par le passé, notamment en raison des journaux d’audit volumineux.
Cochez la case /ifs/.ifsvar/audit et les sous-répertoires suivants,
Where <nodeXXX> is the node ID (for example node001):/ifs/.ifsvar/audit/logs/.
/ifs/.ifsvar/audit/logs/<nodeXXX>
/ifs/.ifsvar/audit/logs/<nodeXXX>/protocol
Si nécessaire, supprimez les fichiers d’audit à l’aide de l’article suivant :
KB 000167091Powerscale : comment supprimer des fichiers de journal d’audit
2) Vérifiez qu’il n’existe aucune différence de niveau de protection entre les deux clusters.
Live cluster :
isi stat -p -q -v
Journaux :
# cat <base log set>/local/isi_stat-p
Dell Technologies peut également vérifier le diskpools niveaux de protection à l’aide d’une commande interne avec l’assistance du support.
3) Vérifiez qu’il n’y a pas de grande différence d’utilisation des snapshots entre les deux clusters en exécutant la commande suivante sur chaque cluster :
# isi snapshot usage
4) Sur le cluster signalant plus d’espace utilisé, vérifiez si des fichiers/dossiers volumineux liés au support résident dans le cluster /ifs/data/Isilon_Support:
# du -so /ifs/data/Isilon_Support
5) Si le problème persiste, l’étape suivante consiste à vérifier la date de la dernière exécution de la collecte sur chaque cluster.
(Remarque : Il est important de noter que le « MultiScan » n’exécute pas toujours le travail de collecte).
Cette tâche de collecte libère les blocs de disque obsolètes sur le cluster et peut souvent expliquer pourquoi un cluster affiche plus d’espace disque utilisé que l’autre. Une façon rapide de le faire est de vérifier le /var/log/messages sur les nœuds pour la dernière fois que la collecte a été exécutée avec succès, par exemple :
# grep Collect /var/log/messages|grep Succeed
# zgrep Collect /var/log/messages*
6) Si vous êtes toujours bloqué, courez FSAnalyze et utilisez InsightIQ pour voir quel dossier occupe le plus d’espace sur le cluster avec le plus d’espace utilisé.
'isi stat heat' sur le cluster, qui est plus complète, peut également fournir des indices sur l’endroit où les nouvelles écritures se produisent.