Тесты nftlb и ключи производительности

РАЗМЕЩЕНО 28 июня 2018 г.

тесты

Последние тесты, выпущенные в июне 2018, показывают значительное улучшение производительности при использовании nftables в качестве пути данных вместо iptables.

Принимая во внимание среду тестирования клиентов 2, выполняющих инструмент снятия нагрузки HTTP, подсистему балансировки нагрузки 1 и бэкэнды 3 с терминатором HTTP, дающим ответ около байтов 210, мы получаем следующие тесты в HTTP потоки в секунду:

iptables DNAT		256.864,07 RPS / cpu
iptables SNAT		262.088,94 RPS / cpu

nftables DNAT		560.976,44 RPS / cpu
nftables SNAT		608.941,57 RPS / cpu
nftables DSR		7.302.517,31 RPS / cpu

Вышеприведенные цифры показаны в расчете на физический процессор, так как добавляющие ядра масштабируемости почти линейны. Хотя эти тесты были выполнены только с бэкэндами 3, Производительность iptables существенно снизится при добавлении дополнительных бэкэндов, поскольку они подразумевают более последовательные правила.

Эти тесты были выполнены с отключенным retpoline (без защиты от Spectre / Meltdown), но как только они включены, потери производительности, обнаруженные в случаях NAT с включенным conntrack для случаев iptables и nftables, намного хуже для первого:

iptables: 40.77% CPU penalty
nftables: 17.27% CPU penalty

Ключи производительности

Наказания за ретполин объясняются из-за использования в iptables гораздо большего количества вызовов косвенной адресации, чем в nftables. Но также есть еще несколько ключей производительности, которые будут объяснены ниже.

Оптимизация правил

Основным ключом производительности является оптимизация правил. В iptables уже было известно, что использование ipset повышает производительность, поскольку уменьшает последовательную обработку правил.

В nftlb, хотя он может быть расширен для использования в других целях, мы устанавливаем основные правила для каждой виртуальной службы, используя выразительный язык, который изначально поддерживает использование множеств и карт. Пожалуйста, смотрите ниже сгенерированные правила для виртуальный tcp сервис с именем vs01 с бэкэндами 2:

table ip nftlb {
    map tcp-services {
        type ipv4_addr . inet_service : verdict
        elements = { 192.168.0.100 . http : goto vs01 }
    }

    chain prerouting {
        type nat hook prerouting priority 0; policy accept;
        ip daddr . tcp dport vmap @tcp-services
    }

    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
    }

    chain vs01 {
        dnat to jhash ip saddr mod 2 map { 0 : 192.168.1.10, 1 : 192.168.1.11 }
    }
}

Как только нам нужно добавить новый бэкэнд, просто регенерируйте связанную цепочку в виртуальный сервис без включения новых правил и без влияния на остальные виртуальные сервисы.

    chain vs01 {
        dnat to jhash ip saddr mod 3 map { 0 : 192.168.1.10, 1 : 192.168.1.11, 2 : 192.168.1.12 }
    }

Тогда, если новый виртуальный сервис vs02 необходимо создать, тогда набор правил станет таким, как показано ниже, без добавления новых правил или влияния на другие виртуальные службы:

table ip nftlb {
    map tcp-services {
        type ipv4_addr . inet_service : verdict
        elements = { 192.168.0.100 . http : goto vs01,
                     192.168.0.102 . https : goto vs02 }
    }

    chain prerouting {
        type nat hook prerouting priority 0; policy accept;
        ip daddr . tcp dport vmap @tcp-services
    }

    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
    }

    chain vs01 {
        dnat to jhash ip saddr mod 3 map { 0 : 192.168.1.10, 1 : 192.168.1.11, 2 : 192.168.1.12 }
    }

    chain vs02 {
        dnat to jhash ip saddr mod 2 map { 0 : 192.168.2.10, 1 : 192.168.2.11 }
    }
}

Ранние крючки

Nftables позволяет использовать ранние входной крюк это используется в nftlb во время сценариев DSR.

Кроме того, этот ранний хук может использоваться для целей фильтрации, что повышает производительность в случаях отбрасывания пакетов. Это показано ниже с самой ранней стадией случаев iptables и nftables в пакетах в секунду:

iptables prerouting raw drop: 38.949.054,35 PPS
nftables ingress drop: 45.743.628,64 PPS

Методы ускорения

Действительно, еще больше возможностей для оптимизации, поскольку nftables уже поддерживает быстрые пути и упрощенные методы, которые можно использовать для манипулирования пакетами. Как примеры этого:

Flowtables, Conntrack fast path для делегирования уже установленных соединений на входную стадию без прохождения всего медленного пути. Больше информации здесь.

NAT без состояния, В некоторых случаях с балансировкой нагрузки NAT без сохранения состояния может выполняться без отслеживания соединения и со стадии входа, чтобы получить всю производительность, применяемую к сценариям NAT.

Поделись:

Документация в соответствии с условиями GNU Free Documentation License.

Была ли эта статья полезна?

Статьи по теме