Нам выпала возможность прикоснуться к заморской диковинке — ARM-серверу Huawei TaiShan. В удалённом формате эти машины предоставляются для теста в рамках Selectel Lab. Ввиду отсутствия физического доступа и наличия ограничений по времени мы не будем вдаваться глубоко в детали, а окинем платформу взглядом свысока. Как если бы это был обыкновенный выделенный сервер где-то в облаке. Но он как раз не обыкновенный:

• 2 × HiSilicon Kunpeng 920-7260: 64 ядра, 2,6 ГГц, L3-кеш 64 Мбайт, TDP 195 Вт;
• 512 Гбайт RAM: 16 × 32 Гбайт DDR-2933 ECC;
• RAID-контроллер LSI SAS3508;
• 12 × SAS3 10k HDD 1,2 Тбайт;
• 2 × сетевых контроллера Huawei TM210 (LOM, 4 × 1GbE RJ-45);
• 2 × сетевых контроллера Huawei IN200 SP580 (PCIe, 4 × 25GbE SFP28);
• 2 × БП 2 кВт.

Серверы Huawei TaiShan

Серия серверов Huawei TaiShan является относительно новой только для нас. На родном, китайском рынке они активно использовались уже давно, в том числе в собственном облаке Huawei Cloud, ещё до всей этой истории с запретами. Впрочем, разрыв отношений с крупными американскими производителями чипов только подстегнул развитие собственной аппаратной платформы. И если дальнейшая поддержка x86-систем остаётся под вопросом, то для текущей ARM-платформы, на которую переведены и другие продукты компании, будущее пока видится неплохим, если доступ к фабрикам не будет перекрыт.

Причём речь идёт именно о платформе. Во-первых, есть несколько базовых вариантов — от одного до четырёх сокетов, включая и «лезвия». На их основе создаются конфигурации под различные задачи: от edge-систем до высокоплотных серверов. На той же базе работают и все последние СХД компании. Во-вторых, Huawei избрала стратегию совместной работы с партнёрами на разных рынках, так что базовые варианты могут быть до определённой степени доработаны под локальные нужды. Например, мы уже писали про работу НОРСИ-ТРАНС. На текущем этапе для одного из базовых шасси TaiShan сделана собственная дисковая корзина, бекплейн и соответствующие модификации ПО.

У нас на тесте оказался сервер TaiShan 200 2280 v2. Это сбалансированная модель, как её называет сам производитель, в шасси высотой 2U (3D-модель). Штатная дисковая корзина предлагается в трёх версиях: 12 × 3,5” SAS/SATA, 24/25 × 2,5” SAS/SATA, 8 × 2,5” SAS/SATA + 12 × 2,5” NVMe. RAID тут сторонний — LSI SAS3x08 с опциональным BBU. В списке совместимых также есть модели Microsemi PM82xx и LSI 94x0-8i. Штатный контроллер выполнен в виде мезонина, так что PCIe-слот он не занимает. Для установки иных карт расширения — Infiniband, Ethernet, Fibre Channel, HBA, SSD — в шасси предусмотрено три IO-модуля. Максимум можно получить или 8 слотов PCIe 4.0 x8, или 3 слота PCIe 4.0 x16 + 2 слота PCIe 4.0 x8.

Но вообще различных вариантов компоновки IO-модулей немало. Есть варианты для установки дополнительных накопителей 2,5”/3,5”, есть и комбинированные платы, а не просто райзеры. Так что лучше ознакомиться с документацией, чтобы понять возможные сочетания. С LOM-картами, которые тут зовутся FlexIO, дело обстоит проще. Для них есть два слота — и типов модулей тоже два. Huawei TM210 включает четыре 1GbE-порта RJ-45, TM280 — четыре порта 10/25GbE SFP28. Между слотами FlexIO находится блочок с портами iBMC.

Блоков питания 80+ Platinum, как обычно, два (1+1) — мощностью до 2 кВт каждый. Хотя базовая платформа потребляет не так уж много, в чём мы убедимся далее. При этом из документации совершенно не ясно, есть ли у БП кабели дополнительного питания для карт расширения. С другой стороны, в списке совместимых «GPU», например, присутствует только ускоритель Atlas 300 на базе чипа Ascend 310, которому достаточно тех 75 Вт, которые даёт слот PCIe.

В целом шасси, быть может, слегка непривычное, но вполне современное. Открытым остаётся вопрос совместимости оборудования, не перечисленного в документации, но за ответом на него Huawei предлагает обращаться к локальным представителям. Опять же, если рассматривать TaiShan как платформу, то под конкретные задачи она вполне может быть «допилена» для поддержки необходимых аппаратных компонентов.

HiSilicon Kunpeng 920

Процессоры Kunpeng 920 были официально представлены в начале прошлого года, хотя мы их видели ещё в 2018 году под именем HiSilicon Hi1620. И на тот момент компания заявляла, что это самые производительные ARM-чипы в мире: 7-нм техпроцесс TSMC, от 24 до 64 ядер ARMv8.2-A с частотой 2,6 ГГц, по 1 Мбайт L3-кеша на каждое ядро, 40 линий PCIe 4.0 с поддержкой CCIX, 4 или 8 каналов DDR4-2933 ECC (до 2 Тбайт RAM суммарно).

Есть возможность создания бесшовных двух- и четырёхсокетных конфигураций посредством шины Hydra (30 ГТ/с, 240 Гбит/с), по три линии которой имеется у каждого CPU. Сам процессор состоит из чиплетов и включает также два блока 100GbE с RoCEv1/v2, 16 каналов SAS 3.0, два канала SATA-III и четыре порта USB 3.0. И всё это в BGA-упаковке, то есть замена только CPU в случае его выхода из строя, а не платы целиком не предусмотрена.

Набор возможностей очень неплохой, а на момент анонса — так и вовсе впечатляющий. Но сейчас картину слегка портит TDP — теплопакет старшей модели приближается к 200 Вт. Вышедшие в августе AMD EPYC Rome остудили пыл любителей предрекать скорую и неминуемую кончину x86-64. Впрочем, в микроархитектурные подробности мы закапываться сейчас не будем.

Отметим лишь некоторую неразбериху в маркировке процессоров. В документации и промоматериалах используются индексы 7260, 52x0 и 3210, указывающие на разное число ядер и каналов памяти. Для серии TaiShan доступны и CPU Kunpeng 916 (они же HiSilicon Hi1616). Однако и в BIOS, и в других местах используется иная нумерация. В частности, наш Kunpeng 920-7260 был обозначен как 920-6426. Две последние пары цифр указывают на число ядер и частоту. Да, о динамической регулировке частоты ничего не говорится.

BIOS и iBMC

BIOS может показаться на первый взгляд слегка бедноватым на опции, но это скорее от непривычки — просто потому, что он другой. Особенность современных ARM-платформ в том, что «классический» BIOS им и не нужен, только UEFI. И ARM пришлось приложить усилия, запустив отдельную программу ServerReady, направленную на повышение совместимости оборудования, UEFI и драйверов, прошивок и ПО и так далее. Проще говоря, довести состояние серверных платформ до того же уровня, что имеется у x86.

Для корректного запуска инсталлятора ОС с ISO-образа пришлось поменять только один параметр. Ну и заодно проверили, что политика питания выставлена в положение Performance («Производительность»). Остальные настройки оставлены в изначальном виде. Отдельно стоит отметить, что по умолчанию используется NUMA (четыре домена), но распределение доменов можно перенастроить.

Опять же iBMC (Intelligent Baseboard Management System) выглядит слегка непривычно, но на поверку оказывается весьма продвинутой системой удалённого управления и мониторинга платформы. Ознакомиться с её возможностями можно с помощью симулятора. В нём реализована не стопроцентная функциональность, но общее представление составить можно.

Из любопытных и полезных возможностей можно отметить интеграцию с LDAP, поддержку многопользовательской работы, двухфакторную аутентификацию (сертификат + пароль), хорошие функции мониторинга и уведомлений об инцидентах, а также сбора данных, включая скриншоты и видеозапись. Правда, для наблюдения за некоторыми параметрами необходимо устанавливать драйверы и ПО уже в самой ОС.

Для управления есть RMCP/RMCP+, в документации также упоминается Redfish, а для iKVM предоставляются классический Java-апплет и HTML5-консоль. Имеется даже VNC. В HTML5-консоли есть поддержка образов ISO/FDD и передачи клавиатурных комбинаций — быть может, не слишком уж комфортно, но управлять машиной удалённо можно.

Для совместимых устройств есть не только отображение параметров, но и управление ими. В частности, собрать массив на RAID-контроллере можно и в веб-интерфейсе (ну или в BIOS). В нашем случае это был LSI SAS3508 вместе с двенадцатью SAS3-дисками Seagate EXOS 10E2400 — ST1200MM0009, согласно данным iBMC. Накопители были собраны в три массива: два «зеркала» из двух дисков для ОС + один RAID-10 под хранение данных из оставшихся восьми.

Ну а интереснее всего в iBMC наблюдать за графиками энергопотребления сервера почти в реальном времени. Huawei упирает в числе прочего и на экономичность TaiShan в сравнении с другими платформами — на главной странице iBMC даже показывается, сколько было сэкономлено энергии и насколько был уменьшен «углеродный след». В нашем же случае максимальное пиковое потребление вплотную приближалось к 600 Вт, а минимальное среднее было чуть больше 360 Вт.

Установка Linux и ПО

В разработке и портировании ПО Huawei во многом полагается на партнёров и просто сторонних разработчиков, которых компания готова стимулировать и финансово. Среди российских дистрибутивов над поддержкой TaiShan работают Alt Linux, Astra Linux и РЕД ОС. Сама Huawei подготовила бесплатный дистрибутив openEuler на базе коммерческой EulerOS, основанной, в свою очередь, на CentOS/RHEL. Поддержки иных ОС и гипервизоров, кроме Linux-based, нет.

Первый релиз openEuler 20.03 LTS вышел в марте, так что при поиске решений проблем или вопросов найти ответы зачастую можно только на китайских форумах или в сообществе самой Huawei. Формального списка совместимых дистрибутивов нигде нет, но в документации приведены инструкции для Ubuntu 18.04 (c HWE-ядром), SLES 15 и CentOS 7.6. Впрочем, AArch64-сборки популярных дистрибутивов выпускаются уже несколько лет.

Для теста были выбраны openEuler 20.30 как официальный дистрибутив, который имеет ряд оптимизаций под Kunpeng 920 «из коробки», и Ubuntu 19.10 с последующим обновлением «на живую» до 20.04 (вышла после начала тестирования), которые имеют достаточно свежие ядра.

Установка Ubuntu 19.10 с ISO-образа посредством iKVM прошла гладко. Сетевые интерфейсы были определены корректно, так что, наверное, можно было бы обойтись и netinstall-версией. Для работы ничего дополнительно настраивать не пришлось. Дальнейшее обновление штатными средствами до 20.04 тоже прошло успешно, если не считать нескольких потерянных симлинков и параметров, которые исправляются парой команд. И это вряд ли вина платформы. В отличие от openEuler, ядро про имя модели CPU ничего не знало, что, впрочем, на работоспособности не отразилось. Все ОС показывали странный размер L3-кеша.

Установка openEuler тоже прошла без особых приключений. После пришлось вручную прописывать репозитории в настройках, так как по умолчанию не было указано ни одного, а документация вообще рекомендует использовать в качестве основного источника ISO-образ установочного DVD. Были использованы только официальные репозитории проекта. И тут нас поджидало первое и, в общем, вполне ожидаемое лёгкое разочарование.

Со своим EPOL дистрибутив явно пытается догнать EPEL по числу готовых пакетов, но пока это не совсем получается. Для ряда пакетов можно найти какую-то альтернативу, для других — нет. Впрочем, большая часть базового ПО, на первый взгляд, там есть, но что-то всё равно придётся собирать самостоятельно.

Тестирование

Для тестирования использовался пакет Phoronix Test Suite 9.6 (PTS). Как обычно, для раздела самой ОС использовалась ext4, а /var, откуда и запускались все тесты, лежала на втором разделе c xfs. Опции монтирования не менялись, но в случае openEuler по настоянию PTS для I/O-планировщика BFQ была отключена опция low_latency, так как она отдаёт приоритет задержке в ущерб пропускной способности, что нам не очень-то и нужно. В Ubuntu 19.10 и 20.04 использовались штатные generic-ядра веток 5.3 и 5.4 соответственно, а комплектный набор компиляторов включал GCC 9.2.1 и 9.3.0.

Для openEuler в комплекте шли собственное ядро 4.19 и GCC 7.3.0. Среди особенностей релиза отмечается наличие оптимизаций библиотек, самого ядра и OpenJDK. Про какие-то фирменные патчи штатного компилятора отдельно ничего не говорится, хотя это была бы просто идеальная связка, так как PTS как раз собирает всё ПО локально из исходных кодов. За основу мы взяли прошлогодний набор тестов AMD EPYC 7002.

Естественно, итоговый набор тестов отличался, но по совершенно разным причинам. Какие-то пакеты ПО в принципе не предназначены для AArch64, и с ними как раз проще всего — их не нужно даже пытаться собрать. С другими же всё может быть сложнее. Для части софта довольно быстро выяснилось, что он активно использует библиотеки и оптимизации строго под x86-64, так что он просто не собирается.

Другая часть такой жёсткой привязки может и не иметь, но проблемы со сборкой всё равно есть. Где-то не хватает буквально одного #define, где-то прописан неподходящий ключ для компилятора. В случае мелкого проекта это легко поправить вручную. В случае большого, где даже несколько Makefile на тысячу строк уже собираются скриптами, это сомнительное удовольствие. При этом различаются не только ключи компилятора: другие утилиты тоже могут не принимать некоторые параметры.

Наконец, самое неприятное — когда ПО собирается, но не работает, не выдавая результатов или падая с ошибкой. Особенно тогда, когда это происходит не сразу же после запуска. И если кажется, что интерпретируемых языков это не касается, то увы — каких-то модулей или библиотек может и не оказаться. Со всеми этими особенностями нам пришлось столкнуться. Хуже всех с точки зрения сборки программ оказался openEuler, в том числе в силу отсутствия ряда ПО в репозиториях.

С другой стороны, openEuler же в итоге оказался и лидером в 61 % сделанных тестов. Правда, в среднем и разница не так велика — на 5% быстрее Ubuntu 19.10 и на 1% быстрее 20.04, — и распределение неравномерное. Например, продукт Canonical лидировал при работе с накопителем и СУБД, а разработка Huawei лучше показала себя в тестах компиляции, при работе с памятью и в Java. При этом были и просто существенные разрывы, и пиковые выбросы. В частности, в Stream openEuler оказался почти в два раза медленнее, но в CacheBench запись была вдвое быстрее. Рендеринг в Java — в три раза быстрее. А вот нативные рендер-движки почти одинаковые по скорости.

В целом можно сказать, что работать в Ubuntu оказалось приятнее и проще. Хотя бы потому, что не пришлось собирать или искать бинарные файлы необходимых вспомогательных утилит для работы самого PTS. Полные результаты представлены в этом файле. Отдельно отметим, что относиться к ним надо именно как к предварительным тестам. Хотелось бы посмотреть через годик, насколько расширится пакетная база openEuler и какие средства разработки будут идти в комплекте. Увы, на этот раз пришлось оставить в стороне виртуализацию и контейнеризацию, а также систему интеллектуального профилирования A-Tune .

А вот с KAE, аппаратным ускорителем, модули и библиотеки для которого есть в openEuler, вышло любопытно. KAE поддерживает китайские алгоритмы SM3/SM4 и более распространённые RSA/AES, а также операции (де)компресии и некоторые другие. Нормальная документация пока есть только на китайском, а на английском она ограничивается лишь описанием операций шифрования. Для работы требуется лицензия, которой у нас не было. Но, похоже, ускорение AES работает и так. Во всяком случае, с параметрами из примеров для блоков до 256 Кбайт с движком KAE почти четырёхкратная разница в скорости действительно есть.

Чтобы хоть примерно прикинуть, как Kunpeng 920 выглядят на фоне AMD EPYC и Intel Xeon, сравним наши тесты вот с этим результатом — совпадающих по версии тестовых пакетов тоже оказалось совсем немного, так что окончательные выводы делать по ним не стоит. Из общей массы были выбраны несколько процессоров, которые наиболее близки по числу потоков, а не только ядер, так как Kunpeng не поддерживает SMT. В итоге получился такой набор:

• 2 × AMD EPYC 7601 (32/64, 2,2/3,2 ГГц, L3-кеш 64 Мбайт, TDP 180 Вт);
• 2 × AMD EPYC 7502 (32/64, 2,5/3,35 ГГц, L3-кеш 128 Мбайт, TDP 180 Вт);
• AMD EPYC 7742 (64/128, 2,25/3,4 ГГц, L3-кеш 256 Мбайт, TDP 225 Вт);
• 2 × Intel Xeon Platinum 8280 (28/56, 2,7/4,0 ГГц, L3-кеш 38,5 Мбайт, TDP 205 Вт);
• 2 × HiSilicon Kunpeng 920-7260 (64, 2,6 ГГц, L3-кеш 64 Мбайт, TDP 195 Вт).

Можно посмотреть и небольшое сравнение с нашими прошлогодними результатами тестов AMD EPYC 7742, которые близки по духу текущим данным в том смысле, что тогда на момент тестирования не были готовы все патчи для ядра и компиляторов. Естественно, EPYC оказался мощнее — Kunpeng под управлением openEuler в среднем на четверть медленнее. Полные результаты сравнения представлены в этом файле.

Заключение

В целом по итогам краткого знакомства платформа нам приглянулась. Дело осталось за ма… Нет, на за малым, а за массовой оптимизацией ПО и развитием средств разработки. В рамках openEuler, в частности, в планах значатся дальнейшая оптимизация OpenJDK, переезд на GCC 9.3.0 и работа над LLVM. Все наработки обещают отдавать в основные ветки проектов. В этом деле частично должны помочь выпуск и массовое распространение дешёвых плат на процессорах попроще.

У нас осталась одна, но очень важная неизвестная — цена. И цена не только за «железо», но и — по крайней мере сейчас — цена за перенос ПО. TaiShan, если верить открытым источникам и обещаниям производителя, обходится дешевле аналогичных массовых 2S-решений x86-64 (с 4S и блейдами ситуация иная). Для единичного сервера это не так критично, но в масштабах от стойки и далее уже может быть интересно. И потенциальная экономия в том или ином виде — это, на наш взгляд, пока единственный разумный аргумент в пользу ARM. Околополитические истории про импортозамещение или безопасность не в счёт.

Huawei была буквально вынуждена перейти на другую архитектуру, но сможет ли она потянуть за собой остальной мир? Когда SMB-пользователи, придя в магазин, крепко задумаются, не стоит ли взять ARM-сервер? Вряд ли скоро. Пока что очевидная стратегия — адаптация под конкретные проекты, задачи и нагрузки заинтересованных заказчиков, а также развитие сообщества.

P.S.: материал был подготовлен до введения очередного пакета ограничений, который может коснуться TSMC, где производятся процессоры HiSilicon Kunpeng.