Назад | Перейти на главную страницу

Почему LVS отбрасывает пакеты?

В настоящее время я пытаюсь разобраться в сути проблемы, когда кажется, что мой LVS-директор время от времени отбрасывает пакет, приходящий от клиента. У нас есть эта проблема в наших производственных системах, и мы можем воспроизвести ее при постановке.

Я разместил эту проблему в списке рассылки lvs-users и пока не получил ответа.

Наша установка:

Мы используем ipvsadm с Linux CentOS5 x86_64 в PV XEN-DomU.

Детали текущей версии:

Ядро: 2.6.18-348.1.1.el5xen
ipvsadm: 1.24-13.el5

LVS-Настройка:

Мы используем IPVS в DR-режиме, для управления запущенными соединениями используем lvs-kiss.

ipvsadm работает в кластере heartbeat-v1-cluster (два виртуальных узла), главный и резервный серверы работают постоянно на обоих узлах.

Для LVS-сервисов мы используем логические IP-адреса, настраиваемые по тактовому сигналу (активный / пассивный-кластерный режим)

Настоящие серверы - это физические Linux-машины.

Настройка сети:

Виртуальная машина, выступающая в качестве директора, работает как XEN-PV-DomU на Dom0 с использованием мостовых сетей.

Сети «в игре»:

abn-network (промежуточная сеть, используемая для подключения клиента к директору), используемая реальными серверами для отправки ответа клиентам (подход прямой маршрутизации), используемая для ipvsadm slave / master multicast-traffic
lvs-network: это выделенная VLAN, которая соединяет директор и реальные серверы.
DR-arp-проблема: решено мое подавление arp-ответов на реальных серверах для service-ip
IP-адрес службы настроен как логический IP-адрес на интерфейсе lvs на реальных серверах.
В этой настройке ip_forwarding нигде не нужен (ни на директоре, ни на реальном сервере).

Детали ВМ:

1 ГБ ОЗУ, 2 виртуальных ЦП, загрузка системы почти 0, память 73 МБ свободно, буферы 224 МБ, кэш 536 МБ, без подкачки.

top показывает почти всегда 100% простоя, 0% us / sy / ni / wa / hi / si / st.

Детали конфигурации:

ipvsadm -Ln для рассматриваемой услуги показывает:

TCP  x.y.183.217:12405 wrr persistent 7200
 -> 192.168.83.234:12405   Route   1000   0          0
 -> 192.168.83.235:12405   Route   1000   0          0

x.y первые два октета относятся к нашему внутреннему диапазону класса B. Мы используем 192.168.83.x как lvs-network для постановки.

Постоянная конфигурация ipvsadm: / и т. д. / sysconfig / ipvsadm: - установить 20 20 20

Кластерная конфигурация: /etc/ha.d/haresources: $ primary_directorname lvs-kiss x.y.183.217

lvs-kiss-configuration-snippet для указанной выше службы:

<VirtualServer idm-abn:12405>
  ServiceType       tcp
  Scheduler         wrr
  DynamicScheduler    0
  Persistance         7200
  QueueSize           2
  Fuzz              0.1
  <RealServer rs1-lvs:12405>
    PacketForwardingMethod  gatewaying
    Test ping -c 1 -nq -W 1 rs1-lvs >/dev/null
    RunOnFailure   "/sbin/ipvsadm -d -t idm-abn:12405 -r rs1-lvs"
    RunOnRecovery   "/sbin/ipvsadm -a -t idm-abn:12405 -r rs1-lvs"
  </RealServer>
  <RealServer rs2-lvs:12405>
    PacketForwardingMethod  gatewaying
    Test ping -c 1 -nq -W 1 rs2-lvs >/dev/null
    RunOnFailure   "/sbin/ipvsadm -d -t idm-abn:12405 -r rs2-lvs"
    RunOnRecovery   "/sbin/ipvsadm -a -t idm-abn:12405 -r rs2-lvs"
  </RealServer>
</VirtualServer>

idm-abn, rs1 и rs2 разрешаются через / etc / hosts.

О сервисе:

Это soa-web-сервис.

Как мы воспроизводим ошибку:

С клиента мы запускаем постоянные вызовы веб-сервиса с интервалом один вызов в три секунды. Время от времени будет происходить сброс соединения от директора к клиенту.

Интересно: это происходит на n x сотых + 1 попытках - вот интересный.

Что мы сделали, чтобы отследить проблему:

Проверено / proc / sys / net / ipv4 / vs: все значения установлены по умолчанию, поэтому drop_packet НЕ на месте (= 0)
tcpdump на клиенте, fronted / abn директора, backend / lvs каталога, lvs и abn реальных серверов

В этом tcpdump мы могли видеть запрос от клиента, на который директор ответил сбросом соединения. Пакет НЕ был отправлен через LVS.

Я приветствую любые идеи о том, как отследить эту проблему в дальнейшем. Если какая-либо информация непонятна или отсутствует, чтобы разобраться в проблеме - спросите.

У тебя есть iptables с отслеживанием состояния правила о директоре LVS-DR? Как я вижу, вы используете порт 12405, поэтому, если у вас есть такое правило:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 12405 -j ACCEPT

В LVS-DR реальные серверы отвечают на запросы от клиентов (а не от директора), директор не будет добавлять эти соединения в таблицу отслеживания соединений и FIN пакеты не будут обнаруживаться на iptables директора с правилами ESTABLISHED,RELATED. Поскольку вы разрешаете только NEW (SYN) пакеты на порт 12405, FIN будет заблокирован. Вы должны использовать брандмауэр без сохранения состояния на директоре LVS-DR для служб балансировки нагрузки:

iptables -A INPUT -m tcp -p tcp --dport 12405 -j ACCEPT