Виртуализация всех основных компонентов ИТ-инфраструктуры — вычислений, хранения и сети — открыла возможность для реализации полностью программно определяемого центра обработки данных. Несмотря на обещание таких преимуществ, как автоматизация, гибкость и масштабируемость, организациям прежде всего необходимо понять, нужен ли им SDDC и для чего именно. Но сначала следует отделить правду от вымысла. Это и попытались сделать участники дискуссии «Программно определяемые ЦОДы: что, зачем и как» с участием экспертов EMC, SimpliVity, Cisco и Mellanox, которая прошла в рамках форума «МИР ЦОД – 2016. Инфраструктура».

Виртуализация всех основных компонентов ИТ-инфраструктуры — вычислений, хранения и сети — открыла возможность для реализации полностью программно определяемого центра обработки данных. Несмотря на обещание таких преимуществ, как автоматизация, гибкость и масштабируемость, организациям прежде всего необходимо понять, нужен ли им SDDC и для чего именно. Но сначала следует отделить правду от вымысла. Это и попытались сделать участники дискуссии «Программно определяемые ЦОДы: что, зачем и как» с участием экспертов EMC, SimpliVity, Cisco и Mellanox, которая прошла в рамках форума «МИР ЦОД – 2016. Инфраструктура».  

В программно определяемом ЦОДе (Software-Defined Data Center, SDDC) вся инфраструктура виртуализирована и предоставляется как сервис. Это достигается благодаря высокому уровню автоматизации всех процессов управления, что упрощает развертывание облачных сервисов, способствуя их более широкому использованию. Неслучайно SDDC называют базисом для следующего поколения облачных вычислений и облачных сервисов.

ИЗ ЧЕГО СДЕЛАН SDDC 

Концепция SDDC появилась вместе с виртуализацией вычислений, и сейчас виртуальные серверы получили едва ли не повсеместное распространение в корпоративных инфраструктурах. Однако программно определяемые (читай, виртуализированные) сети и системы хранения еще не достигли такого уровня развития и распространения. «Технологии, обес- печивающие возможность создания программно определяемого ЦОДа, то есть технологии виртуализации вычислительных ресурсов, сети и СХД, существуют на рынке давно, — отмечает Андрей Николаев, руководитель облачного направления компании EMC. — Никто не сомневается в полезности виртуализации вычислительных ресурсов: 99% компаний используют гипервизоры. Что же касается сети и СХД, то ситуация не такая однозначная, поскольку остается вопрос, нужна для них виртуализация или нет».

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

Согласно формальному определению Forrester Research, SDDC — это интегрированный уровень абстракции, который полностью определяет центр обработки данных посредством программного уровня, представляющего ресурсы ЦОДа в виде пулов виртуальных и физических ресурсов и позволяющего их комбинировать для поддержки произвольных определяемых пользователем сервисов. Александр Скороходов, системный инженер-консультант Cisco, обращает внимание на две стороны понятия SDDC: «Первое — инфраструктурные соображения: например, каким образом происходит реализация хранения, вычислений и сетевого транспорта. Второе, и главное, — как ресурсы ИТ-инфраструктуры потребляются заказчиком и оператором ЦОДа». В Cisco, к слову, такой ЦОД предпочитают называть не программно определяемым, а управляемым в соответствии с правилами, делая акцент не на реализации, а на использовании. 

Помимо трех ключевых компонентов SDDC (программно определяемых вычислений, программно определяемого хранения и программно определяемых сетей), имеется еще и четвертый — уровень оркестрации (управления). В традиционных ЦОДах приходится тратить немало сил и средств на повседневные задачи по управлению и обслуживанию аппаратного обеспечения, а изменение или добавление новых ресурсов отнимает много времени и может оказаться сложной задачей. Одно из главных преимуществ SDDC, по сравнению с традиционными аппаратно-зависимыми центрами обработки данных, состоит в значительном упрощении управления ЦОДом, что способствует увеличению скорости выделения и предоставления всех видов ресурсов и, как следствие, достижению более гибкой и оперативной реакции на запросы рынка. При автоматизированном предоставлении ресурсов в соответствии с заданными правилами развертывание новых приложений занимает несколько минут. «От инфраструктуры требуется слой, с которым смогут взаимодействовать все остальные и который способен выделять ресурсы, — указывает Евгений Красиков, системный архитектор компании SimpliVity. — Если мы внедряем приложение, то делаем это ради приложения, а инфраструктура — всего лишь то необходимое, что нужно построить». 

Тем не менее важность инфраструктуры не стоит недооценивать — в конечном счете именно расширение ее базовых возможностей и повышение производительности сделали возможным перенос интеллекта на программный уровень. «Чтобы выполнить какую-нибудь облачную задачу в виртуальной машине, нужна вычислительная инфраструктура, которая способна ее нормально отработать, — отмечает Александр Петровский, системный инженер компании Mellanox. — Поэтому не совсем корректно предполагать, что переход к программно определяемым инфраструктурам приведет к полной стандартизации инфраструктуры и уходу интеллекта в программную плоскость». По его мнению, часть задач, в том числе по выполнению функций сети и СХД, гораздо эффективнее решать на аппаратных платформах. И в этом плане важно, какие логику и интеллект имеет сама инфраструктура: с одной стороны, она должна позволить получить все преимущества SDDC и виртуализации, а с другой — не жертвовать производительностью, надежностью и качеством сервисов. 

ГИПЕРКОНВЕРГЕНТНАЯ ИНФРАСТРУКТУРА КАК ОСНОВА SDDC? 

Как было отмечено выше, современная концепция SDDC ведет свое начало от виртуальных вычислений, однако история программно управляемых ЦОДов началась несколько раньше, в начале 2000-х годов, с выпуском первых конвергентных решений (иногда называемых «ЦОД из коробки»). Они появились как способ противодействия растущей сложности реализации ЦОДов из-за огромного разнообразия используемого аппаратного и программного обеспечения. Первой коммерческой реализацией этого подхода эксперты Forrester Research считают Utility Data Center компании HP. UDC имел графический интерфейс, с помощью которого можно было «конструировать» серверную ферму, добавляя серверы, устройства хранения, сетевые компоненты, балансировщики нагрузки, МСЭ и т. п. Однако он оказался слишком дорогим (1 млн долларов в минимальной конфигурации), к тому же ресурсы выделялись физические (серверы в стойке), а не виртуальные — это было еще до эры виртуализации. 

Современные гиперконвергентные решения с поддержкой виртуализации появились 6–7 лет назад, наиболее известный их представитель Vblock от VCE (альянса EMC, VMware и Cisco) был представлен в 2009 году. Если рынок традиционных «дискретных» инфраструктурных ИТ-решений не растет, стабилизировавшись на уровне 80 млрд долларов, то рынок конвергентных решений за последние пять лет вырос почти в четыре раза — с 3,4 млрд до 12,1 млрд долларов. По словам Андрея Николаева, организации выбирают конвергентные решения, когда хотят отказаться от ответственности за «самосбор» при построении ЦОДа, чтобы им не приходилось самим покупать, собирать и обслуживать отдельные компоненты, поступившие из разных источников. В случае конвергентной инфраструктуры поставщик обеспечивает все, начиная с установки и запуска под ключ решения до оказания технической поддержки как аппаратных, так и программных компонентов, которые входят в его состав. По сути, это новая модель поставки и эксплуатации любой ИТ-инфраструктуры как единой системы. 

В результате меняются и подходы к построению центров обработки данных. В своем докладе на форуме Андрей Тамбовский, директор по технологиям компании «ФОРС», выделяет три основных. В первом случае сотрудники организации сами все знают и подбирают оборудование, исходя из своего понимания того, чем занимается их компания, что ей нужно, продукция каких вендоров лучше всего подходит для решения поставленных перед ними задач. При втором подходе решение реализуется командой специалистов компании, интегратором или даже вендором в соответствии с набором полученных инструкций из предопределенного набора кубиков. Наконец, есть и третий вариант: оборудование поступает с завода в собранном виде, сразу же устанавливается и запускается, что позволяет значительно ускорить процесс внедрения и облегчить последующую эксплуатацию. 

Вместе с тем в последнее время все большую популярность приобретают гиперконвергентные решения (см. рис. 1). По мнению Евгения Красикова, если главное отличие конвергентных решений от традиционных состоит в способе закупки, то различие между конвергентными и гиперконвергентными заключается в том, что во вторых внутри системы используется единая технология (об особенностях гиперконвергентных решений см. подробнее статью автора «Гиперконвергенция: ИТ-инфраструктура на раз, два, три» в июньском номере «Журнала сетевых решений/LAN» за этот год). 

Как считают в EMC, современная инфраструктура ЦОДа должна состоять из конвергентных либо гиперконвергентных решений (см. рис. 2). Вместе с тем, по словам Андрея Николаева, гиперконвергентные решения не способны, по крайней мере пока, решить все задачи, связанные с построением ЦОДа. «Гиперконвергентные системы хорошо справляются с определенными видами нагрузок, но для отдельных приложений и задач требуется классическая ИТ-инфраструктура — например, для высококритичных приложений, где необходимы высокий уровень отказоустойчивости, защита на аппаратном уровне, аппаратная репликация», — объясняет он.  

Соглашаясь с тем, что гиперконвергентные решения не являются ответом на все вопросы, Александр Скороходов предлагает рассматривать их в качестве доступного и простого примера SDDC. «Тем заказчикам, которые пытаются понять, о чем идет речь, — замечает он, — будет полезно ознакомиться с возможностями гиперконвергентных решений». Кроме того, по его мнению, гиперконвергентные системы имеют ограниченную применимость не только для высококритичных приложений, но и для противоположной части спектра — полностью облачных (cloud native) приложений.

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

БУДУЩЕЕ SDDC СВЯЗАНО С ОТКРЫТЫМ КОДОМ 

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

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

Многие вендоры идут по пути применения внутри своих устройств продуктов общего назначения, добавляя некую собственную интеллектуальную составляющую, которая и делает решение работоспособным. При этом они стремятся к тому, чтобы оно было максимально открытым для пользователей. «Если говорить о создании того же самого SDDC на базе VMware или OpenStack, то на уровне оркестрации все строится на базе продуктов разных вендоров: вы сможете брать какие-то ресурсы и выделять под конкретную задачу, — объясняет Андрей Николаев. — Да, на уровне системного администратора могут быть нюансы, связанные с администрированием тех или иных элементов ИТ-инфраструктуры, но для потребителей все будет выглядеть как некий единый пул ресурсов. Все производители так или иначе стремятся применять открытые технологии на более высоком уровне». 

Вместе с тем, как указывает Александр Петровский, на рынке имеется все необходимое, так что компании с определенным уровнем компетенции ИТ-персонала имеют возможность создать полностью открытые и адаптированные к существующим потребностям решения на базе готовых продуктов, решений и технологий с открытым исходным кодом, в том числе с нужным уровнем производительности: «На наших глазах происходит смена парадигмы. Компании уровня Google и Facebook в погоне за сокращением издержек готовы создавать для себя конкретные рабочие решения, состоящие из открытых компонентов. И теперь их примеру готовы следовать крупные организации и сервис-провайдеры». 

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

SDDC КАК ОСНОВА ДЛЯ ОБЛАКА 

Обеспечивая предоставление ресурсов по запросу, программно определяемый центр обработки данных уже обладает многими чертами облачного ЦОДа. «Конечной целью внедрения SDDC является построение полноценного частного облака, когда есть уровень оркестрации для управления тремя основными инфраструктурными компонентами (серверы, сеть, хранение) и имеется портал самообслуживания, где владельцы приложений и ВМ могут заказать ресурсы», — рассказывает Андрей Николаев. «Мы можем называть или не называть [SDDC] облаком, но все чаще видим, что заказчик выбирает ту или иную программную экономическую модель потребления ресурсов и выстраивает под нее инфраструктурные компоненты как способ реализации этих требований», — отмечает Александр Схороходов. 

Как считают в Gartner, к 2020 году три четверти всех крупнейших предприятий из числа Global 2000 будут считать использование SDDC обязательным для реализации гибридной облачной модели и таких подходов, как DevOps. Уже сейчас, по данным отчета «Рынок программно определяемых ЦОДов» аналитического агентства Markets and Markets, соответствующий рынок оценивается в 25 млрд долларов, а к 2021 году он должен вырасти до 83 млрд при ежегодном темпе роста 26,57%. Как указывается, драйвером этого роста является потребность в экономически эффективных решениях, гибкости, масштабируемости и централизованном управлении всем центром обработки данных.