Dell Unity. Процессоры СХД могут переходить в режим обслуживания из-за увеличения размера журнала (раздел /nbsnas заполняется на 100%)
Summary: Массив может перейти в сервисный режим (данные недоступны) из-за раздувания журнала (исправляется Dell)
Symptoms
В случае массивов с двумя процессорами СХД один процессор СХД переходит в режим обслуживания, и управление всей системой через интерфейсы управления, включая интерфейс командной строки, интерфейс пользователя, API-интерфейс REST и SMI-S, невозможно. Это также может проявляться в том, что процессоры СХД поочередно перезагружаются до тех пор, пока оба процессора СХД не перейдут в режим обслуживания.
Массив Unity с обоими процессорами СХД в режиме обслуживания не будет обслуживать операции ввода-вывода, поэтому это будет ситуация недоступности данных (DU).
В случае VSA один процессор СХД может перезагрузиться в режим обслуживания или просто остаться в обычном режиме, потеряв управление в любом случае.
Вся система не может работать со всей системой с помощью интерфейсов управления, включая интерфейс командной строки, пользовательский интерфейс, API-интерфейс REST и SMI-S.
Должен работать SSH или IPMI. IPMI работает всегда, SSH может работать только после стабилизации массива.
Эта проблема обнаружена в операционной среде версии 4.0.0.x и исправлена в операционной среде версии 4.0.1.x.
Cause
Файл журнала /nbsnas/http/logs/mod_jk.log, в котором записываются все запросы из интерфейса пользователя и REST, находится в файловой системе, смонтированной на /nbsnas основного процессора СХД. Без механизма ротации журналов раздутый массив этого файла продолжает потреблять доступное пространство файловой системы. Другие внутренние потребители начинают отказывать после того, как в файловой системе не осталось места. Один из процессоров СХД переходит в режим обслуживания при обнаружении повторяющихся сбоев этих компонентов.
В лабораторных условиях было замечено, что когда это происходит при попытке служб переключиться на вторичный процессор СХД, наблюдаются те же признаки. Процессоры СХД несколько раз поочередно перезагружаются, после чего оба переходят в режим обслуживания.
Заказчики сталкиваются с этой проблемой, если: всегда используйте пользовательский интерфейс или REST API для настройки системы хранения или открываете пользовательский интерфейс в браузере и оставляете его, не закрывая. Обычно при доступе только к пользовательскому интерфейсу требуется несколько месяцев, чтобы заказчики увидели эту проблему. Если заказчик часто использует REST API для запроса данных из системы хранения, эта проблема возникает быстрее.
Обнаружена вторая проблема. Модернизация до Unity OE 4.0.1.8320161 может усугубить проблему, так как может дублировать рассматриваемый файл журнала во время бесперебойного обновления, что ускоряет процесс.
Это можно проверить, проверив использование пространства в /nbsbas. Если потребление пространства минимально или низкое, эта проблема во время NDU НЕ возникла , поэтому больше ничего не требуется.
Коды 4.0.1.x уже содержат исправление основной проблемы, поэтому сама ротация логов работает корректно.
Если процент использования раздела очень высок, возможно, придется удалить соответствующие файлы журналов (требуется поддержка Dell).
Пример того, как проверить использование пространства и какие журналы удалить, можно найти в разделе примечаний.
Компания Dell приняла решение удалить Unity OE 4.0.1.8320161 для Unity и UnityVSA из support.emc.com. Обновленная версия Unity OE (4.0.1.8404134) была опубликована в сентябре 2016 г.
Resolution
Для решения этой проблемы необходимо, чтобы служба технической поддержки получила root-доступ к массиву.
Обратитесь в службу технической поддержки Unity и укажите следующую статью базы знаний: 489057
Additional Information
Пример проверки использования пространства:
spX:~> df -h /nbsnas Filesystem Size Used Avail Use% Mounted on /dev/c4nasdba1 1013M 55M 908M 6% /nbsnas
Журнал или журналы, вызывающие это, можно найти в /nbsnas/http/logs:
spx:~> cd /nbsnas/http/logs spx:/nbsnas/http/logs> ll -h total 975M -rw-r--r-- 1 root root 12K Sep 8 13:32 access_log -rw-r--r-- 1 root root 165K Sep 8 08:45 access_log.1.gz -rw-r--r-- 1 root root 239K Sep 8 06:59 access_log.2.gz -rw-r--r-- 1 root root 1.6M Sep 8 13:32 error_log -rw-r--r-- 1 root root 167K Sep 3 04:56 error_log.1.gz -rw-r--r-- 1 root root 495M Sep 8 13:32 mod_jk.log <<<<<<<<<< -rw-r--r-- 1 root root 475M Sep 8 08:45 mod_jk.log.1 <<<<<<<<<<
svc_dc -lcd (список дампов ядра) может также показать несколько дампов с суффиксом "_mgmtd".
Они были созданы, когда происходит паника процессоров СХД, когда некоторые службы не могут запуститься (из-за переполнения /nbsnas).
spx:/> svc_dc -lcd ======================== [DC copier]: Available on backend: CP_dump_spb_CKM00161701xxx_2016-09-08_13_29_47_17275_ECOM core-dump_dump_spb_CKM00161701xxx_2016-09-08_08_46_23_778_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_09_18_19_11994_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_09_18_53_21524_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_09_41_05_11446_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_09_41_45_24620_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_13_28_30_3067_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_13_29_08_15086_mgmtd