Введение
У нас есть прекрасно работающая стандартная конфигурация серверов. RAID1 для системных дисков, 2 карты по два 25Гб/с порта под сеть. Итого 100 Гб/с, которые мы научились выжимать в предыдущей заметке про iScsi (https://habr.com/ru/companies/beeline_tech/articles/821855/) под цели СУБД.
В то же время сетевое оборудование, расположенное между сервером и СХД, может значительно больше, чем 100Гб/c, как и СХД. Поэтому захотелось посмотреть, можно ли выжать на стороне сервера 200Гб/c
! Спойлер: Можно, но вы этого не захотите.
Тестовый стенд
Тестирование производилось на том же подключенном по iScsi к СХД.
На том же наборе дисков, что и раньше.
Просто с 4-портового сервера диски были перенесены на 8-портовый.
Для этого достаточно было ‘разлогиниться’ в iscsci на старом сервере, запретить сервисы multipathd и iscsi, перенести их конфиги на новый сервер (чтобы LUNы мапились в такие же устройства в /dev/mapper), перенести iscsi id из файла /etc/iscsi/initiatorname.iscsi, перезапустить multipathd на новом сервере (чтобы подхватил имена дисков и нового-старого конфига), сделать discovery для iscsi и залогиниться на нем (с настроенными средствами разграничения доступа)
#Примеры команд iscsiadm --mode node --logoutall=all systemctl stop multipathd systemctl disable multipathd systemctl stop iscsid systemctl disable iscsid tar cvf - /etc/multipath.conf /etc/iscsi/initiatorname.iscsi /etc/iscsi/iscsid.conf | ssh root@новыйхост "cd /; tar xvf -" # или что больше нравится mv /etc/multipath.conf /etc/multipath.conf.bak mv /etc/iscsi/initiatorname.iscsi /etc/iscsi/initiatorname.iscsi.bak mv /var/lib/iscsi/nodes mv /var/lib/iscsi/nodes.bak Или полее подробно на https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-iscsi
Тесты
Разделили с помощью FRR 8 портов на три группы. По 2, 4 и 2 порта. Условно под приложения, данные и бэкап. Для каждой группы прописали правила роутинга. Хотелось бы получить гарантированные 100Гб по группе из четырех портов. При стабильной работе приложения и бэкапа.
СХД тестируем через fio, два сегмента через iperf3, так как он входит в стандартный образ операционки.
Синтетические тесты с помощью FIO показали, что успех совсем близок. С настройками, которые мы нашли в прошлой статье, выжать 100Гб не проблема, если у нас есть 4 порта. Мы утилизировали группу портов под СХД по максимуму при отсутствии трафика приложения и бэкапа.
Второй синтетический тест показал, что выжать 50Гб по каждому набору из 2 портов тоже несложно.
Ещё один тест, и успех можно будет признать полным!
Запускаем все нагрузки в параллель. Суммарная скорость 100Гб, что в 2 раза меньше ожиданий. Остановка fio до СХД сразу дает скачок до максимальной загрузки второго набора портов.
Откладываем нарезку по портам до лучших времен.
Настраиваем FRR на использование всех 8 портов сразу. Вообще-то у нас было ещё 2 порта тестовом на сервере, итого всего 10, чтобы если вдруг сеть сразу разгонится до 200, можно было бы попробовать замахнуться и на Вильяма нашего, Шекспира, то есть на 250, но, видать, не в этот раз.
Начинаем тестировать только через iperf3. Его недостатки известны, поэтому запускается 24 копии сервера iperf3 (примеры команд будут ниже). Для которых есть парные клиенты.
Для нагона нагрузки у нас есть 2 сервера с 4 портами, про которые мы точно знаем, что 100Гб/c они дают. Ранее делали синтетические тесты раньше, тоже с помощью iperf3, и получали сотку.
Проверяем, что каждый сервер-генератор трафика может выжать почти 100 (96 в реале). По отдельности могут.
Попытка взять 200.
Начинаем гнать с двух 4-портовых серверов iperf3 трафик на 8-портовый сервер. На 3 FRR IP, каждый объединяет 2-4-2 порта
Каждый сервер-генератор ранее утилизировал на 8 портовом сервере 100Гб. Но, запустив генерацию трафика в параллели, мы разгоняемся тоже только до 100, и это предел.
Не страшно. Чтобы убрать FRR на каждом из сетевых портов, поднимаем свои iperf3 сервера на IP каждого порта из 8 и шлём напрямую на конкретный IP трафик с генерящих серверов. Видно, как конкретный порт утилизируется на полную, если гнать трафик только с одного сервера. Но при генерации с двух серверов опять магический потолок в 100Гб. Не физический, тот 200, а именно магический.
Пробуем посмотреть, что же происходит при этом на свитчах. Там Порты при максимальной возможной утилизации сервером заняты на половину. Или, если вы оптимист, порты свитча наполовину свободны.
Первая фаза развенчания магии. Надо запустить тест локально!
Запускам iperf3 трафик на localhost.
Примерно так (аналогично проводилось тестирование между серверами, только localhost меняется на FRR IP или IP порта, и команды раскидываются между серверами)
# Сервера (iperf3 -4 -s -p 5201& iperf3 -4 -s -p 5202& iperf3 -4 -s -p 5203 & iperf3 -4 -s -p 5204& iperf3 -4 -s -p 5205& iperf3 -4 -s -p 5206& iperf3 -4 -s -p 5207 & iperf3 -4 -s -p 5208& iperf3 -4 -s -p 5209& iperf3 -4 -s -p 5210& iperf3 -4 -s -p 5211 & iperf3 -4 -s -p 5212& iperf3 -4 -s -p 5301& iperf3 -4 -s -p 5302& iperf3 -4 -s -p 5303 & iperf3 -4 -s -p 5304& iperf3 -4 -s -p 5305& iperf3 -4 -s -p 5306& iperf3 -4 -s -p 5307 & iperf3 -4 -s -p 5308& iperf3 -4 -s -p 5309& iperf3 -4 -s -p 5310& iperf3 -4 -s -p 5311 & iperf3 -4 -s -p 5312& iperf3 -4 -s -p 5401& iperf3 -4 -s -p 5402& iperf3 -4 -s -p 5403 & iperf3 -4 -s -p 5404& iperf3 -4 -s -p 5405& iperf3 -4 -s -p 5406& iperf3 -4 -s -p 5407 & iperf3 -4 -s -p 5408& iperf3 -4 -s -p 5409& iperf3 -4 -s -p 5410& iperf3 -4 -s -p 5411 & iperf3 -4 -s -p 5412& iperf3 -4 -s -p 5501& iperf3 -4 -s -p 5502& iperf3 -4 -s -p 5503 & iperf3 -4 -s -p 5504& iperf3 -4 -s -p 5505& iperf3 -4 -s -p 5506& iperf3 -4 -s -p 5507 & iperf3 -4 -s -p 5508& iperf3 -4 -s -p 5509& iperf3 -4 -s -p 5510& iperf3 -4 -s -p 5511 & iperf3 -4 -s -p 5512& )|grep receiv | grep SUM # Клиенты (iperf3 -t 30 -V -c localhost -T s1 -p 5201 -P 127 & iperf3 -t 30 -V -c localhost -T s2 -p 5202 -P 127 & iperf3 -t 30 -V -c localhost -T s3 -p 5203 -P 127 & iperf3 -t 30 -V -c localhost -T s4 -p 5204 -P 127 & iperf3 -t 30 -V -c localhost -T s1 -p 5205 -P 100 & iperf3 -t 30 -V -c localhost -T s2 -p 5206 -P 100 & iperf3 -t 30 -V -c localhost -T s3 -p 5207 -P 100 & iperf3 -t 30 -V -c localhost -T s4 -p 5208 -P 100 & iperf3 -t 30 -V -c localhost -T s1 -p 5209 -P 16 & iperf3 -t 30 -V -c localhost -T s2 -p 5210 -P 16 & iperf3 -t 30 -V -c localhost -T s3 -p 5211 -P 16 & iperf3 -t 30 -V -c localhost -T s4 -p 5212 -P 16 & iperf3 -t 30 -V -c localhost -T s1 -p 5301 -P 127 & iperf3 -t 30 -V -c localhost -T s2 -p 5302 -P 127 & iperf3 -t 30 -V -c localhost -T s3 -p 5303 -P 127 & iperf3 -t 30 -V -c localhost -T s4 -p 5304 -P 127 & iperf3 -t 30 -V -c localhost -T s1 -p 5305 -P 100 & iperf3 -t 30 -V -c localhost -T s2 -p 5306 -P 100 & iperf3 -t 30 -V -c localhost -T s3 -p 5307 -P 100 & iperf3 -t 30 -V -c localhost -T s4 -p 5308 -P 100 & iperf3 -t 30 -V -c localhost -T s1 -p 5309 -P 16 & iperf3 -t 30 -V -c localhost -T s2 -p 5310 -P 16 & iperf3 -t 30 -V -c localhost -T s3 -p 5311 -P 16 & iperf3 -t 30 -V -c localhost -T s4 -p 5312 -P 16 ) | grep sender | grep SUM Получаем 170Гб/c.
Мечты, что через сеть будет возможно прокачать 200Гб относятся в недосягаемые.
Но можно же побороться хотя бы за 150. Начинаем борьбу.
Перебираем все настройки tcp окон на уровне ОС в sysctl.conf и портов сетевых карточек (у которой и так были последняя FW и mtu 9000).
Эффекта от изменений как-то незаметно.
Шли по https://fasterdata.es.net/host-tuning/linux/100g-tuning/
Тут возникает гипотеза, что не влияет ли то, что первая сетевая карта стоит в 1м слоте (x16), который относится к CPU1, а вторая в 4м (второй x16 на плате), который относится к CPU2.
Решаемся переставить из x16 слота в x8, которого для 100Гб/c должно быть достаточно.
Запускаем тесты и видим незначительный прирост.
При этом htop показывает, что слишком много iperf3 висит на ядрах 2 процессора.
Решаемся отключить все ядра второго процессора (не путайте их с гипертредовыми CPU).
#echo 0 > /sys/devices/system/cpu/cpu<number>/online ( for cpu in {32..63} {96..127}; do echo "echo 0 > /sys/devices/system/cpu/cpu${cpu}/online" ; done) | sh И повторить тест. Гоним с 2х серверов точно трафик на все порты по отдельности и достигаем 160Гб/c
Победа (пиррова)
Повторяем тест с localhost. На тех же настройках достигается скорость в 250Гб/c.
Почему так происходит.
Сервера, у которых мы хотели разогнать сеть, предназначались для работы СУБД. Инсталлятор этой СУБД для стабильной работы отключает NUMA путем добавления numa=off в GRUB.
Простое удаление этого ключа и перезагрузка более чем в 2 раза увеличивают результаты теста iperf3 на localhost. И с первой попытки дают забить все 8 каналов на примерно 95% о максимума.
У нас же в итоге программно-аппаратный комплекс, и программная часть определяет режим работы. Для него 100Гб/с — предел на имеющемся железе.
Итоги.
Лучшее – враг хорошего. Поэтому все надо тестировать и проверять. Для тестов нужна стратегия. У нас её изначально не было, пришлось импровизировать на ходу. Теперь вы можете придумать свою на основе нашей.
Но помните, неудача — это вполне ожидаемый результат. И от неудачи тоже много пользы.
Будем ли мы использовать 4×25Гб/c карты? Конечно. Они в случае выхода одной карты позволяют работать на той же скорости, что и в случае присутствия обеих.
Если вы думаете переносить большие или огромные базы на распространённые платформы, то сеть всегда может преподнести несколько сюрпризов. Возможно, стоит задуматься о росте локального хранилища путем применения более ёмких моделей NVME накопителей.
Мы походили по граблям, чтобы вы могли этого не делать. Если же вы сами захотите походить по граблям, то знайте, что упомянутые выше эксперименты обеспечивают достойное покрытие грабельного поля.
ссылка на оригинал статьи https://habr.com/ru/articles/838192/
Добавить комментарий