В этом вопросе я хотел бы найти наилучшую возможную конфигурацию / оборудование для доставки 40 Гбит / с с одного сервера.

ситуация

У нас есть прокси-сервер для обмена видео, который снимает пики с медленных серверов хранения. Весь трафик только HTTP. Сервер действует как обратный прокси-сервер (файлы, которые не кэшируются на сервере) и веб-сервер (файлы, которые хранятся на локальных дисках).

В настоящее время на внутренних серверах хранения находится что-то вроде 100 ТБ файлов.

Механизм кэширования реализован независимо, и этот вопрос не касается самого кэширования, поскольку он работает очень хорошо - в настоящее время обеспечивает 14 Гбит / с, передает бэкэнд-серверам только 2 Гбит / с. Так что использование кеша хорошо.

Цель

Получите пропускную способность 40 Гбит / с или даже больше с одной машины.

Аппаратное обеспечение 1

HW: Supermicro SC825, X11SSL-F, Xeon E3-1230v5 (4C/8T @ 3,4 ГГц), 16 ГБ оперативной памяти DDR4, 2x Supermicro 10G STGN-i1S (LACP L3 + 4)

SSD: 1x 512 ГБ Samsung, 2x 500 ГБ Samsung, 2x480 ГБ Intel 535, 1x 240 ГБ Intel S3500

система:

• irqbalancer остановлен
• set_irq_affinity для каждого интерфейса (через скрипт в архиве драйверов ixgbe)
• ixgbe-4.3.15
• Срок действия планировщика ввода-вывода
• iptables empty (выгруженные модули)
• Файловая система: XFS

Nginx:

• отправить файл выключен
• AIO темы
• Directio 1M
• tcp_nopush on
• tcp_nodelay on

Как видно из графиков, мы смогли увеличить скорость до 12,5 Гбит / с. К сожалению, сервер не отвечает.

Есть две вещи, которые привлекли мое внимание. Первый - это большое количество IRQ. В этом случае, к сожалению, у меня нет графиков из / proc / interrupts. Вторым моментом была высокая загрузка системы, которая, я думаю, была вызвана проблемами с kswapd0 для работы только с 16 ГБ ОЗУ.

Аппаратное обеспечение 2

HW: Supermicro SC119TQ, X10DRW-i, 2x Xeon E5-2609v4 (8C/8T@1.70GHz), 128 ГБ оперативной памяти DDR4, 2x Supermicro 10G STGN-i1S

SSD, Конфигурация системы такая же, как и у аппаратного обеспечения 1. Nginx - это sendfile (aio / sendfile сравнивается далее).

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

Sendfile vs aio темы

Я попытался отключить sendfile и вместо этого использовать потоки aio.

• отправить файл выключен
• AIO темы
• directio 1M (соответствует всем имеющимся у нас файлам)

против

• отправить файл на

Затем в 15:00 я снова переключился на sendfile и перезагрузил nginx (поэтому для завершения существующих подключений потребовалось некоторое время). Приятно, что загрузка накопителя (по данным iostat) снизилась. На трафике ничего не изменилось (к сожалению, zabbix решил не собирать данные из bond0).

sendfile вкл / выкл

Просто попытался включить / выключить отправку. Ничего не изменилось, кроме прерывания Перепланирования.

irqbalancer как сервер / cron / отключен

Как упомянул @lsd, я попытался настроить запуск irqbalancer через cron:

*/5 * * * *   root    /usr/sbin/irqbalance --oneshot --debug 3 > /dev/null

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

Я не смог найти, что было не так на графиках, и, как это произошло на следующий день, я вошел на сервер и увидел, что одно ядро ​​работает на 100% (использование системы).

Я попытался запустить irqbalance как сервис, результат был все тот же.

Затем я решил использовать скрипт set_irq_affinity, и он сразу же решил проблему, и сервер снова выдал 17 Гбит / с.

Аппаратное обеспечение 3

Мы выполнили обновление до нового оборудования: 2U 24 (+2) корпуса (6xSFF), 2x Xeon E5-2620v4, 64 ГБ ОЗУ DDR4 (4x16 ГБ), 13x SSD, 2x Supermicro (с чипом Intel) сетевых карт. Новые процессоры значительно улучшили производительность.

Сохраняется текущая настройка - sendfile и т. Д. Разница лишь в том, что мы позволяем только одному ЦП обрабатывать обе сетевые карты (через скрипт set_irq_affinity).

Достигнут предел 20 Гбит / с.

Следующая цель? 30Gbps.

Не стесняйтесь стрелять в меня идеи, как улучшить производительность. Я буду рад протестировать его вживую и поделиться некоторыми тяжелыми графиками здесь.

Есть идеи, как бороться с большим количеством SoftIRQ на процессоре?

Это не вопрос планирования мощности - у меня уже есть оборудование и трафик. Я всегда могу разделить трафик на несколько серверов (что я буду делать в будущем) и решить проблему с деньгами. Однако это вопрос оптимизации системы и настройки производительности в реальном сценарии.

Отказ от ответственности : тот же совет относится ко всем услугам, поддерживающим скорость более 10 Гбит / с. Включены, но не ограничены балансировщиком нагрузки, серверами кэширования, веб-серверами (HAProxy, Varnish, nginx, tomcat, ...)

То, что вы хотите сделать, это неправильно, не делайте этого

Используйте вместо CDN

CDN предназначены для доставки кэшируемого статического контента. Используйте правильный инструмент для работы (akamai, MaxCDN, cloudflare, cloudfront, ...)

Любой CDN, даже бесплатный, будет работать лучше, чем вы можете достичь самостоятельно.

Вместо этого масштабируйте по горизонтали

Я ожидаю, что один сервер будет обрабатывать 1-5 Гбит / с из коробки без особой настройки (примечание: обслуживание только статических файлов). 8-10 Гбит / с обычно в пределах досягаемости с расширенной настройкой.

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

Запустите один блок, попробуйте что-нибудь, измерьте, сравните, оптимизируйте ... пока этот блок не станет надежным и надежным, а его возможности не будут четко определены, а затем поставьте больше подобных блоков с глобальным балансировщиком нагрузки.

Существует несколько вариантов глобальной балансировки нагрузки: большинство CDN могут это делать, циклический DNS-запрос, балансировка нагрузки ELB / Google ...

Давайте проигнорируем хорошие практики и сделаем это в любом случае

Понимание схемы движения

            WITHOUT REVERSE PROXY

[request ]  user ===(rx)==> backend application
[response]  user <==(tx)===     [processing...]

Необходимо учитывать две вещи: ширину полосы и направление (излучение или прием).

Небольшие файлы имеют размер 50/50 tx / rx, поскольку заголовки HTTP и издержки TCP больше, чем содержимое файла.

Большие файлы имеют размер 90/10 tx / rx, потому что размер запроса незначителен по сравнению с размером ответа.

            WITH REVERSE PROXY

[request ]  user ===(rx)==> nginx ===(tx)==> backend application
[response]  user <==(tx)=== nginx <==(rx)===     [processing...]

Обратный прокси-сервер ретранслирует все сообщения в обоих направлениях. Нагрузка всегда 50/50, а общий трафик удваивается.

Это становится более сложным с включенным кэшированием. Запросы могут быть перенаправлены на жесткий диск, данные которого могут быть кэшированы в памяти.

Примечание : я буду игнорировать аспект кэширования в этом посте. Мы сосредоточимся на получении 10-40 Гбит / с в сети. Знание того, поступают ли данные из кеша, и оптимизация этого кеша - это еще одна тема, в любом случае это происходит по проводам.

Monocore ограничения

Балансировка нагрузки является одноядерной (особенно балансировка TCP). Добавление ядер не делает это быстрее, но это может сделать это медленнее.

То же самое для балансировки HTTP с простыми режимами (например, IP, URL, на основе cookie. Обратный прокси-сервер читает заголовки на лету, он не анализирует и не обрабатывает запросы HTTP в строгом смысле).

В режиме HTTPS дешифрование / шифрование SSL является более интенсивным, чем все остальное, необходимое для прокси. Трафик SSL может и должен быть разделен на несколько ядер.

SSL

Учитывая, что вы делаете все через SSL. Вы хотите оптимизировать эту часть.

Шифрование и дешифрование на скорости 40 Гбит / с - это настоящее достижение.

Возьмите процессор последнего поколения с инструкциями AES-NI (используется для операций SSL).

Настройте алгоритм, используемый сертификатами. Есть много алгоритмов. Вам нужен тот, который наиболее эффективен на вашем процессоре (выполните бенчмаркинг), будучи поддерживаемым клиентами и просто достаточно безопасным (без необходимости избыточного шифрования).

IRQ и закрепление ядра

Сетевая карта генерирует прерывания (IRQ), когда появляются новые данные для чтения, и ЦПУ предварительно обрабатывает очередь. Это операция, выполняемая в ядре и / или драйверах устройства, и она строго одноядерная.

Это может быть самый большой потребитель ЦП с миллиардами пакетов, выходящих во всех направлениях.

Назначьте сетевой карте уникальный номер IRQ и закрепите его за конкретным ядром (см. Настройки Linux или BIOS).

Прикрепите обратный прокси к другим ядрам. Мы не хотим, чтобы эти две вещи вмешивались.

Адаптер Ethernet

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

Забудьте о встроенном адаптере на материнских платах (не имеет значения, серверная или потребительская материнская плата), они просто отстой.

Разгрузка TCP

TCP является очень интенсивным протоколом с точки зрения обработки (контрольные суммы, ACK, повторная передача, повторная сборка пакетов, ...) Ядро выполняет большую часть работы, но некоторые операции могут быть выгружены на сетевую карту, если она ее поддерживает.

Мы не хотим просто относительно быструю карту , нам нужна карта со всеми прибамбасами.

Забудьте об Intel, Mellanox, Dell, HP, о чем угодно. Они не поддерживают все это.

На столе только один вариант: SolarFlare - секретное оружие фирм HFT и CDN.

Мир разделен на два типа людей: « Те, кто знает SolarFlare » и « Те, кто не знает ». (первый набор строго эквивалентен « людям, которые работают в сети 10 Гбит / с и заботятся о каждом бите »). Но я отвлекся, давайте сосредоточимся: D

Настройка ядра TCP

Есть опции sysctl.confдля сетевых буферов ядра. Что делают эти настройки или нет. Я действительно не знаю.

net.core.wmem_max
net.core.rmem_max
net.core.wmem_default
net.core.rmem_default

net.ipv4.tcp_mem
net.ipv4.tcp_wmem
net.ipv4.tcp_rmem

Игра с этими настройками является явным признаком чрезмерной оптимизации (то есть, как правило, бесполезной или контрпродуктивной).

В исключительных случаях это может иметь смысл, учитывая экстремальные требования.

(Примечание: 40 Гбит / с на одном блоке - это чрезмерная оптимизация. Разумный маршрут - это горизонтальное масштабирование.)

Некоторые физические ограничения

Пропускная способность памяти

Некоторые цифры о пропускной способности памяти (в основном в ГБ / с): http://www.tweaktown.com/articles/6619/crucial-ddr4-memory-performance-overview-early-look-vs-ddr2-ddr3/index.html

Допустим, диапазон пропускной способности памяти составляет 150-300 Гбит / с (максимальный предел в идеальных условиях).

Все пакеты должны быть в памяти в какой-то момент. Простая загрузка данных со скоростью линии 40 Гбит / с - это большая нагрузка на систему.

Будет ли еще какая-то мощность для обработки данных? Что ж, давайте не будем слишком завышать наши ожидания. Просто говорю ^^

Шина PCI-Express

PCIe 2.0 - 4 Гбит / с на линию. PCIe 3.0 - 8 Гбит / с на линию (не все доступно для карты PCI).

Сетевой адаптер 40 Гбит / с с одним портом Ethernet обещает больше, чем шина PCIe, если длина разъема меньше 16-кратной в спецификации v3.0.

Другой

Мы могли бы перейти за другие пределы. Дело в том, что аппаратные средства имеют жесткие ограничения, присущие закону физики.

Программное обеспечение не может работать лучше, чем оборудование, на котором оно работает.

Магистраль сети

Все эти пакеты должны в конечном итоге куда-то идти, пересекая коммутаторы и маршрутизаторы. Коммутаторы и маршрутизатор 10 Гбит / с [почти] являются товаром. 40 Гбит / с определенно нет.

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

В прошлый раз, когда я проверял у своего сотрудника центра обработки данных небольшой проект на 10 миллионов пользователей, он был совершенно уверен, что в интернете будет максимум 2x 10 Гбит ссылок.

Жесткие диски

iostat -xtc 3

Метрики делятся на чтение и запись. Проверьте очередь (<1 - это хорошо), задержку (<1 мс - это хорошо) и скорость передачи (чем выше, тем лучше).

Если диск медленный, решение состоит в том, чтобы добавить больше и больше SSD в raid 10. (обратите внимание, что пропускная способность SSD увеличивается линейно с размером SSD).

Выбор процессора

IRQ и другие узкие места работают только на одном ядре, поэтому ориентируйтесь на ЦП с наивысшими показателями одноядерности (то есть с самой высокой частотой).

Для шифрования / дешифрования SSL требуются инструкции AES-NI, поэтому ориентируйтесь только на последнюю версию CPU.

SSL использует несколько ядер, поэтому ориентируйтесь на множество ядер.

Короче говоря: идеальный процессор - самый новый с самой высокой доступной частотой и множеством ядер. Просто выбери самое дорогое и вот наверное: D

послать файл()

Sendfile ON

Просто величайший прогресс современных ядер для высокопроизводительных веб-серверов.

Финальная нота

1 SolarFlare NIC 40 Gbps (pin IRQ and core)
2 SolarFlare NIC 40 Gbps (pin IRQ and core)
3 nginx master process
4 nginx worker
5 nginx worker
6 nginx worker
7 nginx worker
8 nginx worker
...

Одна вещь привязана к одному процессору. Это путь.

Одна сетевая карта, ведущая во внешний мир. Один сетевой адаптер, ведущий во внутреннюю сеть. Разделение обязанностей всегда хорошо (хотя двойной сетевой адаптер 40 Гбит / с может быть излишним).

Это много вещей, которые можно настроить, некоторые из которых могут быть предметом небольшой книги. Весело проведите бенчмаркинг всего этого. Вернись, чтобы опубликовать результаты.

Я не могу комментировать еще из-за репутации, поэтому придется добавить ответ ...

В первом примере вы сказали:

Есть две вещи, которые привлекли мое внимание. Первый - это большое количество IRQ. В этом случае, к сожалению, у меня нет графиков из / proc / interrupts. Вторым моментом была высокая загрузка системы, которая, я думаю, была вызвана проблемами с kswapd0 для работы только с 16 ГБ ОЗУ.

Абсолютно согласен, что это важные моменты.

1. Попробуйте использовать агент collectd, который может собирать IRQ и сохранять с использованием RRD.

2. У вас есть график использования памяти?

   На первый взгляд, это похоже на проблему с процессором, но высокий процент мягкости может просто указывать пальцем на память, если происходит много жестких или программных сбоев страниц. Я думаю, что разочарование - это внезапное увеличение IRQ за счет системного процессора примерно в 19:00.

Из того, что я вижу из спецификаций, все выглядит одинаково, кроме:

• память
• модели процессоров - если я не ошибаюсь, тесты будут показывать, что они должны быть похожими, и в таких случаях я бы предпочел коробку с меньшим количеством более быстрых ядер.