Программно-конфигурируемый ЦОД. Грамотный выбор

Илья Владимирович, руководитель отдела виртуализации, компания «ЛАНИТ-Интеграция» (группа компаний ЛАНИТ)
Илья Владимирович, руководитель отдела виртуализации, компания «ЛАНИТ-Интеграция» (группа компаний ЛАНИТ)

В ИТ-отрасли быстро становятся популярными громкие маркетинговые названия. На Западе их называют buzzword, что означает «умное словечко». Бывает, пропустишь пару конференций и перестаешь вообще понимать, о чем говорят с трибуны. А Интернет часто выдает тексты, прошедшие через машинный перевод и «жернова» отдела маркетинга. Самое неприятное, что из-за вакханалии с терминами все труднее общаться с заказчиками. Предлагаю на этот раз разобраться с Software Defined Datacenter (SDDC), или программно-конфигурируемыми ЦОД (ПКЦОД): что же это такое, чем отличается от конвергентной или гиперконвергентной среды, как это понятие связано с облачной концепцией и всякими «аджайлами», «девопсами» с «вэбскейлами».

Рождение концепции

В 2012 г. на конференции VMworld первым про SDDC рассказал Стивен Херрод, представивший совместную концепцию VMware и EMC. Эти компании произвели революцию в ИТ, показав миру лучшую платформу серверной виртуализации. По словам Херрода, ПКЦОД – это ЦОД, где все физические ресурсы виртуализованы и абстрагированы от «железа», конфигурируются из единой точки с помощью специализированного ПО и предоставляются «как сервис».

Конечно, если мы говорим о ЦОД, который необходимо программно-конфигурировать, то в 99% случаев это ИТ-инфраструктура организации, для которой ИТ не являются профильным бизнесом. Оставшийся 1% – это ЦОД поставщиков облачных услуг, ориентированных на оказание услуг подавляющему большинству.

Итак, здесь нужно запомнить, что SDDC – это концепция, придуманная компанией VMware, предполагающая использование продуктов этой компании со всеми их плюсами и минусами для решения определенных задач. Поэтому в основе SDDC – видение именно VMware.

Множество производителей подхватили новый термин и начали подстраивать под новый концепт свои продукты. Однако до сих пор единого стандарта так и не появилось: SDDC называют все подряд.

Многострадальный сервис

Сервис – это как раз то, ради чего все и затевалось. Это слово фигурирует во всех концепциях последнего времени. Под сервисом в SDDC, Cloud, Lean IT, Service Oriented Infrastructure понимается услуга в терминах ITSM, которую ИТ-служба оказывает другим подразделениям. В свою очередь, слово «сервис» в Service Oriented Architecture, Web-Scale имеет отношение к архитектуре самого программного обеспечения и к тому, как компоненты взаимодействуют друг с другом.

Отсюда правило: слышите про сервис, вспоминаете про ITSM и сервис-ориентированную модель вашей ИТ-службы.

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

 

Как устроен ПКЦОД

Что же необходимо сделать? Во-первых, усовершенствовать и автоматизировать организационный процесс прохождения заявки на выделение необходимых ресурсов под сервис: необходима единая точка, портал, где процесс прохождения заявки выполнялся бы в автоматическом режиме, а процесс согласования производился бы кликом мыши.

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

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

В идеале было бы неплохо создать единую систему, способную управлять инфраструктурой и обрабатывать заявки. Это позволит сократить до минимума временной интервал между обработкой заявки и непосредственным исполнением заказа.

Результатом всех ваших шагов и будет программно-конфигурируемый ЦОД согласно концепции VMware.

В минимальной конфигурации он должен состоять из:

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

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

 

Строим традиционно, быстро и дорого

Как только с помощью компании VMware был сформирован спрос на SDDC, производители аппаратного обеспечения объединились в альянсы и стали предлагать законченные, предварительно сконфигурированные, идеально подогнанные наборы оборудования, которые вначале были названы референсными архитектурами, а позже конвергентными платформами или «апробированными дизайнами».

На рынке сейчас представлены два основных решения для конвергентных сред: vBlock – продукт альянса VMware, Cisco, Dell и EMC; FlexPod – продукт сотрудничества NetApp, Cisco и VMware.

VBlock – настоящая конвергентная инфраструктура, имеющая собственный SKU и состоящая из следующих компонентов: средства виртуализации от VMware, коммуникация в виде коммутаторов Cisco, вычислительная часть в виде серверов Dell, системы хранения данных от EMC и все конструктивные компоненты (стойки, кабели, ИБП). Продается «одной коробкой».

FlexPod попадает в категорию референсных архитектур. Сетевая часть строится на базе конвергентных коммутаторов Nexus. Вычислительная часть – на базе серверов Cisco UCS. Системы хранения – от NetApp. Любое из решений обеспечит вас унифицированной платформой для дальнейшего построения SDDC. Какую выбрать, решать вам. vBlock менее гибок и позволяет строить SDDC только «по заветам» VMware. На базе FlexPod, в принципе, можно построить что угодно. Есть готовые архитектуры под VMware, Microsoft, Oracle, SAP. Чтобы превратить это «железо» в SDDC, вам теперь потребуются средства автоматизации для остальных двух слоев.

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

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

Строим инновационно и страшно

Что значит «гиперконвергентность»? Если объяснять совсем просто, то это объединение всех трех компонентов (вычислительной части, сетевой части, хранения) в один стандартный юнит – Web-Scale. Вся интеллектуальная часть, к примеру репликация данных СХД или нарезание VLAN в сети, реализуется средствами специализированной программной платформы и управляется из единого интерфейса. Достаточно взять набор максимально простых серверов х86 c большим количеством дисков и построить плоскую сеть. Вся интеллектуальная составляющая ляжет на специализированное ПО, которое работает на этих серверах.

Основные составляющие любой гиперконвергентной платформы:

  • платформа серверной виртуализации, которая обеспечивает абстрагирование от «железа» вычислительной части;
  • SDS (программно-конфигурируемое хранилище данных) – набор специализированного ПО, обеспечивающего абстрагирование логики хранения от нижележащего «железа»;
  • SDN (программно-конфигурируемая сеть) – набор технологий, отделяющих уровень управления от сетевого оборудования.

Какие преимущества это дает? Представьте себе: недостаточно мощности сети, добавил сервер. Не хватает файерволов, добавил еще сервер. Мало ресурсов хранения? Правильно, добавил еще сервер.

Как будем строить конвергентную платформу? Как и с классической архитектурой, вариантов два: взять готовое решение или собирать самому.

Первое очевидное решение – VMware. Оно состоит из платформы виртуализации vSphere, программно-конфигурируемого хранилища vSAN и SDN-решения NSX. Аппаратную платформу можно собирать самому, ориентируясь на Compatibility List, или взять готовую EVO SDDC от любого производителя, который подписал договор с VMware.

EVO SDDC – это тот же vBlock, только более инновационный. Типовой блок EVO включает в себя восемь серверов, два коммутатора 10 Gbit, два spine-коммутатора для связи между стойками. Как и в vBlock, все уже собрано за вас.

Ближайшим конкурентом EVO в части гиперконвергентных платформ является Nutanix – очень интересное решение по объединению вычислительной части и части хранения в рамках одного устройства. Решение является гипервизоронезависимым, т. е. разворачивать виртуальные машины можно на чем угодно, хоть на ESX, хоть на KVM. Собственного SDN-решения у Nutanix нет, поэтому придется полагаться на то, которое предоставляет производитель платформы серверной виртуализации. Отдельно ПО Nutanix не продается. Купить его можно только вместе с их «железом», по сути обычным сервером, на котором все гарантированно заработает.

Стоимость подобных коммерческих «гиперконвергентных» сред не намного ниже традиционных, но строить с их помощью геораспределенные ЦОД гораздо проще и быстрее. Если же бюджет ограничен, на помощь придут открытые и свободные продукты. Например, открытые SDS-решения Ceph, Swift, GlusterFS очень неплохо работают в связке с KVM и Xen. О минусах использования открытых продуктов уже написано достаточно во многих источниках.

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

 

Средства автоматизации

Обзор начнем с лидеров, т. е. с VMware. Естественно, у этой компании есть весь спектр продуктов для реализации собственной концепции.

Основной компонент SDDC (vRealize Automation) является средством автоматизации доставки ресурсов заинтересованным пользователям. Представляет собой портал самообслуживания с каталогом сервисов, где владельцы могут настраивать и самостоятельно выделять ресурсы, а также управлять жизненным циклом сервисов в соответствии с установленными политиками. В нем же предусмотрен механизм заказа новых услуг.

vRealize Orchestrator – слой согласованной конфигурации. Это инструмент для автоматизации любых ИТ-процессов. Дает возможность разрабатывать сложные задачи автоматизации в графическом конструкторе рабочих процессов. Именно там создаются те самые комплексные услуги, которые публикуются на портале. Интеграция с оборудованием и другими средствами автоматизации, например Puppet, Chef или Ansible, обеспечивается дополнительными плагинами, которые разрабатываются самими производителями.

vRealize Operations Manager – средство мониторинга и аналитики. Содержит информацию о рисках, эффективности использования инфраструктуры, возможностях оптимизации.

vRealize LogInsight – инструмент для автоматизированного централизованного сбора и анализа логов со всей вашей инфраструктуры.

vRealize Business – биллинговая система для руководства. Если вы все же потрудились разработать SLA для ваших сервисов, финансовую модель и метрики оценки качества, то в vRealize Business сможете увидеть, кто потратил сколько ресурсов и на что, и узнаете, насколько качественно оказываются услуги. Работает в связке с vRealize Operations Manager.

Дополнительно есть продукты для организации DevOps в вашей компании. DevOps – это ITSM для программистов. Указанная концепция позволяет максимально упростить и по возможности автоматизировать взаимодействие между командой программистов, тестировщиков и эксплуатационщиков. Для этого есть целый пласт продуктов и методологий по их использованию. У VMware предусмотрена интеграция с большинством из них. Так что, если в вашей компании есть разработчики ПО и они пытаются построить свою работу по современным методологиям разработки типа Agile-SCRUM-Waterfall, без DevOps им никак не обойтись.

У конкурентов, в принципе, есть все то же самое, однако в свои концепции SDDC они не включают финансовые компоненты и, к примеру, средства анализа логов, концентрируясь исключительно на автоматизации и конфигурировании в части предоставления инфраструктуры как услуги. У Cisco есть UCS Director, который по функционалу схож с vRealize Automation в сочетании с Orchestration, у HPE есть OneView, EMC предлагает использовать продукты VMware и называет это решение EMC Hybrid Enterprise Cloud.

В чем отличия, что лучше? Тут все достаточно просто: купили vBlock – используйте vRA c vRO, купили FlexPod – используйте UCS Director. Если корпоративный стандарт HPE – тогда OneView. Если есть набор из решений разных производителей, тогда выбор практически безальтернативен – vRA.

Теперь «десерт». Слышали про OpenStack? Это набор открытых программных продуктов для построения облачных сред. Их разработкой и развитием заняты крупнейшие ИТ-компании по всему миру – Canonical, Cisco, Citrix, Dell, EMC, Fujitsu, Hewlett-Packard Enterprise, Hitachi Data Systems, Huawei, IBM, Intel, Mirantis, NetApp, Oracle, Red Hat, VMware, Google и др. Все проекты, с одной стороны, абсолютно независимы, с другой – тесно связаны между собой посредством Rest API. Объединенные вместе, они представляют собой настоящую SOA ОС, где каждый компонент независим, может наращиваться отдельно, но при этом является сервисом для другого компонента. В базовый набор входят вычислительная часть, объектное хранилище данных, блочное хранилище данных, открытое SDN-решение, сервис управления авторизацией и аутентификацией, модуль конфигурирования и автоматизации, а также каталог стандартных сервисов по типу vRA.

Почему это потрясающее решение не используют все? Во-первых, сам OpenStack чрезвычайно тяжел в развертывании и настройке и в чистом виде не встречается. Есть платные дистрибутивы OpenStack, например Mirantis Fuel OpenStack, HP Helion или VMware Integrated OpenStack. Во-вторых, в нем нет и не должно быть того функционала, который требует корпоративный сегмент. Эта платформа предназначена не для традиционных приложений, а для проектов «нового типа». Их называют Cloud Aware, Cloud Native или Web-Scale. Это различные порталы, распределенные архивы и т. д. Именно для них применение традиционной инфраструктуры будет невыгодным и необоснованным выбором.

Кстати, VMware vRA может управлять OpenStack, т. е. с помощью vRA можно построить единое облако для любых типов сервисов.

 Заключение

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

Гиперконвергентность и SDDC – это не одно и то же. Гиперконвергентная платформа может стать SDDC при появлении слоев согласованного конфигурирования и автоматизации.

Для бизнес-критичных приложений пока оптимальной остается традиционная платформа: серверы, СХД, сеть.

Для новых сервисов типа VDI правильным выбором будет использование гиперконвергентных сред.

Для приложений новой формации, Cloud Aware, единственно верное решение – OpenStack.

Что касается средств автоматизации, то выбор следующий:

  • VMware vRealize Automation – наиболее универсальное решение. Может являться зонтичным средством автоматизации процессов управления ИТ для всех видов платформ, особенно в связке с другими продуктами из портфеля VMware;
  • UCS Director – оптимальное решение для автоматизации, если ваш выбор пал на FlexPod в качестве платформы;
  • HPE One View – лучший выбор, если ваш корпоративный стандарт оборудования – HPE.
Поделиться:
Спецпроект

Форум «ИТОПК-2020» оценил потенциал господдержки

Подробнее
Спецпроект

Напряженный трафик или Современные требования к инфраструктуре ЦОД

Подробнее

Подпишитесь
на нашу рассылку