Ежедневно через сеть Cloudflare Network проходит более миллиарда уникальных IP-адресов; она обслуживает более 11 млн HTTP-запросов в секунду; она находится на расстоянии не более 100 мс от 95% интернет-населения. Наша сеть раскинулась на 200 городов в более чем 90 странах, а наша команда инженеров построила чрезвычайно быструю и надёжную инфраструктуру.
Мы очень гордимся нашей работой и настроены помочь сделать интернет лучше и безопаснее. Инженеры Cloudflare, чья работа связана с железом, тщательно разбираются в серверах и их компонентах, чтобы хорошо понять и выбрать наилучшее оборудование для максимизации его эффективности.
Наш программный стек обрабатывает высоконагруженные вычисления и очень зависит от скорости CPU, из-за чего нашим инженерам приходится постоянно оптимизировать эффективность и надёжность Cloudflare на всех уровнях стека. На стороне сервера проще всего увеличить вычислительную мощность, добавив ядер CPU. Чем больше ядер можно уместить в сервере, тем больше он сможет обрабатывать данных. Для нас это важно, поскольку разнообразие наших продуктов и клиентов со временем растёт, и рост запросов требует от серверов увеличения производительности. Чтобы увеличить их производительность, нам требовалось увеличить плотность ядер – и именно эту задачу мы выполнили. Ниже приводим детализацию данных по процессорам для серверов, разворачиваемых нами с 2015 года, включая и количество ядер:
—
Gen 6
Gen 7
Gen 8
Gen 9
Начало работы
2015
2016
2017
2018
CPU
Intel Xeon E5-2630 v3
Intel Xeon E5-2630 v4
Intel Xeon Silver 4116
Intel Xeon Platinum 6162
Физических ядер
2 x 8
2 x 10
2 x 12
2 x 24
TDP
2 x 85W
2 x 85W
2 x 85W
2 x 150W
TDP на ядро
10.65W
8.50W
7.08W
6.25W
В 2018 году мы сделали большой скачок в общем количестве ядер на один сервер с 9-м поколением. Влияние на окружающую среду было уменьшено на 33% по сравнению с 8-м поколением, что дало нам возможность увеличить объёмы и вычислительные мощности в пересчёте на стойку. Конструктивные требования по теплоотводу (, TDP) упомянуты, чтобы подчеркнуть, что наша энергоэффективность со временем также росла. Этот показатель важен для нас: во-первых, мы хотим выделять в атмосферу меньше углерода; во-вторых, мы хотим наилучшим образом использовать энергию дата-центров. Но мы знаем, что у нас есть, к чему стремиться.
Основная наша определяющая метрика – это число запросов на ватт. Можно увеличить количество запросов в секунду, добавив ядер, однако нам нужно оставаться в рамках нашего энергетического бюджета. Нас ограничивает инфраструктура питания дата-центров, которая совместно с нашими избранными модулями распределения энергии даёт нам определённую верхнюю границу для каждой серверной стойки. Добавление серверов в стойку увеличивает энергопотребление. Операционные расходы серьёзно возрастут, если мы выйдем за ограничение энергии на стойку и нам придётся добавлять новые стойки. Нам нужно увеличить вычислительную мощность, оставаясь в том же диапазоне энергопотребления, что увеличит число запросов на ватт – нашу ключевую метрику.
Как вы могли догадаться, мы тщательно изучали энергопотребление ещё на этапе проектирования. Из таблицы выше видно, что нам не стоит тратить время на развёртывание более жадных до энергии CPU, если TDP на ядро будет выше, чем у текущего поколения – это негативно скажется на нашей метрике, числе запросов на ватт. Мы тщательно изучили готовые к работе системы для нашего поколения Х, представленные на рынке, и приняли решение. Мы переходим с нашей схемы с 48-ю ядрами Intel Xeon Platinum 6162 и двумя сокетами на 48-ядерный AMD EPYC 7642 с одним сокетом.
—
Intel
AMD
CPU
Xeon Platinum 6162
EPYC 7642
Микроархитектура
“Skylake”
“Zen 2”
Кодовое имя
“Skylake SP”
“Rome”
Техпроцесс
14nm
7nm
Ядер
2 x 24
48
Частота
1.9 GHz
2.4 GHz
L3 Cache / socket
24 x 1.375MiB
16 x 16MiB
Memory / socket
6 каналов, до DDR4-2400
8 каналов, до DDR4-3200
TDP
2 x 150W
225W
PCIe / socket
48 lanes
128 lanes
ISA
x86-64
x86-64
Из спецификаций видно, что чип от AMD позволит нам оставить то же количество ядер, понизив TDP. У 9-го поколения показатель TDP на ядро был 6,25 Вт, а у Х-го поколения это будет 4,69 Вт. Понижение на 25%. Благодаря увеличению частоты, и, возможно, более простой схеме с одним сокетом, можно предположить, что чип от AMD покажет себя в деле лучше. Пока мы проводим различные тесты и симуляции, чтобы понять, насколько лучше покажет себя AMD.
А пока отметим, что TDP – это упрощённая метрика из спецификаций производителя, которую мы использовали на ранних стадиях проектирования серверов и выбора CPU. Быстрый поиск в Google демонстрирует, что AMD и Intel по-разному подходят к определению TDP, из-за чего эта спецификация не является надёжной. Реальное потребление энергии CPU, и, что ещё важнее, потребление энергии сервером – вот, что мы реально используем при принятии окончательного решения.
Готовность экосистемы
В начале нашего пути к выбору следующего процессора мы изучили большой ассортимент CPU от разных производителей, хорошо подходивших для нашего программного стека и сервисов (написанных на C, LuaJIT и Go). Мы уже подробно описывали набор инструментов для измерения скорости . В данном случае мы использовали тот же набор – он позволяет за разумное время оценить эффективность CPU, после чего наши инженеры могут начинать приспосабливать наши программы к конкретному процессору.
Мы испытали различные процессоры с разнообразным количеством ядер, сокетов и частот. Поскольку в данной статье мы описываем, почему мы остановились на AMD EPYC 7642, все графики в данном блоге концентрируются на том, как показывают себя процессоры от AMD по сравнению с Intel Xeon Platinum 6162 из .
Результаты соответствуют измерениям работы одного сервера с каждым из вариантов процессоров – то есть, с двумя 24-ядерными процессорами от Intel, либо с одним 48-ядерным процессором от AMD (сервер для Intel с двумя сокетами и сервер для AMD EPYC с одним). В BIOS мы выставили параметры, соответствующие работающим серверам. Это 3,03 ГГц для AMD и 2,5 ГГц для Intel. Очень сильно упрощая, мы ожидаем, что при одинаковом количестве ядер AMD покажет результаты на 21% лучше, чем у Intel.
Криптография
Выглядит многообещающе для AMD. На криптографии с публичным ключом он работает на 18% лучше. С симметричным ключом он проигрывает для вариантов шифрования AES-128-GCM, но в целом показывает себя сравнимо.
Сжатие
На edge-серверах мы сжимаем много данных, чтобы экономить на пропускной способности и увеличивать скорость доставки контента. Мы пропускаем данные через С-библиотеки zlib и brotli. Все тесты проходили на HTML-файле blog.cloudflare.com в памяти.
AMD победил в среднем на 29% при использовании gzip. В случае с brotli результаты ещё лучше, на тестах с качеством 7, которые мы используем для динамического сжатия. На тесте brotli-9 происходит резкое падение – мы объясняем это тем, что Brotli потребляет очень много памяти и переполняет кэш. Тем не менее, AMD выигрывает с большим отрывом.
Многие наши сервисы написаны на Go. На следующих графиках мы перепроверяем скорость криптографии и сжатия на Go с RegExp на строчках длиной 32 КБ с использованием библиотеке strings.
Go криптография
Go Сжатие
Go Regexp
Go Strings
AMD показывает лучшие результаты во всех тестах с Go кроме ECDSA P256 Sign, где он отстал на 38% — что странно, с учётом того, что на С он показал результат на 24% лучше. Стоит разобраться, что там происходит. А в целом, AMD выигрывает не сильно, но всё же показывает лучшие результаты.
LuaJIT
Мы часто используем LuaJIT в стэке. Это клей, удерживающий все части Cloudflare. И мы рады, что AMD и здесь выиграл.
В целом тесты показывают, что EPYC 7642 работает лучше, чем два Xeon Platinum 6162. На паре тестов AMD проигрывает – к примеру, AES-128-GCM и Go OpenSSL ECDSA-P256 Sign – однако на всех других побеждает, в среднем на 25%.
Симуляция рабочей нагрузки
После наших экспресс-тестов мы прогнали сервера через другой набор симуляций, в которых синтетическая нагрузка применяется к программному edge-стеку. Здесь мы симулируем рабочую нагрузку сценариев с различными типами запросов, которые можно встретить в реальной работе. Запросы разнятся по объёму данных, протоколам HTTP или HTTPS, источникам WAF, Workers, и прочим из множества переменных. Ниже показано сравнение пропускной способности у двух CPU для тех типов запросов, которые встречаются у нас наиболее часто.
Результаты на диаграмме измеряются по базовым показателям 9-го поколения машин с процессорами Intel, нормализованным до значения 1,0 по оси х. К примеру, взяв простые запросы объёмом 10 КиБ по HTTPS, мы можем видеть, что AMD справляется в 1,5 раз лучше Intel по количеству запросов в секунду. В среднем для приведённых тестов AMD справилась на 34% лучше, чем Intel. Учитывая, что TDP для единственного AMD EPYC 7642 равны 225 Вт, а для двух процессоров Intel – 300 Вт, получается, что по показателю «запросов на ватт» AMD показывает в 2 раза лучшие результаты, чем Intel!
К этому моменту мы уже явно склонялись к варианту с одним сокетом для AMD EPYC 7642 в качестве наших будущих CPU для поколения Х. Нам было очень интересно узнать, как сервера AMD EPYC поведут себя в реальной работе, и мы сразу же отправили несколько серверов в некоторые из дата-центров.
Реальная работа
Первым делом, естественно, нужно было подготовить сервера к работе в реальных условиях. Все машины нашего парка работают с одними и теми же процессами и сервисами, что даёт прекрасную возможность корректно сравнивать быстродействие. Как в большинстве дата-центров, у нас развёрнуто несколько поколений серверов, и мы собираем наши сервера в кластеры так, чтобы в каждом классе содержались сервера примерно одинаковых поколений. В некоторых случаях это может привести к тому, что кривые утилизации будут различаться между кластерами. Но не у нас. Наши инженеры оптимизировали утилизацию CPU для всех поколений так, чтобы вне зависимости от того, 8 ядер у CPU конкретной машины или 24, использование CPU обычно не отличается от остальных.
График иллюстрирует наш комментарий по схожести утилизации – не видно значительной разницы между использованием CPU от AMD в серверах поколения Gen X и использования процессоров Intel в серверах поколения Gen 9. Это означает, что и тестовые, и базовые серверы нагружены одинаково. Отлично. Именно этого мы и добиваемся в работе наших серверов, и это нужно нам для честного сравнения. Два графика ниже показывают количество запросов обработанных одним ядром CPU и всеми ядрами на уровне сервера.
Запросов на ядро
Запросов на сервер
Видно, что в среднем AMD обрабатывает на 23% запросов больше. Совсем неплохо! Мы в своём блоге часто писали о способах увеличения производительности Gen 9. И вот у нас совпадает количество ядер, однако AMD проделывает больше работы с меньшими энергозатратами. Сразу из спецификаций по количеству ядер и TDP видно, что AMD выдаёт большую скорость с большей энергоэффективностью.
Но, как мы уже упоминали, TDP – это не стандартная спецификация, и она не едина для всех производителей, поэтому давайте посмотрим на реальное использование энергии. Измерив потребление энергии сервером параллельно с количеством запросов в секунду, мы получили следующий график:
По количеству запросов в секунду на потраченный ватт сервер Gen X на процессорах AMD работает на 28% эффективнее. Можно было ожидать и большего, учитывая что у AMD TDP на 25% ниже, однако следует помнить, что TDP – характеристика неоднозначная. Мы видели, что реальное потребление энергии у AMD практически совпадает с указанными TDP при частоте, сильно превышающей базовую; у Intel такого нет. Это ещё одна причина, по которой TDP не является надёжной оценкой энергопотреления. CPU от Intel в наших серверах Gen 9 интегрированы в мультинодную систему, а от AMD работают в стандартных серверах форм-фактора 1U. Это говорит не в пользу AMD, поскольку мультинодные сервера должны обеспечивать большую плотность при меньшем потреблении энергии на одну ноду, однако AMD всё равно обогнала Intel по показателю потребления энергии на ноду.
В большинстве сравнений по спецификациям, испытательным симуляциям и реальной работе, конфигурация 1P AMD EPYC 7642 показала себя значительно лучше, чем 2P Intel Xeon 6162. В некоторых условиях AMD может работать на 36% лучше, и мы считаем, что оптимизировав железо и программы, мы сможем достичь такого улучшения на постоянной основе.
Получается, AMD выиграла.
На дополнительных графиках показаны средняя задержка и задержка p99 в работе NGINX в течение 24 часов. В среднем процессы на AMD работали на 25% быстрее. На p99 он работает на 20-50% быстрее в зависимости от времени суток.
Заключение
Инженеры отдела оборудования и быстродействия в Cloudflare проделывают значительные объёмы испытательной и исследовательской работы чтобы выбрать наилучшую конфигурацию серверов для наших клиентов. Нам нравится работать здесь потому, что мы можем решать такие грандиозные задачи, а также помогаем вам решать ваши задачи при помощи таких сервисов, как бессерверные edge-вычисления и массива решений задач по безопасности, в частности, Magic Transit, Argo Tunnel и защиты от DDoS. Все сервера в сети Cloudflare настроены на надёжную работу, и мы всегда пытаемся сделать каждое следующее поколение серверов лучше предыдущего. Мы считаем, что AMD EPYC 7642 является ответом на вопрос о выборе процессоров для Gen X.
При помощи сервиса Cloudflare Workers разработчики развёртывают свои приложения в нашей сети, расширяющейся по всему миру. Мы с гордостью предоставляем нашим клиентам возможность сконцентрироваться на написании кода, пока мы занимаемся безопасностью и надёжностью в облаке. И сегодня нам ещё более радостно сообщить, что их работа будет развёрнута на наших серверах поколения Gen X, работающих под управлением процессоров AMD EPYC второго поколения.
Процессоры EPYC 7642, кодовое имя «Rome» [Рим]
Благодаря использованию EPYC 7642 от AMD мы смогли увеличить наше быстродействие и облегчить расширение сети на новые города. Рим строился не за один день, однако скоро он окажется ближе ко многим из вас.
В последние пару лет мы экспериментировали со многими x86-чипами от Intel и AMD, а также с процессорами от ARM. Мы ожидаем, что и в будущем эти производители CPU будут работать совместно с нами, чтобы мы все вместе могли строить улучшенный интернет.
Источник: habr.com