Соединение с удаленным сервером SQL прерывается при обновлении веб-сервера до.net Framework 4.6.1.

В настоящее время мы работаем над обновлением нашего веб-приложения asp.net (размещенного на IIS 7.5) с.net framework v4.5 до v4.6.1. В небольших нижних средах / локальной разработке, в которых SQL-сервер работает на том же компьютере, что и IIS, это обновление работает нормально и ничего не нарушает. Однако, как только мы обновляем наши веб-серверы в наших тестовых средах, в которых SQL-сервер размещается удаленно с наших веб-серверов, наше приложение больше не может устанавливать соединение с базой данных. Мы получаем эту ошибку:

Connection Timeout Expired. The timeout period elapsed while attempting to
consume the pre-login handshake acknowledgement. This could be because the
pre-login handshake failed or the server was unable to respond back in time.

Сервер SQL работает с версией CLR v4.0.30319. Мы используем Entity Framework версии 6.0.0.0 для доступа к данным, и все строки подключения используют встроенную защиту. Нужно ли обновлять ящики с SQL-сервером до.net 4.6.1? Я не понимаю, почему нашему приложению было бы необходимо установить соединение с базой данных, но я не смог найти никаких указаний на MSDN по этому поводу.

РЕДАКТИРОВАТЬ:

После этой поломки мы вернули наши веб-серверы обратно до.net v4.5 и смогли восстановить соединение с SQL-сервером. повторное обновление до v4.6.1 снова вызвало поломку. Поэтому мы относительно уверены, что обновление является проблемой, а не изменением кода приложения и / или настроек IIS.

4 ответа

Прежде всего - эта проблема появляется только при использовании аутентификации Active Directory.

Я справился с грязным исправлением: добавьте ваш MSSQL-сервер в ваш локальный (компьютер, который не может подключиться к MSSQL-серверу) файл hosts (%windir%\system32\drivers\etc\hosts).

Например: 192.168.0.5 mssqlserver

Это действительно не имеет значения, имя. Это также хорошо работает, если у вас есть несколько серверов SQL на одном IP-адресе (подключение через NAT).

Это грязное исправление также исправит медленную загрузку, используя проблему SQL Management Studio.

Обновление - похоже, что мы нашли (по крайней мере, решение) проблемы. Оказывается - как и предполагалось в качестве исключения - что, увеличив свойство времени ожидания подключения в нашей строке подключения (по умолчанию 15 секунд, мы установили его на 60 секунд), мы смогли установить соединение с нашей базой данных через наше веб-приложение. Однако открытие этого соединения занимает непомерно много времени, поэтому мы начали искать решения, позволяющие ускорить открытие нашего соединения. Мы обнаружили, что на нашем сервере баз данных включен протокол Netbios через TCP/IP и что благодаря открытию портов UDP (137, 138) в нашей сети для доступа к Netbios мы смогли быстрее и быстрее открывать соединения с базой данных. <1 секунда вместо>15 секунд. Мы все еще не уверены, почему обновление.net выявило эту проблему. Проведя тестирование с использованием файла UDL, мы смогли установить, что сетевое подключение к нашей базе данных работает примерно так же на наших веб-серверах в.net 4.5 и на наших веб-серверах в.net 4.6.1. Таким образом, кажется, что наши соединения открывались так медленно, что мы уже были очень близки к тайм-ауту, и какая-то дополнительная логика / хитрость в 4.6.1 поставили нас в тупик. Я обновлю, если мы найдем больше ясности в этом.

В следующей статье описывается новый параметр строки подключения по умолчанию для подключений к SQL Server в.net 4.6.1.

https://blogs.msdn.microsoft.com/dataaccesstechnologies/2016/05/07/connection-timeout-issue-with-net-framework-4-6-1-transparentnetworkipresolution/

Это должно было решить одну проблему в некоторых средах, но также вызвало проблему, с которой вы столкнулись в других средах.

По сути, вы хотите добавить следующую строку подключения:

TransparentNetworkIPResolution=False;

Вы можете проверить файлы machine.config и web.config в windows\micorsoft.net\framework64\v######\config папки. каждая версия.NET работает на разных конфигурационных файлах. Поскольку в обеих средах используется один и тот же код, он должен быть из конфигурации, унаследованной отсюда. Я предполагаю, что в 4.6.1 по умолчанию для строки подключения задано значение localhost, и поскольку SQL в local и dev находятся на одном сервере, это не проблема. Вы, вероятно, обнаружите, что в конфигурации в версии.NET 4.5 есть строка подключения, определенная за пределами localhost.

если 4.5 и 4.61 используют одни и те же файлы конфигурации, убедитесь, что вы определили строку подключения по умолчанию, которая будет использоваться структурой сущностей в этом web.config.

Другие вопросы по тегам