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

В дата-центрах практически каждая ИС построена на процессорах Intel. Кто не использует виртуализацию, тот отстал настолько, что пора сворачивать бизнес, а разговоры о непрерывной интеграции, микросервисах и гибкости сопровождают создание любой современной информационной системы. Все ждут от производителей оборудования нового технологического чуда, которое сможет изменить весь мир ИТ, как это сделали новые подходы в разработке ПО. В некоторых кругах принято считать, что таким чудом является ARM. Так ли это?

Сначала было слово

Новые, а порой и не очень новые технологические или софтверные разработки (enabling technology) часто называют тем ключевым звеном, без которого бы не было большого количества решений, действительно меняющих мир и успешно монетизируемых. От момента появления технологии до того, как она начнет приносить существенный доход, может пройти довольно много времени. Приведу два простых примера. Со времени получения патента на интегральную схему (ничего общего с нынешними СБИС у нее не было — разве что общая подложка для пяти транзисторов) в 1949 г. до первого микропроцессора Intel, тогда еще 4-битного, в 1971-м, прошло 22 года. На тот момент во всем мире делали большие вычислительные машины — счастье, что уже на полупроводниковой элементной базе с использованием ИС. Ничто не предвещало резкой смены поколений и начала гонки производительности, однако она, производительность, с тех пор росла чуть ли не по экспоненте.

Виртуализация как технология, позволяющая программно эмулировать сервер и запустить на исполнение код для эмулируемой платформы, стала доступны уже в 1972 году на IBM System/370. Такие виртуальные машины (ВМ) позволяли начать разработку ПО для новой платформы, которая сама еще находилась в стадии разработки и не была реализована в «железе». Позже, когда производительность отдельных процессоров возросла настолько, что даже для выполнения целого ряда задач одного процессора стало явно много, на сцену ЦОД вышла виртуализация и стала универсальным инструментом, который помог повысить утилизацию оборудования: сначала мэйнфреймов, а потом и просто больших серверов Enterprise-уровня. Позже, во второй половине 2000-x, VMware привела в дата-центры виртуализацию на x86 — это сделало высокую доступность простым, доступным свойством практически любой системы, а виртуализацию — повседневным инструментом в руках ИТ-служб. Бизнес же получил возможность значительно быстрее выводить на рынок новые продукты, не дожидаясь поставки серверов в течение длительного срока. Profit.

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

В первой половине 2000-х весь Enterprise-сектор старательно потреблял RISC-серверы производства SUN, IBM и HP. И казалось, это будет неизменно. Тут и многопроцессорность, и безграничные возможности ввода-вывода. Чтобы все это хорошо и красиво работало, использовалось различное СПО для обеспечения множественного доступа к дисковым массивам и управления дисковыми томами, а также доступ к дискам отдельно от ненадежной ЛВС. Казалось, вот она — инфраструктура мечты. Все управляется, все предсказуемо, и можно годами не выключать серверы даже для того, чтобы добавить память или процессоры. Оставалось положиться на закон Мура и ожидать, что производительность этих систем будет расти так же быстро, как количество транзисторов в каждом из процессоров большого сервера. Согласно тому же закону увеличивалась сложность и производительность самих процессоров Intel, создававшей также платформы для недорогих серверов и настольных систем. Компания делила эту нишу с AMD, которая также имела свою долю на рынке desktop-решений. Другие игроки в то время занимали куда более скромные позиции в сфере специализированной техники. Вскоре и AMD сошла с дистанции, не выдержав конкуренции на рынке серверных процессоров, а Intel в 2008 году выпустила процессор Nehalem. Уже настоящий многоядерный процессор, имевший в одном кристалле четыре полноценных ядра, поддерживающих к тому же 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, Red Hat и еще целый ряд компаний) объединились в группу Linaro и проспонсировали портирование экосистемы Linux на ARM. И продолжают спонсировать поддержку разработки и содержание репозиториев СПО и ППО для ARM. Помимо этого Canonical самостоятельно занимается поддержкой Ubuntu Linux на ARM, а поддерживаемый Red Hat проект Fedora вообще объявил ARM64 приоритетной платформой для разработки. Благодаря этому, в частности, стал доступен Red Hat Enterprise Linux Server for ARM Development Preview 7.1. А гиганты вроде Facebook перешли к работе на оборудовании в форм-факторе, разработанном ими самими и производимым непосредственно для них.

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

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

Кто победит? Армада 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.

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

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

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

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