сервер AMD

Если говорить про сервер AMD, до сих пор встречаю коллег, которые морщатся. Словно это что-то второсортное, для энтузиастов, а не для серьёзного дата-центра. Укоренилось это, наверное, ещё со времён Opteron, когда конкуренция была жёстче, а экосистема — слабее. Сам долгое время был в лагере скептиков, пока не пришлось вплотную столкнуться с проектом для одного из наших клиентов в госсекторе — бюджет был жёсткий, а задачи по вычислениям не самые типовые. Вот тогда и начался разговор про EPYC.

Почему EPYC перестал быть тёмной лошадкой

Первое, что бросается в глаза — количество ядер. Когда на одном сокете можно получить 64, а то и 96 ядер, это меняет экономику многих проектов. Не нужно городить два сервера там, где можно обойтись одним. Лицензирование ПО, кстати, часто привязано к сокетам, а не к ядрам — вот и первая существенная экономия для заказчика. Но сразу оговорюсь: не для всех workloads это панацея.

Второй момент — память. Каналов памяти у EPYC много, это факт. В теории это даёт огромную пропускную способность. На практике же всё упирается в приложение. Если оно жадно до памяти и не очень хорошо распараллеливается, выгода может быть не так очевидна. Помню, пытались запустить одну старую, но критически важную для клиента СУБД — пришлось долго ковыряться с настройками NUMA, чтобы выжать адекватную производительность. Без глубокого погружения в архитектуру приложения можно легко промахнуться.

И третий, самый жирный плюс — цена. Точнее, соотношение цена/производительность на поток. Для виртуализации среднего масштаба, для некоторых задач рендеринга или контейнеризированных сред — это часто решающий аргумент. Особенно для малого и среднего бизнеса, где каждый рубль на счету. Мы в ООО Чжунчуан Жуньцзинь (Пекин) Информационные Технологии как раз часто работаем с МСП, и для них этот экономический расчёт бывает первостепенным.

Где мы применяли и где спотыкались

Один из самых показательных кейсов был для интернет-провайдера. Нужно было развернуть платформу для виртуализации сетевых функций (NFVi). Требовалась высокая плотность vCPU и хорошая пропускная способность сети. Взяли за основу платформу на EPYC 7B13 (это облачные процессоры). Сетевую часть сделали на картах с поддержкой SR-IOV. Изначально всё шло хорошо, пока не упёрлись в драйверы для конкретного гипервизора. Пришлось катить не самые свежие, но стабильные ревизии, потеряли пару недель на согласованиях и тестах. Это общая болезнь — иногда поддержка со стороны вендоров софта отстаёт от железа.

Другой проект — система хранения на базе Ceph. Тут как раз сыграли на руку многоядерность и каналы памяти. OSD-ноды отлично встали, кластер показал себя с лучшей стороны по сравнению с альтернативами на других архитектурах в той же ценовой категории. Но пришлось самостоятельно тюнить параметры ядра Linux, особенно касающиеся планировщика и работы с памятью. Готовых ?серебряных пуль? для сервер AMD в таких нишевых сценариях меньше, нужно быть готовым к кастомизации.

А вот для высоконагруженного transactional-сервера баз данных мы после нагрузочного тестирования всё же выбрали другую архитектуру. Латентность и предсказуемость отклика на пиковых нагрузках у конкурента в том конкретном тесте была стабильнее. Возможно, дело было в микрокоде или настройках BIOS, которые мы не до конца изучили, но времени на бесконечные эксперименты у клиента не было. Это к вопросу о том, что слепо гнаться за ядрами и мегагерцами нельзя — всё упирается в конечную задачу.

Про железо и вендоров: что есть на рынке

Сейчас с платформами стало проще. Крупные вендоры вроде Supermicro, ASUS предлагают хороший выбор материнских плат и готовых систем. Мы, например, в своих комплексных решениях иногда используем шасси от проверенных производителей, но собираем и конфигурируем под проект сами. Это позволяет точно попадать в требования по охлаждению и энергопотреблению, что для дата-центра клиента часто не менее важно, чем чистая производительность.

С памятью и дисками — история отдельная. Рекомендую не экономить и брать память из QVL списка материнской платы. С EPYC бывают капризы с не самой популярной памятью, особенно при полной загрузке слотов. Ошибки ECC, которые не ловятся сразу, а вылезают через месяц работы — это худший кошмар админа. Проходили это, теперь закупаем только проверенные модули.

С SSD тоже есть нюанс. Шина PCIe 4.0, а теперь уже и 5.0, которые поддерживают современные EPYC, — это здорово. Но чтобы раскрыть её потенциал, нужны соответствующие накопители. Часто клиенты хотят сэкономить и ставят PCIe 3.0, создавая бутылочное горлышко в системе. Приходится объяснять, что мощный процессор — это только часть уравнения.

Подход нашей компании к решениям на AMD

В ООО Чжунчуан Жуньцзинь мы не продвигаем какую-то одну архитектуру как универсальную. Наши инженеры исходят из технического задания и экономических рамок клиента. Если проект подходит под сильные стороны AMD — а это высокая плотность ядер, выгодная цена за поток и сильная масштабируемость в памяти — мы предлагаем этот вариант. На нашем сайте itbktech.ru можно увидеть, что спектр наших аппаратных решений широк, и серверные платформы — лишь одна его часть.

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

Ключевое для нас — устойчивая работа решения в долгосрочной перспективе. Поэтому даже предлагая экономичный вариант на сервер AMD, мы закладываем время на дополнительное тестирование совместимости, прорабатываем сценарии обновления микрокода и драйверов. Потому что сэкономить на этапе закупок, а потом потерять в деньгах и репутации на простое — это не наш подход.

Выводы, которые можно потрогать

Так стоит ли сейчас рассматривать AMD для серверов? Однозначно да, но с умом. Это уже не авантюра для гиков, а вполне рабочая, конкурентоспособная платформа для определённого круга задач. Она убийственно хороша там, где нужна высокая плотность вычислений и широкая полоса памяти без удвоения стоимости за сокеты.

Но нужно быть готовым к более глубокой настройке, чем с некоторыми альтернативами. Документация есть, сообщество активное, но magic из коробки случается реже. Требуется инженер, который понимает, что делает, а не просто следует инструкции по развёртыванию.

В итоге, мой скепсис сменился на осторожный прагматизм. Для типовых задач виртуализации, для веб-сервисов с горизонтальным масштабированием, для некоторых научных расчётов — это отличный выбор. Для узких, специфичных workloads с жёсткими требованиями к латентности — нужно считать, тестировать и ещё раз тестировать. Главное — не верить маркетингу слепо, а самому гонять benchmarks, максимально приближенные к production. Как мы и делаем, предлагая клиентам ООО Чжунчуан Жуньцзинь не просто оборудование, а готовое, выверенное решение под его боль.