Comments 18
Надпись «Часть 1» воодушевляет, с нетерпением буду ждать продолжения)
а есть какие-нибудь бенчмарки? как было, как стало?
а есть какие-нибудь бенчмарки? как было, как стало?
Сюжет произведения не очевиден. В Части 1 прослеживается Интрига и некая Завязка, но далее вместе с нумерацией теряется Экспозиция. Развитие действий перегружено личными переживаниями и подробностями. Кульминация выражена слабо. Развязка скомкана. Возможно, Автор приберег захватывающий Эпилог для комментариев. В любом случае, пожелаем ему дальнейших творческих успехов.
Спасибо за статью.
Можете более подробно описать подбор параметров syslog? Были использованы формулы или подсчет был эмпирическим путем?
Можете более подробно описать подбор параметров syslog? Были использованы формулы или подсчет был эмпирическим путем?
Наверно не syslog а sysctl?
Те, которые net.core.*mem* — есть мнение что следует использовать формулу 1М на каждый 1G оперативной памяти. Мы решили немного подстраховаться, и для начала остановились на 54М при 128G оперативы. Меняя этот параметр под нагрузкой, не заметили по графикам никаких изменений, и решили оставить как есть.
net.core.somaxconn — отталкивались от статистики количества текущих соединений на боевых машинах.
Те, которые net.core.*mem* — есть мнение что следует использовать формулу 1М на каждый 1G оперативной памяти. Мы решили немного подстраховаться, и для начала остановились на 54М при 128G оперативы. Меняя этот параметр под нагрузкой, не заметили по графикам никаких изменений, и решили оставить как есть.
net.core.somaxconn — отталкивались от статистики количества текущих соединений на боевых машинах.
Для начала покрутил настройки сетевых карт
Забавно, что Вы стали крутить настройки даже не посмотрев, что у вас за карты.
Не совсем понял вопроса. Модель и вендора я знал, текущие параметры и максимальные, которые может использовать текущий драйвер — я получил от ethtool (это в статье указано)
На тот момент это были интеловские карты, драйвер ixgbe я менять не стал.
На тот момент это были интеловские карты, драйвер ixgbe я менять не стал.
Это не вопрос, что вы. Удивило, что вы не упомянув железа стали накатывать на него настройки. Так же и с jumbo. Их ведь должны поддерживать не только конечные девайсы, но и все L3 на маршруте. Получается начитаются юниоры таких статей, начнут применять у себя и порушат всё окончательно. Ну нельзя давать простыни конфигов без объяснений. Мне кажется.
Подскажите пожалуйста, где подробно и доступно почитать по агрегацию линков с помощью OSPF.
То ли Google не хочет выдавать что-то приличное, то ли я его спрашиваю не о том, или не так.
То ли Google не хочет выдавать что-то приличное, то ли я его спрашиваю не о том, или не так.
Я пользовался документацией frr
docs.frrouting.org/en/latest/ospfd.html
docs.frrouting.org/en/latest/ospfd.html
Интересно как вы тестировали производительность LACP. Потому что странный результат какой-то
Предположительно потому, что LACP не может слать по разным интерфейсам пакеты у которых совпадает и mac адреса и\или IP адреса и\или номер порта(в зависимости от алгоритма балансировки) получателя и отправителя.
Вот тут подробнее о балансировку нагрузки в классическом LACP.
Из-за этого с помощью LCAP не получится распараллелить классический iSCSI между парой клиент-сервер. Кроме того оно может упираться в возможность коммутатора(служебный трафик, просчет хешей, и т.д.).
Вот тут подробнее о балансировку нагрузки в классическом LACP.
Из-за этого с помощью LCAP не получится распараллелить классический iSCSI между парой клиент-сервер. Кроме того оно может упираться в возможность коммутатора(служебный трафик, просчет хешей, и т.д.).
Ваш ответ несколько не про то. Я спросил именно про способ тестирования (софт, настройки как со стороны коммутатора так и сервера). Потому что вижу несколько странных вещей
1) Поток все-таки распараллелен. Ибо результат больше скорости одного интерфейса.
2) Делить пакеты от одного источника в отношениях других чем 1/2, 1/4 итд ну никак нельзя (Хотя в том случае если у нас не один генератор трафика и пакеты не одинаковые можно получить ассиметрию по утилизации)
3) Я помню некоторые линейные платы в шеститонник у которых четыре гигабитных порта обслуживались асиком производительностью <2 Гигабит и бондинг там надо было собирать на 1-5-9-13 портах ( или 2-6-10-14 итд). Но современные приличные 10-Гиг коммутаторы уже все неблокирующие. Тем более что автор говорит что в итоге они утилизировали порты.
4) Если это действительно проблема в коммутаторах — очень интересен производитель. ( чтобы не брать такие)
4.1) Кроме того интересно — собирали коммутаторы в стек, или использовали что-то проприеритарное, так как собрать LACP при полностью независимых коммутаторах по определению невозможно.
1) Поток все-таки распараллелен. Ибо результат больше скорости одного интерфейса.
2) Делить пакеты от одного источника в отношениях других чем 1/2, 1/4 итд ну никак нельзя (Хотя в том случае если у нас не один генератор трафика и пакеты не одинаковые можно получить ассиметрию по утилизации)
3) Я помню некоторые линейные платы в шеститонник у которых четыре гигабитных порта обслуживались асиком производительностью <2 Гигабит и бондинг там надо было собирать на 1-5-9-13 портах ( или 2-6-10-14 итд). Но современные приличные 10-Гиг коммутаторы уже все неблокирующие. Тем более что автор говорит что в итоге они утилизировали порты.
4) Если это действительно проблема в коммутаторах — очень интересен производитель. ( чтобы не брать такие)
4.1) Кроме того интересно — собирали коммутаторы в стек, или использовали что-то проприеритарное, так как собрать LACP при полностью независимых коммутаторах по определению невозможно.
Я, похоже, веткой промахнулся немного. :)
Судя по всему тестировали живой нагрузкой. Не полная утилизация, скорее всего, была из за того что так карта легла, т.е. на какой-то из линков было 10 а на другом 6, из за совпадения адресов сервера и клиента(так как между парой серверов больше 10Гбит/с быть не может, а серверов немного, такой сценарий выглядит наиболее вероятно).
Мне тоже жутко интересно как и что, так как с ospf работал мало и о таком назначении не знал.
Андрей, здорово.
а что за проблема с ласп, не пробовали разбираться? Ограничение в 16 гбит было в какую сторону, от коммутаторов к серверу или обратно, или в обе стороны, что вдвойне странно?
Да, и правильно я понял, что для кластера отдельную физическую сеть выделили? Какие-то проблемы возникли с подключением к фабрике? Выглядит как-то странновато, на 5 стоек иметь фабрику из лифов и спайнов, а потом еще некоторые кластеры выносить на дополнительные коммутаторы.
а что за проблема с ласп, не пробовали разбираться? Ограничение в 16 гбит было в какую сторону, от коммутаторов к серверу или обратно, или в обе стороны, что вдвойне странно?
Да, и правильно я понял, что для кластера отдельную физическую сеть выделили? Какие-то проблемы возникли с подключением к фабрике? Выглядит как-то странновато, на 5 стоек иметь фабрику из лифов и спайнов, а потом еще некоторые кластеры выносить на дополнительные коммутаторы.
Sign up to leave a comment.
Сeph — от «на коленке» до «production»