У меня проблема с подключением к SQL server 2016 SP1 в настройке AlwaysOn со стороны приложения.
В кластере два Windows сервера:
- Узел A, IP-адрес xxx3
- Узел B, IP-адрес xxx4
На каждом узле имеется два SQL экземпляра :
- X с использованием порта 14035
- Y с использованием порта 14033
Таким образом, существует 4 фактических SQL экземпляры A \ X, A \ Y, B \ X и B \ Y. Теперь есть две группы AlwaysOn:
- XAG, например, A \ X и B \ X с прослушивателем, использующим порт по умолчанию 1433 и имеющий IP xxx7
- YAG, например, A \ Y и B \ Y со слушателем, использующим порт по умолчанию 1433 и имеющий IP xxx6
Пользователи сообщают о повторяющихся проблемах соединения для приложения, использующего слушатель XAG. У меня нет аналогичных отзывов от пользователей второго приложения, подключающегося к XAG, и пользователей, подключенных к YAG. В соответствии с проверкой, слушатели каждый раз подключаются к сети, но один из них для XAG перестает отвечать на запросы. Нам удалось найти временный обходной путь, переведя его (слушатель) в автономный режим и вернув его в оперативный режим вручную из Cluster Manager.
Я заметил несколько ошибок тайм-аута подключения в расширенных событиях и автоматическое восстановление после сбоя c. , В средстве просмотра событий нет связанных ошибок.
Мое общее предположение состоит в том, что когда обе группы AG имеют первичную реплику на одном Windows сервере, возникает конфликт портов, поскольку они являются частью другого процесса, использующего один и тот же процесс. порт. Я знаю, что они используют разные IP-адреса для слушателей, но опять же они принадлежат двум разным экземплярам SQL, имеющим IP-адрес одного и того же узла Windows и использующим один и тот же порт по умолчанию. Правильно ли мое предположение или я ошибаюсь? Или мы должны глубже изучить конфигурацию сети - таблицы ARP и т. Д.?
Мое предположение основано на документации MS:
Если вы используете порт по умолчанию 1433 для VNN прослушивателя группы доступности, вам все равно нужно будет убедиться, что никакие другие службы на узле кластера не используют этот порт, иначе это вызовет конфликт портов.
Если один из экземпляров SQL Сервер уже прослушивает TCP-порт 1433 через прослушиватель экземпляров, и на компьютере, прослушивающем порт 1433, нет других служб (включая дополнительные экземпляры SQL Server), это не приведет к конфликту портов с прослушивателем группы доступности. Это связано с тем, что прослушиватель группы доступности может использовать один и тот же порт TCP внутри одного и того же процесса службы. Однако несколько экземпляров SQL Server (рядом) не должны быть настроены на прослушивание одного и того же порта.
Источник: https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/listeners-client-connectivity-application-failover?view=sql-server-ver15
EDIT Причиной root оказалось наводнение ARP и обнаружение GARP, не включенное на EPG, где находился кластер.