Гиперконвергенция: ИТ-инфраструктура на раз, два, три

За последний год гиперконвергенция стала едва ли не самым модным трендом в ИТ, хотя еще два-три года назад о ней мало кто слышал. Аналитики предсказывают этому сегменту интегрированных решений головокружительные темпы роста — 50–70% ежегодно. Соответствующие устройства уже начали предлагать HPE, EMC и Cisco — крупнейшие игроки рынка серверов, СХД и сетевого оборудования. С чем связана такая популярность гиперконвергентных систем и насколько обоснованны надежды на успешное решение с их помощью задач, с которыми сталкиваются корпоративные ИТ-отделы?

Гиперконвергенция реализует программно определяемый подход к управлению хранением, объединяя средства хранения, вычислительные мощности, сетевые ресурсы и технологии виртуализации в одном физическом устройстве, управление которым осуществляется как единым целым

Позволяя избавиться от выделенной сети хранения, гиперконвергентная инфраструктура фактически реализует виртуальную сеть хранения. Обычно такая SAN предполагает использование виртуального контроллера VSA в виде ВМ

Историю гиперконвергентных решений в их текущем воплощении можно проследить до 2009 года, когда были образованы два стартапа, с которыми они ассоциируются в первую очередь, — Nutanix и SimpliVity. Компания Nutanix вышла на рынок летом 2011 года со своим программно-аппаратным решением Complete Cluster, а спустя полтора года свое гиперконвергентное устройство OmniCube представила SimpliVity (см. рис. 1).

Рис. 1. OmniCube компании SimpliVity — одно из первых гиперконвергентных устройств на рынке. OmniCube в форм-факторе 2U объединяет вычислительные ресурсы, гипервизор, сервисы хранения на базе серверной платформы x86. Помимо единого централизованного управления, поддерживаются такие функции, как встроенное резервное копирование ВМ, дедупликация данных не лету, сжатие и оптимизация на источнике и др.

Что же отличало эти решения? Nutanix предложила три ключевые на тот момент инновации: вычислительные мощности и ресурсы хранения были объединены в единое целое (один уровень) с помощью распределенной файловой системы, аппаратное обеспечение специально адаптировано для поддержки виртуализации с единым управлением всеми ресурсами, а вся система оптимизирована для использования SSD (в то время флеш-накопители не получили еще столь широкого распространения, как сегодня). Такой подход позволял отказаться от отдельной сети хранения, обеспечивал быстрое развертывание и наращивание высокопроизводительной виртуализированной инфраструктуры и сервисов на ее основе (по примеру Google и Facebook).

Ранний выход на рынок позволил Nutanix занять лидирующее положение. Так, по данным IDC, в первой половине 2014 года на ее долю приходилось более половины всех продаж гиперконвергентных решений (52%). Однако уже тогда было ясно, что компании вряд ли удастся надолго сохранить столь высокие показатели. Хотя первоначальное объявление Nutanix о выпуске нового продукта осталось по большей части незамеченным, потенциальный спрос на простые в управлении, быстро развертываемые и относительно недорогие интегрированные решения привлек множество новых игроков — только за последние несколько месяцев таких производителей появилось больше десятка.

Потенциальный спрос, впрочем, быстро превратился в реальный. По данным исследования Actual Tech Media «Состояние рынка гиперконвергентной инфраструктуры», в 2015 году уже почти четверть из более 500 опрошенных компаний (24%) использовали соответствующие решения. Даже с учетом того, что опрос проводился на тематическом сайте и, следовательно, в нем принимали участие те, кто заинтересован в данном решении, цифра впечатляет. По данным IDC, на гиперконвергентные системы приходилось 10,9% рынка конвергентных систем, а Technology Business Research прогнозирует, что к 2020 году их доля возрастет до 32%. Согласно оценкам IDC, уже в этом году объем продаж гиперконвергентных систем составит 2 млрд долларов и к 2019-му достигнет 4 млрд долларов, а по расчетам Gartner, рынок гиперконвергентных интегрированных систем будет ежегодно увеличиваться на 68% — с 371,5 млн долларов в 2014 году до 5 млрд в 2019-м (см. рис. 2).

Рис. 2. Прогноз роста продаж гиперконвергентных систем

На волне растущего интереса перспективный сегмент не мог не заинтересовать и многолетних лидеров ИТ-рынка. Так, в феврале этого года EMC представила интегрированное устройство VxRail (см. подробнее материал автора «Гиперконвергентное устройство VxRail с единым управлением» в «Журнале сетевых решений/LAN», № 3, 2016 год), а в марте свою систему HyperFlex анонсировала Cisco (см. статью Алекcандра Барскова «Гиперконвергенция ради экономии» в № 4, 2016 год). Такие решения, зачастую выпускаемые в партнерстве с кем-либо из стартапов, есть и у других традиционных игроков, в частности у HPE, Dell, Hitachi, Fujitsu и Lenovo. А благодаря функциональности Storage Spaces Direct встроенная поддержка гиперконвергентного кластера появится и в Microsoft Windows Server 2016.

Как свидетельствуют последние анонсы новых продуктов, интерес к этому рынку огромен, но заслуживает ли он того? Буквально за пару лет его основатели, Nutanix и SimpliVity, вошли в круг «единорогов» — стартапов, чья рыночная стоимость превышает миллиард долларов. Так, на конец 2014 года Nutanix оценивалась в 2,2 млрд долларов, а SimpliVity — в 1 млрд долларов на март 2015-го (на основании привлеченного венчурного финансирования). Между тем, даже при реализации оптимистичных прогнозов относительно размера рынка, возникают сомнения в том, что инвесторам удастся быстро вернуть свои вложения — слишком много претендентов на относительно небольшой по размерам пирог (для сравнения, ежегодный оборот таких крупных игроков рынка СХД, как EMC и NetApp, составляет 56 и 15 млрд долларов соответственно).

На самом деле потенциальный приз значительно больше, чем ежегодный оборот в 4–5 млрд, о котором говорят IDC и Gartner (а есть и менее оптимистичные оценки). Зачастую гиперконвергентные устройства рассматриваются как решение для малых и средних предприятий, и многие стартапы их так и позиционируют. Действительно, пока основными потребителями являются предприятия SME и филиалы крупных компаний. Однако и Nutanix, и SimpliVity с самого начала нацеливались на другой рынок, считая приоритетным для себя направлением центры обработки данных, где происходит переход к программно определяемым ЦОДам. А это уже совсем другие объемы. В своем исследовании «Рынок программно определяемых ЦОДов» аналитическое агентство Markets&Markets ожидает, что соответствующий рынок вырастет с 22 млрд долларов в 2015 году до 77 млрд в 2020-м. Но насколько гиперконвергентные устройства подходят для этой задачи? Прежде чем пытаться ответить на этот вопрос, необходимо сначала понять, а что же такое гиперконвергенция.

ОПРЕДЕЛЕНИЕ ГИПЕРКОНВЕРГЕНЦИИ

Если говорить о гиперконвергенции вообще, то это изначальная интеграция в одно целое двух и более разнородных компонентов. Ключевым словом здесь является «изначальная»: для достижения наибольшего эффекта компоненты должны быть интегрированы с нуля, а не просто объединены друг с другом. Так о каких же компонентах идет речь?

В текущем ИТ-дискурсе часто имеются в виду гиперконвергентные системы хранения, однако для краткости упоминание о них опускается. Таким образом, на самом элементарном уровне можно говорить о соединении вычислительных мощностей и ресурсов хранения в одном устройстве. Однако такое расхожее понимание (фактически оно предполагает обычный сервер) жестко критикуется основными отраслевыми игроками, поскольку вендоры вполне обоснованно считают, что оно не отражает всей полноты картины и к тому же фокусируется на отдельном устройстве, упуская из виду соответствующую инфраструктуру (Hyper Converged Infrastructure, HCI). Гиперконвергентные решения представляют собой нечто большее, чем объединение в общий пул вычислительных ресурсов и средств хранения.

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

В узком понимании гиперконвергенция — это программно определяемый подход к управлению хранением, объединяющий средства хранения, вычислительные мощности, сетевые ресурсы и технологии виртуализации в одном физическом устройстве, управление которым осуществляется как единой системой (определение techtarget.com). В широком смысле гиперконвергенция — это объединение вычислительных мощностей, сетевых ресурсов и средств хранения с использованием стандартных компонентов x86 в качестве общих строительных блоков, при этом интеллект больше не привязан к отдельным физическим устройствам — все функции центра обработки данных выполняются как программное обеспечение на гипервизоре (трактовка VMware).

Если первое определение фокусируется на отдельном устройстве и хранении, то второе по своей сути эквивалентно программно определяемому центру обработки данных. Фактически оба определения задают направление развития гиперконвергентных решений: от интегрированных устройств, объединяемых в кластер, к полномасштабному программно определяемому ЦОДу. Однако они опускают ряд важных конкретных деталей — например, отказ от отдельной сети хранения данных (Storage Area Network, SAN).

ГИПЕРКОНВЕРГЕНТНАЯ АРХИТЕКТУРА

Гиперконвергенция предлагает полноценную альтернативу доминирующей модели использования выделенных систем хранения. Она предполагает отказ от отдельного уровня хранения (см. рис. 3), что рассматривается как одно из ключевых преимуществ HCI.

Рис. 3. Гиперконвергенция позволяет упростить архитектуру вычислительных систем за счет отказа от отдельного уровня хранения

Воссоединение вычислительных ресурсов и ресурсов хранения в одном устройстве может породить опасения о возврате в 90-е годы, когда преобладали напрямую подключаемые системы хранения (Directed Attached Storage, DAS). Однако, в отличие от прежних архитектур, гиперконвергентная не приводит к образованию изолированных островков хранения. Чтобы каждый сервер мог воспользоваться ресурсами хранения на других системах, она опирается на программно определяемые решения в области хранения (Software-Defined Storage, SDS).

Программно определяемый подход предполагает трехэтапный процесс: абстрагирование, объединение в пул и автоматизация. Благодаря программному уровню абстрагирования физических ресурсов, все серверы фактически превращаются в узлы единого кластера. Абстрагирование физических компонентов отдельных серверов позволяет объединить в общий пул их ресурсы хранения, которые затем представляются кластеру как связное целое. Автоматизация позволяет упростить и ускорить управление, реализуя различного рода высокоуровневые функции.

Гиперконвергентные системы обычно состоят из нескольких физических модулей (узлов), объединяемых в горизонтально масштабируемый кластер. Каждый из них содержит вычислительное ядро, ресурсы хранения, сетевые компоненты и, как правило, гипервизор. Наличие последнего формально не обязательно, но он имеется во всех основных продуктах известных вендоров, причем нередко на выбор предлагаются два гипервизора или более.

Отдельное устройство (appliance) имеет от одного до четырех узлов, каждый из которых представляет собой самостоятельный сервер с процессором и памятью в общем шасси. Гиперконвергентные кластеры обычно содержат от 4 до 64 узлов, хотя некоторые производители не указывают конкретных пределов масштабируемости. Чтобы узлы могли совместно использовать ресурсы хранения, применяются программное обеспечение для создания виртуальной сети хранения или кластерная файловая система.

Программное обеспечение для реализации гиперконвергентной инфраструктуры может предлагаться как отдельно, так и предустановленным на физические устройства (appliance). Каждый подход имеет свои плюсы и минусы. В случае покупки ПО недостаток заключается в том, что заказчику придется отдельно приобретать оборудование и затем самостоятельно его устанавливать, а преимуществом является возможность самостоятельно выбирать аппаратное обеспечение (в отличие от приобретения готовых устройств с предустановленным ПО). Основную часть предлагаемых на рынке решений составляют полностью готовые самодостаточные вычислительные системы, хотя некоторые стартапы делают ставку на предложение соответствующего ПО (правда, чаще всего заказчики покупают его не напрямую, а уже предустановленным на серверы, чем занимаются OEM-партнеры разработчиков или интеграторы).

Чаще всего поставщики (прежде всего из числа тех же стартапов) разрабатывают свое собственное программное обеспечение для реализации функций хранения и управления либо эти функции выполняются как виртуальная машина на используемом гипервизоре. Так, во многих продуктах используется виртуальное устройство хранения (Virtual Storage Appliance, VSA) для объединения ресурсов хранения в общий пул. Другой подход состоит в использовании платформы VMware EVO:RAIL, своего рода референсной архитектуры, в которой функции хранения и управления интегрированы в соответствующий гипервизор.

Позволяя избавиться от выделенной сети хранения, гиперконвергентная инфраструктура фактически реализует виртуальную сеть хранения (Virtual SAN, VSAN). Обычно такая SAN предполагает использование VSA в виде ВМ. Виртуальное устройство хранения предоставляет функции контроллера хранения для гипервизора в кластере. Ресурсы хранения физичес-кого узла предоставляются VSA. Группа VSA совместно создает виртуальную сеть хранения. Исключением из этого подхода является реализация VSAN компании VMware. Сервисы хранения помещаются непосредственно в ядро vSphere, так что решение полностью интегрируется в vSphere. Однако необходимо использование vSphere 5.5 или более поздних версий.

ЧЕМ ПРИВЛЕКАТЕЛЬНА ГИПЕРКОНВЕРГЕНЦИЯ?

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

В соответствии с известной пропорцией, 80% всего времени тратится на поддержание ИТ-инфраструктуры в должном состоянии и только 20% — на ее стратегическое развитие для решения задач бизнеса, поскольку выполнение текущих операций поглощает большую часть рабочего времени сотрудников ИТ-отделов. Согласно недавнему исследованию IDC, применение гиперконвергентных систем позволило корпоративным ИТ-отделам больше времени уделять инновациям и новым проектам — 29% вместо прежних 16%. Кроме того, в результате удалось увеличить долю ИТ-бюджета, направляемую на новые проекты, — с 43 до 56%. И это только одно из потенциальных преимуществ реализации гиперконвергентной инфраструктуры. Аналитики из 451 Research утверждают, что поставщики HCI наиболее часто выделяют еще четыре.

Сокращение числа управляемых систем. Один гиперконвергентный узел объединяет вычислительные и СХД-ресурсы, что, соответственно, ведет к сокращению числа отдельных устройств и, как следствие, уменьшению количества объектов, которые надо приобретать, устанавливать и обслуживать. Кроме того, более простому развертыванию и обслуживанию гиперконвергентных устройств способствует то, что они базируются на стандартных серверных компонентах (это не требует знания проприетарного оборудования поставщиков традиционных СХД). Наконец, наличие во многих решениях интегрированных инструментов управления упрощает задачи администрирования.

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

Упрощение масштабирования. Как отмечают аналитики 451 Research, масштабирование систем хранения всегда было трудным делом: после заполнения имеющихся полок для дисков либо приобреталась еще одна система, которой приходилось управлять отдельно, либо осуществлялся переход на более крупную систему. В отличие от них, гиперконвергентные системы рассчитаны не на вертикальное (scale-up), а на горизонтальное (scale-out) масштабирование. Когда возникает необходимость в дополнительной вычислительной мощности, ИТ-отделу достаточно приобрести еще один узел и добавить его к имеющемуся кластеру. По сравнению с традиционными и конвергентными решениями типичный квант наращивания значительно меньше.

Фокус на ВМ. Гиперконвергентные продукты изначально создавалиcь в расчете на поддержку виртуальных сред. Так, многие поставщики разрабатывали свое программное обеспечение с учетом того, что управление хранением должно осуществляться с точки зрения виртуальных машин, а не СХД. Традиционные системы хранения оптимизированы для управления LUN. Однако, когда на хосте выполняются несколько ВМ, все они зачастую хранятся в одном LUN. Эта особенность затрудняла применение индивидуальной политики хранения для ВМ, к тому же оно происходило на уровне системы хранения.

В противовес такому подходу ВМ-центричные гиперконвергентные платформы позволяют применять политику к отдельным ВМ, назначая для каждой свои правила резервного копирования, тиражирования и т. д. В конечном итоге для ИТ-администраторов приоритетом является управление ВМ, а не инфраструктурными составляющими. А инструменты управления HCI позволяют контролировать всю гиперконвергентную среду с одной административной консоли. Тем самым повышается возможность маневрирования (agility), так как ВМ можно быстро перемещать между узлами в ответ на изменившиеся требования.

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

Использование локального кэша на базе флеш-накопителей повышает производительность при работе с данными, однако какой может быть реальная производительность гиперконвергентного кластера при его масштабировании до нескольких десятков узлов? Если виртуальная машина функционирует на конкретном узле, то данные распределяются между узлами (см. рис. 4). Новые записи сегментируются, обычно по числу узлов. Каждый сегмент передается через коммутатор всем узлам в кластере. И это только одна операция. А насколько большим окажется сетевой трафик, когда потребуется выполнить десятки тысяч операций ввода-вывода в секунду (а ведь помимо этого происходит обычная передача данных между серверами и между серверами и пользователями). Все это ставит вопрос о качестве и производительности сетевой инфраструктуры.

Рис. 4. Данные распределяются между всеми узлами в кластере

А КАК ЖЕ СЕТЬ?

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

Использование конвергентной инфраструктуры ведет к резкому увеличению объемов трафика в направлении восток — запад. До недавнего времени самым узким местом были системы хранения. Решением этой проблемы стало появление твердотельных накопителей, но в результате потенциально узким местом оказалась сеть. Большинство поставщиков гиперконвергентных решений успешно справляются с трафиком восток — запад внутри модулей. Некоторые из них рекомендуют ту или иную архитектуру для межсоединения и нередко включают небрендированные коммутаторы с предустановленной ОС (white box) в каждый модуль. Однако это не означает, что соединения между узлами масштабируются аналогичным образом. Гиперконвергентная инфраструктура требует изменения многих традиционных сетевых технологий.

Межсоединение узлов является потенциально слабым местом гиперконвергентных решений. Поставщики фокусируются на вычислениях и хранении, обещая линейное масштабирование путем добавления узлов. Гиперконвергентное программное обеспечение хорошо справляется с интеграцией новых узлов, но подходит ли для успешного решения этой задачи физический уровень? Межсоединение узлов осуществляется на основе уже имеющейся сетевой инфраструктуры. Узлы кластера взаимозависимы, поэтому любая неисправность сетевой карты, коммутатора или соединительных кабелей может отрицательно повлиять на функционирование всего кластера. В некоторых случаях это не представляет проблемы, поскольку в ЦОДе уже имеется быстрая и надежная сеть. Однако гораздо больше вероятность того, что существующая сеть не способна поддерживать межсоединения с низкой задержкой, что требуется для гиперконвергентных решений.

Иногда необходимая кабельная и сетевая инфраструктура попросту отсутствует, и подключить очередной узел некуда. Между тем часто очень мало времени при реализации уделяется планированию различных компонентов сетевой инфраструктуры и межсоединению узлов между собой. Как показывает весь предшествующий отраслевой опыт, во многих компаниях, особенно небольших, стремятся использовать как можно более дешевые кабельные компоненты, недорогие сетевые карты и бюджетные коммутаторы. Но сможет ли такая инфраструктура обеспечить надежные высокоскоростные соединения между узлами кластера?

Установка коммутаторов с высокоскоростными портами (10G+) в верхней части стойки или в конце ряда проблемы не решает: повышения производительности недостаточно, помимо этого сеть должна обеспечить контроль за созданием соединений и выделением пропускной способности. Программно определяемые коммутируемые фабрики предоставляют необходимую гибкость и средства автоматизации для управления трафиком между модулями, однако это ведет к значительному усложнению сетевой инфраструктуры, что входит в противоречие с одной из главных целей HCI — упрощением использования ИТ. Таким образом, некоторые отсутствующие в модулях HCI специализированные функции управления сетью придется пока воссоздавать на уровне агрегации или ядра.

Если многим поставщикам гиперконвергентной инфраструктуры еще предстоит найти эффективный способ создания межсоединений, то от такого сетевого вендора, как Cisco, можно было ожидать, что при выпуске своей гиперконвергентной системы HyperFlex он заранее позаботится о поиске подходящего решения. И действительно, в архитектуре HyperFlex, как и в USC, на которой она базируется, за организацию всех соединений отвечают два коммутатора Fabric Interconnect 6248s (серию 6300 с портами 40 Гбит/с в Cisco считают пока избыточной для создания HCI). Это обеспечивает единое управление как сетевыми соединениями, так и гиперконвергентными и вычислительными узлами (в кластер HyperFlex можно добавлять блейды). Как утверждает производитель, после развертывания кластера его можно масштабировать до максимального размера без необходимости вносить изменения в сеть.

ГЛАДКО БЫЛО НА БУМАГЕ

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

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

Программному обеспечению хранения, как в случае VSA, приходится конкурировать с другими виртуальными машинами и процессами за процессорное время (по некоторым оценкам, оно потребляет до 20–30% процессорного времени), так что производительность ввода-вывода может значительно варьироваться. Поскольку многие гиперконвергентные решения появились совсем недавно и являются довольно сложными по своему внутреннему устройству, можно априори утверждать, что в них наверняка имеются те или иные ошибки и баги. Программное обеспечение распределено между всеми узлами и взаимодействует с дисками и накопителями по собственным правилам. Если оно вдруг перестанет функционировать, то это чревато потерей всей инфраструктуры и всех данных. Таким образом, речь идет о потенциальной точке общесистемного отказа.

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

Возможно, главным препятствием на пути гиперконвергенции является человеческий фактор: широкое распространение нового подхода требует серьезных организационных изменений — от модели закупок до структуры ИТ-отдела. В перспективе широкое использование гиперконвергентных решений способно привести к полному отказу от традиционных систем хранения (хотя это вовсе не обязательно, так как необходимо осуществлять поддержку множества «унаследованных» приложений). Между тем во многих организациях зоны ответственности администраторов традиционно разделены, а значит, те, кто обслуживает системы хранения, могут воспринимать HCI как угрозу своему положению и своей работе, что может вызвать сопротивление со стороны сотрудников. Конечно, этот фактор способен проявиться в первую очередь в крупных компаниях, поскольку в небольших и средних ИТ-специалисты зачастую являются универсалами и упрощение управления будут только приветствовать.

ОТ ЦОДА ДО САМЫХ ДО ОКРАИН

Гиперконвергентные устройства рассматриваются прежде всего как решения для небольших компаний, и многие поставщики позиционируют их именно так. Однако в отчете «Состояние рынка гиперконвергентной инфраструктуры», подготовленном ActualTech Media, утверждается: чем больше организация, тем выше вероятность того, что она уже использует гиперконвергентные решения. Правда, крупные компании приобретают их преимущественно для установки в своих филиалах и удаленных офисах.

Основным приложением, для поддержки которого изначально использовались гиперконвергентные устройства, были тонкие клиенты — виртуальные рабочие места (Virtual Desktop Infrastructure, VDI). Как отмечают эксперты ActualTech Media, хотя VDI остается важным драйвером для внедрения HCI, сегодня она все более широко применяется и для других рабочих нагрузок. Гиперконвергентная инфраструктура изначально рассчитана на поддержку виртуальных машин, а значит, и любых нагрузок в виде ВМ.

Так, помимо поддержки VDI, в SimpliVity выделяют целый ряд сценариев применения для гиперконвергентных устройств, в том числе поддержку критичных для бизнеса приложений (Tier I application). Среди других возможных применений называются создание среды для тестирования и разработки, модернизация резервного копирования, восстановление после аварий, упрощение администрирования удаленных площадок, плавная модернизация унаследованной инфраструктуры и, наконец, консолидация серверов и центров обработки данных.

Многие аналитики сомневаются в том, что HCI в виде гиперконвергентных устройств подходит для поддержки критичных для бизнеса приложений и является адекватным решением для модернизации ЦОДа. Такие приложения, как ERP и CRM, придется переписывать или оптимизировать для работы в распределенной среде. Поэтому для их поддержки больше подходят конвергентные (а не гиперконвергентные) решения с традиционной архитектурой. В ЦОДах могут острее проявиться такие слабые места гиперконвергентных устройств, как межсоединение узлов (поддержка сети) и ограниченная масштабируемость. Однако с появлением гиперконвергентных архитектур EVO:RAIL от VMware и VxRack от EMC инфраструктура HCI может получить более широкое распространение в ЦОДах.

Рис. 5. Планы внедрения гиперконвергентной инфраструктуры в зависимости от размера компании в ближайшие 2–3 года

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

Дмитрий Ганьжа — главный редактор «Журнала сетевых решений/LAN». С ним можно связаться по адресу: diga@lanmag.ru.