Стоимость x86
Закупка серверов начинается не с желания купить «железо», а с планирования будущей инфраструктуры. Для этого оценивают количество прикладных сервисов, например ERP, базы данных или весь бизнес-софт. Добавляют инфраструктурный слой, включая файлообменники, VDI, Kubernetes, SDS, брокер сообщений и т.п. Учитывают желаемое время выполнения, высокую доступность и отказоустойчивость. В итоге может получиться, что физических серверов требуется заметно больше, чем казалось на первый взгляд.
Если для одного сервиса нужно, скажем, одно ядро, то в реальной инфраструктуре с учетом резервирования для отказоустойчивости их может понадобиться в несколько раз больше. Один контроллер и две ноды – и вот уже три машины вместо одной.
В особо «параноидальных» схемах обеспечения безопасности и резервирования для критически важных приложений могут потребоваться уже семь-восемь физических машин, которые будут размещаться в трех геораспределенных ЦОДах и исполнять роль одного логического сервера. И так для каждого сервиса. Инфраструктура разрастается до чудовищных размеров.
Допустим, для бизнес-задач нужно докупить и внедрить дополнительные 100 тыс. ядер. Если ориентироваться, скажем, на двухсокетную платформу на x86-процессоре диапазона выше среднего – ядер на 48 или 64, – то понадобится примерно 1 тыс. физических серверов (каждый из которых будет потреблять 0,8–1,3 кВт без учета GPU).
Разместить эти серверы можно по 10–15 единиц в стойке. Если стойка рассчитана на 15 кВт подводимой мощности, потребуется условно 80 стоек. Хуже, если доступно только 5 кВт на стойку, тогда нужно 150–200 стоек. Эта тысяча серверов будет потреблять в среднем (без пиков) около 1 МВт или чуть меньше. Каждый мегаватт в капитальных затратах на новый ЦОД сейчас обойдется примерно в 1,3 млрд руб.
Сами серверы при цене около $20 тыс. за платформу с двумя CPU без учета волатильной памяти и дисков будут стоить примерно $20 млн на весь комплект, т.е. около 1,7 млрд руб. Итого приблизительно 3 млрд руб. – это сумма, которую компания потратит только на закупку, а впереди еще эксплуатация с затратами на охлаждение, электроэнергию, зарплату и т.д.
Та же задача, но на ARM
В ARM-архитектуре ядер в процессоре вдвое больше. Те же искомые 100 тыс. ядер обеспечиваются уже 400 серверами с двумя 128-ядерными процессорами. Потребление у каждого процессора не превысит 178 Вт (сравните с TDP в 300 Вт для 64 ядер или 400–500 Вт у 128 ядер x86), а общее потребление сервера составит 0,4–0,6 кВт. То есть в два раза меньше.
Реальное потребление электроэнергии также ниже в несколько раз. Даже с запасом экономия на электричестве получается существенная: вместо 1 МВт будет не более 0,3 МВт – это экономия почти в миллиард рублей на инфраструктуре.
Сами ARM-процессоры при большем количестве ядер стоят существенно дешевле сопоставимых x86-решений, давая общую цену на комплект для 100 тыс. ядер не более чем 0,5 млрд руб. Итого: вместо 3 млрд руб. получаем меньше 1 млрд.
Конечно, это идеалистический расчет для гетерогенной среды с одинаковой конфигурацией. На практике цифры будут зависеть от реалий машинных залов, задач и карт расширения, СХД, GPU и прочего. Но суть понятна – при сколько-нибудь значимом масштабе экономика становится экономной.
И тут возникает естественный вопрос. Если все так хорошо, то почему российский рынок до сих пор не перешел на ARM?
«Как деды завещали»
Одна из причин – разнородность. В x86 исторически сложился относительно единый стандарт, всего пара производителей. В ARM вендоров больше, и каждый продвигает на рынок свои «уникальности»: разные SoC, версии ядер, системные библиотеки, драйверы и т.д. Готовые собранные пакеты, подходящие для абсолютно любого популярного приложения, нужно поискать. Драйверы для периферии производители часто не портируют, как и проприетарный софт, особенно, если они не предназначены для массового сектора.
Приходится собирать из исходников, устранять зависимости и вносить исправления. Это деньги, время и нервы. А если у вас legacy-код, который годами писался для x86, со специфическими оптимизациями, то он на ARM не запустится. И хорошо, если переписывать придется не всё.
Есть и человеческий фактор. Сисадмины и разработчики не горят желанием мигрировать. Для пяти серверов переписывать стек экономически бессмысленно – сэкономишь тысяч тридцать долларов, а ресурсов на переписывание уйдет куда больше. Для тысячи серверов выгода уже очевидна. Но первый шаг дается тяжелее всего.
Люди привыкли делать так, как «деды завещали», запускать, например, 1С на Windows. На Linux тоже можно, но зачем менять то, что 20 лет и так работало? При этом часть трудностей надумана, но никто не хочет в них разбираться, многие отмахиваются, даже не попробовав.
Как избавиться от привычки
Один из крупных российских банков за полтора года провел тесты всех своих приложений на ARM, как только инфраструктурный слой это позволил. Конечно, были технические сложности, так как первоначально именно инфраструктура была жестко привязана к x86. Но как только VMware заявила о поддержке ARM, и стало понятно, что OpenStack и «ванильный» Kubernetes работают «из коробки», ситуация стала меняться.
Выяснилось, что если писать код на Python, Go или других кроссплатформенных языках, то проблем практически нет. Основные сложности возникают там, где разработчики «гвоздями прибили» сервисы к x86, а все остальное решается на уровне рутины.
Если компания крупная и готова инвестировать в приведение инфраструктуры к однородному состоянию, то миграция на ARM реальна. Особенно когда сервисы распределены по нескольким ЦОДам и должны автоматически перемещаться между ними. Небольшим компаниям такой путь часто самостоятельно не пройти, поскольку трудозатраты для них слишком высоки. На ARM им проще брать готовые решения (ПАК), в которых вендор все заранее собрал и проверил.
Стереотип, что ARM медленнее, чем x86, устарел. Если взять свежий ARM и устаревший x86 или наоборот, то картина получится искаженная. В одинаковых поколениях ARM не уступает, а в некоторых сценариях, например на Postgres, может обходить x86. Есть задачи, где x86 пока предпочтительнее, но говорить о тотальном отставании ARM уже нельзя.
Российская психология
В России среди физических машин на ARM-серверы приходятся доли процента. Примерно столько же занимает «Эльбрус» со своей альтернативной архитектурой. Все еще встречаются IBM Power, но их тоже немного, и доля только уменьшается. Все остальное – x86, существенно больше 90%.
Столь малые масштабы распространения ARM-серверов обусловлены тем, что инженеры, отвечающие за сопровождение критичных систем, не хотят рисковать и брать на себя ответственность за изменения, которые теоретически могут нарушить их работу. Психология здесь сильнее экономики. ИТ-директор в первую очередь отвечает за надежность сервиса. Уровень затрат важен, но стоит на втором или даже третьем месте. И за экономию редко хвалят так же громко, как ругают за простои и сбои.
Кроме того, рядовой айтишник-гик, нацеленный на все новое, мало влияет на решения по закупке «железа». Это зона ответственности закупщика или ИТ-директора, которым важно не нарушить установленную регламентом процедуру.
ИИ станет драйвером
Глобальные гиперскейлеры, такие как Google, Amazon и Tesla, массово переходят на ARM. В установках новых крупных облачных игроков доля ARM уже заметна. Экономика пока не победила консерватизм, но мировой тренд уже сформировался. Рано или поздно он доберется и до российских заказчиков, хотя бы через ИИ-кластеры и постепенное накопление опыта.
По мере развития ИИ-сервисов ситуация постепенно меняется. Если вы покупаете современные ИИ-ускорители от Nvidia, вас даже спрашивать не будут – продадут готовое решение и там в качестве центрального процессора будет чип на ARM.
И с этого момента у вас в инфраструктуре появится тот самый неведомый ARM (хотя не такой уж и неведомый, подобные чипы уже давно стоят в смартфонах, планшетах, компьютерах Apple и во всех крупнейших ЦОДах). Возможно, это станет тем самым драйвером, который заставит российские компании всерьез заняться ARM.
Вероятно, через два-три года улучшится и поддержка российского софта, и вендоры будут поставлять сборки и для x86, и для ARM. Тогда миграция в основном будет сводиться к проверке собственного внутреннего кода, а рынок начнет расширяться органически по мере появления большего количества успешных кейсов, которые покажут, что ARM – это «не больно и не стыдно».
Филипп Моднов, заместитель директора управления продуктов и технологий, «Е-Флопс»
