Добавить узел в отказоустойчивый кластер, не устанавливающий связь по 3343

Добавить узел в отказоустойчивый кластер, не устанавливающий связь по 3343

У нас есть существующий кластер Windows 2012 из 2 узлов с файлом-свидетелем, но мы заменяем их серверами 2019. Поэтому мы можем просто повторно использовать существующий объект кластера, мы добавляем серверы 2019 в кластер, а затем удаляем серверы 2012 после синхронизации кластеризованных баз данных. Тест проверки показывает только несколько предупреждений, включая предупреждение «только одна пара сетевых интерфейсов» при проверке сетевых коммуникаций, предупреждение «Пароль не соответствует требованиям политики паролей» при проверке настроек CSV, новые серверы не находятся в том же OU, что и старые серверы (они сгруппированы по версии ОС сервера 2012 и 2019), «Свойство кластера «ClusterLogSize» имеет значение меньше значения по умолчанию 1536» и очевидное предупреждение «разные, но совместимые версии операционных систем». Так что ничто не должно помешать нам добавить узлы в кластер.

Процесс добавления узла завершается сбоем на этапе «Ожидание уведомления о том, что узел... является полностью функциональным членом кластера». Журналы системных событий показывают ошибки 1653 и 5398, что указывает на проблему со связью. Служба кластеризации взаимодействует по порту 3343, поэтому устранение неполадок было сосредоточено на нем. Полностью отключил брандмауэр и AV, но проблема все еще сохраняется.

Единственное, что я заметил, что отличается между новыми и старыми серверами, это то, что во время работы мастера добавления узлов, когда на новом сервере активируется служба кластера, сервер не прослушивает UDP 3343. Увидел это, запустив TCPView на обоих серверах 2012, которые в настоящее время находятся в кластере, и на серверах 2019, которые я пытаюсь добавить в кластер. Серверы 2012 будут показывать прослушивание через 3343 по TCP и UDP, но серверы 2019 будут показывать прослушивание и отправку информации только по TCP 3343. Будет 4 ожидания связи по TCP 3343 с двумя серверами 2012, но в конечном итоге они истекут, что приведет к сбою процесса добавления узла с ошибкой тайм-аута. Не уверен, является ли отсутствие прослушивания UDP 3343 на этом этапе процесса нормальным поведением до полного добавления узла или указывает на то, что служба неправильно прослушивает как TCP, так и UDP 3343 на новых серверах.

Кажется, ничто активно не блокирует связь; просто кажется, что новые серверы не слушают должным образом связь с другими узлами. Или я просто лаю не на то дерево?

решение1

Хотя в отчете о проверке об этом не говорилось, физически невозможно добавить узел 2019 года в кластер 2012 года.

Связанный контент