Наличие проблемы с удаленными узлами из активного членства в отказоустойчивом кластере
В этой статье описывается, как устранить проблемы, в которых узлы удаляются из активного членства в отказоустойчивом кластере случайным образом.
Симптомы
При возникновении проблемы вы видите такие события, как это событие, вошедшее в журнал событий системы:
Это событие регистрируется на всех узлах в кластере, за исключением удаленного узла. Причина этого события заключается в том, что один из узлов в кластере помечает этот узел как вниз. Затем он уведомляет все остальные узлы события. Когда узлы уведомляются, они прекращают работу и удаляют подключения пульса к узлу с пониженным узлом.
Что привело к тому, что узел будет помечен вниз
Все узлы в отказоустойчивом кластере Windows Server общаются друг с другом по сетям, установленным для разрешения сетевого взаимодействия кластера в этой сети. Узлы отправляют пакеты пульса в этих сетях на все остальные узлы. Эти пакеты должны быть получены другими узлами, а затем ответ отправляется обратно. Каждый узел в кластере имеет собственные пульса, которые будут отслеживаться, чтобы убедиться, что сеть работает, и другие узлы находятся в состоянии. Следующий пример должен помочь прояснить это поведение:
Если какой-либо из этих пакетов не возвращается, то определенный пульс считается неудачным. Например, W2K8-R2-NODE2 отправляет запрос и получает ответ от W2K8-R2-NODE1 на пакет пульса, чтобы определить сеть и узел. Если W2K8-R2-NODE1 отправляет запрос на W2K8-R2-NODE2 и W2K8-R2-NODE1, он считается потерянным пульсом, и W2K8-R2-NODE1 отслеживает его. Этот пропущенный ответ может содержать W2K8-R2-NODE1, чтобы отобразить сеть вниз до получения другого запроса пульса.
По умолчанию узлы кластера имеют ограничение на пять сбоев в течение 5 секунд, прежде чем соединение помечается. Поэтому если W2K8-R2-NODE1 не получает ответ пять раз в период времени, он считает, что конкретный маршрут к W2K8-R2-NODE2 будет отключен. Если другие маршруты по-прежнему считаются активными, W2K8-R2-NODE2 останется активным членом.
Если все маршруты помечены для W2K8-R2-NODE2, он удаляется из активного членства в отказоустойчивом кластере и событие 1135, которое отображается в первом разделе. В W2K8-R2-NODE2 служба кластера завершается, а затем перезапускается, чтобы попытаться повторно присоединиться к кластеру.
Дополнительные сведения об обработке определенных маршрутов с тремя или более узлами см . в блоге "Секционированные" кластерные сети , написанном Джеффом Хьюзом.
Теперь, когда мы знаем, как работает процесс пульса, что такое некоторые из известных причин сбоя процесса
Фактические сбои сетевого оборудования. Если пакет теряется на проводе где-то между узлами, пульс завершается ошибкой. Трассировка сети от обоих узлов, участвующих в этом, покажет это.
Профиль сетевых подключений может быть отскочил от домена к общедоступной и обратно в домен снова. Во время перехода этих изменений сетевые ввода-вывода могут быть заблокированы. Вы можете проверить, является ли это дело, просмотрев журнал операций профиля сети. Этот журнал можно найти, открыв Просмотр событий и перейдя к журналам приложений и служб\Microsoft\Windows\NetworkProfile\Operational. Просмотрите события в этом журнале на узле, который был указан в идентификаторе события 1135, и проверьте, изменился ли профиль в настоящее время. Если это так, см . изменения профиля сетевого расположения с "Домен" на "Общедоступный" в Windows 7 или в Windows Server 2008 R2.
На серверах включен протокол IPv6, но в брандмауэре Windows отключены следующие два правила:
- Базовая сеть — реклама обнаружения соседей
- Базовая сеть — запрос на обнаружение соседей
Антивирусное программное обеспечение может также вмешиваться в этот процесс. Если вы подозреваете это, проверьте, отключив или удалив программное обеспечение. Это делается в вашем собственном риске, потому что вы не защищены от вирусов на этом этапе.
Задержка в сети также может привести к этому. Пакеты могут не быть потеряны между узлами, но они могут не добраться до узлов достаточно быстро до истечения срока ожидания.
IPv6 — это протокол по умолчанию, который кластеризация отработки отказа будет использоваться для своих пульсов. Пульс сам является одноадресным сетевым пакетом UDP, который взаимодействует через порт 3343. Если есть коммутаторы, брандмауэры или маршрутизаторы, которые не настроены должным образом, чтобы разрешить этот трафик, вы можете столкнуться с такими проблемами.
Обновления политики безопасности IPsec также могут вызвать эту проблему. Конкретная проблема заключается в том, что при обновлении групповой политики IPSec все связи безопасности IPsec (SAS) удаляются брандмауэром Windows с расширенной безопасностью (WFAS). Пока это происходит, все сетевые подключения блокируются. При повторном определении связей безопасности при возникновении задержек при проверке подлинности с Помощью Active Directory эти задержки (где все сетевые связи заблокированы) также блокируют пульс кластера от прохождения и вызывают мониторинг работоспособности кластера для обнаружения узлов, как если бы они не ответили в пределах 5-секундного порогового значения.
Старые или устаревшие драйверы сетевых карт и /или встроенное ПО. Иногда простая неправильное настройка сетевой карты или коммутатора также может привести к потере пульса.
Современные сетевые карты и виртуальные сетевые карты могут столкнуться с потерей пакетов. Это можно отслеживать, открыв Монитор производительности и добавив счетчик "Сетевой интерфейс\Пакеты получены отменены". Этот счетчик является накопительным и увеличивается только до перезагрузки сервера. Просмотр большого количества пакетов, отброшенных здесь, может быть признаком того, что буферы получения на сетевой карте заданы слишком низко или что сервер выполняется медленно и не может обрабатывать входящий трафик. Каждый производитель сетевых карт выбирает, следует ли предоставлять эти параметры в свойствах сетевой карты, поэтому необходимо обратиться к веб-сайту производителя, чтобы узнать, как увеличить эти значения и рекомендуемые значения следует использовать. Если вы работаете в VMware, в следующем блоге рассказывается об этом немного подробнее, в том числе о том, как определить, является ли это проблемой, а также указывает на статью VMware о параметрах, которые необходимо изменить.
Узлы, удаленные из членства в отказоустойчивом кластере в VMware ESX
Это наиболее распространенные причины, по которым регистрируются эти события, но могут быть и другие причины. Суть этого блога заключалась в том, чтобы дать вам некоторое представление о процессе, а также дать идеи о том, что искать. Некоторые из этих значений приведут к максимальному значению, чтобы попытаться остановить эту проблему.
| Параметр | По умолчанию. | Диапазон |
|---|---|---|
| SameSubnetDelay | 1000 миллисекунда | 250-2000 миллисекунда |
| CrossSubnetDelay | 1000 миллисекунда | 250-4000 миллисекунда |
| SameSubnetThreshold | 5 | 3-10 |
| CrossSubnetThreshold | 5 | 3-10 |
Увеличение этих значений до максимального значения может привести к удалению события и узла, он просто маскирует проблему. Это не исправляет ничего. Самое лучшее, чтобы выяснить первопричину сердечных сбоев и получить его исправление. Единственной реальной необходимостью увеличения этих значений является сценарий с несколькими сайтами, где узлы находятся в разных расположениях, а задержка сети не может быть преодолена.