Я хотів би дізнатися найкращу можливу конфігурацію / обладнання для доставки 40 Гбіт / с з одного сервера в цьому питанні.

Ситуація

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

Наразі на серверах зберігання резервних копій файли ростуть приблизно як 100TB файлів.

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

Мета

Досягнення 40 Гбіт / с або навіть більше пропускної здатності від однієї машини.

Обладнання 1

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

SSD: 1x 512GB Samsung, 2x 500GB Samsung, 2x480GB Intel 535, 1x 240GB Intel S3500

Система:

• irqbalancer зупинився
• set_irq_affinity для кожного інтерфейсу (через скрипт в ixgbe драйвер tarball)
• ixgbe-4.3.15
• Кінцевий термін роботи планувальника вводу / виводу
• iptables порожні (незавантажені модулі)
• Файлова система: XFS

Nginx:

• sendfile off
• aio нитки
• directio 1M
• tcp_nopush увімкнено
• tcp_nodelay увімкнено

Як видно з графіків, нам вдалося натиснути 12,5 Гбіт / с. На жаль, сервер не відповідав.

Є дві речі, які привернули мою увагу. Перший - це велика кількість IRQ. У цьому випадку у мене, на жаль, немає графіків з / proc / переривання. Друга річ - це високе завантаження системи, яке, на мою думку, було спричинене тим, що kswapd0 мав проблеми працювати лише з 16G оперативної пам’яті.

Обладнання 2

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

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

Це здається кращим, тому тепер, коли у нас є сервер, який працює в піках, ми можемо спробувати деякі оптимізації.

Sendfile vs aio теми

Я намагався вимкнути sendfile і використовувати замість нього потоки aio.

• sendfile off
• aio нитки
• directio 1M (що відповідає всім файлам, які ми маємо)

проти

• sendfile on

Потім о 15:00 я переключився на sendfile і перезавантажив nginx (так що знадобилося деякий час, щоб закінчити існуючі з'єднання). Приємно, що використання накопичувача (вимірюється йостатом) знизилося. У трафіку нічого не змінилося (на жаль, zabbix вирішив не збирати дані з bond0).

sendfile включено / вимкнено

Щойно спробував переключити надсилання / вимкнення. Нічого не змінилося, крім перепланування перерв.

irqbalancer як сервер / cron / disabled

Як згадував @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 (модулі 4x16GB), 13x SSD, 2x Supermicro (з мікросхемою Intel), мережеві карти. Нові процесори значно покращили продуктивність.

Залишається поточна установка - sendfile і т. Д. Різниця полягає лише в тому, що ми дозволяємо лише одному ЦП обробляти обидві мережеві карти (за допомогою сценарію set_irq_affinity).

Досягнуто ліміту 20 Гбіт / с.

Наступна мета? 30 Гбіт / с.

Не соромтеся знімати на мене ідеї, як покращити продуктивність. Я буду радий перевірити це в прямому ефірі і поділитися деякими важкими графіками тут.

Будь-які ідеї, як боротися з великою кількістю SoftIRQ на процесорі?

Це не питання щодо планування потужностей - у мене вже є обладнання та трафік. Я завжди можу розділити трафік на кілька серверів (що мені доведеться робити в майбутньому в будь-якому разі) і виправити проблему грошима. Це, однак, питання оптимізації системи та налаштування продуктивності в реальному реальному сценарії.

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

Те, що ви хочете зробити, - це неправильно, не робіть цього

Замість цього використовуйте CDN

CDN призначені для доставки вмісту, що підлягає збереженню, статичного вмісту. Використовуйте правильний інструмент для роботи (akamai, MaxCDN, cloudflare, cloudfront, ...)

Будь-який CDN, навіть безкоштовний, буде краще, ніж те, що ви можете досягти самостійно.

Натомість масштабуйте горизонтально

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

Тим не менш, існує багато жорстких обмежень щодо того, що може взяти один ящик. Вам слід віддати перевагу масштабуванню горизонтально.

Запустіть єдину коробку, спробуйте речі, виміряйте, орієнтир, оптимізуйте…, поки ця скринька не буде надійною та надійною та її можливості не будуть добре визначені, а потім поставте більше таких ящиків, як глобальний балансир навантаження спереду.

Є кілька варіантів глобального збалансування навантаження: більшість CDN може це зробити, DNS roundrobin, 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 Гбіт / с в мережі. Знаючи, чи дані надходять із кешу, і оптимізація кешу - це інша тема, вона в будь-якому випадку пересувається через провід.

Монокоррективні обмеження

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

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

У режимі HTTPS дешифрування / шифрування SSL є більш інтенсивним, ніж усе, що потрібно для проксі. SSL-трафік може і повинен бути розділений на кілька ядер.

SSL

Враховуючи, що ви робите все через SSL. Ви хочете оптимізувати цю частину.

Шифрування та розшифрування 40 Гбіт / с на льоту - це ціле досягнення.

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

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

IRQ і основне закріплення

Мережева карта генерує переривання (IRQ), коли з’являються нові дані для читання, і центральний процесор не має змоги негайно обробляти чергу. Це операція, що працює в ядрі та / або драйверах пристроїв, і це суворо монокорректор.

Це може бути найбільший споживач процесора, коли мільярди пакетів виходять у будь-який бік.

Призначте мережевій картці унікальний номер IRQ і закріпіть її на певному ядрі (див. Параметри Linux або BIOS).

Закріпити зворотний проксі-сервер до інших ядер. Ми не хочемо, щоб ці дві речі втручалися.

Ethernet Adapter

Мережева карта робить багато важких підйомів. Всі пристрої та виробники не рівні, коли мова йде про виступи.

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

TCP Offloading

TCP - це дуже інтенсивний протокол з точки зору обробки (контрольні суми, ACK, повторна передача, повторна збірка пакетів, ...) Ядро обробляє більшу частину роботи, але деякі операції можуть бути завантажені на мережеву карту, якщо вона підтримує її.

Ми не хочемо просто порівняно швидкої картки , а хочемо одну зі всіма дзвіночками.

Забудьте про Intel, Mellanox, Dell, HP, що завгодно. Вони не підтримують усе це.

На столі є лише один варіант: SolarFlare - таємна зброя фірм HFT і CDN.

Світ розділений на два види людей: " тих, хто знає SolarFlare " та " тих, хто цього не робить ". (перший набір суворо еквівалентний " людям, які працюють у мережі 10 Gbps та піклуються про кожен шматочок "). Але я відволікаюся, давайте зосередимось: 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).

NIC потужністю 40 Гбіт / с з одним портом Ethernet обіцяє більше, ніж шина PCIe, якщо роз'єм щонайменше 16x довжини в специфікаціях v3.0.

Інший

Ми могли б перейти інші межі. Справа в тому, що апаратні засоби мають жорсткі обмеження, притаманні закону фізики.

Програмне забезпечення не може робити краще, ніж обладнання, на якому він працює.

Магістральна мережа

Усі ці пакети зрештою повинні кудись поїхати, перемикаючи комутатори та маршрутизатори. Вимикачі та маршрутизатор на 10 Гбіт / с є [майже] товаром. 40 Gbps, безумовно, немає.

Крім того, пропускна здатність повинна бути від кінця до кінця, тому які посилання у вас є до користувача?

Минулого разу, коли я перевірив свого хлопця з центру даних щодо проекту, що займається 10-мільйонним користувачем, він зрозумів, що в Інтернеті буде не менше 2-х посилань на 10 Гбіт.

Жорсткі диски

iostat -xtc 3

Метричні показники розбиваються на читання та запис. Перевірте чергу (<1 - це добре), затримку (<1 мс - це добре) та швидкість передачі (чим вище, тим краще).

Якщо диск повільний, рішенням потрібно поставити більше І більшого SSD в рейді 10. (зауважте, що пропускна здатність SSD лінійно збільшується з розміром SSD).

Вибір процесора

IRQ та інші вузькі місця працюють лише на одному ядрі, тому націлюйте на процесор з найвищими одноядерними характеристиками (тобто найвищою частотою).

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

Вигода SSL від декількох ядер, тому націлена на багато ядер.

Короткий короткий огляд: Ідеальний процесор - це найновіший з найвищою доступною частотою та багатьма ядрами. Просто виберіть найдорожче, і це, мабуть, все: D

sendfile ()

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
...

Одна річ була прив’язана до одного процесора. Це шлях.

Один НІК, що веде до зовнішнього світу. Один NIC, що веде до внутрішньої мережі. Розбиття обов'язків завжди добре (хоча подвійний NIC з 40 Gbps може бути надмірним).

Це дуже багато тонких налаштувань, деякі з яких можуть бути предметом невеликої книги. Розважайте тестування всього цього. Поверніться, щоб опублікувати результати.

Я ще не можу коментувати через репутацію, тому замість цього потрібно додати відповідь ...

У першому прикладі ви сказали:

Є дві речі, які привернули мою увагу. Перший - це велика кількість IRQ. У цьому випадку у мене, на жаль, немає графіків з / proc / переривання. Друга річ - це високе завантаження системи, яке, на мою думку, було спричинене тим, що kswapd0 мав проблеми працювати лише з 16G оперативної пам’яті.

Абсолютно згоден, що це важливі моменти.

1. Спробуйте скористатися засобом збирання, який може збирати IRQ та зберігати за допомогою RRD.

2. Чи є у вас діаграма використання пам'яті?

   Хоча на поверхні це виглядає як проблема з процесором, високий softirq% може просто вказати пальцем на пам'ять, якщо відбувається багато важких або м'яких помилок сторінки. Я думаю, що віддача - це раптова ескалація IRQ, за рахунок системного процесора близько 19:00.

Як я бачу з специфікацій, все виглядає окрім:

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