Стоит ли собирать сервер на ryzen5 3600 и будет ли он работать?
на первый взгляд это скорее «игровая» конфигурация чем серверная. зачем на сервере видеокарта ? 120 G диска для 1С тоже маловато кажется. если делать ежедневный бэкап особенно. корпус судя по цене какой-то детский.
если он будет стоять в соседней комнате то сойдет. если на удаленном ДЦ -выбирайте серверный вариант.
вот чисто для сравнения, хар-ки в РАЗЫ меньше.
отличие сервера — это безостановочная работа на полной нагрузке в автономном режиме. то есть охлаждение, надежность, контроль. ничего из перечисленного в этой конфигурации я не вижу.
работать будет, будет и летать, а вот получить аптайм 400 дней, (да и 40 хотя бы) на нем вряд-ли получится. Что случится при аварийном выключении питания ?
Что случится при аварийном выключении питания ?
Rsa97, «если блок питания вышел из строя» — на то и есть серверные системы с резервированием питания с горячей заменой блока питания. » или винт накрылся» — на то и есть серверные RAID контроллеры с журналированием и горячей заменой дисков.
а если ты не видишь отказов памяти — то только по одной причине — твоя non-ecc память просто не умеет регистрировать такие отказы.
и использовать или не использовать специализированное железо надо исходя из стоимости простоя. например какие потери понесет фирма если сервер 1С будет недоступен целый рабочий день пока вы покупаете и устанавливаете ноывый б/п? или сдохнет диск и вам придется поднимать бэкап 3-х дневной давности, а потом из бумаги восстанавливать все проводки?
Drivers & Software
Subscribe to RSS Feed
Mark Topic as New
Mark Topic as Read
Float this Topic for Current User
Bookmark
Subscribe
Printer Friendly Page
Hi I have a Ryzen 7 2700X and Windows Server 2016. When I try to run Ryzen Master I get the error:
Ryzen Master requires Windows 10 or greater. Missing required OS! — How do I bypass this message or somehow get the software to run?
Mark as New
Bookmark
Subscribe
Subscribe to RSS Feed
Permalink
Print
Email to a Friend
Report Inappropriate Content
Reddit is your friend.
Mark as New
Bookmark
Subscribe
Subscribe to RSS Feed
Permalink
Print
Email to a Friend
Report Inappropriate Content
My guess, and it is a guess, is that Ryzen Master is not meant for a server OS ans is not supported. Typically running anything other than defaults on a server is a no no as stability is the goal. Someone I with more knowledge than me will likely confirm or correct my statement. Good Luck.
Mark as New
Bookmark
Subscribe
Subscribe to RSS Feed
Permalink
Print
Email to a Friend
Report Inappropriate Content
I’m not trying to overclock, i’m just trying to see the CPU temperature as AIDA64 is showing it incorrectly. It’s saying the CPU temp is 26 deg and the CPU Diode is 93 deg. In the BIOS is shows the CPU being 33 deg. So I wanted to check with Ryzen Master to see what the correct temperature is. Because 93 does not seem correct and also lots of people are complaining that the temperature reading they are getting is incorrect.
Drivers & Software
Subscribe to RSS Feed
Mark Topic as New
Mark Topic as Read
Float this Topic for Current User
Bookmark
Subscribe
Printer Friendly Page
We are installing Radeon drivers on Windows 2016. We have used Windows 10 x64 driver package.
Card: Sapphire AMD RX 480 8GB
OS: Windows 2016 server x64.
When performing installation, driver installer says that is unable to locate a valid hardware. However, we can install manually via device manager providing a «Have a disk» driver pointing to drivers folder. However, this does not install all required apps (for example control panel).
P.D: On Windows 2012 R2 with Windows 8.1 driver package (x64) there is no problem.
Thanks in advance.
Mark as New
Bookmark
Subscribe
Subscribe to RSS Feed
Permalink
Print
Email to a Friend
Report Inappropriate Content
These products are not supported under Windows Server 2016.
The only supported OS’s are 64 bit Windows 7, Windows 8.1 and Windows 10.
Mark as New
Bookmark
Subscribe
Subscribe to RSS Feed
Permalink
Print
Email to a Friend
Report Inappropriate Content
Yes, OK, I understand.
However you have to take into consideration that due to licensing restrictions you cannot use desktop OS (Win 10, 8 or 7) to provide accelerated GPU applications remotely. This is a restriction imposed by Microsoft at EULA.
And since Windows 2012 R2 runs perfectly with Windows 8.1 drivers, I don’t understand why installer restricts Windows 10 driver installation into Windows Server 2016. It’s only a matter to include and extra «case» in installer code flow. In fact, drivers install properly from Device Manager, but not additional apps.
Mark as New
Bookmark
Subscribe
Subscribe to RSS Feed
Permalink
Print
Email to a Friend
Report Inappropriate Content
Part of driver Q & A involves testing on the supported operating systems. The install code verifies the OS being used. So while a manual INF install may work. there is no way to get the rest of the software components working on a non supported OS.
Mark as New
Bookmark
Subscribe
Subscribe to RSS Feed
Permalink
Print
Email to a Friend
Report Inappropriate Content
Perhaps I should move question to another forum and reformulate question:
— How do I install manually software components from driver packages in unsupported operating systems (ex: Windows Server 2016)?
Mark as New
Bookmark
Subscribe
Subscribe to RSS Feed
Permalink
Print
Email to a Friend
Report Inappropriate Content
Unfortunately, the answer I provided is not going to change on any of the AMD forums.
Mark as New
Bookmark
Subscribe
Subscribe to RSS Feed
Permalink
Print
Email to a Friend
Report Inappropriate Content
I have installed Crimson before on Server 2016 despite the install code verification many times with no tricks or workarounds needed, not sure what changed with 17.3.3 or MSUpdate. That said- i’m in the same boat but with a slightly different situation.
1x MSI AMD RX 480 GAMING 8GB
1x MSI AMD RX 480 GAMING 8GB
Intel Xeon E5 2690 V3
Asus X99 Deluxe U3.1
Windows Server 2016 Standard 64bit Version 10.0 Build 1439
After attempting to upgrade to Crimson-ReLive-17.3.3 I encountered the exact same issue you are having. All previous versions of Crimson have installed flawlessly for me even while being on an ‘unsupported’ operating system. I’ve run DDU in safemode, toggled crossfire on and off through BIOS, tried one card, permissions are not of issue (running everything under administrator since I’m using Serv2016); none of the tricks used in the past experiences with driver are working.
I can’t say for sure but either the new Crimson setup is more verbose in how it checks for OS dependencies/reqs, or one of the new Microsoft Updates messed with the build # which isn’t allowing AMD installer to run now (ERR 182). Digging around and attempting to install older version of Crimson have resulted in the same error, which makes me think this is more likely a side-effect from an MS update.
I’ve been running Server 2016 for the past few months and have successfully installed many version of Crimson, so I am also stuck as to why it doesn’t work now.
[Lastly, yes force installing the drivers works just fine but obviously we lose a lot of features/functions necessary for gaming without Crimson]
Переход с Intel Xeon на AMD EPYC: развенчиваем мифы, обходим подводные камни
Рассмотрим типичную ситуацию: в вашей компании пришло время расширять свой ЦОД, или производить замену устаревшего оборудования, и ваш поставщик предлагает вам рассмотреть сервер на процессоре AMD EPYC (ROME). Не важно, приняли вы уже решение или только раздумываете, эта статья — для вас.
Один мой друг, биржевой трейдер, любит повторять, что самые большие деньги зарабатываются на смене тренда, и успешный биржевой игрок должен уметь не только увидеть этот перелом (что на самом деле просто), но и принять его для себя, изменив стиль работы под новые реалии (что на самом деле сложно).
AMD-лихорадка в самом разгаре
Сегодня с уверенностью можно сказать, что астрологи объявили 2019 год — годом AMD. Компания празднует один успех за другим, процессоры Ryzen для настольных ПК выбиваются в лидеры по продажам среди энтузиастов, чиплетная компоновка позволяет выпустить 1-сокетный сервер с 64 ядрами, серверные процессоры EPYC с ядром Rome устанавливают один мировой рекорд производительности за другим, недавно пополненные результатами рендеринг-бенчмарка Cinebench, а всего таких рекордов уже набралось более сотни (это, кстати, тема для отдельной статьи). Вот некоторые любопытные сравнения из маркетинговых материалов AMD:
Даже VMware в своём блоге подтвержает, что 1-сокетные конфигурации стали достаточно мощными для определённых задач.
Акции AMD выросли с начала года в два раза, и листая заголовки статей, ты ощущаешь себя словно в другой реальности: про AMD — только хорошее, а что же Intel?
Вчерашний законодатель IT-моды сегодня вынужден отбиваться от проблем в области безопасности, снижая цены на старшие процессоры и вкладывая сумасшедшие 3 миллиарда долларов в демпинг и маркетинг для противостояния AMD. Акции Intel не растут, рынок захвачен AMD-лихорадкой.
ЧТО предлагает AMD?
Прежде всего, AMD вышла на рынок с серьёзным предложением: «1-сокетный сервер вместо 2-сокетного». Для рядового заказчика это эдакий посыл, означающий, что у AMD в процессорах ядер так много и стоят они ощутимо дешевле, поэтому если раньше вы приобретали себе 2-процессорную машину для 64 потоков, то сегодня в 1-процессорной машине у вас может быть 128 вычислительных потоков (64 физических ядра с Hyperthreading) помимо массы планок памяти, дисков и карт расширения. Вообще, даже применительно к первому поколению EPYC это — десяток тысяч долларов экономии с каждого сервера. Давайте для примера используем расчёт прошлогодних конфигураций серверов HPE Proliant.
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)
На этапе конфигурирования сервера, разница между 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
Citrix XenServer Enterprise Edition
Red Hat Virtualization со стандартной поддержкой
Red Hat Virtualization с расширенной поддержкой
SUSE Linux Enterprise Virtual Machine Driver, Unlimited
VMWare vSphere Standard с базовой поддержкой
VMWare vSphere Standard с расширенной поддержкой
Дальше — больше! При использовании 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? Скажем так: если бы всё было просто и гладко, этой статьи не возникло бы, и даже учитывая, что общение виртуальной машины с процессором и компонентами ввода/вывода осуществляется через прослойку в виде гипервизора, вопросов хватает. На момент написания статьи совместимость с основными операционными системами при установке на голое железо выглядит так:
* У Microsoft, можно прямо сказать, всё как обычно: новейший Windows Server 2019 (релиз после октября 2019 г) поддерживает новые процессоры, как говорится, «из коробки». Первое поколение AMD EPYC вообще поддерживается всеми тремя версиями Windows Server без ограничений, а для установки Windows Server 2016 на 64-ядерные AMD EPYC 77×2 в 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
Операционная система: тип / версия
Запускается и работает
Запускается и работает
Не удалось проинсталлировать ОС
Запускается и работает
Вообще, что значит «запускается» в отношении 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
и в открывшемся файле в конце находим
и прописываем (вместо ffff будут ваши ID устройства)
После чего перегружаем хост, добавляем видюхи в гостевую операционную систему и включаем её. Устанавливаем/запускаем 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, это полезная для больших ЦОДов функция.
Артём Гениев, архитектор бизнес-решений «VMware» (Россия).
