Инфраструктура без смузи*

Что же дальше?

В первой половине 2000-х годов весь Enterprise-сектор старательно потреблял RISC-серверы производства SUN, IBM и HP. И казалось, это будет неизменно. Тут и многопроцессорность, и безграничные возможности ввода/вывода. Чтобы все это хорошо и красиво работало, использовалось различное СПО для обеспечения множественного доступа к дисковым массивам и управления дисковыми томами, а также доступ к дискам отдельно от ненадежной ЛВС. Казалось, вот она – инфраструктура мечты. Все управляется, все предсказуемо, и можно годами не выключать серверы даже для того, чтобы добавить память или процессоры. Оставалось положиться на закон Мура и ожидать, что производительность этих систем будет расти так же быстро, как количество транзисторов в каждом из процессоров большого сервера. Согласно тому же закону увеличивалась сложность и производительность самих процессоров Intel, создающего также платформы для недорогих серверов и настольных систем. Intel делил эту нишу с AMD, которая также имела свою долю на рынке desktop-решений. Другие игроки в то время занимали куда более скромные позиции в сфере специализированной техники. Вскоре и компания AMD сошла с дистанции, не выдержав конкуренции на рынке серверных процессоров, а Intel в 2008 году выпустил процессор Nehalem. Уже настоящий многоядерный процессор, имевший в одном кристалле 4 полноценных ядра, поддерживающих к тому же SMT. Это открыло дверь для 2-процессорных серверов в ЦОД. Да так открыло, что на этих серверах начали запускать системы SAP и Oracle. Зачастую проект миграции на новую платформу с полной заменой серверного оборудования стоил меньше, чем апгрейд имеющихся серверов, не говоря уже о резком снижении операционных затрат на поддержку нового оборудования в сравнении с Enterprise- линейкой серверов, применявшихся ранее.

Дальнейшее развитие многоядерных процессоров от Intel привело нас к 16-ядерным процессорам по 32 потока и 32 ядра в 1RU. Или даже два сервера по 32 ядра в 1RU. Это примерно то же самое, что 10 лет назад умещалось в два шкафа и стоило на два порядка дороже.

Для большего проникновения новейших технологий в мир ИТ потребовалось воспитать многочисленное сообщество разработчиков, готовых использовать самые новые функции различных библиотек экосистемы LAMP и множество версий Java в составе большой системы (в соответствии с принципами agile она состоит из некоторого количества микросервисов). Запустить такой сервис стало возможным в эру облачных вычислений и непрерывной интеграции. Как позже выяснилось, облако может быть как частным, т.е. развернутым на собственном оборудовании компании, так и публичным, т.е. принадлежащим сторонней организации. Благодаря этим подходам максимально быстро получить новые виртуальные серверы не составляет труда, а значит, можно радикально сократить время от возникновения бизнес-идеи до провала вывода продукта на рынок.

Такое движение нога в ногу с передовыми методологиями стало приводить к тому, что количество виртуальных серверов, необходимых для функционирования продукта, увеличивалось от релиза к релизу. Все потому, что было крайне неудобно держать, а главное поддерживать в одной ОС библиотеки разных версий, несколько версий Java и т.д. Ответ разработчиков на такой запрос не заставил себя долго ждать – и это были контейнеры. По сути никакой виртуализации – просто изолированные наборы ресурсов и процессов в составе одного сервера, позволяющие собрать файловую систему с необходимыми для приложения библиотеками послойно, из репозитория, сконфигурировать на лету приложение (верхний слой этой FS) и запустить его в продуктив. Для собственных разработок это очень удобно. Для ПО, доступного из публичного репозитория Docker Hub, еще удобнее. Особенно в свете того, что как раз созрел весь инструментарий, необходимый для автоматизированной сборки и инсталляции приложений – тут и Jenkins, и Maven, и JBoss tools и PHP тоже готовые в виде контейнеров. Мы плыли-плыли и наконец приплыли. От IaaS доплыли до CaaS (Containers as a Service). Казалось бы, причем тут ARM?

ARM’атура

В этой новой парадигме становится понятно, что разработчик довольно индифферентен к тому, на каком процессоре работает Linux, в чьем контейнере запущен разработанный им микросервис. Главное, чтобы все нужные библиотеки с так необходимыми ему функциями были доступны для этой платформы. Для того чтобы это стало возможно на процессорах ARM, лидеры рынка (ARM, Cavium, Broadcom, Facebook, HP, ZTE, AMD, RedHat и еще целый ряд компаний) объединились в группу Linaro и проспонсировали портирование экосистемы Linux на ARM. И продолжают спонсировать поддержку разработки и содержание репозиториев Open Source СПО и ППО для ARM. Помимо этого Canonical самостоятельно занимается поддержкой Ubuntu Linux на ARM, а поддерживаемый RedHat проект Fedora вообще объявил ARM64 приоритетной платформой для разработки. Благодаря этому, в частности, стал доступен RedHat Enterprise Linux Server for ARM Development Preview 7.1. А гиганты вроде Facebook перешли к работе на оборудовании в формфакторе, разработанном ими самими и производимым непосредственно для них.

Такие резкие изменения в мире ARM привели к тому, что менеджеры Intel не на шутку озаботились происходящим. На деле производитель изрядно упустил рынок процессоров для мобильных устройств, а, когда эти процессоры вдруг стали появляться в дата-центрах, пришлось действовать. Надо сказать, что Intel здесь борется «на своей территории» и обладает ресурсами, чтобы при необходимости продолжительное время сдерживать соперника. Первым ответом в 2013 году (в основном на низкое энергопотребление) стало семейство процессоров Intel Atom C2000. Вторым и, видимо, не последним – Intel Xeon-D. И если Atom может вызывать довольно смешанные чувства (его ядро примерно в 3 раза менее производительно, чем ядро в Xeon E5 v3), то Intel Xeon-D – вполне годный экземпляр. Производительность ядра уже сравнима с Xeon E5 v3. Конечно же, не обошлось без ложки дегтя: процессор может работать только в односокетном сервере с памятью до 128GB. При этом TDP сохраняется на уровне 45W для 8-ядерного процессора. Это позволило не беспокоиться о том, что на рынок принесли APM (X Gene-1) и AMD (A1100).

Но что делать с Cavium Thunder-X? Это 48-ядерный ARMv8 c TDP на уровне 95W, который может быть установлен в 2-сокетный сервер, поддерживающий до 1TB памяти. Создатели серверов утверждают, что производительность одного такого процессора соответствует Intel Xeon E5-2699 v3. А это уже разница в энергопотреблении по 50W на сокет. Также в 2015 году ожидались первые образцы гиперскейлера от APM (до 64 ядер, 3GHz). Если все пойдет “хорошо” – то первые серверы можно ожидать через пару лет после первых образцов кристаллов.

Кто победит? Армада ARM или Intel?

Производители процессоров ARM не витают в облаках и в первую очередь позиционируют свои продукты в качестве нишевых: Software Defined Storage, Network Function Virtualization, Security appliances, HPC. Основная цель для них – большие облачные провайдеры, что вполне логично: Linux на ARM работает; KVM, Xen – работают; Docker – тоже работает. Этого достаточно для того, чтобы использовать ARM как в облаке с виртуальными машинами (OpenStack, CloudStack и т.д.), так и в прикладном облаке (Cloud Foundry, OpenShift, Rancher и т.д.). Как раз в этой экосистеме живет и очень быстро растет сегмент потребителей серверного оборудования, представители которого практически через слово используют все нашумевшие модные понятия, стимулирующие эволюцию в разработке ПО в наше время.

Тем не менее, даже если ARM удастся “занести” в ЦОД на роль вычислительного узла, не стоит ожидать что он сразу существенно потеснит в этом качестве Intel. Тому есть несколько предпосылок:

• это действительно игрушка для владельцев облака – большого частного, а скорее – еще большего публичного;
• все то прикладное ПО, которое принято громко называть ”Enterprise Solution”, зачастую официально не поддерживает в качестве платформы ARM – пусть даже это Java-приложения;
• только Linux, только hardcore.

Большим компаниям для того чтобы начать эффективно использовать такие серверы, сначала потребуется сменить парадигму, в которой работает их ИТ-служба. Потом будут длительные тесты ППО (или даже пересоздание ПО, если оно собственной разработки), а после – миграции.

На наш взгляд, это может привести к гипотетической доле в 5–10%, что будет просто ошеломляющим результатом. С точки зрения потребителя, самым значимым итогом может стать сам факт появления конкуренции на рынке процессоров, а значит, и снижение стоимости продуктов.

Всем смузи за счет заведения!

Возвращаясь к начальной мысли про enabling technology: не сразу видно, какое из звеньев технологического процесса запускает на рынке цепную реакцию. Та первая интегральная схема, на основании которой был получен патент, предназначалась для слухового аппарата, а не для частного облака, как кто-то мог подумать. Возможно, сам по себе ARM не является «серебряной пулей», а вот переход к облачным вычислениям вполне может быть тем самым недостающим звеном для того, чтобы процессор из мобильного устройства появился в ЦОД и разрушил монополию Intel.

Опубликовано: PC Week, март 2016 г.

* Смузи (от англ.  smooth — «однородный, мягкий, гладкий, приятный») — густой напиток в виде смешанных в блендере или миксере ягод или фруктов (обычно одного вида) с добавлением сока или молока. Стоимость производства смузи в США составляет 10—15 центов, а цена продажи 2,5—4,5 доллара. © Wikipedia