• nav


Переход с Intel Xeon на AMD EPYC: развенчиваем мифы, обходим подводные камни

Рассмотрим типичную ситуацию: в вашей компании пришло время расширять свой ЦОД, или производить замену устаревшего оборудования, и ваш поставщик предлагает вам рассмотреть сервер на процессоре AMD EPYC (ROME). Не важно, приняли вы уже решение или только раздумываете, эта статья - для вас.

Один мой друг, биржевой трейдер, любит повторять, что самые большие деньги зарабатываются на смене тренда, и успешный биржевой игрок должен уметь не только увидеть этот перелом (что на самом деле просто), но и принять его для себя, изменив стиль работы под новые реалии (что на самом деле сложно).

AMD-лихорадка в самом разгаре

Сегодня с уверенностью можно сказать, что астрологи объявили 2019 год - годом AMD. Компания празднует один успех за другим, процессоры Ryzen для настольных ПК выбиваются в лидеры по продажам среди энтузиастов, чиплетная компоновка позволяет выпустить 1-сокетный сервер с 64 ядрами, серверные процессоры EPYC с ядром Rome устанавливают один мировой рекорд производительности за другим, недавно пополненные результатами рендеринг-бенчмарка Cinebench, а всего таких рекордов уже набралось более сотни (это, кстати, тема для отдельной статьи). Вот некоторые любопытные сравнения из маркетинговых материалов AMD:

Даже VMware в своём блоге подтвержает, что 1-сокетные конфигурации стали достаточно мощными для определённых задач.

Акции AMD выросли с начала года в два раза, и листая заголовки статей, ты ощущаешь себя словно в другой реальности: про AMD - только хорошее, а что же Intel?

Динамика котировок Intel и AMD с 1 января сего года

Вчерашний законодатель IT-моды сегодня вынужден отбиваться от проблем в области безопасности, снижая цены на старшие процессоры и вкладывая сумасшедшие 3 миллиарда долларов в демпинг и маркетинг для противостояния AMD. Акции Intel не растут, рынок захвачен AMD-лихорадкой.

ЧТО предлагает AMD?

Прежде всего, AMD вышла на рынок с серьёзным предложением: «1-сокетный сервер вместо 2-сокетного». Для рядового заказчика это эдакий посыл, означающий, что у AMD в процессорах ядер так много и стоят они ощутимо дешевле, поэтому если раньше вы приобретали себе 2-процессорную машину для 64 потоков, то сегодня в 1-процессорной машине у вас может быть 128 вычислительных потоков (64 физических ядра с Hyperthreading) помимо массы планок памяти, дисков и карт расширения. Вообще, даже применительно к первому поколению EPYC это - десяток тысяч долларов экономии с каждого сервера. Давайте для примера используем расчёт прошлогодних конфигураций серверов HPE Proliant.

Ценовое сравнение для 32-ядерного сервера

Компонент / сервер

AMD EPYC

Xeon Platinum

Платформа

HPE ProLiant DL325 Gen10 4LFF

HPE ProLiant DL360 Gen10 4LFF

Процессор

1x HPE DL325 Gen10 AMD EPYC 7551P (2.0 GHz/32-core/180W) FIO Processor Kit 
(P04852-L21)

2 x HPE DL360 Gen10 Intel Xeon-Platinum 8153 (2.0GHz/16-core/125W) FIO Processor Kit 
(870972-B21)

Память

16 x HPE 32GB (1x32GB) Dual Rank x4 DDR4-2666 CAS-19-19-19 Registered Smart Memory Kit 
(815100-B21)

SSD 

4x HPE 1.92TB SATA 6G Mixed Use LFF (3.5in) LPC 3yr Wty Digitally Signed Firmware SSD 
(P09724-B21)

Блок питания

2 x HPE 500W Flex Slot Platinum Hot Plug Low Halogen Power Supply Kit 
(865408-B21)

Цена, $

34 027

44 525

На этапе конфигурирования сервера, разница между 1-процессорной и 2-процессорной конфигурациями составляет около 30%, и она будет тем больше, чем проще ваш сервер. Например, если не устанавливать 2-терабайтные SSD в каждый сервер, то разница в цене между Intel и AMD будет 1.5-кратная. Теперь самое интересное - стоимость лицензирования софта для сконфигурированных нами серверов. Сегодня большинство программных серверных платформ лицензируются за процессорный сокет.

Сравнение стоимости лицензирования софта для выбранных серверов


1 x AMD EPYC
(HPE ProLiant DL325 Gen10 4LFF)

2 x Xeon Platinum
(HPE ProLiant DL360 Gen10 4LFF)

Citrix Hypervisor Standard Edition

763 $

1526 $

Citrix XenServer Enterprise Edition

1525 $

3050 $

Red Hat Virtualization со стандартной поддержкой

2997 $

2997 $

Red Hat Virtualization с расширенной поддержкой 

4467 $

4467 $

SUSE Linux Enterprise Virtual Machine Driver, Unlimited

1890 $

3780 $

VMWare vSphere Standard с базовой поддержкой

1847 $

3694 $

VMWare vSphere Standard с расширенной поддержкой

5 968 $

11 937 $

Дальше - больше! При использовании 64-ядерных EPYC Rome вы можете в одном AMD-сервере с двумя CPU получить 256 потоков, а в Intel-сервере - 112 используя процессоры Xeon Platinum 8276 - 8280. Процессоры Xeon Platinum 9258 с 56 физическими ядрами мы не рассматриваем по причинам, разобранным в этой статье. И если, например, рабочая нагрузка подразумевает 2000 потоков, то вам хватит 8 двухпроцессорных машины на AMD EPYC 7742, или 18 аналогичных серверов на паре Xeon Platinum 8280. При меньшем числе физических серверов вы начинаете экономить и на лицензии за хост, и на энергопотреблении, и даже на обслуживающем персонале. Возникает резонный вопрос, а что с производительностью? Вначале посмотрим на маркетинговые слайды AMD.

Глядя на слайды презентаций, нужно всё-таки отдавать себе отчёт, что в вашем случае и скорость Intel, и скорость AMD может быть другой, и картина для Epyc (Rome) будет менее радужной на однопоточных приложениях, зависящих от высокой частоты. Однако критерии, предъявляемые к безопасности данных для обеих платформ абсолютно одинаковы. И AMD мало того что не дискредитировала себя в этой области, а наоборот имеет технологии типа SEV для физической изоляции виртуалок и контейнеров в рамках одного хоста, без необходимости перекомпиляции приложений. Мы подробно рассказывали об этой технологии, и рекомендуем вам ознакомиться с нашей статьёй. Но даже несмотря на всё вышесказанное, простите за каламбур, но остаётся ощущение недосказанности. Рядовые сисадмины и крупные IT-директора, когда речь заходит об AMD, задают порой совершенно детские вопросы, а мы на них отвечаем.

Вопрос №1 - совместимость существующего стэка на AMD

Излишне будет говорить, что все современные операционные системы, включая Windows Server, VMware ESX, Red Hat Enterprise Linux и даже FreeBSD поддерживают процессоры AMD EPYC как для запуска приложений, так и для виртуализации. Но у некоторых IT-специалистов возникают вопросы: будут ли работать виртуальные машины, созданные на сервере с Intel Xeon под AMD EPYC? Скажем так: если бы всё было просто и гладко, этой статьи не возникло бы, и даже учитывая, что общение виртуальной машины с процессором и компонентами ввода/вывода осуществляется через прослойку в виде гипервизора, вопросов хватает. На момент написания статьи совместимость с основными операционными системами при установке на голое железо выглядит так:

Операционная система: тип / версия

Совместимость с AMD EPYC 1 (Naples)

Совместимость с AMD EPYC 2 (Rome)

Red Hat Enterprise Linux

7.4.6 (Kernel 3.10)
8.0 (Kernel 3.10)

7.6.6
8.02

Ubuntu Linux

16.04 (Kernel 4.5)
17.04 (Kernel 4.10)
17.10 (Kernel 4.12)
18.04 (Kernel 4.15)
19.10 (Kernel 5.3)

18.04 (Kernel 4.21)
19.10 (Kernel 5.3)

Microsoft Windows Server

2012 R2 (2013-11)
2016 (2016-10)
2019

2012 R2 *
2016 *
2019

VMware vSphere

6.7

6.5 U3
6.7 U3

FreeBSD

-

-

* У Microsoft, можно прямо сказать, всё как обычно: новейший Windows Server 2019 (релиз после октября 2019 г) поддерживает новые процессоры, как говорится, "из коробки". Первое поколение AMD EPYC вообще поддерживается всеми тремя версиями Windows Server без ограничений, а для установки Windows Server 2016 на 64-ядерные AMD EPYC 77x2 в BIOS нужно вначале отключить SMT, а если вы вздумали установить Windows Server 2012 R2, то в BIOS нужно отключить ещё и X2APIC. С процессорами EPYC, имеющими 48 ядер и меньше, всё гораздо проще: ничего в BIOS отключать не нужно, но если вы вдруг решите накатить Windows Server 2012 на машину с двумя 64-ядерными EPYC-ами, то вспомните, что в 2012 году ещё никто не думал, что в один сервер можно запихнуть 256 логических ядер, и эта операционная система поддерживает только 255 логических ядер, так что одно ядро идёт навыброс.

Совсем всё печально лишь у FreeBSD: в самом свежем стабильном релизе 11.3 от июля 2019 года нет ни слова про AMD EPYC даже первого поколения. У меня очень предвзятое отношение к FreeBSD: операционная система, которая не поддерживает многие сетевые карты, которая обновляется раз в полгода, да и к которой издатели просто не могут сделать нормальный загрузочный .ISO образ, свободно записываемый Rufus-ом или Balena Etcher лично мне говорят о том, что у вас должны быть очень веские причины в 2019 году использовать "фряху" на голом железе. И я бы сбросил эту операционную систему со счетов, но на FreeBSD работают такие популярные шлюзы безопасности как PFSense и OPNSense, а так же системы хранения данных с ZFS (Nexenta, FreeNAS). Давайте проверим, означает ли это, что вы не сможете использовать указанные дистрибутивы на голом железе?

Тестирование совместимости AMD EPYC и дистрибутивов FreeBSD

Операционная система: тип / версия

AMD EPYC 7551p

AMD EPYC 7552

PFSense 2.4.4 P3

Запускается и работает

OPNSense 19.7

Запускается и работает

FreeBSD 11.3

Не удалось проинсталлировать ОС

FreeNAS 11.2 U6

Запускается и работает

Вообще, что значит "запускается" в отношении FreeBSD? Сетевую карту Intel X550, интегрированную в материнскую плату, с ходу увидел и настроил по DHCP только FreeNAS, с сетевыми же шлюзами предстояли танцы с бубном.

Представитель компании Nexenta в письме рекомендовал нам не заниматься ерундой, а запускать их виртуальный продукт Nexenta VSA в виртуалке под ESXi, тем более, что у них есть даже плагин для vCenter, облегчающий мониторинг СХД. Вообще, начиная с 11-й версии FreeBSD прекрасно работает и под ESXi, и под KVM, и под Hyper-V, и прежде чем мы перейдём к виртуализации, позвольте подвести промежуточный итог, который будет важен для наших дальнейших исследований: при установке операционной системы на AMD EPYC 2 (Rome), вам нужно использовать новейшие дистрибутивы ваших операционных систем, скомпилированные после сентября 2019 года.

Вопрос №2: что с совместимостью с VMWare vSphere

Поскольку для AMD EPYC родной средой обитания являются "облака", все cloud-операционные системы поддерживают эти процессоры без нареканий и без ограничений. И здесь недостаточно просто сказать, что оно "запускается и работает". В отличие от Xeon-ов, процессоры EPYC используют чиплетную компоновку. В случае с первым поколением (серия 7001) на общем корпусе CPU имеются четыре отдельных чипа со своими ядрами и контроллером памяти и может произойти такая ситуация, когда виртуалка использует вычислительные ядра, принадлежащие одному NUMA-домену, а данные лежат в планках памяти, подключённых к NUMA-домену другого чипа, что вызывает лишнюю нагрузку на шину внутри CPU. Поэтому производителям ПО приходится оптимизировать свой код под особенности архитектуры. В, частности, в VMWare научились избегать таких перекосов в распределении ресурсов для виртуальных машин, и если вас интересуют подробности, рекомендую почитать эту статью. К счастью, в EPYC 2 на ядре Rome этих тонкостей компоновки ввиду особенностей компоновки нет, и каждый физический процессор можно инициализировать как единый NUMA-домен.

Компоновка процессоров

У тех, кто начинает интересоваться процессорами AMD часто возникают вопросы: а как EPYC будет взаимодействовать с продукцией конкурентов в области виртуализации? Ведь в области машинного обучения пока что безраздельно властвует Nvidia, а в сетевых коммуникациях - Intel и Mellanox, который нынче часть Nvidia. Хочу привести один скриншот, на котором указаны устройства, доступные для проброса в среду виртуальной машины, минуя гипервизор. Учитывая, что AMD EPYC Rome имеет 128 линий PCI Express 4.0, вы можете устанавливать 8 видеокарт в сервер и пробрасывать их в 8 виртуальных машин для ускорения работы Tensorflow или других пакетов машинного обучения.

Давайте сделаем небольшое лирическое отступление и настроим наш мини-ЦОД для нужд машинного обучения с видеокартами Nvidia P106-090, не имеющими видеовыходов и созданными специально для GPU-вычислений. И пусть злые языки скажут, что это "майнинговый огрызок", для меня это "мини-тесла", прекрасно справляющаяся с небольшими моделями в Tensorflow. Собирая небольшую рабочую станцию для машинного обучения, установив в неё десктопные видеокарты, вы можете заметить, что виртуалка с одной видеокартой запускается прекрасно, но чтобы вся эта конструкция заработала с двумя и более GPU, не предназначенными для работы в ЦОД, надо изменить метод инициализации PCI-E устройства в конфигурационном файле VMware ESXi. Включаем доступ к хосту по SSH, подключаемся под аккаунтом root

vi /etc/vmware/passthru.map

и в открывшемся файле в конце находим 

# NVIDIA

и прописываем (вместо ffff будут ваши ID устройства)

10de ffff d3d0 false

10de ffff d3d0 false

После чего перегружаем хост, добавляем видюхи в гостевую операционную систему и включаем её. Устанавливаем/запускаем Jupyter для удалённого доступа "а-ля Google Colab", и убеждаемся, что обучение новой модели запущено на двух GPU. 

Когда-то мне нужно было оперативно посчитать 3 модели, и я запускал 3 виртуалки Ubuntu, пробросив в каждую по одному GPU, и соответственно на одном физическом сервере одновременно считал три модели, чего без виртуализации с десктопными видеокартами никак не сделаешь. Только представьте себе: под одну задачу вы можете использовать виртуалку с 8 GPU, а под другую - 8 виртуалок, каждая из которых имеет 1 GPU. Но не стоит выбирать игровые видеокарты вместо профессиональных, ведь после того, как мы изменили метод инициализации на bridge, как только вы выключите гостевую ОС Ubuntu с проброшенными видеокартами, повторно она уже не запустится до рестарта гипервизора. Так что для дома/офиса такое решение ещё терпимо, а для Cloud-ЦОД с высокими требованиями к Uptime - уже нет. 

Но это не все приятные сюрпризы: поскольку AMD EPYC - это SoC, ему не нужен южный мост, и производитель делегирует процессору такие приятные функции, как проброс в виртуалку SATA контроллера. Пожалуйста: здесь их два, и один вы можете оставить для гипервизора, а другой отдать виртуальному программному хранилищу данных.

К сожалению я не могу показать на живом примере работу SR-IOV, и для этого есть причина. Я оставлю эту боль "на потом" и изолью душу дальше по тексту. Эта функция позволяет пробросить физически одно устройство, такое как сетевую карту сразу в несколько виртуальных машин, например, Intel X520-DA2 позволяет делить один сетевой порт на 16 устройств, а Intel X550 - на 64 устройства. Вы можете физически пробросить один адаптер в одну виртуалку несколько раз для того, чтобы пошаманить с несколькими VLAN-ами... Но как-то эта возможность не сильно находит применение даже в cloud-средах.

Вопрос №3: что с виртуалками, созданными на Intel?

Я не люблю простые ответы на сложные вопросы, и вместо того, чтобы просто написать "оно будет работать", максимально усложню себе задачу. Во-первых, я возьму хост на Intel Xeon-D 2143IT, и поставлю на него ESXi 6.7 U1, не самую свежую версию гипервизора, в то время как на AMD-машине будет установлена ESXi 6.7 U3. Во-вторых, в качестве гостевой операционной системы я буду использовать Windows Server 2016, а к этой операционной системе я отношусь ещё более предвзято, чем к FreeBSD (вы помните, выше по тексту я высказывал своё "фи"). В-третьих под Windows Server 2016 я запущу Hyper-V используя вложенную виртуализацию, и внутри проинсталлирую ещё один Windows Server 2016. Фактически, я эмулирую мултитанантную архитектуру, в которой Cloud-провайдер сдаёт в аренду часть своего сервера под гипервизор, который тоже можно сдавать в аренду или использовать под VDI среду. Здесь сложность в том, что VMware ESXi передаёт в Windows Server функции виртуализации процессора. Это чем-то напоминает проброс GPU в виртуалку, только вместо PCI платы - любое количество CPU ядер, и память резервировать не надо: прелесть, да и только. Конечно, где-то там, за кадром, я уже перенёс с Intel-овского хоста на EPYC и шлюз Pfsense (FreeBSD), и несколько Linux-ов, но хочу себе сказать: "если эта конструкция заработает, то всё заработает". Теперь самое важное: устанавливаю все апдейты на Windows Server 2016, и выключаю виртуалку, открывая VMware VSCA. Очень важно - виртуалку нужно именно выключить в состояние Off, ведь если та, дальняя ВМ в Hyper-V при выключении Windows Server сохранится в состояние "Saved", на AMD-сервере она не запустится и нужно будет выключать её, нажимая кнопку "Delete state", что может привести к потере данных.

Выключаю виртуальную машину и перехожу в VCSA для переноса. Я предпочитаю осуществлять клонирование вместо миграции, и копирую Window Server 2016 на хост с процессором EPYC. После прохождения валидации на совместимость, можно добавить немного процессорных ядер виртуалочке и убедиться, что флажки для вложенной виртуализации включены. Процесс проходит за считанные минуты, включаем виртуалку уже на AMD-сервере, ждём пока Windows неторопливо загрузится, и в менеджере Hyper-V включаем гостевую операционную систему. Всё работает (более подробно о том почему же всё работает, написала компания HPE в своём документе, посвящённом переходу с Intel на AMD, доступному по ссылке).

И если не брать какие-то пограничные состояния контейнерной виртуализации, то всё то же самое и с Docker и Kubernetes. Для наглядности я перенесу Ubuntu 18.04, на которой внутри Docker в контейнере работает форум нашего сайта. Как только перенос закончен, я отключаю сеть у новой виртуалки и запускаю её, ожидая, пока всё загрузится. Подождав, пока на клоне форума загрузились кэши Redis, я быстро отключаю сеть на старой виртуальной машине и включаю на новой. Таким образом, downtime форума у меня составляет около 10-15 секунд, но есть временной разрыв с момента начала копирования и до запуска на новом хосте, что даже между двумя SSD укладывается где-то в 5 минут. Если кто-то в течение этих 5 минут создал тему или написал ответ - он останется в прошлом, и бесполезно объяснять пользователю, что мы ушли с 8-ядерного Xeon-а на 48-ядерный EPYC: наш форум, как и весь Docker, работает в 1 ядро, пользователи не простят нам 5 минут разрыва.

Вопрос №4: что с живой миграцией?

И у VMware, и у Red Hat есть технологии живой миграции виртуальной машины между хостами. При этом процессе работа виртуалки не останавливается ни на секунду, и при переносе хосты синхронизируют данные до тех пор, пока не убедятся, что в состоянии оригинала и клона нет временного разрыва, а данные консистентны. Эта технология позволяет балансировать нагрузку между узлами в рамках одного кластера, но хоть ты лоб себе разбей - между Intel и AMD виртуальные машины "наживую" не переносятся.

Артём Гениев, архитектор бизнес-решений  «VMware» (Россия).

• VMware vSphere содержит функционал, позволяющий маскировать (по сути, делать недоступными для виртуальных машин) расширенные наборы инструкций, приводя к общему знаменателю все серверы, входящие в кластер vSphere, что даёт возможность делать vMotion нагрузок между серверами с процессорами различных поколений. Теоретически, можно замаскировать все инструкции, не входящие в спецификацию AMD64, что позволит переносить виртуальные машины «на живую» между любыми серверами с AMD64 – совместимыми процессорами. Результатом такого сценария является максимально урезанные возможности процессоров, все дополнительные наборы команд (AES-NI, SSE3 и выше, AVX в любой форме, FMA, INVPCID, RDRAND и тд) становятся недоступными для виртуальных машин. Это приведет к очень заметному падению производительности или даже неработоспособности приложений, запущенных в виртуальных машинах, работающих на таких серверах.

• По этой причине VMware vSphere не поддерживает vMotion между серверами с процессорами разных производителей. Хотя технически это может получиться сделать в определенных конфигурациях, официальная поддержка vMotion есть только между серверами одного и того же производителя (при этом допустимы процессоры различных поколений).

Если совсем грубо, то всё дело в том, что драйвер процессора транслирует в виртуальную машину расширенные инструкции CPU, а у Intel и AMD их набор отличается. И работающая виртуальная машина, можно сказать, рассчитывает на эти инструкции, даже если их и не использует, и запустившись, допустим с поддержкой AES-NI (Intel), ты у неё не заменишь эту функцию на AES (AMD). По этой же причине живая миграция с новых процессоров на старые даже между Intel и Intel или AMD и AMD может не поддерживаться. 

Артём Гениев, архитектор бизнес-решений  «VMware» (Россия).

• Для того, чтобы vMotion работал между серверами с различными поколениями процессоров одного и того же производителя используется функция EVC (Enhanced vMotion Compatibility). EVC включается на уровне кластера серверов. При этом все серверы, входящие в кластер, автоматически настраиваются таким образом, чтобы презентовать на уровень виртуальных машин только те наборы инструкций, которые соответствуют выбранному при включении EVC типу процессора. 

Есть возможность расширенные инструкции отключить, ограничив доступ виртуальной машины к возможностям CPU, но во-первых, это может сильно снизить производительность виртуалки, а во-вторых, саму виртуалку придётся для этого остановить, изменить конфигурационный файл и запустить заново. А если мы можем её остановить, то к чему нам эти пляски с конфигами - переноси её в выключенном состоянии и всё.


Если покопаться в документации KVM, то можно с удивлением обнаружить, что миграция между Intel и AMD заявлена, хоть явно и не прописана, что она осуществляется "наживую", и этот вопрос периодически всплывает в сети. Вот, например, на Reddit пользователь утверждает, что под Proxmox (гипервизор на базе Debian) у него перенеслись виртуалки "на горячую". Но вот например компания Red Hat категорична в своём видении: "нет живой миграции - и всё тут".

Владимир Карагиоз, руководитель группы архитекторов по решениям Red Hat (Россия).

• На платформе виртуализации Red Hat Virtualization (RHV) такая операция технически невозможна, так как наборы расширенных инструкций Intel и AMD различаются, и сервера на Intel и AMD нельзя добавить в один кластер RHV. Это ограничение введено в целях сохранения высокой производительности: виртуальная машина работает быстро именно потому, что использует особенности конкретного процессора, которые не пересекаются между Intel и AMD.

На других виртуализационных платформах миграция внутри кластера теоретически возможна, однако она, как правило, официально не поддерживается, так как наносит серьезный удар по производительности и работоспособности...

Конечно, существуют костыли, например такие как Carbonite. Судя по описанию, программа использует снэпшоты виртуалки с последующей синхронизацией, что позволяет ей переносить ВМ не то что между хостами с разными процессорами, но даже и между облаками. В документации мягко сказано, что при миграции удаётся добиться "почти нулевого downtime", то есть машина всё же выключается, и вы знаете, что удивительно лично для меня? То что вокруг этой проблемы с отсутствием живой миграции - полный информационный вакуум: никто не кричит и не требует от VMware: "Дайте нам совместимость vMotion между Intel и AMD, а ещё ARM не забудьте!" и связано это с тем, что аптайм на уровне "пять девяток" нужен лишь одной категории потребителей.

Вопрос №5: почему всем плевать на вопрос №4?

Допустим, у нас есть банк или авиакомпания, которая серьёзно решила снизить OPEX за счёт экономии на лицензиях, уходя с Xeon E5 на EPYC 2. В таких компаниях отказоустойчивость является критичной, и достигается не только за счёт резервирования средствами кластеризации, но и за счёт приложения. Это значит, что в самом простом случае, какая-нибудь там MySQL работает на двух хостах в режиме Master/Slave, а распределённая база данных NoSQL вообще допускает отвал одного из узлов без остановки своей работы. И уж здесь совсем нет проблем остановить резервный сервис, перенести его куда требуется и загрузить заново. И чем крупнее компания, чем важнее для неё отказоустойчивость, тем большую гибкость допускают её IT-ресурсы. То есть, там где к IT мы относимся как к сервису, у нас резервируется сам сервисный софт, не важно где и на какой платформе он работает: в Москве на VMware или в Никарагуа на Windows.

Совсем другое дело - облачные провайдеры типа Mail.ru, Yandex, Облакотека, Selectel... Для них продукт - это работающая виртуальная машина с аптаймом 99.99999%, и выключить клиентский ВМ ради переезда на EPYC - нонсенс. Но и они не рвут на себе волосы от отсутствия живой миграции между Intel и AMD, и дело тут в философии построения ЦОДа. В нашей статье "Секреты профессионалов: как масштабируют ЦОД облачные провайдеры" представитель компании "ИТ-Град" (входит в группу МТС) рассказал, что облачные ЦОДы строятся по принципу "кубиков", или "островков". Допустим, один "кубик" - это вычислительный кластер на абсолютно одинаковых серверах + СХД, которая его обслуживает. Внутри этого кубика происходит динамическая миграция виртуалок, но сам кластер никогда не расширяется и виртуалки с него на другой кластер не мигрируют. Естественно, что кластер, построенный на Intel, всегда и будет оставаться таким, и в одно время либо просто будет модернизирован (все серверы заменят на новые), либо утилизирован, а все ВМ переедут на другой кластер. Но апгрейды/замены конфигураций внутри "кубика" не происходят.

Николай Араловец, cтарший системный инженер облачного провайдера "ИТ-ГРАД" (входит в Группу МТС)

• Мне видится грамотным подход к сайзингу исходя из определения "кубика" для вычислительного узла (compute node) и хранилища данных (storage node). В качестве вычислительных кубиков выбирается аппаратная платформа с определенным числом ядер CPU и заданным объёмом памяти. Исходя из особенностей платформы виртуализации делаются прикидки сколько "стандартных" VM можно запустить на одном "кубике". Из таких "кубиков" набираются кластера/пулы где могут быть размещены VM с определенными требованиями к производительности.

• Базовый принцип сайзинга заключается в том, что все серверы в рамках пула ресурсов - одинаковые по мощности, соответственно и стоимость их одинакова. Виртуальные машины не мигрируют за рамки кластера, по крайней мере, при штатной эксплуатации в автоматическом режиме.

И если захочет Cloud-провайдер сэкономить на лицензиях и вот просто на железе в пересчёте на CPU ядро, то он просто поставит отдельный "кубик" из десятка-другого серверов на AMD EPYC, настроит СХД и введёт в эксплуатацию. Так что даже для облачников не имеет значения, что клиентскую виртуальную машину нельзя перенести наживую с Intel на AMD: у них просто не возникает таких задач, и представитель VMware это подтверждает.

Дополнительный вопрос: у вас есть ложка дёгтя? У нас есть ведро

Давайте начистоту: всё то время, пока AMD не было на серверном рынке, компания Intel зарабатывала себе статус пуленепробиваемого поставщика решений, которые работают хоть ты кол им на голове теши, а AMD не почила на лаврах, не сидела в глухой обороне, а просто прогуливала все те уроки, которые выносил рынок, и когда в курилках менеджеры поливали грязью старые Opteron-ы, AMD нечем было ответить, и засевшие в голове страхи нас подталкивают к тому, что любая проблема на AMD сервере - это проблема AMD, даже если просто вылетел SSD, отключили электричество, или новый апдейт повесил хост - всё равно "нужно было брать Intel". Нам нужен Моисей, который будет 40 лет водить людей по пустыне, чтобы мы избавились от этих предубеждений, но пока ему приходить рано.

Начнем “за здравие”. AMD всегда старается поддерживать долгую жизнь процессорных сокетов, ведь в отличие от Intel, они не заставляют выкидывать материнские платы с каждым следующим поколением процессора. И несмотря на то, что в Enterprise-сегменте не принято делать апгрейды процессоров, это дает возможность определенной унификации парка серверов при плановых закупках, разнесенных во времени. И если Dell EMC и Lenovo запустили под EPYC Rome новые сервера без поддержки первого поколения EPYC 7001, и видимо, будут поддерживать и следующего поколение EPYC Milan, то HPE, хоть и с ограничениями, но уже позволяет установку первых двух поколений EPYC в свои сервера DL325 и DL385 10 Gen.

С точки зрения схемотехники, материнская плата под AMD EPYC - это просто сокет(ы) и слоты с разводкой: южного моста нет, делителей PCI Express нет, все дополнительные чипы - это периферийные контроллеры для Ethernet, USB 3.x и BMC. На материнской плате просто нечему ломаться, она простая как барабан, и особенно впечатляет концепция мощного однопроцессорного сервера AMD. Но, если посмотреть на рынок самосборных решений, как будто бы специально AMD не смогла пройти мимо конкретной лужи. Дело в том, что платы EPYC для самосбора не всегда совместимы с EPYC 2, и дело не в поддержке памяти DDR3200 или нового стандарта PCIe. Для поддержки EPYC ROME необходим чип BIOS объёмом не менее 32 Мб, а на платформах под первое поколение EPYC сплошь и рядом 16-мегабайтные. Благо, флэш-чип поменять - это вам не сокет перепаивать, и сделать это легко, но всё равно сама ситуация неприятна. Поэтому, если присмотреться, помимо процедур замены чипов BIOS, Supermicro и производители второго эшелона тихо запускают либо новые платы и платформы, либо обновляют ревизии ранее выпущенных плат. 

Кроме этого, открыв раздел Known Issues в релизе vSphere 6.7 U3 и видим, что у нас две проблемы касаются именно EPYC ROME 2. Конечно, Intel тоже не безгрешен: функция SR-IOV с драйвером ixgben (наша тестовая сетевуха X520-DA2) может глючить, что приводит к перезагрузке хоста. Браво! Это не процессор размером с ладонь, которому без году неделя - это карта, которой 10 лет, которая стоит в 4 из 5 серверах с 10-гигабитными сетями.

Для меня всё вышеуказанное значит, что если мы смотрим на троицу "Intel, AMD, VMware", то здесь хорошего мальчика нет, и 100% уверенность в том, что работающий сегодня стэк будет работать и после апдейта, на Intel, AMD или Arm никто гарантировать не может. Ну а если мы живём в таком мире, где любой вопрос надёжности решается за счёт резервирования на уровне приложения, то какая вообще разница, била компания баклуши 10 лет на серверном рынке, или строила имидж мега-поставщика, рухнувший с первым же анонсом Meltdown/Spectre, и продолжает лететь в пропасть - лишь ветер в ушах! 

Заключение: Рекомендации IT директорам

Ещё очень долго на форумах, в блогах и группах в соцсетях опытные специалисты с сертификатами и заполненными профилями будут говорить, что переходить на AMD рано, а какие бы неудачи ни преследовали Intel - за ними две декады доминирования в ЦОД-ах, подавляющая доля рынка и абсолютная совместимость. Это хорошо, что большая часть людей следует навязанной модели поведения, они не видят, что рынок развернулся и надо менять стратегию. Мой друг, биржевой трейдер, говорил, что чем больше людей ставят на понижение, тем сильнее актив выстрелит вверх, поэтому всё, что должен делать грамотный специалист - это брать в руки калькулятор и считать.

AMD интересен при простом сравнении стоимости сервера, его производительность в современного многопоточных приложениях позволяет значительно консолидировать сервера и даже мигрировать на односокетные сервера, снижая общее энергопотребление стоек. Интересна для анализа и ситуация с OPEX при ежегодных отчислениях за лицензии многих приложений. 

Маркетинг у AMD неэффективен, и по крайней мере на российском cloud-рынке остаётся совершенно неразыгранной карта повышенной безопасности виртуальных машин с помощью изолирования памяти ВМ, о чём мы писали ранее.То есть, уже сейчас есть возможности получить на EPYC преимущества на уровне цены и функционала как при консолидации ЦОД-а, так и при построении облака с нуля. 

После того, как посчитаете цены, безусловно, нужно тестировать “руками”. Для этого не обязательно брать сервер на тест. Вы можете арендовать физическую машину у cloud-провайдера, в частности, Selectel и на голом железе развернуть ваши приложения. При тестировании невычислительных приложений обратите внимание на то, что все ядра в Turboboost у AMD работают на частотах выше 3ГГц. Плюс, если есть железо под руками, попробуйте выставить в BIOS повышенный или пониженный пороги энергопотребления CPU, это полезная для больших ЦОДов функция.

Михаил Дегтярев (aka LIKE OFF)
11/11.2019




ПОХОЖИЕ СТАТЬИ:

Что такое Edge Computing и почему граничные вычисления - это побег из облака

Подумайте об устройствах, которые следят за производственным оборудованием на заводе, или видеокамере, которая отправляет запись в реальном времени из удаленного офиса. Пока устройство одно, передавать их по сети довольно легко, но...

Обзор видеокарты Palit GTX 1660 Super: тестируем новинку в задачах вычислений и машинного обучения

Новая серия видеокарт GTX 1660 Super интересна, прежде всего, памятью GDDR6, имеющей высокую пропускную способность. Это именно то, что надо для задач машинного обучения и работы в Tensorflow. Как минимум, вы можете создать собст...

5 основных отличий рабочей станции от настольного ПК

И маленький компьютер для бухгалтера, и рендер-станцию на 6 видеокарт в понимании производителей ПК можно обозвать словом «Workstation», так что если уж руководство поставило перед вами задачу выбора «Рабочей станции», то чтобы не ...

Обзор материнской платы Biostar Racing X570GT формата Micro ATX

В компании Biostar посчитали, что вам для апгрейда нужно просто место, куда можно поставить новый AMD Ryzen, а со всем другим можно и потерпеть. Так что встречаем сверхбюджетку для тех, кому многого не надо.

...

Каковы шансы у AMD на серверном рынке? Часть 2.

Для успешного возвращения на серверный рынок AMD задумала максимально унифицировать производство, связав воедино принципы микроархитектуры Zen, идеологию чипа и финальной сборки процессоров

...

НА ФОРУМЕ ГОВОРЯТ



НОВЫЕ СТАТЬИ
Обзор трёх miniITX корпусов CrownMicro серии CMC-170

Сегодня речь пойдёт о трёх корпусах бренда CrownMicro для сборки ультракомпактных miniITX систем, а именно: CMC-170-113, CMC-170-303 и CMC-170-803. Эти модели имеют стильный дизайн, внешние блоки питания, VESA крепление...

Экспресс-тест видеокарты Palit GeForce RTX 2080 Super в задачах машинного обучения

Если вы выбираете GPU не только для игр, но и для научных расчётов, вам интересно видеть видеокарту с тензорными ядрами и современной памятью GDDR6 объёмом 8 Гб. Благодаря поддержке FP16, в некоторых теслах она показывает...