Вопросы Теги

Циклическое выравнивание нагрузки на пакет для UDP

Несомненно, можно исказить существующие заголовки в постфиксе, если Вы действительно хотите. Но IIRC, большая часть MTAs не добавит, что заголовок, если он не был уже добавлен MUA.

4
задан 27 April 2013 в 22:00
2 ответа

Требование было удовлетворено следующим образом:

Я установил более свежую версию ipvsadm (и ее модули ядра), которая поддерживает - ops флаг (1.26). Поскольку keepalived не выставляет этот флаг в своем файле конфигурации, вы должны применить его вручную. К счастью, вы можете сделать это после создания «виртуальной службы» (в терминах простого ipvsadm вы можете сначала ipvsam -A виртуальную службу без - ops , а затем ipvsadm -E , чтобы добавить планирование одного пакета).

Поскольку keepalived создает виртуальную службу для вас, все, что вам нужно сделать, это отредактировать ее после ее создания, что происходит, когда для этого виртуального сервера набирается кворум (в основном, имеется достаточное количество работающих реальных серверов). Вот' s как это выглядит в файле keepalived.conf : 

virtual_server <VIP> <VPORT> {
    lb_algo rr
    lb_kind NAT
    protocol UDP
    ...

    # Enable one-packet scheduling when quorum is gained
    quorum_up "ipvsadm -E -u <VIP>:<VPORT> --ops -s rr"

    ... realserver definitions, etc ...
}

Это работает, но я столкнулся с рядом проблем (вроде) с этой настройкой:

  1. Небольшой промежуток времени (меньше чем на секунду, больше похоже на 1/10), между увеличением кворума и выполнением сценария в quorum_up . Любые дейтаграммы, которым удастся пройти через директор в течение этого времени, создадут запись о подключении в ipvsadm, и дальнейшие дейтаграммы с этого исходного хоста / порта будут застрять на том же реальном сервере даже после - ops ] добавлен флаг . Вы можете минимизировать вероятность этого, убедившись, что виртуальная служба никогда не удаляется после создания. Вы делаете это, указав флаг ignit_on_failure в ваших определениях реального сервера, чтобы они не удалялись, когда соответствующий реальный сервер не работает (когда все реальные серверы удаляются, виртуальная служба также удаляется), а вместо этого устанавливается их вес до нуля (тогда они перестают получать трафик). В результате дейтаграммы могут проскочить только во время запуска keepalived (при условии, что в это время у вас есть хотя бы один реальный сервер, так что кворум будет немедленно получен).
  2. Когда - ops активен, директор не перезаписывает исходный хост / порт дейтаграмм, которые реальные серверы отправляют клиентам, поэтому исходный хост / порт - это тот хост / порт реального сервера, который отправил эту конкретную дейтаграмму. Это могло быть проблемой (это было для моих клиентов). Вы можете исправить это, добавив SNAT датаграмм с помощью iptables.
  3. Я заметил значительную системную загрузку процессора, когда директор находится под нагрузкой. Оказывается, процессор забит ksoftirqd. Этого не происходит, если выключить - ops . Вероятно, проблема в том, что алгоритм диспетчеризации пакетов запускается для каждой дейтаграммы, а не только для первой дейтаграммы в «соединении» (если это даже применимо к UDP ...). На самом деле я не нашел способа «исправить» это, но, возможно, я недостаточно старался. Система предъявляет определенные требования к нагрузке, и при такой нагрузке использование процессора не исчерпывается; также нет потерянных дейтаграмм, поэтому эта проблема не считается преградой. Однако это все еще вызывает тревогу.

Резюме:

5
ответ дан 3 December 2019 в 03:07

Должен быть способ сделать это с помощью многопутевой маршрутизации ....

Балансировщик нагрузки и реальный сервер совместно используют IP-адреса в подсети (10.0.0 / 24). Для обоих реальных серверов вы добавляете один и тот же IP-адрес из другой подсети в качестве вторичного для интерфейса обратной связи (172.16.1.1/32). Именно по этому адресу ваша служба будет прослушивать. 

                              +-------------------------------------+
                         +----|A: eth0:10.0.0.2/24 lo:172.16.1.1/32 |
+--------------------+   |    +-------------------------------------+
|LB eth0:10.0.0.1/24 |---|
+--------------------+   |    +-------------------------------------+
                         +----|B: eth0:10.0.0.3/24 lo:172.16.1.1/32 |
                              +-------------------------------------+

, а затем вы можете использовать: 

 ip route add 172.16.1.1/32 nexthop via 10.0.0.2 nexthop via 10.0.0.3

Но пока что хорошие новости: очевидно, последние ядра Linux будут кэшировать маршруты, так что пакеты из того же источника все равно будут попадать на то же место назначения. Есть некоторые патчи для отключения этого поведения, но все они, похоже, предназначены для старых ядер (например, патч выравнивания многопутевого кода для ядра 2.4, mpath в 2.6). Может быть, более тщательный поиск поможет найти рабочий патч для последнего ядра.

Отказоустойчивость можно легко реализовать, запустив CARP как для 10.0.0.2, так и для 10.0.0.3. Таким образом, B берет на себя 10.0.0.2, когда A выходит из строя.

1
ответ дан 3 December 2019 в 03:07

Теги

Похожие вопросы