MACHINE_DOWN при живой ноде: разорвано storage-кольцо

Симптом

• Письма и GUI: MACHINE_DOWN CRITICAL по одной ноде, повторяется ровно раз в час (интервал чекера).
• Сама нода: пингуется по mgmt-адресу, SSH отвечает, диски в модели ONLINE, службы живы.
• Побочно: DSS_STORAGEPOOL_NOT_UPDATED, column.resources=0, задачи ленты/сканеров падают (coldstorage.tape_drive_verify — FAILED каждые несколько минут).
• Запросы к модели по «провинившейся» ноде идут с таймаутом в десятки секунд.

Что проверить первым (read-only)

1. Живость ноды не по mgmt, а по storage. С каждой ноды — до всех storage-адресов: bash for ip in <STORAGE_NET>.1 <STORAGE_NET>.2 <STORAGE_NET>.3; do ping -c 2 -W 1 "$ip" >/dev/null && echo "$ip ok" || echo "$ip FAIL" done Ожидается ok по всем адресам с каждой ноды. Любой FAIL — разрыв кольца, дальше железо не смотреть.

2. Состояние реплик. replSetGetStatus по трём базам читается через venv продукта (py2 + TLS, PEM /opt/ampli/cfg/mongo/ssl/<rs>/mongodb_node1.pem) — нужен инженер. Ожидается три члена, у каждого health=1. Строка (not reachable/healthy) h:0 означает «процесс недоступен по сети», а не «данных нет».

3. Карта портов на ноде: bash sudo ss -ltnp | grep -E ':2701[789]' sudo cat /etc/network/interfaces.d/marvin Ожидается: листенеры mongod на месте и в файле интерфейсов прописан storage-адрес с нужной маской/mtu. Если storage-адрес получен на порту, который по факту в другом VLAN, файл покажет расхождение с проектом.

4. Линк и скорость storage-порта: bash ip -br link show ethtool <STORAGE_IF> | grep -E 'Speed|Link detected' Ожидается UP, Link detected: yes, скорость по проекту. no — кабель/порт.

5. MAC-таблица свича. Порт ищем по MAC ноды, а не по описанию порта. Команда вывода таблицы зависит от модели свича (show mac-address-table или её аналог в CLI площадки). Ожидается: MAC storage-порта ноды выучен на том порту, который в проекте назначен storage-VLAN. Если MAC виден на порту с чужим VLAN — это и есть корень.

Причина

1. Storage-сеть — это кольцо, а не «ещё один интерфейс»

Ноды видят друг друга по выделенной сети хранения. Репликация модели, DSS и служебные проверки идут по ней. MACHINE_DOWN поднимает чекер, который судит о доступности ноды по этому кольцу; mgmt-сеть для него не доказательство.

2. Разрыв даёт каскад, похожий на смерть ноды

Когда кольцо разорвано, у каждой пострадавшей реплики третий член помечается недоступным. Модель на такой реплике не может собрать кворум быстро, запросы висят, задачи, которым нужен ресурс колонки, падают. Всё это читается оператором как «нода умерла» и «данные потеряны», хотя железо и диски целы.

3. Самая частая физическая причина — VLAN порта

Порт свича, описанный как storage, оказывается в VLAN управления, а соседний — наоборот. После любой правки VLAN (или перекладки патч-панели) конфигурация может не совпасть с проектом. Сброс питания конфиг свича обычно не теряет — проверять надо фактические VLAN, а не гипотезу «свич сбросился».

4. Ложные следы

• «Нода упала» — узел ONLINE, диски ONLINE, службы живы. Красное — сетевое.
• «Данные потеряны» — health=0 у члена реплики означает недоступность процесса по сети. До любых выводов о данных проверяется ping по storage-сети.
• «Вентилятор/PSU» — отдельный класс событий, к MACHINE_DOWN отношения не имеет.

Решение (штатное)

1. Найти порт по MAC. В таблице MAC-адресов свича (команда зависит от модели) сопоставить MAC storage-интерфейса ноды с портом. Описания портов не использовать как источник истины.
2. Привести VLAN порта к проекту. На порту, куда фактически подключён storage-интерфейс, выставить access-VLAN сети хранения (значение — из проектной схемы площадки): configure interface <PORT> switchport access vlan <STORAGE_VLAN> exit exit write memory Ожидается подтверждение записи и совпадение startup-config с running-config.
3. Проверить кольцо сразу после правки — пункт 1 списка проверок: все три адреса ok с каждой ноды. Только после этого идти дальше.
4. Дать репликам пересобраться. PRIMARY + 2×SECONDARY, все health=1. Модель по ноде должна отвечать быстро.
5. Убедиться, что задачи вернулись: периодические задачи (лента, сканеры, обновление колонки) снова SUCCESS, column.resources не ноль.
6. Кабель и оптика — если MAC не виден на порту вообще: проверить линк в ethtool, заменить патч-корд/модуль, повторить пункт 1.

Если штатный путь недоступен

Временная мера, не штатно. Если правка VLAN невозможна в рабочее окно, допустимо переключить storage-интерфейс ноды на резервный порт свича, заранее настроенный в тот же VLAN, и записать это как временную схему с планом возврата. Перекладывать кабель «на любой свободный порт» нельзя: пока VLAN не совпадает с проектом, кольцо останется разорванным, а MACHINE_DOWN продолжит подниматься.

Проверка

• ping по трём storage-адресам с каждой ноды → ok без потерь.
• Реплики: PRIMARY + 2×SECONDARY, все health=1, ALL_HEALTHY.
• https://<MGMT_IP>:8443/model/machine/<MGUID>/ → 200 за доли секунды (не 20–25 с).
• S3-фронт на каждой ноде → 307 и заголовок Server: Quantum-ActiveScale.
• MACHINE_DOWN по ноде → HANDLED_AUTO; новых подъёмов нет в течение часа (следующий цикл чекера).
• Периодические задачи ленты/колонки → SUCCESS.

Профилактика

• Хранить проектную схему портов/VLAN (см. роли портов и VLAN) и сверять её с startup-config свича после каждой правки.
• Любую правку VLAN заканчивать write memory и проверкой startup-config.
• В мониторинг добавить ping по storage-сети между нодами — ранний сигнал до MACHINE_DOWN.
• Порт искать по MAC; описания портов на свичах часто не соответствуют факту.

Источники и дата

• Software Documentation Center (доступ 2026-11-07).
• Наша практика (обезличено): разбор MACHINE_DOWN при живой ноде на 3-нодном кластере — порт свича в чужом VLAN; после приведения VLAN к проекту кольцо, реплики и задачи восстановились, событие закрылось автоматически.
• Обновлено: 2026-11-07.