Что вызывает проблемы неустойчивых соединений с веб-сервера на SQL-сервер 2 008 r2?
- Копируйте свою полную конфигурацию DHCP на втором DC.
- Остановите и отключите сервис DHCP на нем.
- Контролируйте сервис DHCP для доступности на первом DC (например, опрашивайте его каждый час со сценарием или чем-то подобным).
Это не даст Вам полностью автоматическую обработку отказа, но в Вашем сценарии я не думаю, что это будет слишком большим соглашением. Во-первых, Ваш срок действия арендного договора DHCP предотвратит клиенты от резкого понижения сети. Во-вторых, если Ваш первый DC умирает, я думаю, что Вы собираетесь иметь намного большие проблемы, что просто не наличие DHCP, и что Вы будете знать о нем заранее любых проблем с недоступностью вступления в силу DHCP.
Таким образом, эти серверы БД находятся в другой сети (через брандмауэр)? Раз так смотрите на кэш ARP на веб-серверах и серверах БД в то время, когда проблема происходит, и посмотрите на таблицу ARP на брандмауэре, когда проблема происходит. Веб-серверы должны иметь MAC-адрес брандмауэра для IP-адреса сервера БД в их кэше, серверы БД должны иметь MAC-адрес брандмауэра для IP-адреса веб-сервера в их кэше, и брандмауэр должен иметь MAC-адрес для IP-адреса сервера БД и MAC-адрес для IP-адреса веб-сервера в, он - кэш. Удостоверьтесь, что таблица ARP брандмауэра показывает адреса MAC для серверов, перечисленных в соответствующем интерфейсе брандмауэра, что каждый сервер "подключен" с. Если это получает Вас не, где затем проверяют таблицу ARP на переключателях между веб-серверами и серверах БД.
Можно также поместить сетевой анализатор на веб-серверы и серверы БД и запустить захват пакетов. Когда проблема происходит, посмотрите на получение на обоих концах и посмотрите то, что происходит. Необходимо видеть трафик от веб-серверов к серверам БД (к брандмауэру) и от серверов БД до веб-серверов (к брандмауэру). Если Вы делаете затем, это - сетевая проблема, если Вы не делаете затем, это - проблема с сервером.
Править
Кроме того, можно искать любые пакеты RST, прибывающие из любого конца соединения в сборе сетевых данных, который мог бы прибывать из брандмауэра из-за настроек тайм-аута соединения на брандмауэре.
Я предложил бы смотреть на статистику NIC - главным образом ошибочные количества, существует ли какая-либо разгрузка к случаю модуля ПАЛЬЦА НОГИ, и становится ли ссылка веб-серверов на переключатель (или другое сетевое устройство) влажной. Также вывод 'netstat-ano' - возможно, что Вы получите ошибки, если весь эфемерный диапазон портов (49152-65535 по умолчанию в Windows 2008) будет использоваться на веб-серверах.
Быть периодически не мог соединиться с SQL может иметь бесчисленные причины от аппаратных средств до проблем организации пула подключений, поэтому если Вы могли бы отправить сообщение об ошибке, это регистрируется или отображается (предполагающий, что существует один), который мог бы дать людям лучшее представление что случилось.