PowerFlex. Сбой переключения MDM из-за сбоев выделения памяти — mos_MemMalloc

События, выходные данные от принимающего MDM /opt/emc/scaleio/mdm/bin/showevents.py, будут иметь несколько записей для попытки взять на себя обязанности основного MDM, и все они находятся в пределах короткого времени друг от друга:  

 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.

Файл exp.0 от принимающего MDM содержит следующие записи: 

 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]

В файле /var/log/messages отображаются множественные перезапуски службы MDM, как это делает 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'.

Это не проблема ScaleIO. ScaleIO работает должным образом.

Чтобы проверить и/или изменить параметры vm.overcommit, выполните следующие действия.

1. Войдите в SDS через SSH в качестве пользователя root

2. Выполните 

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. Выполните следующие команды.

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

Валидация

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

Повторите эти действия для всех затронутых SDS в среде, чтобы убедиться, что для них установлены рекомендуемые настройки. Для выполнения этой операции не нужно переводить SDS в режим обслуживания. 

Дополнительные сведения об этих параметрах см. в документации по ядру Linux по учету избыточных коммитов

Проверьте параметры ядра sysctl на предмет чрезмерного выделения памяти:

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

В этом случае установка для параметра «vm.overcommit_memory» значения 2 не означает чрезмерное выделение памяти. При этом происходит сбой любого выделения памяти, превышающего лимит превышения лимита выделения. Общий объем выделенного адресного пространства для системы не должен превышать объем подкачки + настраиваемый объем (по умолчанию 50%) физического ОЗУ. Если этот параметр равен 0, он отклоняет очевидные запросы на превышение лимита, но корневым процессам разрешено выделять ресурсы сверх лимита. 

Чтобы проверить текущий лимит превышения и объем выделенных данных, см. CommitLimit и Committed_AS соответственно с помощью следующей команды:

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

На этом хосте 8 ГБ ОЗУ, а CommitLimit установлен в ~4 ГБ, что составляет 50% от общего адресного пространства.

Чтобы решить эту проблему, добавьте/отредактируйте что-нибудь из следующего в /etc/sysctl.conf:

 - Измените «vm.overcommit_ratio» на 100, чтобы ОС могла зафиксировать все доступное адресное пространство и перезагрузиться.