Гости Windows Server 2016 в кластере WSFC случайным образом помещаются на карантин из-за потери маршрутов heartbeat

Question

У меня была та же проблема с отказоустойчивым кластером Windows Server 2019 (для Hyper-V 2019). Обычно я также отключаю IPv6 на своих серверах, и это вызывало проблемы. Кластер выдавал много критических ошибок и иногда выполнял жесткий отказ, хотя файловый ресурс-свидетель также был на месте и работал(?!).

Ошибки и предупреждения, которые я заметил в журнале событий:

Идентификаторы событий FailoverClustering:

1135 (Узел кластера «....» был удален из активного членства в отказоустойчивом кластере)
1146 (Процесс кластерной подсистемы размещения ресурсов (RHS) был завершен и будет перезапущен)
1673 (Узел кластера «....» перешел в изолированное состояние.)
1681 (Виртуальные машины на узле «....» перешли в неконтролируемое состояние.)

Идентификаторы событий диспетчера управления службами:

7024 (Отсутствует кворум узлов кластера для формирования кластера.)
7031 (Служба кластерной службы неожиданно завершилась.)

FailoverClustering-клиент

81 (Расширенная информация об ошибке RPC)

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

Используя следующую команду, я извлек журналы кластера (также спасибо за подсказку! Я не знал о такой полезной команде):

# -Destination (Folder) in my case changed to be not on the "C:\" SATADOM (this thing is slow and has few write cycles)
# -TimeSpan (in minutes) limited to one of the Failovers because these logs get HUGE otherwise.
Get-ClusterLog -Destination "E:\" -TimeSpan 5

К сожалению, у меня были те же записи в журнале, которые вы уже опубликовали.

Я повторно включил IPv6 на всех адаптерах и отменил настройки адаптеров/конфигураций, связанных с туннелем, с помощью:

Set-Net6to4Configuration -State Default
Set-NetTeredoConfiguration -Type Default
Set-NetIsatapConfiguration -State Default

Это не помогло... Присмотревшись, я заметил, что я также всегда отключаю "ненужные" правила брандмауэра, связанные с IPv6... И это, похоже, было действительно важным изменением! Эти правила, похоже, влияют и на невидимый адаптер.

Похоже, дело в следующем: IPv6 не использует ARP для поиска MAC-адресов своих партнеров по коммуникации. Он использует протокол Neighbor Discovery Protocol. И этот протокол не работает, если вы отключите соответствующие правила брандмауэра. В то время как вы можете проверить записи IPv4 ARP с помощью:

arp -a

Это не покажет вам MAC-адреса для адресов IPv6. Для них вы можете использовать:

netsh interface ipv6 show neighbors level=verbose

При желании вы можете отфильтровать вывод по адресам вашего адаптера IPv6 следующим образом:

netsh interface ipv6 show neighbors level=verbose | sls ".*fe80::1337:1337:1234:4321.*" -Context 4 |%{$_.Line,$_.Context.PostContext,""}

Сделав это, я обнаружил, что эти записи, похоже, очень недолговечны. Состояние записи для локального адреса ссылки Microsoft "Failover Cluster Virtual Adapter" кластерного партнера всегда переключалось между "Reachable" и "Probe". Я не понял, в какой момент она была "Unreachable", но после повторного включения правил IPv6 проблема исчезла:

Get-NetFirewallRule -ID "CoreNet-ICMP6-*" | Enable-NetFirewallRule

Каким-то образом этот MAC-адрес, похоже, обменивается другим способом между партнерами кластера (вероятно, потому что это адрес «виртуального удаленного», а не реального?). Поэтому он продолжает появляться снова и снова, что приводит к этим диким состояниям Failover / Quarantine / Isolated.

Возможно, отключение IPv6 на невидимом адаптере тоже помогло бы, но поскольку это не рекомендуется, я решил вообще прекратить отключать все, что связано с IPv6. В любом случае, это дело будущего :-)

Надеюсь, это поможет еще одному товарищу, отключающему IPv6!

Answer 1