Компонуемые системы (Composable Infrastructure System, CIS) рассматриваются как следующий этап эволюции конвергентных инфраструктур (см. рис. 1). Основная идея проста: для выполнения конкретной рабочей нагрузки необходимая конфигурация формируется «на лету» посредством программного обеспечения из имеющегося пула аппаратных ресурсов.
.jpg "Рис. 1. Сравнение конвергентной, гиперконвергентной и компонуемой инфраструктур") |
| Рис. 1. Сравнение конвергентной, гиперконвергентной и компонуемой инфраструктур |
Стимулом к реализации данного подхода послужило, в частности, стремление предприятий получить у себя на площадке те же возможности, что и в облаке. Как и в облачной модели «инфраструктура как сервис», необходимые ресурсы запрашиваются из общего пула, который размещается не в публичном облаке, а в ЦОД клиента и контролируется им же.
КОМПОНУЕМАЯ ИНФРАСТРУКТУРА — ЭТО…
Существуют разные мнения о том, какими характеристиками должна обладать компонентная инфраструктура, поскольку концепция достаточно нова (хотя ее истоки можно возвести к мейнфреймам). Так, например, HPE, один из пионеров в данной области, выделяет три обязательные характеристики: гибкий пул ресурсов, унифицированный интерфейс API и программно-определяемый интеллект.
Чтобы составить необходимую конфигурацию в соответствии с (изменяющимися) требованиями приложений, пул ресурсов из вычислительных мощностей, средств хранения и сетевых компонентов должен быть достаточно гибок. На его основе программное обеспечение создает абстрактную физическую систему, которая и предоставляется внешнему приложению.
Чтобы такой подход работал, компонуемые системы должны быть неотличимы от типовых физических систем — с точки зрения программного обеспечения, которое на них будет выполняться. Кроме того, компоновку и возвращение освободившихся ресурсов в пул следует организовать таким образом, чтобы это не влияло на работу остальных систем.
Для динамического распределения ресурсов необходим интеллект. Средства компоновки и оркестрации ресурсов позволяют различным приложениям и устройствам работать скоординированно. А полнофункциональная система управления обеспечивает автоматизированное обнаружение ресурсов в пуле и облегчает реализацию политики их предоставления.
Управление компонуемыми системами осуществляется через API. Как считают в Forrester, наличие опубликованного набора API, с помощью которого пользователи и приложения могли бы получить доступ к управлению компонуемой инфраструктурой, является обязательным, тогда как поддержка графического интерфейса и интерфейса командной строки опциональны. В HPE подчеркивают важность унифицированных API для реализации унифицированного интерфейса управления.
В Forrester различают локальную и глобальную компонуемые инфраструктуры. В локальном варианте она обеспечивает детальный выбор оборудования вплоть до уровня отдельных процессоров и модулей памяти. В глобальном предусматриваются виртуализированные конструкты — например, контейнеры и виртуальные машины, которые пользователи могут задействовать в пределах нескольких площадок.
Для соединения различных компонентов нужна высокоскоростная сеть с низкой задержкой. Таким образом, ключевым фактором (локальной) компонуемой инфраструктуры в долгосрочной перспективе становится замена традиционных медных соединений на оптические. Однако, как отмечают в 451 Research, оптическая фотоника для организации соединений между стойками вряд ли станет широко доступна в течение ближайших трех-пяти лет. Соответственно, имеющиеся на рынке системы пока ограничиваются преимущественно масштабами стойки.
В ЧЕМ ПРЕИМУЩЕСТВА КОМПОНУЕМОЙ ИНФРАСТРУКТУРЫ?
Как указывается в исследовании «Дорога к компонуемой инфраструктуре», которое провела аналитическая компания Moor Insights & Strategy, первыми кандидатами на внедрение данной архитектуры являются организации, использующие гиперконвергентную инфраструктуру, поскольку они уже знакомы с преимуществами единой платформы, объединяющей вычислительные мощности, емкости хранения и сетевые ресурсы. Но зачем им это? Чем отличается компонуемая инфраструктура от доступных повсеместно решений, таких, например, как гиперконвергентная инфраструктура?
Список ее преимуществ во многом пересекается с аналогичными перечнями для HCI: повышение степени использования ресурсов, ускорение развертывания приложений, сокращение капитальных и операционных расходов и т.д. и т.п. Правда, как утверждается, в этом случае выгода оказывается еще большей, чем у предшественников.
Конечный объем доступного места ограничивает свободу маневра при компоновке стоечных серверов, где необходимо разместить процессоры, память, диски, шлейфы, блоки питания, вентиляторы и т.д. Это означает, что конфигурация типового сервера обычно не оптимальна с точки зрения выполняемой нагрузки: приложения с высокими вычислительными нагрузками не задействуют в полной мере память и диски, а в случае приложений с высокими нагрузками ввода-вывода, наоборот, процессоры и память оказываются избыточными.
Для достижения наибольшей эффективности заказчики стараются подобрать конфигурацию в соответствии с планируемой нагрузкой. Однако, как отмечает Ашиш Надкарни, вице-президент по направлению инфраструктуры IDC, управление и обслуживание множества различных конфигураций приводят к усложнению инфраструктуры, а в конечном итоге — к пониманию того, что необходимо создать новую серверную архитектуру — общую платформу, на которой могли бы выполняться различные приложения.
Благодаря дезагрегированной архитектуре компонуемая инфраструктура позволяет использовать ресурсы более эффективно, чем гиперконвергентные решения. По некоторым оценкам, в существующих гипермасштабируемых центрах обработки данных утилизация ресурсов составляет всего 45% (в среднем за сутки). Как утверждают в Western Digital, компонуемая архитектура позволяет довести этот показатель до 70% и выше.
Оптимальная конфигурация системы и более полное использование ресурсов позволяют сократить инвестиции в необходимое оборудование и удешевить предоставление сервисов на базе компонуемой архитектуры. По оценке WD, при использовании данного подхода финансовых вложений потребуется на 50% меньше, а стоимость владения сократится на 40% (по сравнению с традиционными гипермасштабируемыми решениями).
Предприятия нередко имеют одну инфраструктуру для унаследованных приложений, а другую — для мобильных и облачных. Применение компонуемой архитектуры позволяет ликвидировать разрыв между старыми системами и новыми облачными приложениями: на одном и том же оборудовании можно развертывать и те и другие. Это позволяет одновременно поддерживать разные классы нагрузок — традиционные серверные (bare metal в английской терминологии, то есть запускаемые на физическом сервере), виртуализированные и контейнеризованные — более эффективно, чем существующие технологии виртуализации.
Таким образом, компонуемая инфраструктура оказывается привлекательной альтернативой перемещению рабочих нагрузок в публичные облака, предос-тавляя при этом необходимую гибкость для поддержки меняющихся нагрузок. Это соответствует желанию многих предприятий оставить ключевые системы на собственной площадке под своим контролем.
НЕДОСТАТКИ КОМПОНУЕМОЙ АРХИТЕКТУРЫ
Компонуемая архитектура предполагает полную дезагрегацию различных серверных компонентов, но пока это технически невозможно. Для разнесения процессоров и памяти требуются сети с очень высокой пропускной способностью и сверхмалой задержкой, однако необходимая для этого кремниевая фотоника пока находится в стадии разработки.
ИТ-инфраструктура все еще недостаточно гибка, чтобы ее компоненты можно было комбинировать произвольным образом. В идеале компонуемая архитектура должна позволять объединять процессорные сокеты различных серверов, чтобы из них можно было сформировать один логический процессор.
Такие ресурсы, как ускорители (GPU, FPGA, ASIC), память для длительного хранения данных (Storage Class Memory, SCM), сетевые интерфейсы, желательно комбинировать «на лету» произвольным образом в соответствии с запросами приложений. Однако, как указывает Роберт Хормат, технический директор Dell EMC Server Group, это невозможно, пока память привязана к процессору внутри сервера. Необходимо, чтобы серверная архитектура строилась вокруг памяти, а не процессоров (memory centric).
Тем не менее, благодаря новейшим технологиям, в частности общим интерфейсам прикладного программирования (API), функциональность «инфраструктура как код» может быть реализована уже сегодня, однако ее потенциал ограничен возможностями дезагрегации нижележащего оборудования. Пока же компонуемая (программно-определяемая) и дезагрегируемая (аппаратная) архитектуры развиваются разными путями.
Пул ресурсов для компонуемой инфраструктуры должен охватывать все имеющееся оборудование в центре обработки данных. Однако ИТ-инфраструктура современного ЦОД формируется из разнотипного оборудования множества различных вендоров. На сегодняшний день нет стандартизованных способов для оркестрации такой инфраструктуры.
В результате при реализации компонуемой архитектуры заказчики оказываются ограничены в выборе серверами и другим оборудованием конкретного производителя. Таким образом, компонуемая инфраструктура, повышая гибкость масштабирования вычислительных ресурсов, порождает ту же зависимость от одного вендора, как и гиперконвергентная.
Одним из потенциальных преимуществ компонуемой архитектуры является упрощение администрирования и управления. Действительно, использование готовых сценариев и шаблонов для формирования необходимой инфраструктуры из набора компонентов упрощает обслуживание ИТ, но для создания этих шаблонов и адаптации кода нужны специалисты более высокой квалификации.
Таким образом, компонуемой архитектуре предстоит пройти еще долгий путь развития. Пока же набор компонентов, которые можно комбинировать произвольным образом, ограничен процессорами, жесткими дисками и флеш-накопителями.
ОТЛИЧИЯ ОТ ГИПЕРКОНВЕРГЕНТНОЙ АРХИТЕКТУРЫ
Как и в конвергентных и гиперконвергентных инфраструктурах, в компонентной объединяются вычислительные мощности, емкости хранения и сетевые ресурсы, однако предварительное конфигурирование для поддержки определенных классов нагрузок отсутствует.
Гиперконвергентные системы больше подходят для масштабирования однотипных нагрузок, когда на всех узлах выполняются одинаковые приложения. Узлы имеют фиксированную конфигурацию, что упрощает масштабирование HCI, но ограничивает ее гибкость.
В HCI вычислительные мощности и ресурсы хранения масштабируются блоками, тогда как в компонуемой инфраструктуре они дезагрегированы. Это позволяет обеспечить более гибкое масштабирование за счет независимого наращивания вычислительных ресурсов и емкости хранения (см. рис. 2).
.jpg "Рис. 2. Компонуемая архитектура позволяет независимо наращивать ресурсы") |
| Рис. 2. Компонуемая архитектура позволяет независимо наращивать ресурсы |
Если гиперконвергенция обеспечивает горизонтальное масштабирование за счет агрегирования ресурсов в фиксированные блоки, то дезагрегированная архитектура (Rack Scale Design, RSD) использует для этой цели, соответственно, дезагрегацию. Компонуемая же архитектура пытается устранить различие между этими двумя, определяя агрегацию на программном уровне, а не на аппаратном.
Компонуемая инфраструктура позволяет предоставлять приложениям компьютерные ресурсы с помощью кода и, таким образом, избавляет от необходимости физически менять конфигурацию оборудования при добавлении или обновлении приложений. Поэтому она нередко рассматривается в качестве реализации концепции «инфраструктура как код».
«Инфраструктура как код» предполагает использование готовых сценариев для автоматизации развертывания инфраструктуры по требованию. Для этого используются, в частности, продукты Ansible и Chef. Поставщики компонуемых систем используют ту же самую концепцию для упрощения развертывания инфраструктуры на базе имеющегося пула ресурсов. Соответственно, при описании своих систем они нередко используют определения «дезагрегированный» и «инфраструктура как код» (Infrastructure as a Code, IAC). Существующие компонуемые системы представляют собой, по сути, объединение дезагрегированной аппаратной платформы и программной надстройки IAC.
CIS В КОНТЕКСТЕ ПРОГРАММИРУЕМЫХ ЦОД
В отчете Forrester Research, озаглавленном «Программно-определяемые ЦОД достигли зрелости» («The Software-Defined Data Center Comes of Age», Forrester Research, 2017), утверждается, что в будущем компонуемые инфраструктурные системы (Composable Infrastructure Systems, CIS) станут преобладающим подходом к реализации вычислительной инфраструктуры в программируемых центрах (Software-Defined Data Center, SDDC).
Компонуемая инфраструктура представляет собой одну из возможных реализаций программно-определяемой среды (Software Defined Infrastructure, SDI). Как отмечает Ашиш Надкарни, появление программно-определяемых серверов логически дополняет программно-определяемые хранение и сети, так как они могут служить в качестве уровня, на базе которого данные сервисы могут предоставляться в виде «компонуемых полезных нагрузок» внутри виртуальных машин или контейнеров.
Для внесения изменений в конфигурацию оборудования ЦОД необходимо участие человека: подача заявки, ее одобрение, исполнение, — на все это требуется время. В идеале, когда полностью компонуемые центры обработки данных станут реальностью, администраторам не придется определять требования к ресурсам для поддержки тех или иных приложений — это будет делаться автоматически.
Управляющее программное обеспечение ЦОД сможет выделять необходимые ресурсы безотносительно к тому, где физически они находятся. Избавление от необходимости человеческого вмешательства позволит не только ускорить внедрение изменений, но и избежать ошибок и повысить безопасность
В этом идеальном ЦОД низкоуровневые механизмы контроля будут дезагрегировать и затем агрегировать ядра, память, хранение и сеть таким образом, чтобы приложения получали требуемую конфигурацию вне зависимости от реальной компоновки физической инфраструктуры.
Однако инфраструктурные блоки, из которых формируются ЦОД, пока недостаточно гибки: процессор и память тесно привязаны к системной плате сервера, поэтому в такой ситуации выполнить их агрегацию не так просто, нежели в случае, когда они находились бы на разных серверах (например, наподобие жестких дисков).
Как отмечалось выше, чтобы полностью компонуемая инфраструктура и, соответственно, полностью компонуемые центры данных стали реальностью, необходимо, чтобы центральным элементом вычислительной архитектуры стала память, а не процессор (Memory-Centric Architecture, MCA). В то же время архитектуру, ориентированную на работу с памятью, в IDC рассматривают как следующую фазу развития архитектуры после компонуемой/дезагрегированной архитектуры.
КТО ЕСТЬ КТО НА РЫНКЕ CIS
Термин «компонуемая инфраструктура» введен в широкий оборот компанией HPE, которая представила соответствующее решение в 2015 году. В 2017 году, как следует из отчета Forrester, HPE оставалась единственным вендором, чье решение — HPE Synergy — соответствовало определению локальной компонуемой инфраструктурной системы.
По утверждению этого производителя, HPE Synergy можно полностью запрограммировать с использованием единого API. Предлагаемый «инновационный компонуемый интерфейс прикладного программирования» позволяет «с помощью одной строки кода» описать и инициировать необходимую приложению инфраструктуру без трудоемкого написания сценариев.
Между тем в Cisco считают, что решение HPE не отвечает требованиям к компонуемой инфраструктуре. В техническом бюллетене компании, озаглавленном «HPE Synergy: претензии на компонуемость недостаточно, чтобы скрыть сложную инфраструктуру», утверждается, что в данном случае необходимо знать заранее, какие ресурсы понадобятся приложению, а после развертывания системы ее трудно изменить, масштабировать или перепрофилировать.
Соответствующие решения Cisco появились примерно в то же время, что и у HPE, но вскоре компания отказалась от продвижения серверов Cisco UCS M-Series, которые она позиционировала как компонуемые системы. Как было заявлено, «инвестиции перенаправляются на программы, которые позволят реализовать эти возможности во всех решениях UCS».
В свою очередь, авторы технического бюллетеня «HPE Synergy в качестве компонуемой инфраструктуры в сравнении с Cisco UCS» утверждают, что HPE Synergy представляет собой более унифицированное, чем UCS, решение в смысле объединения вычислительных мощностей, емкостей хранения и сетевых ресурсов, при этом оно проще и дешевле в эксплуатации и реализует самую современную — компонуемую — архитектуру.
Тем временем на рынке появился третий претендент. Как прогнозировали в своем отчете авторы Forrester, концепция компонуемой инфраструктуры столь привлекательна, что в 2018 году можно ожидать волну объявлений о выпуске таких систем. Действительно, весной Dell EMC представила Kinetic Infrastructure.
Для описания своей компонуемой архитектуры в Dell EMC используют определение «кинетический». Этим хотят подчеркнуть тот факт, что предлагаемое решение не ограничивается модульным дизайном, а принцип компонуемости распространяется на отдельные устройства хранения — а в конечном итоге на память и другие зависимые устройства, в частности DRAM, SCM, GPU и FPGA.
Помимо признанных вендоров, свои решения предлагают и несколько стартапов. Однако число их невелико, что подчеркивает тот факт, что этот сегмент рынка только начинает формироваться. К тому же, как и Dell EMC, они нередко используют иную терминологию для описания своих решений и иные принципы их реализации.
Так, TidalScale называет свое решение «программно-определяемым сервером». По утверждению разработчика, его технология позволяет объединить несколько серверов в один виртуальный практически любого размера. Процессоры, память и ввод-вывод объединяемых систем агрегируются, при этом нет необходимости вносить какие-либо изменения в используемые ОС и приложения.
Говоря о компонуемой архитектуре, нельзя не упомянуть Intel. В 2013 году компания предложила концепцию масштабируемой архитектуры (Rack Scale Architecture, RSA), предполагающей, что типовые компоненты серверов объединяются в пулы, а не располагаются на системной плате. В результате компоненты оказываются больше не привязаны к конкретному серверу и их можно обновлять независимо.
Intel Rack Scale Design (так теперь называется Rack Scale Architecture) реализует концепцию компонуемой дезагрегированной архитектуры (Composable Disaggregated Infrastructure, CDI). Помимо прочего, он определяет стандартный набор API, которые Intel предложила в качестве расширений платформы управления RESTful Redfish. Открытость предлагаемой архитектуры позволяет избежать зависимости от вендора и гарантирует стабильность и интероперабельность (см. рис. 3).
_600.jpg "Рис. 3. Архитектура Intel Rack Scale Design позволяет динамически комбинировать ресурсы в зависимости от потребностей поддерживаемой нагрузки") |
| Рис. 3. Архитектура Intel Rack Scale Design позволяет динамически комбинировать ресурсы в зависимости от потребностей поддерживаемой нагрузки |
Год назад OpenStack Foundation выпустила 16-ю по счету версию облачной инфраструктурной платформы на базе открытого кода под названием Pike, в которой акцент сделан на компонуемых сервисах. Как утверждается в анонсе, компонуемость делает возможными такие сценарии использования, как граничные вычисления и NFV, при этом модульная архитектура позволяет выбирать, какую функциональность включать в инфраструктурный стек, будь то блочное хранилище или «чистые» серверы.
ЗАКЛЮЧЕНИЕ
Вычислительная инфраструктура существующих центров обработки данных не обладает той степенью гибкости, какая необходима для поддержки всего разнообразия возможных нагрузок, при этом компонуемая инфраструктура обеспечивает такую поддержку одновременно и для унаследованных, и для перспективных нагрузок — «чистых» серверов, виртуальных машин и контейнеров.
Компонуемые системы позволяют оптимизировать использование существующей ИТ-инфраструктуры за счет программно-определяемой агрегации ресурсов, виртуализации имеющихся инфраструктурных активов и программного управления ими. В результате повышается степень использования ресурсов, снижаются капитальные и операционные расходы, появляется возможность быстро адаптировать инфраструктуру к меняющимся нагрузкам.
Как считают в IDC, если не произойдет никаких прорывов в кремниевой фотонике, то программно-определяемая компонуемая архитектура будет развиваться быстрее, чем аппаратная дезагрегация. Совершенствование последней создаст условия для ее включения в компонуемую архитектуру, возможности которой после этого еще больше расширятся.
Дмитрий Ганьжа, главный редактор «Журнала сетевых решений/LAN»