Карьера в Stack Overflow подается примерно так:
user -> internet -> our fw -> nginx -> haproxy -> web farm
Во время нормальной работы nginx получает HTTP-запрос, выполняет свою задачу и передает запрос экземпляру haproxy, который привязан к адресу обратной связи (127.0.0.1) в том же самом поле.
Чтобы на днях устранить неполадки, я переместил экземпляр haproxy на тот же интерфейс, на котором работал nginx. Это сразу добавило задержки ко всем запросам на 100 мс. Этот интерфейс - не настоящий физический интерфейс, а карп интерфейс.
Может ли кто-нибудь объяснить мне, почему это было так? Может быть, конфликт с очередью пакетов? Или, может быть, шлейф всегда быстрее, потому что он «мягкий»? Мне здесь не хватает чего-то фундаментального, и я надеюсь, что кто-то любезно меня просветит.
Постоянная задержка в 100 мс выглядит странно. Похоже, пакеты попадают в буфер и не доставляются сразу. Или, может быть, некоторые из них отброшены и переданы повторно. Можете ли вы запустить tcpdump в этом интерфейсе, чтобы показать проблему? Я не знаю, как IP-стек работает во FreeBSD, и как реализуется CARP, но возможно ли, например, что ведомое устройство регулярно объявляет свой MAC-адрес с помощью бесплатных ARP и что ведущий альтернативно отправляет пакеты каждой стороне?
Не могли бы вы также запустить tcpdump на реальном интерфейсе, чтобы ничего не выводилось?
Возможно ли, что система воздерживается от кэширования записи ARP устройства CARP, вызывая тем самым отправку запроса ARP для каждого пакета сеанса, на который демон CARP должен будет ответить?
По большей части это глупые идеи, но они предназначены для того, чтобы помочь вам искать в правильном направлении.
Для ясности вы изменили только способ доступа с адреса 127 на локальный IP; верный?
Если это так, и это имело значение, что-то не так. Проверьте свою таблицу маршрутизации с помощью netstat -rn и посмотрите, на что маршрутизируются локальные IP-адреса, он должен быть направлен на интерфейс lo0 (как и 127).
Ваш netstat -rn вывод должен быть примерно похож на этот:
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 1.2.3.1 UGS 131 2655014 nge1
1.2.3.0/23 link#2 U 0 88 nge1
1.2.3.4 link#2 UHS 0 34848 lo0
127.0.0.1 link#5 UH 0 64678 lo0
192.168.0.0/26 link#1 U 2 41703537 nge0
192.168.0.1 link#1 UHS 0 70088 lo0
Я видел, как loopback реализован как программный интерфейс уровня прерывания, так что трафик никогда не выходит за рамки. Могло ли это быть в случае, когда вы использовали loopback? Отказ от ответственности: просто общий вопрос; Я ничего не знаю о FreeBSD.
- Пит