Отказ от ответственности : тот же совет относится ко всем услугам, поддерживающим скорость более 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 Гбит / с может быть излишним).
Это много вещей, которые можно настроить, некоторые из которых могут быть предметом небольшой книги. Весело проведите бенчмаркинг всего этого. Вернись, чтобы опубликовать результаты.
