Нюанс при развертывании MSSQL кластера под Windows Server 2008

Столкнулся с некоторой тонкостью в настройке кластеризованного приложения, в частности MSSQL2008. В один прекрасный день при переключении SQL с ноды на ноду, приложение не захотело стартовать.
На резервной ноде запустились ресурсы Name, Cluster Disk, Analysis Services. А вот сам SQL Server и соответственно SQL Server Agent запуститься отказались. При попытке вернуть их на первую ноду они так-же отказались стартовать.
Журнал ошибок приложений по этому поводу выдал следующее:

Log Name: Application
Source: MSSQLSERVER
EventID: 19019
[sqsrvres] ODBC sqldriverconnect failed

Log Name: Application
Source: MSSQLSERVER
EventID: 19019
[sqsrvres] checkODBCConnectError: sqlstate = 28000; native error = 4818;
message = [Microsoft][SQL Server Native Client 10.0][SQL Server]Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.

Log Name: Application
Source: MSSQLSERVER
EventID: 18456
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
Reason: Token-based server access validation failed with an infrastructure error.
Check for previous errors. [CLIENT: 78.109.91.140]

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

Log Name: System
Source: FailoverClustering
EventID: 1196
Cluster network name resource 'SQL Network Name (sql)' failed registration of one or more associated DNS name(s) for the following reason:
DNS operation refused.
.
Ensure that the network adapters associated with dependent IP address resources are configured with at least one accessible DNS server.

Log Name: System
Source: FailoverClustering
EventID: 1196
Cluster network name resource 'procDtc' failed registration of one or more associated DNS name(s) for the following reason:
DNS operation refused.
.
Ensure that the network adapters associated with dependent IP address resources are configured with at least one accessible DNS server.

Покопавшись в TechNet по данным событиям, нашел что связано это может быть либо с некорректными записями в реестре, либо с некорректно работающим или отсутствующем DNS.
Записи в реестре оказались на месте. Поэтапная проверка DNS ничего не выявила (DNS сервера работают, на запросы отвечают, ресурсные записи кластерных приложений на месте, имена кластерных приложений резолвятся в прямом и обратном направлениях).
Казалось бы все нормально, но меня смутила запись "DNS operation refused". Стало очевидным, что кластерный сервис просто не может обновить регистрацию кластерных имер ресурсов в DNS.

Решение этой проблемы следующее:
Удалить существующие записи в DNS на все A-записи, касающиеся кластерных ресурсов (в моем случае это были sql и procDtc) и создать их заново, поставив разрешение обновлять DNS записи авторизованным пользователям с общим именем владельца (Allow any authenticated user to update DNS records with the same owner name).
Того что при операции удаления-создания записей что то в кластере упадет, бояться не надо - ничего не упадет.

Соответствующее изменение внесу в свою статью о развертывании SQL кластера.

Поделиться

Опубликовать в Facebook
Опубликовать в LiveJournal

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

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

*

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>