Назад | Перейти на главную страницу

Устранение проблем с подключением IIS к SQL 2005 в сложной среде

У меня сложная среда, множество высокопроизводительных сетевых боксов Cisco, межсетевых экранов и маршрутизаторов. У меня много (100-200) ошибок тайм-аута соединения (просто проверка подлинности, без выполнения каких-либо запросов) при подключении с IIS к SQL Server 2005 с использованием проверки подлинности Windows. Наши сетевые инженеры переполнили дампы tcp / ip, у нас нет собственных специалистов по AD, похоже, что Kerberos не работает в нашей среде db, поэтому я подумал, что вы все могли бы указать на документацию о том, как IIS делает подключение к серверу SQL, где домен серверов отличается от домена пользователя, а домен пользователя находится в другом состоянии по выделенным выделенным линиям. В обоих местах есть резервные контроллеры постоянного тока и настроены метрики сайта. Сетевые фанаты считают, что время, необходимое Kerberos для отказа и по умолчанию NTLM, может быть проблемой.

Дополнительная информация: Мы снова пригласили главного консультанта MS и нашли LSASS.exe sp? потреблял тонны ЦП на ящиках AD. Виновником был спам-ящик Barracuda, выполнявший запросы к AD на предмет несуществующих столбцов метаданных. Если я узнаю, как он это понял, я напишу.

TIA, Чак

Я не уверен, что вы получите хороший ответ, если не разбиваете проблему на более мелкие части.

Я бы начал с этих шагов, отменив все изменения, которые не помогают. Обновите свой вопрос по мере получения дополнительной информации о проблеме:

  • Проверьте DNS - убедитесь, что ваши DNS-серверы быстро отвечают:

    • попробуйте использовать в источнике данных жестко заданный IP-адрес или
    • добавьте запись в файл hosts, чтобы устранить проблему с задержкой при разрешении имен.

  • Исключите NT-аутентификацию как проблему, переключив ваше веб-приложение на использование SQL-аутентификации. Обычно я бы даже не подумал об этом, но в своем вопросе вы упомянули некоторые проблемы с аутентификацией.

  • Убедитесь, что нет потери пакетов между веб-сервером и сервером БД.

    • Попробуйте выполнить ping с большим размером пакета, даже запустив сразу несколько экземпляров следующей команды ping: ping -t -w 100 -l 5000 dbhost

  • Попробуйте изменить настройки пула подключений.

Microsoft KB319723 описывает использование Kerberos с SQL Server и IIS. Не должно быть проблем с аутентификацией на серверах SQL в одном домене с использованием учетных записей пользователей из другого домена, если они находятся в одном лесу AD. Однако я видел проблемы с подключением к именованным экземплярам SQL-сервера извне. Вы должны настроить псевдоним SQL для именованного экземпляра.

Вот инструмент поддержки Premier, используемый для выяснения того, почему lsass использует так много ЦП: spa_v2.msi «Советчик по производительности сервера» Измените значение раскрывающегося списка на активный каталог и с помощью HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ NTDS \ Diagnostics изменить REG_DWORD значение от «0» до «5», затем просмотрите журнал служб каталогов на наличие ошибок.

Это выявило поиск виновных в OtherMailBox.

Затем он вытащил это из головы, окно cmd: Ldifde -F foo.txt –s corpdc01 –P subtree –d «DC = Corp, DC = redmond, DC = Local» –r «(OtherMailBox = *)»

Чтобы определить, использовали ли мы этот объект в AD. Мы не. В журнале были указаны IP-адреса барракуд, а NSLOOKUP сделал все остальное. Передал эту информацию ИТ-администраторам, и они смогли исправить.