Клиентская точка доступа отказоустойчивого кластера отвечает только на эхо-запросы на узле-владельце

Задний план

Мы запускаем две виртуальные машины (Windows Server 2012 R2) в Azure с установленным SQL Server, настроенным как группа доступности. У нас также, конечно же, есть еще одна виртуальная машина в качестве выделенного DC. Все они связаны через одну виртуальную сеть. Эта установка хорошо работала для нас, и я смог без проблем подключиться к SQL с моей локальной физической машины, но затем был достигнут предел расходов в учетной записи, и все было деинициализировано. Мы сняли ограничение, и я снова выделил все серверы, использующие те же виртуальные жесткие диски, со всеми (предположительно) восстановленными настройками, но я больше не могу получить доступ к SQL Server.

Определения имен

Чтобы лучше объяснить это, мы назовем два узла SQL1 и SQL2, группу доступности SQL-AG, прослушиватель группы доступности SQL-Listener и облачную службу, через которую все это выполняется (с соответствующими установленными конечными точками). вверх) SQL-CloudService. SQL1 является владельцем роли отказоустойчивого кластера (и, соответственно, выполняет роль реплики первичного), а SQL2 является вторичным.

Сценарий

Я могу подключиться к обоим серверам по протоколу RDP, использовать SSMS из SQL1, подключиться к SQL-Listener и просмотреть панель мониторинга SQL-AG, которая сообщает обо всем как о работоспособном и синхронизированном.

На SQL2 я не могу подключиться к SQL-Listener. Я также не могу подключиться к SQL-CloudService с моего локального компьютера, который работал раньше. Обе системы возвращают ошибку,

Не удается подключиться к SQL-Listener.

Произошла ошибка, связанная с сетью или конкретным экземпляром, при установке соединения с SQL Server. Сервер не найден или не был доступен. Убедитесь, что имя экземпляра правильное и что SQL Server настроен на разрешение удаленных подключений. (поставщик: поставщик именованных каналов, ошибка: 40 - не удалось открыть соединение с SQL Server) (Microsoft SQL Server, ошибка: 53)

Сетевой путь не найден

Когда я перехожу на SQL1 и подключаюсь через SSMS, я могу сказать SQL-AG переключиться на SQL2. Делает это успешно. Однако после этого я больше не могу подключаться к SQL-Listener из SQL1, но я из SQL2.

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

Настоящая проблема

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

Вещи, которые я нашел в пути

Неудивительно, учитывая сообщение об ошибке и ситуацию, но я не могу проверить связь с SQL-Listener, если он не запущен на машине, с которой я инициирую проверку связи. Когда SQL1 помечен как основной, я могу без проблем выполнить эхо-запрос из SQL1, но когда я пытаюсь выполнить запрос из SQL2, он успешно ищет IP-адрес с помощью DNS, но возвращается с сообщением «Ответ от [IP-адрес SQL2]: целевой хост недоступен». Когда я выполняю аварийное переключение SQL-AG, та же проблема возникает в другом направлении. Однако я всегда могу выполнить эхо-запрос SQL1 из SQL2 и наоборот. Из-за этого я склонен считать, что это проблема отказоустойчивого кластера, а не проблема SQL. Отсюда и название этого вопроса.

Я также обнаружил, что брандмауэр кажется нетронутым. Я бы сказал, что это согласуется с проблемой ping, но мониторинг на брандмауэре не показывает попыток доступа к SQL Server с каких-либо удаленных машин (моей локальной или виртуальной машины, не являющейся владельцем).

Это можно вывести из того, что я уже сказал, но стоит отметить, что даже через облачную службу я не могу коснуться брандмауэра с портом 1433. Я не совсем уверен, почему это могло быть, так как прямой Маршрут -to-server, я полагаю, должен направлять его прямо на сервер. Таким образом, я ожидал бы, что в журнале появится элемент, представляющий это, но есть множество элементов, и ни один из них не является этим.

Неудивительно, что учитывая проблемы с проверкой связи, я также могу получить доступ к URL-адресу сервера отчетов (который похож на http://sql-listener/ReportServer) локально на узле-владельце, но не удаленно от другого.

Я могу подключиться к любому SQL-серверу с другого, если я укажу имя компьютера (SQL1 или SQL2 по сравнению с SQL-Listener). В любом случае, для меня странно то, что я не могу получить доступ через облачную службу. Я бы подумал, что это означает, что он слушает, где бы он ни был, и, учитывая, что мне никогда не приходилось указывать Azure указывать на SQL-Listener, я не ожидал, что это будет иметь какое-либо значение. Так что, возможно, я просто неправильно читаю всю эту ситуацию.

Действия по устранению неполадок, которые я предпринял

• Перезагрузите все задействованные машины
• Убедитесь, что все IP-адреса статичны и соответствуют нашим ожиданиям.
• Убедитесь, что брандмауэр настроен правильно
• Выключите каждый сервер SQL (в Azure это освобождает виртуальную машину, поэтому это гораздо серьезнее, чем просто перезагрузка) и снова загрузите их.
• Удалите и воссоздайте точку доступа клиента роли отказоустойчивого кластера (а вместе с ней и прослушиватель группы доступности)
• Воссозданы конечные точки облачной службы (хотя это больше не похоже на то, что это может помочь чему-либо, так как это было до того, как я узнал о проблеме между серверами)
• Попытка подключиться к серверу с явно указанным IP-адресом («tcp: [IP-адрес SQL-прослушивателя]»). Это возвращается с ошибкой, связанной с сетью / конкретным экземпляром, в которой говорится: «Попытка подключения не удалась, потому что подключенная сторона не ответила должным образом по прошествии определенного периода времени, или установленное соединение не удалось, потому что подключенный хост не ответил».

Мысли у меня были

• Может дело в подсетях? Они наверняка кажутся одними и теми же, но я могу представить, что это вызывает некоторые странные проблемы, подобные этой.
• Кто-нибудь знает что-нибудь конкретное, что делает Azure, когда выключает серверы из-за превышения лимита расходов? Есть ли хоть одна настройка, которую я не заметил?