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

У меня есть отказоустойчивый кластер с двумя узлами под управлением SQL Server 2016 (стандартный) с использованием групп доступности (DB1 и DB2). Я отключил DB2 в качестве меры экономии для COVID, переключив все роли на DB1, удалив все базы данных из групп доступности на DB1, а затем отключив DB2.

Три года спустя я вернул DB2 в оперативный режим, и это, похоже, привело к сбою DB1. Мне удалось вернуть его в сеть, удалив и повторно добавив, но все еще есть неработающие роли, которые я не могу вернуть в сеть. IP-адрес для каждой роли находится в сети, но ресурс сетевого имени находится в состоянии сбоя.

Если я попытаюсь подключить его к сети или использовать функцию восстановления, чтобы исправить это, я получаю сообщение об ошибке «Неверное имя пользователя или пароль». События кластера показывают сообщение об ошибке, в котором говорится, что ему не удалось найти доступный для записи контроллер домена по причине «Неверное имя пользователя или пароль».

Я нашел статью о необходимости применения исправления, но это было для Windows Server 2012, а это Windows Server 2016. В других статьях говорилось, что нужно попробовать сбросить DNS, но это не сработало.

Мне нужно настроить другую группу доступности, и она также не подключается к сети с тем же сообщением об ошибке о поиске доступного для записи контроллера домена и не может создать компьютер в активном каталоге или имя домена в DNS.

Если я подключаюсь к DB1 и запускаю диспетчер отказоустойчивого кластера, он не подключается к отказоустойчивому кластеру, и при попытке я получаю сообщение об ошибке «Отказано в доступе».

Это не контроллеры домена, и я вошел на серверы, используя учетную запись администратора домена.

1 ответ
1

Возможно, что DB2 потеряла свои доверительные отношения с доменом во время своего автономного режима, что может быть не сразу очевидно во всех случаях (особенно если вы входите в систему, используя учетную запись, которая ранее использовалась для входа в систему (поскольку, если она не может чтобы связаться с контроллером домена для проверки учетных данных, он вернется к своему локальному кешу)).

Это может объяснить симптомы, которые вы видите из-за невозможности записи/изменения ресурсов, таких как записи DNS.

Я бы предложил проверить, что DB2 по-прежнему имеет доверительные отношения с доменом — честно говоря, учитывая описанные вами обстоятельства, самым прямым действием здесь может быть просто удаление DB2 из домена и повторная процедура присоединения к домену.

Как только это будет сделано, вы можете повторить попытку повторного добавления его в отношение кластера.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *