TL; DR версия: Оказывается, это была серьезная ошибка сети Broadcom в Windows Server 2008 R2. Замена аппаратным обеспечением Intel исправила это. Мы больше не используем оборудование Broadcom. Когда-либо.
Мы использовали HAProxy вместе с пульсом из проекта Linux-HA. Мы используем два экземпляра Linux для обеспечения отработки отказа. Каждый сервер имеет свой собственный общедоступный IP-адрес и один IP-адрес, который используется двумя виртуальными интерфейсами (eth1: 1) по IP-адресу: 69.59.196.211.
Виртуальный интерфейс (eth1: 1) IP 69.59.196.211 настроен как шлюз для оконных серверов позади них, и мы используем ip_forwarding для маршрутизации трафика.
Мы иногда испытываем перебои в работе сети на одном из наших серверов Windows за нашими шлюзами Linux. HAProxy обнаружит, что сервер находится в автономном режиме, что мы можем проверить, установив удаленный сервер и попытавшись пропинговать шлюз:
Пинг 69.59.196.211 с 32 байтами данных: Ответ от 69.59.196.220: узел назначения недоступен.
Работа arp -aна этом отказавшем сервере показывает, что для адреса шлюза нет записи (69.59.196.211):
Интерфейс: 69.59.196.220 --- 0xa Тип физического адреса интернет-адреса 69.59.196.161 00-26-88-63-c7-80 динамический 69.59.196.210 00-15-5d-0a-3e-0e динамический 69.59.196.212 00-21-5e-4d-45-c9 динамический 69.59.196.213 00-15-5d-00-b2-0d динамический 69.59.196.215 00-21-5e-4d-61-1a динамический 69.59.196.217 00-21-5e-4d-2c-e8 динамический 69.59.196.219 00-21-5e-4d-38-e5 динамический 69.59.196.221 00-15-5d-00-b2-0d динамический 69.59.196.222 00-15-5d-0a-3e-09 динамический 69.59.196.223 ff-ff-ff-ff-ff-ff static 224.0.0.22 01-00-5e-00-00-16 статический 224.0.0.252 01-00-5e-00-00-fc статический 225.0.0.1 01-00-5e-00-00-01 статический
На наших экземплярах шлюза Linux arp -aпоказано:
peak-colo-196-220.peak.org (69.59.196.220) на <не завершено> на eth1 stackoverflow.com (69.59.196.212) в 00: 21: 5e: 4d: 45: c9 [эфир] на eth1 peak-colo-196-215.peak.org (69.59.196.215) в 00:21: 5e: 4d: 61: 1a [эфир] на eth1 peak-colo-196-219.peak.org (69.59.196.219) в 00: 21: 5e: 4d: 38: e5 [эфир] на eth1 peak-colo-196-222.peak.org (69.59.196.222) в 00:15: 5d: 0a: 3e: 09 [эфир] на eth1 peak-colo-196-209.peak.org (69.59.196.209) в 00: 26: 88: 63: c7: 80 [эфир] на eth1 peak-colo-196-217.peak.org (69.59.196.217) в 00:21: 5e: 4d: 2c: e8 [эфир] на eth1
Почему arp иногда устанавливает запись для этого отказавшего сервера как <incomplete>? Должны ли мы определять наши записи arp статически? Я всегда оставляю arp в покое, так как он работает в 99% случаев, но в этом случае он, похоже, дает сбой. Есть ли какие-либо дополнительные меры по устранению неполадок, которые мы можем предпринять, чтобы решить эту проблему?
Вещи, которые мы испытали
Я добавил статическую запись arp для тестирования на одном из шлюзов linux, который все еще не помог.
root@haproxy2:~# arp -a
peak-colo-196-215.peak.org (69.59.196.215) at 00:21:5e:4d:61:1a [ether] on eth1
peak-colo-196-221.peak.org (69.59.196.221) at 00:15:5d:00:b2:0d [ether] on eth1
stackoverflow.com (69.59.196.212) at 00:21:5e:4d:45:c9 [ether] on eth1
peak-colo-196-219.peak.org (69.59.196.219) at 00:21:5e:4d:38:e5 [ether] on eth1
peak-colo-196-209.peak.org (69.59.196.209) at 00:26:88:63:c7:80 [ether] on eth1
peak-colo-196-217.peak.org (69.59.196.217) at 00:21:5e:4d:2c:e8 [ether] on eth1
peak-colo-196-220.peak.org (69.59.196.220) at 00:21:5e:4d:30:8d [ether] PERM on eth1
root@haproxy2:~# arp -i eth1 -s 69.59.196.220 00:21:5e:4d:30:8d
root@haproxy2:~# ping 69.59.196.220
PING 69.59.196.220 (69.59.196.220) 56(84) bytes of data.
--- 69.59.196.220 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6006ms
Перезагрузка веб-сервера Windows временно решает эту проблему без каких-либо других изменений в сети, но наш опыт показывает, что эта проблема вернется.
Обмен сетевых карт и коммутаторов
Я заметил, что индикатор соединения на порту коммутатора для отказавшего сервера Windows работал на 100 МБ вместо 1 ГБ на отказавшем интерфейсе. Я переместил кабель к нескольким другим открытым портам, и ссылка указала 100 МБ для каждого порта, который я попробовал. Я также поменял местами кабель с тем же результатом. Я попытался изменить свойства сетевой карты в Windows, и сервер заблокировался, и после нажатия кнопки «Применить» потребовалась полная перезагрузка. Этот сервер Windows имеет два физических сетевых интерфейса, поэтому я поменял местами кабели и настройки сети на этих двух интерфейсах, чтобы увидеть, следует ли проблема за интерфейсом. Если общедоступный интерфейс снова выйдет из строя, мы будем знать, что это не проблема с сетевой картой.
(Мы также попробовали другой переключатель, который у нас есть, без изменений)
Изменение версий драйверов сетевого оборудования
У нас была та же проблема с последним драйвером Broadcom, а также со встроенным драйвером, который поставляется в Windows Server 2008 R2.
Замена сетевых кабелей
В качестве последнего усилия мы вспомнили еще одно изменение, произошедшее с заменой всех коммутационных шнуров между нашими серверами / коммутатором. Мы купили два комплекта: один зеленый длиной 1–3 фута для частных интерфейсов и другой комплект красных кабелей для открытых интерфейсов. Мы заменили все соединительные кабели общедоступного интерфейса другой марки и без проблем работали на наших серверах целую неделю ... ааааа, а затем проблема возобновилась.
Отключить разгрузку контрольной суммы, удалить TProxy
Мы также попытались отключить разгрузку контрольной суммы TCP / IP в драйвере, без изменений. Сейчас мы вытаскиваем TProxy и переходим к более традиционному x-forwarded-forсетевому соглашению без какой-либо сложной перезаписи IP-адреса. Посмотрим, поможет ли это.
Переключить провайдеров виртуализации
В случае, если это каким-то образом связано с Hyper-V (на нем мы размещаем виртуальные машины Linux), мы переключились на VMWare Server. Без изменений.
Переключить модель хоста
Мы достигли конца нашей цепочки устранения неполадок и теперь формально привлекаем поддержку Microsoft. Они рекомендовали изменить модель хоста:
- http://en.wikipedia.org/wiki/Host_model
- http://technet.microsoft.com/en-us/magazine/2007.09.cableguy.aspx
Мы сделали это, и мы также получили некоторые неопубликованные исправления ядра, которые предположительно были добавлены в 2008 R2 SP1. Не исправить.
Замена оборудования сетевой карты
В конечном счете, замена сетевого оборудования Broadcom сетевым оборудованием Intel решила эту проблему для нас. Поэтому я склонен думать, что виноваты драйверы Broadcom для Windows Server 2008 R2!
источник
Ответы:
С http://linux-ip.net/html/ether-arp.html :
Похоже, ваш шлюз не отвечает (или слишком медленно) на ARP-запросы от вашего шлюза. Это в
<incomplete>конечном итоге переключиться на<failed>? Какое сетевое оборудование у вас есть между сервером и шлюзом? Возможно ли, что широковещательные ARP-запросы фильтруются или блокируются где-то между двумя хостами?источник
Это означает, что вы пропинговали адрес, IP-адрес имеет запись PTR (отсюда и имя), но ничего не отвечало с рассматриваемой машины. Когда мы видим это, это чаще всего происходит из-за того, что маска подсети установлена неправильно - или в случае IP-адресов, привязанных к интерфейсу обратной связи, которые вместо этого были случайно привязаны к интерфейсу eth.
Что такое 196,220? Каковы его отношения с 196.211? Я предполагаю, что .220 является одним из хостов прокси-сервера HA. Когда вы запускаете на нем ifconfig -a & arp -a, что это показывает?
источник
Как говорит Макс Кларк, <неполное> означает, что 69.59.196.211 выдал запрос ARP для 69.59.196.220 и еще не получил ответа. (В Windows-land вы увидите это как ARP-отображение на «00-00-00-00-00-00» ... Мне кажется странным, что вы не видите такого ARP-отображения на 69,59,196,220 для 69,59,196,211.)
Я не люблю использовать статические записи ARP, потому что, по моему опыту, ARP обычно выполняет свою работу все время.
Если бы это был я, я бы прослушал соответствующий интерфейс Ethernet на «сбойной» машине с Windows (69.59.196.220), чтобы наблюдать за ARP'ом для 69.59.196.211, и наблюдать, как / если он отвечает на запросы ARP от 69.59. 196,211. Я также рассмотрел бы прослушивание на машине шлюза только для ARP (
tcpdump -i interface-name arp), чтобы увидеть, как выглядит ARP-трафик со стороны машины Linux.Из блога я знаю, что у вас есть внутренняя сеть и внешняя сеть. Во время этих сбоев возникает ли у "сбойного" Windows-сервера (69.59.196.220) какие-либо проблемы с подключением к другим машинам в интерфейсной сети, или это просто проблемы с его шлюзом? Мне любопытно, попадете ли вы на неисправный компьютер через интерфейсную или фоновую сеть, когда вы ловите его в действии.
Что вы делаете, чтобы «решить» проблему, когда она возникает?
Редактировать:
Из вашего обновления я вижу, что вы перезагружаете «сбойную» машину Windows, чтобы решить эту проблему. Прежде чем вы сделаете это в следующий раз, можете ли вы убедиться, что машина Windows вообще способна «общаться» по интерфейсу внешнего интерфейса? Также возьмите копию таблицы маршрутизации с машины Windows (
route print) также во время сбоя. (Я пытаюсь выяснить, действительно ли сетевой адаптер / драйвер не работает на Windows-машине.)источник
Этот документ показывает различные состояния (таблица 2.1). Неполный будет означать, что он отправил первый запрос ARP (предположительно, после устаревания, задержки, исследования), но еще не получил ответ.
источник
Причина, по которой статический ARP на узле haproxy не помогает, заключается в том, что ваш веб-сервер все еще не может понять, как вернуться к шлюзу.
Статический ARP на веб-сервере не позволяет вашим веб-серверам переключать шлюзы в случае сбоя одного из узлов haproxy. Я предполагаю, что виртуальный интерфейс использует тот же MAC-адрес, что и eth1 узла haproxy, поэтому вам придется код для одного из двух шлюзов в каждый веб-сервер.
У вас установлено какое-либо защитное программное обеспечение на неисправном веб-сервере? Я провел долгую ночь с сервером Windows 2008, на котором был установлен Symantec Endpoint Security - он устанавливает некоторый фильтрующий код в сетевой стек, который вообще не позволяет пакетам ARP видеть шлюз. Исправление для этого (как предусмотрено Microsoft) заключалось в удалении записи реестра, которая загружала DLL.
В другой раз, когда возникла эта проблема, казалось, помогло удаление всего сетевого адаптера из диспетчера устройств и переустановка.
источник
Поскольку вы статически устанавливаете свою запись arp, ваши серверы знают, где найти шлюз. Однако, если ваш коммутатор не знает, где находится шлюз, он не будет пересылать ваши пакеты.
Похоже, у вас плохой (или запутанный) переключатель между вашим HAproxy и вашими веб-серверами. Перезагрузите его.
Либо так, либо ваши HAproxy-серверы не согласны с тем, какой из них находится под контролем, и оба отвечают на запросы arp для .211.
В том же духе, если ваш коммутатор перегружен, ваши HA-прокси могут быть не в состоянии обмениваться данными друг с другом достаточно быстро и при сбое.
источник
В следующий раз, когда возникнет эта проблема, я бы предложил запустить некоторые перехваты пакетов на двух указанных хостах, чтобы определить, какой трафик ARP наблюдает каждый из них.
На вашей машине HAproxy, скорее всего, будет установлен некоторый вариант tcpdump . Для компьютера с Windows вам потребуется либо приложение WinPCAP , например Wireshark , либо Microsoft Network Monitor .
На самом деле, если подумать об этом, поскольку проблема, как представляется, связана именно с ARP, вы потенциально можете просто непрерывно записывать весь трафик ARP на машине HAproxy и рассматриваемой машине Windows с помощью файла непрерывного захвата (ради аргумента) 10 МБ. Это должно быть достаточно большим, чтобы к моменту обнаружения сбоя файл захвата все еще содержал трафик ARP до сбоя. (Стоит поэкспериментировать, запустив захват в течение часа или около того, чтобы увидеть, сколько данных он генерирует).
Пример синтаксиса захвата для Linux tcpdump (обратите внимание, у меня нет под рукой Linux-бокса, чтобы проверить это; пожалуйста, проверьте поведение -C и -W перед использованием в производстве!):
Надеюсь, это должно дать вам некоторое представление о том, что именно терпит неудачу. Когда срок действия ARP истекает (и в соответствии с этой статьей новые версии Windows, как представляется, очень агрессивно устаревают «неактивными» записями), я ожидаю, что произойдет следующее:
Как бы просто это ни звучало, есть множество других вещей, которые могут помешать этому процессу:
Что нужно проверить, если / когда это произойдет снова:
источник
У нас была похожая проблема с одним из наших терминальных серверов 2008 R2, когда весь трафик на NIC останавливался, но оставался подключенным, а светодиоды NIC показывали бы связь. Это была постоянная проблема, которая продолжала появляться 2-3 раза в неделю, но только после 12-13 часов безотказной работы (сервер перезагружался ночью).
Я обнаружил, что причиной стал Seriousbit Netbalancer, после того как я попытался (из любопытства) прекратить службу NetbalancerService. Затем трафик начал двигаться через интерфейс. С тех пор я удалил Netbalancer.
источник
У меня была такая же проблема с локальной сетью Asus. Это было исправлено путем установки последней версии драйвера с сайта realtek
источник