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

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

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

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

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

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

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

FailoverClustering-Client

• 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-адресов своих партнеров по связи. Он использует протокол обнаружения соседей. И этот протокол не работает, если вы отключите соответствующие правила межсетевого экрана. Хотя вы можете проверить записи 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 «Виртуальный адаптер отказоустойчивого кластера» партнера по кластеру всегда переключалось между «достижимо» и «зондом». Я не понял момента, когда он был «недоступен», но после повторного включения правил IPv6 проблема исчезла:

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

Каким-то образом кажется, что этот MAC-адрес обменивается другим способом между партнерами по кластеру (возможно, потому, что это «виртуальный удаленный» адрес, а не реальный?). Таким образом, он продолжает появляться, что приводит к этим диким состояниям аварийного переключения / карантина / изолированного состояния.

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

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