Локальный кластер недоступен: как проверить узлы Dell и не получить split-brain

Пользователи потеряли доступ к сервису, один узел не отвечает, но iDRAC ещё открывается. Не перезапускайте оба сервера и не запускайте ресурс вручную на резервном узле: сначала сохраните время сбоя, состояние кластера и журналы с обеих сторон.

Порядок такой: проверьте узлы → межузловую сеть → кворум и владельца ресурса → аппаратные события PowerEdge. Перезапуск допустим, когда Вы понимаете причину отказа и подтвердили, что ресурс принадлежит одному узлу. Иначе можно получить split-brain — оба узла сочтут себя владельцами одних данных.

Сначала отделите отказ сервиса от отказа узла #

Запишите точное время, когда пропал доступ. Оно понадобится, чтобы сопоставить сетевые события, сообщения кластерной службы и аппаратный журнал Dell.

Затем определите масштаб:

• сервис недоступен, но оба узла отвечают;
• один узел не видит кластер;
• оба узла работают, но кластер потерял кворум;
• проблемный PowerEdge не отвечает даже через локальную консоль.

Не начинайте с перезапуска службы 1С или Windows. Если оборвалась сеть между узлами, перезапуск не восстановит канал, зато изменит состояние ресурсов и затруднит разбор.

Когда пользователи видят ошибку соединения с 1С, сначала полезно пройти диагностику потери связи с сервером 1С. Она помогает отделить отказ приложения от проблемы кластера и оборудования.

Для PowerScale статус узла задаёт следующий шаг #

В Dell PowerScale выполните на исправном узле:

isi status

Статья Dell «What to do when a node reports as Down or Offline» определяет три состояния, которые нужны для первичной проверки:

• OK — узел доступен и входит в кластер;
• Attention (-A--) — узел остаётся в кластере, но сообщает о критическом событии;
• Down (D---) — узел не может связаться с остальными участниками кластера.

При Attention запросите события:

isi event list

Сообщение покажет, какой слой проверять дальше. Сам статус Attention не доказывает отказ диска, сети или операционной системы.

При Down переходите к межузловой связи. Dell указывает, что причины этого состояния лежат в диапазоне от аппаратной неисправности до сбоя ОС. По одной букве D причину не определить.

Расшифровки D, A, S, R, C и N относятся к выводу isi status в Dell PowerScale и приведены в статье Dell «What to do when a node reports as Down or Offline». Не переносите эти обозначения на Windows Failover Cluster, кластер 1С или другие продукты Dell.

Проверьте межузловую сеть до кластерных служб #

С исправного узла PowerScale проверьте проблемный по имени вида clustername-nodeномер. Если публичному интерфейсу назначен статический IP-адрес, проверьте и его.

Список статических адресов выводит команда:

isi network interfaces list

Развилка здесь простая. Узел отвечает по сети или через консоль, но остаётся в состоянии Down — проверяйте кластерный обмен и ОС. Узел не отвечает ни одним способом — переходите к iDRAC и аппаратным журналам.

Dell допускает локальное подключение к недоступному узлу через последовательную консоль. Для него нужны компьютер с последовательным портом либо адаптер USB–serial и нуль-модемный кабель.

Если связь восстановить не удалось, а причина Down неизвестна, инструкция Dell требует открыть сервисное обращение. До этого сохраните журналы и текущее состояние: после перезапуска часть симптомов исчезнет.

Для кластера 1С отдельно проверьте сетевые правила. Агент может отвечать, а рабочие процессы — оставаться недоступными из-за закрытого диапазона. Нужные соединения собраны в материале про порты кластера серверов 1С.

Кворум и владелец ресурса проверяют по одной временной шкале #

В Windows Failover Cluster соберите cluster.log с обоих узлов. Затем откройте в Event Viewer:

Applications and Services Logs
└─ Microsoft
 └─ Windows
 └─ FailoverClustering

В ответе специалиста Microsoft на Microsoft Q&A для проверки предполагаемого split-brain названы четыре признака:

• повторные попытки арбитража ресурса;
• потеря кворума;
• тайм-ауты heartbeat;
• пересекающиеся переходы одного ресурса в OnlinePending или Online.

Сопоставляйте записи по времени, а не по порядку появления в журналах. Если оба узла в одну секунду зафиксировали смену владельца одного ресурса, это сильный признак split-brain. Вручную поднимать ресурс на втором узле в такой момент нельзя.

Похожая запись после краткого сетевого разрыва ещё не доказывает, что оба узла одновременно работали с данными. Проверьте события Witness и Quorum: они покажут, мог ли кластер определить единственного владельца.

Если журналы объясняют отказ потерей сети или кворума, чините этот слой. Если записи обрываются одновременно с пропажей узла, проверяйте сам PowerEdge.

При проектировании нового контура заранее сверяйте настройку отказоустойчивого кластера 1С: второй сервер без независимой сети, кворума и проверенного переключения не устраняет общую точку отказа.

Снимите SEL через iDRAC и ничего не очищайте #

SEL — системный журнал событий PowerEdge. По инструкции Dell «PowerEdge: How to View or Clear the System Event Log» открыть его можно тремя способами.

В iDRAC путь такой:

Maintenance → System Event Log

Через RACADM получите все записи:

racadm getsel

Количество записей без полного вывода:

racadm getsel -i

Если iDRAC недоступен, SEL открывается через System Setup после нажатия F2 при загрузке. Ищите события, совпавшие по времени с потерей узла: питание, системную батарею и другие аппаратные отказы. Не подставляйте расшифровку от соседней модели — сверяйте событие с руководством для своего поколения PowerEdge.

Не выполняйте racadm clrsel во время первичной диагностики. Команда удаляет SEL. Lifecycle Controller сохранит имя пользователя и IP-адрес, с которого журнал очистили, но сами записи для сопоставления со сбоем уже пропадут.

Разбирать PowerEdge стоит только после вывода узла из кластера #

Если сервер не проходит POST, сначала убедитесь, что кластер не считает его владельцем ресурса. Затем проверьте гарантийный статус.

В руководстве Dell EMC PowerEdge Servers Troubleshooting Guide минимальная конфигурация для POST у стоечного сервера состоит из четырёх элементов:

• блока питания PSU1;
• процессора CPU1;
• модуля памяти в слоте A1;
• штатного райзера без плат расширения.

Это уже сервисная работа, а не диагностическая команда. Dell предупреждает: часть ремонтов должен выполнять сертифицированный специалист, а повреждения после неавторизованного вмешательства гарантия не покрывает. Если сервер на гарантии, сохраните SEL, фотографии индикации и описание проверки, затем передайте случай в поддержку.

После возврата узла проверьте не только доступность сервиса #

Для PowerScale снова выполните:

isi status

Все узлы должны получить состояние OK. По определению Dell это подтверждает, что они доступны и входят в кластер.

В Windows Failover Cluster отдельно проверьте три условия:

• кворум восстановлен;
• у каждого ресурса один владелец;
• в журналах нет новых повторных арбитражей и одновременных переходов Online.

Только после этого возвращайте пользовательскую нагрузку. Открывающаяся база ещё не доказывает исправность кластера: сервис может работать на одном узле, пока второй продолжает спорить за ресурс или остаётся без межузловой связи.

Порядок действий во время аварии #

1. Запишите время отказа и симптомы.
2. Определите, недоступен сервис, один узел или весь кластер.
3. Проверьте управляющую и межузловую сеть.
4. Сопоставьте cluster.log, журнал FailoverClustering и события кворума.
5. Сохраните SEL через iDRAC или racadm getsel.
6. Устраните одну подтверждённую причину, не меняя остальные слои одновременно.
7. Проверьте кворум, единственного владельца ресурсов и состояние всех узлов.

Рабочее правило одно: пока кластер не подтвердил кворум и единственного владельца, не запускайте ресурс вручную на втором узле. Если узел Down недоступен удалённо и через консоль, а причина неизвестна, сохраните журналы и открывайте обращение в поддержку Dell.