Щодня через мережу 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
центральний процесор
Intel Xeon E5-2630 v3
Intel Xeon E5-2630 v4
Intel Xeon Silver 4116
Intel Xeon Platinum 6162
Фізичні ядер
2 х 8
2 х 10
2 х 12
2 х 24
TDP
2 х 85W
2 х 85W
2 х 85W
2 х 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
центральний процесор
Xeon Platinum 6162
EPYC 7642
Мікроархітектура
"Skylake"
"Дзен 2"
кодове ім'я
"Skylake SP"
"Rome"
Техпроцес
14nm
7nm
Ядер
2 х 24
48
частота
1.9 ГГц
2.4 ГГц
L3 Cache / socket
24 x 1.375MiB
16 x 16MiB
Memory / socket
6 каналів, до DDR4-2400
8 каналів, до DDR4-3200
TDP
2 х 150W
225W
PCIe / socket
48 смуг
128 смуг
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