У меня есть отказоустойчивый кластер SQL Server 2012 с несколькими подсетями, работающий на 2 узлах Windows 2012 R2. Кластер расположен на 192.168.1.10 на УЗЛЕ A и на 192.168.5.10 при работе на УЗЛЕ B. Когда я смотрю на DNS в домене, я вижу 2 записи A:
SQLCLUSTER - 192.168.1.10
SQLCLUSTER - 192.168.5.10
Из того, что я прочитал, когда есть 2 записи A с тем же именем, клиенты Windows должны быть достаточно умными, чтобы определять действующий IP в течение 10 секунд, но я этого не понимаю. Если я перейду кластер с УЗЛА A на УЗЕЛ B, многие клиентские машины (веб и SSRS) не получат новый IP-адрес.
Так, например, если я нахожусь на машине SSRS и пингую SQLCLUSTER, я увижу ответ от 192.168.1.10. Если я не смогу переключить кластер на УЗЕЛ B и снова выполнить пинг, он все равно будет пытаться пинговать 192.168.1.10, а не .5.10, как должен.
Кажется, единственный способ убедиться, что он работает правильно, - это удалить DNS-запись автономного узла, а затем выполнить flushdns / registerdns на клиентах. Возможно, я что-то здесь пропустил? Проблема в том, что DNS-сервер находится в подсети 192.168.1.x, и это может дать приоритет адресам .1.x?
Я смотрю в средство просмотра событий и не вижу никаких ошибок, касающихся записи записей DNS или их чтения, поэтому это наводит меня на мысль, что я просто что-то настроил неправильно.
Хорошо, я думаю, что нашел обходной путь - он не совсем красивый, но он работает.
Из информации, найденной здесь: https://blogs.msdn.microsoft.com/sambetts/2014/02/04/multi-subnet-clustered-sql-registerallprovidersip-sharepoint-2013/
Я установил RegisterAllProvidersIP на 0, затем установите HostRecordTTL до 300 и перезапустил роль.
Это заставит кластер регистрировать только 1 адрес в DNS и по умолчанию TTL составляет 5 минут.