PowerFlex : Échec du basculement MDM en raison de défaillances d’allocation de mémoire - mos_MemMalloc

La sortie des événements du MDM récepteur /opt/emc/scaleio/mdm/bin/showevents.py aura plusieurs entrées pour tenter de prendre en charge les responsabilités du MDM principal, le tout à peu de temps d’intervalle :  

 2017-10-04 12:08:33.915 MDM_CLUSTER_BECOMING_MASTER WARNING This MDM, ID 394760fd6714xxxx, took control of 
the cluster and is now the Master MDM. 2017-10-04 12:08:33.915 MDM_BECOMING_MASTER WARNING This MDM is
 switching to Master mode. MDM will start running. .. 2017-10-04 12:08:34.309 MDM_CLUSTER_BECOMING_MASTER 
WARNING This MDM, ID 394760fd6714xxxx, took control of the cluster and is now the Master MDM. 
2017-10-04 12:08:34.309 MDM_BECOMING_MASTER WARNING This MDM is switching to Master mode. MDM will start 
running.

Le fichier exp.0 du MDM destinataire contient des entrées comme celle-ci : 

 04/10 12:08:34.079823 Panic in file /data/build/workspace/ScaleIO-SLES12-2/src/mos/usr/mos_utils.c, line 73, 
function mos_MemMalloc, PID 9978.Panic Expression bCanFail . /opt/emc/scaleio/mdm/bin/mdm-2.0.13000.211(
mosDbg_PanicPrepare+0x115) [0x6a86f5] /opt/emc/scaleio/mdm/bin/mdm-2.0.13000.211(mos_MemMalloc+0x81) 
[0x6ac0d1] /opt/emc/scaleio/mdm/bin/mdm-2.0.13000.211(multiHeadMgr_GetUpdateMultiHeadsMsg+0x66) [0x57123c]
 /opt/emc/scaleio/mdm/bin/mdm-2.0.13000.211(tgtMgr_ConfigureTgt+0x9c1) [0x4d579e] 
/opt/emc/scaleio/mdm/bin/mdm-2.0.13000.211(tgtMgr_HandleWorkReq+0x41b) [0x4d6206] 
/opt/emc/scaleio/mdm/bin/mdm-2.0.13000.211() [0x6c57d8] 
/opt/emc/scaleio/mdm/bin/mdm-2.0.13000.211(mosUmt_StartFunc+0xea) [0x6c51af]
 /opt/emc/scaleio/mdm/bin/mdm-2.0.13000.211(mosUmt_SignalHandler+0x51) [0x6c65d1]
 /lib64/libpthread.so.0(+0x10b00) [0x7f844e8a6b00] /lib64/libc.so.6(sleep+0xd4) [0x7f844d8911a4]

Le fichier /var/log/messages affiche les redémarrages multiples du service MDM, comme le fait le events.txt : 

 systemd[1]: mdm.service: Main process exited, code=exited, status=255/n/a systemd[1]: mdm.service: 
Unit entered failed state. systemd[1]: mdm.service: Failed with result 'exit-code'. systemd[1]: mdm.service:
 Service has no hold-off time, scheduling restart. systemd[1]: Stopped scaleio mdm. systemd[1]: mdm.service: 
Start request repeated too quickly. systemd[1]: Failed to start scaleio mdm. systemd[1]: mdm.service: Unit 
entered failed state. systemd[1]: mdm.service: Failed with result 'start-limit'.

Il ne s’agit pas d’un problème ScaleIO. ScaleIO fonctionne normalement.

Pour vérifier et/ou modifier les paramètres vm.overcommit, procédez comme suit :

1. Connectez-vous au SDS à l’aide de SSH en tant qu’utilisateur root

2. Exécutez 

cat /etc/sysctl.conf | grep "vm.overcommit"
Ex.
[root@sds-node logs]# cat /etc/sysctl.conf | grep "vm.overcommit"
vm.overcommit_memory = 2
vm.overcommit_ratio = 50

3. Exécutez les commandes suivantes.

sed -i 's/vm\.overcommit_memory = .*/vm\.overcommit_memory = 2/g' /etc/sysctl.conf
sed -i 's/vm\.overcommit_ratio = .*/vm\.overcommit_ratio = 100/g' /etc/sysctl.conf
sysctl -p

Validation

[root@sds-node logs]# cat /etc/sysctl.conf | grep "vm.overcommit"
vm.overcommit_memory = 2
vm.overcommit_ratio = 100

Répétez ces étapes sur tous les SDS concernés dans l’environnement pour vous assurer qu’ils sont définis sur les paramètres de bonnes pratiques recommandés. Vous n’avez pas besoin de mettre le SDS en mode maintenance pour effectuer cette opération. 

Pour en savoir plus sur ces paramètres, reportez-vous à la documentation du noyau Linux sur overcommit-accounting

Vérifiez les paramètres de noyau sysctl pour la surallocation de mémoire :

# sysctl -a |grep commit
vm.overcommit_memory = 2 (default is 0)
vm.overcommit_ratio = 50 (default is 50)

Dans ce cas, le fait d’avoir « vm.overcommit_memory » sur 2 signifie qu’il n’y a pas de surallocation de mémoire. Cette opération entraîne l’échec de toute allocation de mémoire dépassant la limite de surallocation. L’espace d’adressage total engagé pour le système ne peut pas dépasser swap + une quantité configurable (la valeur par défaut est de 50 %) de RAM physique. Lorsque ce paramètre est défini sur 0, il refuse les demandes évidentes de surengagement, mais les processus racine sont autorisés à allouer des ressources au-delà de la limite de survalidation. 

Pour vérifier la limite de surallocation actuelle et le montant engagé, reportez-vous respectivement à CommitLimit et Committed_AS à partir de la commande suivante :

#cat /proc/meminfo 
MemTotal: 8174572 kB 
.. 
CommitLimit: 4087284 kB 
Committed_AS: 3879388 kB

Cet hôte dispose de 8 Go de RAM et la limite CommitLimit est définie sur ~4 Go, soit 50 % de l’espace d’adressage total.

Pour résoudre ce problème, ajoutez/modifiez l’un des éléments suivants dans /etc/sysctl.conf :

 - Remplacez « vm.overcommit_ratio » par 100 pour que le système d’exploitation puisse valider l’espace d’adressage total disponible et redémarrer.