Сeph — от «на коленке» до «production»

[@yatheo]

Надпись «Часть 1» воодушевляет, с нетерпением буду ждать продолжения)
а есть какие-нибудь бенчмарки? как было, как стало?

[@MrCleaner]

Сюжет произведения не очевиден. В Части 1 прослеживается Интрига и некая Завязка, но далее вместе с нумерацией теряется Экспозиция. Развитие действий перегружено личными переживаниями и подробностями. Кульминация выражена слабо. Развязка скомкана. Возможно, Автор приберег захватывающий Эпилог для комментариев. В любом случае, пожелаем ему дальнейших творческих успехов.

[@chemtech]

Спасибо за статью.
Можете более подробно описать подбор параметров syslog? Были использованы формулы или подсчет был эмпирическим путем?

[@DerekNN]

Наверно не syslog а sysctl?
Те, которые net.core.*mem* — есть мнение что следует использовать формулу 1М на каждый 1G оперативной памяти. Мы решили немного подстраховаться, и для начала остановились на 54М при 128G оперативы. Меняя этот параметр под нагрузкой, не заметили по графикам никаких изменений, и решили оставить как есть.
net.core.somaxconn — отталкивались от статистики количества текущих соединений на боевых машинах.

[@chemtech]

Да, sysctl

[@gto]

Для начала покрутил настройки сетевых карт

Забавно, что Вы стали крутить настройки даже не посмотрев, что у вас за карты.

[@DerekNN]

Не совсем понял вопроса. Модель и вендора я знал, текущие параметры и максимальные, которые может использовать текущий драйвер — я получил от ethtool (это в статье указано)
На тот момент это были интеловские карты, драйвер ixgbe я менять не стал.

[@gto]

Это не вопрос, что вы. Удивило, что вы не упомянув железа стали накатывать на него настройки. Так же и с jumbo. Их ведь должны поддерживать не только конечные девайсы, но и все L3 на маршруте. Получается начитаются юниоры таких статей, начнут применять у себя и порушат всё окончательно. Ну нельзя давать простыни конфигов без объяснений. Мне кажется.

[@DerekNN]

Понял. В последующих статьях постараюсь более детализировано разворачивать.
Спасибо за совет.

[@MrNobody]

Подскажите пожалуйста, где подробно и доступно почитать по агрегацию линков с помощью OSPF.
То ли Google не хочет выдавать что-то приличное, то ли я его спрашиваю не о том, или не так.

[@DerekNN]

Я пользовался документацией frr
docs.frrouting.org/en/latest/ospfd.html

[@sYB-Tyumen]

Очень прошу во второй части рассказать-таки про приключения с BGP.
И ещё, скажите, касаемо LACP удалось выяснить причину такой разности в пропускной способности по сравнению с OSPF? Ведь второй линк использовался, а значит хэширование работало (или оно работало асимметрично и проблема в этом?)

[@net_lamer]

Интересно как вы тестировали производительность LACP. Потому что странный результат какой-то

[@MrNobody]

Предположительно потому, что LACP не может слать по разным интерфейсам пакеты у которых совпадает и mac адреса и\или IP адреса и\или номер порта(в зависимости от алгоритма балансировки) получателя и отправителя.
Вот тут подробнее о балансировку нагрузки в классическом LACP.
Из-за этого с помощью LCAP не получится распараллелить классический iSCSI между парой клиент-сервер. Кроме того оно может упираться в возможность коммутатора(служебный трафик, просчет хешей, и т.д.).

[@net_lamer]

Ваш ответ несколько не про то. Я спросил именно про способ тестирования (софт, настройки как со стороны коммутатора так и сервера). Потому что вижу несколько странных вещей
1) Поток все-таки распараллелен. Ибо результат больше скорости одного интерфейса.
2) Делить пакеты от одного источника в отношениях других чем 1/2, 1/4 итд ну никак нельзя (Хотя в том случае если у нас не один генератор трафика и пакеты не одинаковые можно получить ассиметрию по утилизации)
3) Я помню некоторые линейные платы в шеститонник у которых четыре гигабитных порта обслуживались асиком производительностью <2 Гигабит и бондинг там надо было собирать на 1-5-9-13 портах ( или 2-6-10-14 итд). Но современные приличные 10-Гиг коммутаторы уже все неблокирующие. Тем более что автор говорит что в итоге они утилизировали порты.
4) Если это действительно проблема в коммутаторах — очень интересен производитель. ( чтобы не брать такие)
4.1) Кроме того интересно — собирали коммутаторы в стек, или использовали что-то проприеритарное, так как собрать LACP при полностью независимых коммутаторах по определению невозможно.

[@MrNobody]

Я, похоже, веткой промахнулся немного. :)
Судя по всему тестировали живой нагрузкой. Не полная утилизация, скорее всего, была из за того что так карта легла, т.е. на какой-то из линков было 10 а на другом 6, из за совпадения адресов сервера и клиента(так как между парой серверов больше 10Гбит/с быть не может, а серверов немного, такой сценарий выглядит наиболее вероятно).
Мне тоже жутко интересно как и что, так как с ospf работал мало и о таком назначении не знал.

[@blackabdula]

Андрей, здорово.

а что за проблема с ласп, не пробовали разбираться? Ограничение в 16 гбит было в какую сторону, от коммутаторов к серверу или обратно, или в обе стороны, что вдвойне странно?

Да, и правильно я понял, что для кластера отдельную физическую сеть выделили? Какие-то проблемы возникли с подключением к фабрике? Выглядит как-то странновато, на 5 стоек иметь фабрику из лифов и спайнов, а потом еще некоторые кластеры выносить на дополнительные коммутаторы.

[@blackabdula]

собственно, во второй части уже увидел