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 настроен как шлюз для серверов Windows за ними, и мы используем ip_forwarding для маршрутизации трафика.
Время от времени у нас возникают перебои в работе сети на одном из наших серверов Windows за нашими шлюзами linux. HAProxy обнаружит, что сервер отключен, что мы можем проверить, удаленно подключившись к неисправному серверу и попытавшись пропинговать шлюз:
Pinging 69.59.196.211 with 32 bytes of data: Reply from 69.59.196.220: Destination host unreachable.
Бег arp -a на этом отказавшем сервере показывает, что нет записи для адреса шлюза (69.59.196.211):
Interface: 69.59.196.220 --- 0xa Internet Address Physical Address Type 69.59.196.161 00-26-88-63-c7-80 dynamic 69.59.196.210 00-15-5d-0a-3e-0e dynamic 69.59.196.212 00-21-5e-4d-45-c9 dynamic 69.59.196.213 00-15-5d-00-b2-0d dynamic 69.59.196.215 00-21-5e-4d-61-1a dynamic 69.59.196.217 00-21-5e-4d-2c-e8 dynamic 69.59.196.219 00-21-5e-4d-38-e5 dynamic 69.59.196.221 00-15-5d-00-b2-0d dynamic 69.59.196.222 00-15-5d-0a-3e-09 dynamic 69.59.196.223 ff-ff-ff-ff-ff-ff static 224.0.0.22 01-00-5e-00-00-16 static 224.0.0.252 01-00-5e-00-00-fc static 225.0.0.1 01-00-5e-00-00-01 static
На наших экземплярах шлюза linux arp -a показывает:
peak-colo-196-220.peak.org (69.59.196.220) at <incomplete> on eth1 stackoverflow.com (69.59.196.212) at 00:21:5e:4d:45:c9 [ether] on eth1 peak-colo-196-215.peak.org (69.59.196.215) at 00:21:5e:4d:61:1a [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-222.peak.org (69.59.196.222) at 00:15:5d:0a:3e:09 [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
Почему 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. Они рекомендовали изменить модель хоста:
Мы сделали это, и мы также получили несколько неопубликованных исправлений ядра, которые предположительно были включены в 2008 R2 SP1. Никакого исправления.
Замена оборудования сетевой карты
В конечном счете, замена сетевого оборудования Broadcom на сетевое оборудование Intel решила эту проблему для нас. Поэтому я склонен думать, что виноваты драйверы Broadcom Windows Server 2008 R2!
Из http://linux-ip.net/html/ether-arp.html:
Если для запрошенного IP-адреса назначения нет записи кэша ARP, ядро будет генерировать запросы ARP mcast_solicit до получения ответа. В течение этого периода обнаружения запись кэша ARP будет отображаться в незавершенном состоянии. Если поиск не будет успешным после указанного количества запросов ARP, запись кэша ARP будет указана в состоянии сбоя. Если поиск действительно успешен, ядро вводит ответ в кэш ARP и сбрасывает таймеры подтверждения и обновления.
Похоже, ваш шлюз не отвечает (или отвечает слишком медленно) на запросы ARP от вашего шлюза. Это <incomplete> в конечном итоге переключиться на <failed>? Какое сетевое оборудование установлено между сервером и шлюзом? Возможно ли, что широковещательные запросы ARP фильтруются или блокируются где-то между двумя хостами?
Это означает, что вы выполнили эхо-запрос адреса, IP-адрес имеет запись PTR (отсюда и название), но от рассматриваемой машины ничего не ответили. Когда мы видим это, чаще всего это происходит из-за неправильной установки маски подсети - или в случае IP-адресов, привязанных к интерфейсу обратной связи, которые вместо этого были случайно привязаны к интерфейсу eth.
Что такое 196,220? Какая связь с 196.211? Я предполагаю, что .220 - один из хостов HA Proxy. Когда вы запускаете ifconfig -a & arp -a, что он показывает?
Как говорит Макс Кларк, <incomplete> просто означает, что 69.59.196.211 отправил ARP-запрос для 69.59.196.220 и еще не получил ответа. (В среде Windows вы увидите это как сопоставление ARP с "00-00-00-00-00-00" ... Мне кажется странным, BTW, что вы не видите такого сопоставления 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.
Точно так же, если ваш коммутатор перегружен, ваши HAproxies могут быть не в состоянии связываться друг с другом достаточно быстро и выходят из строя.
В следующий раз, когда возникнет эта проблема, я бы предложил запустить перехват пакетов на двух рассматриваемых хостах, чтобы определить, какой ARP-трафик наблюдает каждый из них.
Ваша машина HAproxy, скорее всего, будет иметь tcpdump установлены. Для Windows-машины вам понадобится WinPCAP приложение, как Wireshark, или Монитор сети Microsoft.
Фактически, если подумать, поскольку проблема, по-видимому, связана именно с ARP, вы потенциально можете просто непрерывно записывать весь трафик ARP на машине HAproxy и машине Windows, о которой идет речь, с непрерывным файлом захвата (для аргументации) 10 МБ. Он должен быть достаточно большим, чтобы к тому моменту, когда вы обнаружите сбой, файл захвата все еще будет содержать трафик ARP до сбоя. (Стоит поэкспериментировать, запустив захват в течение часа или около того, чтобы увидеть, сколько данных он генерирует).
Пример синтаксиса захвата для Linux tcpdump (обратите внимание, у меня нет Linux-бокса, чтобы проверить это; пожалуйста, проверьте поведение -C и -W перед использованием в производстве!):
tcpdump -C 10 -i eth1 -w /var/tmp/arp.cap -W 1 arp
Надеюсь, это даст вам некоторое представление о том, что именно не удается. Когда срок действия записи ARP истекает (и в соответствии с Эта статья, новые версии Windows очень агрессивно истощают «неактивные» записи), я бы ожидал, что произойдет следующее:
Как бы просто это ни звучало, есть множество других вещей, которые могут помешать этому процессу:
Что нужно проверить, если / когда это произойдет снова:
У нас была аналогичная проблема с одним из наших терминальных серверов 2008 R2, когда весь трафик на NIC останавливался, но оставался подключенным, а светодиоды NIC отображали связь. Это была постоянная проблема, которая возникала 2-3 раза в неделю, но только после 12-13 часов безотказной работы (сервер перезагружается каждую ночь).
Я обнаружил, что причиной был Seriousbit Netbalancer, после того как я попытался (из любопытства) завершить работу службы NetbalancerService. Затем трафик начал перемещаться по интерфейсу. С тех пор я удалил Netbalancer.
У меня была такая же проблема с локальной сетью материнской платы Asus. Это было исправлено установкой последней версии драйвера из Realtek интернет сайт