Два бокса с одинаковой нагрузкой, обслуживающие одни и те же сайты, обычно замедляются и перестают отвечать на пинг. Медленный (или прерывистый) пинг заставляет наш балансировщик нагрузки думать, что серверы отключены, и отключать их. Существует третий сервер с идентичным контентом, на котором нет проблем, поэтому я вполне уверен, что это не сайты.
ОС - это Windows Server 2008. Конфигурация немного особенная: поскольку мы используем балансировщик нагрузки Barracuda Networks в режиме Direct Server Return, нам пришлось настроить несколько адаптеров обратной связи, которые «подделывают» IP-адрес, как описано Вот. На физическом адаптере включена пересылка в соответствии с требованиями к 2008 году, чтобы адаптеры обратной петли работали.
Симптомы:
Вопрос:
Какие для этого есть возможные причины? Что я должен попытаться диагностировать? Я ничего не исключаю. Конфигурация коммутатора, домен / DNS сервер, все идеи приветствуются.
К сожалению, у меня очень мало знаний о хорошем сетевом администрировании, поэтому очевидные ответы тоже приветствуются.
РЕДАКТИРОВАТЬ:
Отвечая на некоторые из заданных вопросов.
Я связался с Barracuda, и они, похоже, считают, что проблема связана с сетью. Думаю, я согласен с этим.
IP назначается физическому интерфейсу, а не разделяется между серверами. Пинг выполняется из той же подсети.
Третье поле обрабатывает всю загрузку сайта, когда два других выходят из строя, и у него не было особых проблем, но иногда и у него тоже есть проблемы. Я еще не нашел шаблона с этим.
Этим вечером я сел с другим (более опытным) специалистом по сети, чтобы просмотреть некоторые конфигурации домена и сервера. Одна из вещей, которые он обнаружил, - это плохая настройка DNS на контроллерах домена. Они были настроены с использованием внешних DNS-серверов в качестве альтернативы, а не с другим DC. Мы переключили их на ссылки друг на друга для DNS и добавили пересылку в службу DNS. Мы также удалили внешние ссылки DNS со всех веб-серверов.
РЕДАКТИРОВАТЬ 2:
С Wireshark я смог проверить ICMP-трафик во время одного периода простоя. Я начал этот тест, потому что мне не удалось получить доступ к общей папке на ящике 2 из ящика 1.
Тест:
Таким образом, каким-то образом трафик между двумя серверами приводит к тому, что блок 2 не работает на ICMP в течение определенного периода времени.
Я должен отметить, что ящик 1 работал нормально на протяжении всего этого теста, но не видел никаких запросов из поля 2. При проверке связи с ящиком 1 из поля 2 программа Wireshark в поле 2 показала сообщение «Пункт назначения недоступен (связь административно отфильтрована)» из источника. IP я не узнал.
Вам нужно использовать ICMP ping для тестирования вашего сервера? HTTP-запросы поддерживаются большинством балансировщиков нагрузки и, как правило, лучше, поскольку ваш веб-сервер может не работать, пока ваша сетевая карта все еще работает.
Третий сервер находится под нагрузкой или он отличается от двух других по-другому?
Не зная больше, я бы предложил получить Wireshark на эти серверы, проверяя их связь и отслеживая активность ICMP. Мое (возможно, необоснованное) подозрение заключается в том, что на этих серверах возникают проблемы с ARP, и они отправляют ответные пакеты обратно, а вы их просто не получаете.
С помощью Wireshark установите фильтр на «arp или icmp» и посмотрите, что он покажет. Вы также должны быстро взглянуть на свои журналы системных событий - там может быть что-то очевидное, что сокращает любые дальнейшие догадки.
Если вы не знакомы с arp, это протокол для преобразования адресов уровня 3 (IP) в адреса уровня 2 (MAC). Это должно происходить правильно, иначе кадр уровня 2, содержащий пакет уровня 3, либо никогда не будет отправлен, либо будет доставлен не в тот пункт назначения.
Наконец, рекомендации других плакатов по дуплексной печати / скорости являются надежной лучшей практикой, хотя я сомневаюсь, что они здесь являются основной причиной. Обратите внимание, что в гигабитном Ethernet вам больше не нужно беспокоиться об отсасывании автосогласования.
РЕДАКТИРОВАТЬ
Внесенные вами изменения DNS, безусловно, являются хорошей идеей, но мне сложно представить сценарий, при котором это приведет к тайм-аутам ICMP. Возможно, приложение блокирует тысячи DNS-запросов и настолько поглощает свои ресурсы, что не может отвечать на ICMP?
В любом случае, если это не решит проблему, трассировки пакетов должны показать больше того, что происходит.
Я бы сначала посоветовался с Barracuda Networks. Это может быть известная проблема. У нас была похожая проблема, которая оказалась у нашего балансировщика нагрузки Cisco. Обновление прошивки устранило проблему.
Одна вещь, которую я обнаружил, помогает - убедиться, что сетевой адаптер на сервере и порт на коммутаторе, к которому он подключен, имеют одинаковую скорость и настройки дуплексного режима. У меня были проблемы с "автоматическим согласованием", которое не очень хорошо согласовывалось, что начинало вызывать множество ошибок на порту и сетевой карте.
Попробуйте установить скорость в интерфейсах вручную и по возможности избегайте использования автосогласования.
Обновите сетевые драйверы на своих серверах до последней версии, предоставленной поставщиком оборудования. Я считаю, что это иногда решает странные проблемы с сетью.
Какой исходный IP-адрес выполнял административную фильтрацию? Скорее всего, это источник проблемы, и я подозреваю, что она внутренняя для балансировщика нагрузки.