Виртуализация всех основных компонентов ИТ-инфраструктуры — вычислений, хранения и сети — открыла возможность для реализации полностью программно определяемого центра обработки данных. Несмотря на обещание таких преимуществ, как автоматизация, гибкость и масштабируемость, организациям прежде всего необходимо понять, нужен ли им 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 и виртуализации, а с другой — не жертвовать производительностью, надежностью и качеством сервисов.

 

Открытая облачная инфраструктура от NEC

Облачные платформы для ЦОДов на базе OpenStack получили импульс для развития в 2014–2015 годах, после того как в 2014-м вышел релиз, обеспечивающий единое управление всеми тремя составляющими ИТ-инфраструктуры (СХД, сеть и серверы), поддержку основных гипервизоров для серверов, виртуализации СХД и сетевой инфраструктуры, а также управление контейнерами для развертывания различных ОС, баз данных и компонентов NFV в рамках общей инфраструктуры. Когда появились такой механизм и возможность внедрять его достаточно быстро, OpenStack стал серьезным конкурентом для основных коммерческих платформ. Как отметил в своем выступлении на форуме «МИР ЦОД – 2016» Алексей Стребулаев, менеджер по маркетингу и развитию бизнеса из компании «NEC Нева Коммуникационные Системы», внимание в развитии облачных платформ сосредоточено на Open Source, потому что ни один крупный производитель не обладает ресурсами, достаточными для обеспечения необходимой динамики развития платформ.

На пути к программно определяемому центру обработки данных
Общая стоимость владения облачным ЦОДом на базе NEC Cloud IaaS оказывается более чем в два раза меньше, чем ЦОДом с традиционной архитектурой

 

Для коммерческого использования NEC предлагает две облачные платформы на базе программного обеспечения с открытым исходным кодом: NEC Cloud IaaS и NEС Cloud System. Первая предназначена для КЦОДов, нацеленных на телеком-операторов, то есть для хостинга высококритичных телекоммуникационных платформ, а вторая представляет собой более легкую и простую платформу, ориентированную как на новые технологии Интернета, так и на различные варианты частного облака и небольших ЦОДов. На основании опыта эксплуатации собственного ЦОДа на базе NEC Cloud IaaS компания утверждает, что стоимость владения облачным ЦОДом оказывается в два раза меньше, чем традиционным. Частично сокращение затрат достигается за счет эффективных технологий охлаждения (у NEC, кроме ИТ-инфраструктуры, есть системы охлаждения, литиевые батареи, гарантированное питание). Однако около 30–40% экономии приносят виртуализация и программные решения. Производитель заявляет, что, если сравнивать с традиционным ЦОДом, NEC Cloud System может быть внедрена намного быстрее: в стандартном модельном варианте можно построить ЦОД в течение 3–4 месяцев.

Помимо компонентов OpenStack, используются и компоненты собственной разработки, однако после кастомизации решения в соответствии с требованиями пользователя код становится достоянием сообщества Open Source. «NEC не производит коммерческих реинкарнаций/вариантов различных платформ с открытым кодом. Если нам что-то надо, мы берем открытый код, дорабатываем и снова открываем его, — говорит Алексей Стребулаев. — Поэтому все, что мы построили, в дальнейшем может эксплуатироваться без участия NEC». По мнению специалистов компании, пока с помощью OpenStack может быть реализовано только 30% необходимой функциональности облачных платформ. Все остальное — либо дополнительные компоненты с открытым кодом, либо заказной код, который написан либо для конкретного заказчика, либо под конкретную модель корпоративного ЦОДа, частного или публичного облака.

Чтобы выяснить, чего в OpenStack не хватает, NEC провела исследование рынка, а также обобщила свой опыт эксплуатации коммерческих ЦОДов на базе NEC Cloud IaaS. Как оказалось, прежде всего нужна интеграция распределенных ЦОДов (то есть распределенной физической инфраструктуры) в единый виртуальный ЦОД, которая осуществляется на базе SDN. Такая распределенная инфраструктура позволяет упростить и оптимизировать функции резервного копирования и восстановления после аварий, управление же распределенными площадками осуществляется как единым ЦОДом. При аварии за счет распределенной инфраструктуры и используемых технологий SDN единый виртуальный ЦОД имеет повышенную живучесть и продолжает обслуживать пользователей и предоставлять сервисы.

NEC не привязывает свою платформу к какому-либо производителю или «железу», отдельному компоненту или коммерческому ПО. Компания имеет собственную команду поддержки OpenStack и может выступать в качестве «одного окна» с точки зрения поддержки всей развернутой инфраструктуры. Вместе с тем заказчик вправе в любой момент отказаться от ее услуг, чтобы заниматься обслуживанием системы либо самостоятельно, либо взаимодействуя с дистрибьютором / сообществом OpenStack.

 

ГИПЕРКОНВЕРГЕНТНАЯ ИНФРАСТРУКТУРА КАК ОСНОВА 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» за этот год).

Рис. 1. Эволюция интегрированных систем
Рис. 1. Эволюция интегрированных систем 

 

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

Рис. 2. Cовременная инфраструктура ЦОДа, как утверждают в EMC, должна состоять из конвергентных либо гиперконвергентных решений. Компания VCE (контрольный пакет акций принадлежит EMC) предлагает три соответствующих решения: конвергентный стек Vblock, гиперконвергентные стойки VxRack и гиперконвергентные устройства VxRail
Рис. 2. Cовременная инфраструктура ЦОДа, как утверждают в EMC, должна состоять из конвергентных либо гиперконвергентных решений. Компания VCE (контрольный пакет акций принадлежит EMC) предлагает три соответствующих решения: конвергентный стек Vblock, гиперконвергентные стойки VxRack и гиперконвергентные устройства VxRail

 

Соглашаясь с тем, что гиперконвергентные решения не являются ответом на все вопросы, Александр Скороходов предлагает рассматривать их в качестве доступного и простого примера 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%. Как указывается, драйвером этого роста является потребность в экономически эффективных решениях, гибкости, масштабируемости и централизованном управлении всем центром обработки данных.

Дмитрий Ганьжа, главный редактор «Журнала сетевых решений/LAN»

Купить номер с этой статьей в PDF