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

Фон

Мы запускаем две виртуальные машины (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-слушателю. Я также не могу подключиться к SQL-CloudService с моей локальной машины, которая работала и раньше. Обе системы возвращают ошибку,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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