да как же вы заебали уже в корень со своим этим Грутом

Че? :)

Там же принцип, что мы fc приземляем на все гиперы, а синдер/гланс ходят в веб-апи и режут волумы/таргеты/луны?

Кто то писал что это из за того что квм-кему пишет в один поток. Хз

А в стеке это как реализовать?

Покажи iperf по бонду в 20Гб больше 10Гб - я тебе поверю

А если на одном серваке два айперфа в режиме сервера, а на другом - два айперфа в режиме клиента ?

Там по маку/ip балансит

Интересно протестить как часто проблемы с фрагментацией пакетов возникают. Я давно как-то тестил 802.3ad с layer 3-4 и утилизация была норм, а вот фрагментацию не проверял

@creepy_owlet Извини что в вечер субботы тэгаю, но потом забуду) Подскажи, я верно понимаю что во время периодического sync_power_state все conductor воркеры параллельно долбят каждый BMC? То есть, 8 воркеров == 8 запросов к BMC параллельно. Авось хоть один отработает) Так?

Интересно протестить как часто проблемы с фрагментацией пакетов возникают. Я давно как-то тестил 802.3ad с layer 3-4 и утилизация была норм, а вот фрагментацию не проверял

Включаем этот режим, запускаем два аперфа в режиме сервера на разных портах, например так: iperf3 -s -D -p 10444 iperf3 -s -D -p 10443

Получишь для каждого iperf по пропускной способности одного интерфейса в бонде. Суть алгоритмов хэширования и режимов работы бонда без LACP, но с балансировкой в том чтобы намеренно пускать фрйемы относящиеся к одному обмену (флоу) через один и тот же интерфейс. Это не ограничение железа, а необходимость, потому что если просто херачить пакет туда-пакет сюда, как делает balance-rr или если использовать хитрый алгоритм, а не консистентное хеширование, то велик шанс что фреймы будут прилетать на хост назначения не в том порядке ак были отправлены. Для TCP примера возьми TCP. Для него out-of-order в порядке вещей, в нем заложен механизм сборки потока по sequence number. Но в эзернете ничо такого нет. Поэтому out of order tcp сегменты в поток собрать можно, но перед этим тебе надо собрать ip пакеты и завернутые в них сегменты из ethernet фреймов. Но если фреймы приходят не в том порядке как отправлялись, то ничо не соберется. Есть вариант для одного флоу получить полную пропускную способность бонда - если у тебя будут прямые линки между отправителем и получателем с одинаковыми характеристиками среды передачи и бонд в режиме balance-rr. А если balance-rr попытаться гнать через свитч, то не заработает нормально. В целом, конечно, если не фрагментировать ip пакеты и если они все будут одинакового размера и если tcp сегменты будут одинакового размера, то должно работать и так. Но наверн такие реализации разве что в студенческих научных работах)

Если в моём примере под flow понимать комбинацию IP address/TCP port для источника и приёмника, то да. Если эти параметры неизменны, то хэш будет одинаковый и весь такой траффик уйдёт по одной верёвке из двух. Важно понимать, что даже iperf при многопоточной работе в режиме клиента динамически получает порты и трафик начинает балансироваться. Но для большей эффективности лучше и серверные порты сделать разными, что увеличит равномерность балансировки

Да, все так. То есть как тебе выше и говорили, одна пара хэшируемых заголовков - один линк) А уж маки там, порты транспортного протокола или ваще поле прикладного протокола это не так важно. Все упирается в убогость простоту эзернета.

Ок, так. Но вопрос был про Iperf и возможность распределить трафик по двум ногам между двумя серверами. Это можно сдедать если хочется, я описал как.

Dell и его lifecycle controller готовы с тобой об этом поспорить

@creepy_owlet Извини что в вечер субботы тэгаю, но потом забуду) Подскажи, я верно понимаю что во время периодического sync_power_state все conductor воркеры параллельно долбят каждый BMC? То есть, 8 воркеров == 8 запросов к BMC параллельно. Авось хоть один отработает) Так?

Каждый BMC должен получить только один запрос, там очередь.

Так, а тогда если можешь поясни в чем смысл предупреждения вот тут: https://docs.openstack.org/ironic/latest/admin/power-sync.html In deployments with many nodes and IPMI as the configured BMC protocol, the default values of a 60 seconds power sync interval and 8 worker threads may lead to a high rate of required retries due to client-side UDP packet loss (visible via the corresponding warnings in the conductor logs). While Ironic automatically retries to get the power status for the affected nodes, the failure rate may be reduced by increasing the power sync cycle, e.g. to 300 seconds, and/or by reducing the number of power sync workers, e.g. to 2. Pleae keep in mind, however, that depending on the concrete setup increasing the power sync interval may have an impact on other components relying on up-to-date power states.

Потому что Supermicro? 😁

Я советую не использовать ipmi без крайней необходимости

Сволочи вообще говоря

Напиши в понедельник, что у тебя там с ipmi. Я вряд ли помогу, но могу от души посочувствовать.