Особенности выбора ИТ-оборудования для облаков в условиях санкций

Полностью заместить импортное ИТ-оборудование невозможно – отечественные процессоры «Эльбрус» и «Байкал» есть, но их запасы ограничены и новые изготовить нельзя, поскольку в стране соответствующие технологии не освоены, а Тайвань со своими заводами присоединился к санкциям. 

Для создания «матчасти» облаков остаются несколько вариантов:

На практике используются все три варианта. Перестроили работу российские компании сервисной поддержки, которые до 2022 г. в основном придерживались «брокерской» бизнес-модели, перепродавая клиентам услуги техподдержки западных вендоров, которые при этом поставляли запчасти и брали на себя сложный ремонт. После ухода зарубежных вендоров для выполнения сервисных контрактов поставщиков пришлось полностью заменять.

Наладились поставки ИТ-оборудования покинувших Россию мировых лидеров через азиатские страны. И если в 2022 г. в условиях повышенной турбулентности рынка стоимость серверов и СХД иногда вырастала в несколько раз, и никто не мог гарантировать, что даже по этой цене их привезут, то теперь такое оборудование, хотя и стоит на 30–50% больше, чем раньше, но до потребителя доходит.

Активно стали занимать освободившуюся нишу ИТ-оборудования для облаков российские вендоры. Серверы производят Aquarius, GAGAR>N, Kraftway. Серверы и СХД для виртуализации и облачных платформ выпускает компания YADRO, коммутаторы – Qtech, Fplus, Eltex, Utinet. Выбор есть, но усложнился сам процесс комплектования ИТ-инфраструктуры.

На тренинге по облачным технологиям, организованном АНО КС ЦОД, отвечающий за архитектуру аппаратных решений технический эксперт RСloud by 3data Сергей Гордеев перечислил критерии, по которым облачный провайдер в новых условиях выбирает серверы.

Прежде всего провайдер смотрит на совместимость сервера с используемым в облаках программным обеспечением, зарубежными и отечественными системами виртуализации. Задача непростая, поскольку на рынке то и дело появляются новые вендоры ПО и «железа». Далее рассматриваются характеристики производительности (СPU, память, пропускная способность), которые должны соответствовать нагрузкам в облаке (рис. 1). 

 

Следующий критерий, на который сильно повлияла изменившаяся реальность, – наличие сервисного обслуживания и ремонтопригодность. «Когда-то жили в полной уверенности, что есть контракт на обслуживание и мы застрахованы на случай выхода “железа” из строя. Теперь пристально изучаем компетенции российских интеграторов. Смотрим, насколько легко привезти ЗИП, есть ли вообще такая возможность и насколько сложно обслуживать и ремонтировать оборудование, если придется делать это самостоятельно», – пояснил С. Гордеев. 

Последний критерий – энергоэффективность, важный прежде всего для предоставляющих облачные услуги коммерческих ЦОДов. 

Российские облачные провайдеры по-прежнему предлагают облака на решениях зарубежных вендоров, прежде всего VMware. На первый взгляд, самый простой способ получить совместимое c решениями VMware ИТ-оборудование – привезти его по параллельному импорту и работать как раньше. Но и здесь появились нюансы. Однородность конфигурации во многом обеспечивали официальные дилеры, заказывавшие у вендора партии одинаковых серверов. Теперь партии серверов состоят из того, что смог достать посредник. 

«Заказав крупную партию одинаковых по конфигурации серверов мирового вендора, получили неожиданный результат – не смогли их собрать в кластер для облака VMware. Оказалось, что процессоры имеют разный степпинг – версии кристаллов чипа, которые можно сравнить с мелкими патчами для программ, исправляющими ошибки. И хотя по функциональным характеристикам серверы одинаковые, VMware перестраховывается и не добавляет в кластер серверы, различающиеся по степпингу чипов. При работе с официальными дилерами мы об этом и не задумывались, они все брали на себя», – привел пример возникающих из-за санкций проблем генеральный директор Nubes Василий Степаненко.

Еще сложнее с российскими решениями. Отчасти можно ориентироваться на сообщения компаний, периодически проверяющих совместимость своих облачных платформ с теми или иными аппаратными решениями. Но, конечно, лучше провести такое тестирование самостоятельно, скажем, в тестовых лабораториях.

Прежде чем выбирать сервер, нужно понять, для каких целей он будет использоваться, какая бизнес-функция будет автоматизирована. Так, для работы с базами данных нужны высокопроизводительные CPU, для систем виртуализации – наличие в чипе большого числа ядер, для задач машинного обучения нужны GPU. Исходя из поставленной бизнесом задачи архитектор составляет проект информационной системы, и начинается выбор конкретного оборудования, основанный на специфике предприятия и существующих рекомендациях. Например, компания «1С» рекомендует приобретать серверы исходя из выбранного приложения и количества работающих с ним сотрудников.

Каждая информационная система – ценность, окупаемость которой легко просчитывается. Компания может позволить себе держать разнокалиберное, но оптимальное для ее конкретных задач оборудование. У облачного провайдера все сложнее. Он, как правило, заранее не знает, кто и как будет использовать вычислительные ресурсы, и ориентируется на некоторые усредненные профили (задачи), для которых проводит сайзинг виртуальных машин (ВМ), т.е. определение их оптимальных параметров. 

Ключевые параметры при сайзинге ВМ:

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

Если говорить о «железе», то на производительность ВМ больше всего влияют четыре параметра: CPU, RAM, дисковая подсистема и сетевой адаптер. Их выбор определяется потребностями типовых клиентов облачного провайдера. «Облачный провайдер старается максимально удовлетворить средние потребности бизнеса. У нас есть несколько видов процессоров с разными частотами и сайзингом виртуальных машин в соответствии с нагрузкой и требованиями приложений. При этом в рамках одной конфигурации берем однородное оборудование одного и того же вендора. К сожалению, это теперь не всегда получается», – отметил С. Гордеев.

В России несколько облачных провайдеров начали предлагать услуги на базе ARM-процессоров, но таких пока немного. Чаще используются процессоры AMD (AMD EPYC), которые можно найти у Selectel, Cloud.ru и RUVDS, еще чаще – Intel.

По данным Mercury Research, доля Intel на мировом серверном рынке уже к концу 2022 г. снизилась до 76,4% (рис. 2), но процессоры компании по-прежнему являются наиболее распространенными и, как следствие, наиболее доступными в условиях санкций.

 

Стоит учитывать, что по ряду тестов последние поколения процессоров AMD EPYC показывают лучшее соотношение «цена – производительность» и обеспечивают более низкую совокупную стоимость владения (ТСО), учитывающую не только стоимость процессора (которая у АМD выше), но и стоимость лицензий решения виртуализации, технической поддержки и затраты на электроэнергию. 

На своем сайте AMD приводит алгоритм расчета ТСО системы виртуализации. Воспользовавшись им, оценим трехлетнюю стоимость владения облачной платформой Red Hat для процессоров, например, AMD 2 EPYC 9325 и Intel Xeon E-2288 G для России. ТСО системы на основе процессоров AMD оказывается ниже почти на 40% (рис. 3). Конечно, следует учитывать, что методика расчета предложена AMD, поэтому нет уверенности, что Intel с ней согласится.

 

Оба вендора предлагают схожие технологии аппаратного ускорения виртуализации: AMD-V (Virtualization Technology) и Intel VT (Virtualization Technology), так что в плане виртуализации преимуществ нет. В дата-центрах пространство для ИТ-инфраструктуры ограничено, поэтому лучше выбирать топовые модели процессоров с большим количеством ядер и высокой тактовой частотой. Обратная сторона – они сильно греются и придется принимать дополнительные меры для охлаждения.

У топовых моделей AMD больше ядер, и провайдер сможет развернуть больше виртуальных машин. Если же главное – производительность ВМ, то тактовая частота важнее, чем количество ядер, и преимущество получают топовые модели Intel Xeon.

Предпосылки выбора процессоров тех или иных моделей раскрывает Федор Прохоров, технический директор провайдера облачных и ИИ-технологий Cloud.ru: «В наших сервисах используются процессоры Intel Xeon разных моделей нескольких последних поколений. При выборе конкретных моделей мы отталкиваемся от потребностей клиентов, типа сервиса и соотношения тактовой частоты, количества ядер и стоимости процессоров. Например, клиентам, которым требуются простые ресурсы IaaS Compute, важны тактовая частота и производительность процессора. Для пользователей высокоуровневых PaaS-сервисов это уже не имеет такого значения, поскольку для них тарификация основывается на показателях производительности самого сервиса, а не процессора, на котором он работает. 

Процессоры AMD можно задействовать в сценариях создания высокопроизводительных узлов суперкомпьютеров, где при обучении больших AI-моделей требуется высокая производительность. Она может достигаться при использовании AMD EPYC за счет большего числа PCIe-линий и реализации архитектуры NUMA (Non-Uniform Memory Access), более подходящей для обучения».

Жесткие критерии применяются при выборе СХД. Чтобы выполнить заявленное SLA, провайдеру приходится разворачивать конфигурации с запасом. Например, в RCloud by 3data оказалось выгоднее продавать NVMе-диски даже клиентам с низкими требованиями к производительности, для которых были бы достаточны SATA- и SSD-устройства, чем покупать для таких нагрузок отдельные CXД и обеспечивать их резервирование и сервисное обслуживание. В текущих условиях это существенно большие накладные расходы.

Ключевой критерий выбора СХД в RCloud by 3data – возможность использовать технологии обеспечения отказоустойчивости в рамках одной СХД. Кроме этого, требуются высокая производительность – низкая задержка и высокая скорость чтения/записи, что критично для динамичных облачных нагрузок, а также возможность быстро увеличивать объем хранения по мере накопления данных без существенного вмешательства в работу оборудования. Важно, чтобы неполадки в СХД не влияли на работу заказчиков, все можно было чинить на лету, чтобы в СХД были интегрированные решения для защиты данных и автоматического восстановления при сбоях.

Российские СХД пока проигрывают мировым лидерам по надежности и функциональности. При высоких требованиях можно достать СХД китайских лидеров, поддержка которых затруднена, но возможна. Или надеяться на экспертизу российских компаний сервисной поддержки, решающих в меру возможностей проблемы, которые возникают с западными СХД.

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

«Есть классические СХД и подходы к их реализации: DAS, NAS, SAN. Они имеют ряд преимуществ в плане производительности, но жестко привязаны к аппаратному обеспечению, и как следствие, клиенты не могут повлиять на цену. У них ограниченная гибкость, например, сложно приобрести дополнительные диски, сложная система управления и администрирования. Рынок начинает искать пути оптимизации расходов и выбирает программно определяемые хранилища», – указал генеральный директор vStack Евгений Карпов.

Один из плюсов SDS – использование стандартного серверного оборудования. В итоге облачный провайдер может выделить часть серверов (хостов, нод) под виртуализацию, часть под SDS и построить конвергентную систему. Такой подход практикует, например, VK.Cloud. Другой подход – «нарезать» ВМ и SDS из общего пула вычислительных ресурсов и перейти на гиперконвергентную систему. Так работает облачный провайдер beCloud, использующий в качестве решения виртуализации платформу vStack. 

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

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!

<< Предыдущая статья   Вернуться к содержанию   Следующая статья >>