Подписаться
Читать в телеграм
Специалисты понимают программно-определяемый ЦОД как подход, предусматривающий комплексную оркестрацию компонентов дата-центра – виртуализированных (в большинстве своем) и физических: виртуальных машин, СХД, сети, сетевых сервисов, инженерной инфраструктуры и пр. В готовом виде (в формате «коробочного» решения) инструмент, позволяющий обеспечить оркестрацию для всех значимых компонентов ЦОД, на рынке отсутствует, хотя имеются его отдельные компоненты.
Предпосылки движения к SDDC
Как отметил Сергей Андронов, предприятия, в середине прошлого года планировавшие строительство собственных ЦОД, в силу экономической ситуации оказались в условиях лимитированных бюджетов. От 30 до 40% предприятий строят новые ЦОД, пытаясь сократить расходы за счет более интенсивного использования ресурса инженерной инфраструктуры существующих ЦОД; отказа от применения дорогостоящих экологичных/энергосберегающих решений; перехода на оборудование азиатских и/или отечественных производителей; комбинируя вышеперечисленные подходы. Но большинство предприятий не могут себе позволить даже таких, сокращенных, расходов. Поэтому фокус внимания пользователей ЦОД смещается от строительства собственных площадок к аренде готовых.
Продолжая тему, Александр Гуляев отметил, что тенденция перехода на сервисную модель в ИТ и стремление заказчиков минимизировать расходы служат драйверами движения рынка в сторону программно-определяемых ЦОД. Этому способствуют также массовый переход на платформу х86 и наличие в существующих ЦОД избыточного вычислительного ресурса, который можно использовать для создания виртуальных СХД и коммутаторов вместо физических.
Имеются коммерческие и Open Source-продукты для управления отдельными виртуализованными компонентами ЦОД. Для создания решения, подходящего под определение полноценного SDDC, их требуется интегрировать между собой и с уровнем управления/оркестрации.
Оркестрация SDDC предполагает обеспечение мониторинга, учета и тарификации, автоматизированного изменения конфигурации (provisioning), планирования ресурсов, согласованной реакции на события смежных систем и т.д. В условиях разнообразной корпоративной среды реализовать в полной мере концепцию SDDC на базе имеющихся продуктов сложно, долго и дорого, поскольку интеграция компонентов и кастомизация решений требуют высокой квалификации программистов.
Желающим двигаться в сторону SDDC рекомендуется сперва определить ключевые показатели дата-центра, обеспечить их независимый мониторинг и работать над улучшением наиболее значимых показателей с помощью отдельных внедряемых решений, встраивая их в общую концепцию SDDC.
Мифы вокруг SDDC
На рынке существует ряд мифов, связанных с SDDC. На них указал Андрей Шапошников.
Является ли SDDC законченным решением?
SDDC как законченное решение уже работает у провайдеров услуг (таких как Amazon или Google), имеющих однородную инфраструктуру и собственный штат разработчиков. Для корпоративного сектора законченных SDDC-решений, покрывающих весь спектр прикладных систем и гетерогенных инфраструктур, пока нет, и перспективы их появления в течение ближайших пяти лет сомнительны. Причины тому – несильная заинтересованность ведущих производителей аппаратных решений в развитии тематики SD, организационные сложности, возникающие у ИТ-служб компаний-заказчиков при эксплуатации таких гиперконвергентных решений, а также дороговизна ключевых компонентов SDDC – систем автоматизации и управления – как в реализации, так и в обслуживании.
Годится ли OpenStack для корпоративных решений?
Вопреки расхожему мнению, ПО OpenStack является не готовым продуктом, а набором программных модулей, которые нужно интегрировать вручную, а затем и эксплуатировать, обеспечивая достаточно высокий уровень доступности. Это трудоемкий процесс, требующий участия квалифицированных программистов (собственной или привлеченной команды). Кроме того, архитектура современных корпоративных приложений не «заточена» под облачную архитектуру, которую предлагает OpenStack. Поэтому OpenStack пока не очень подходит для корпоративного применения.
Всем ли подходят программно-определяемые (виртуализованые) СХД?
Вопреки уверениям производителей, чисто программные реализации виртуализации СХД пока еще не обеспечивают функционала, надежности и производительности уровня массивов Hi-End или серьезных Midrange. С аппаратными реализациями дела обстоят гораздо лучше, но и они по ряду причин показаны далеко не во всех случаях. Не всегда они снимают проблемы совместимости оборудования, дороговизны и сложности эксплуатации гетерогенных СХД. Тем не менее применение виртуализации СХД хорошо подходит для определенных задач, таких как распределенный («растянутый») на разные площадки кластер виртуальных машин, расширение емкости Hi-End-массивов более бюджетными дисковыми полками или миграция данных со старых массивов на новые.
Структура программно-определяемого ЦОД
Андрей Лукичев рассмотрел структуру, которую должен иметь программно-определяемый ЦОД. «Нижний слой» SDDC будут составлять как унаследованные компоненты инфраструктуры ЦОД, так и более новые программно-определяемые компоненты на базе стандартных серверов. Ресурсы этого инфраструктурного слоя предоставляются вышележащему уровню сервисов SDDC через единый набор интерфейсов взаимодействия и представления ресурсов ЦОД. Над уровнем сервисов надстраивается уровень управления сервисами; еще выше находятся инструменты управления политиками доступа и сервисный каталог. «Верхний слой» программно-определяемого ЦОД представлен порталом самообслуживания и прикладными интерфейсами для персонализированной конфигурации пакета сервисов под заказчика.
Рис. 1. Структура программно-определяемого ЦОД
Для некоторых из перечисленных слоев уже существуют продукты на рынке, но единой конструкции пока не существует. Многочисленные пока решения на базе открытых стандартов, в том числе OpenStack, скорее всего сгруппируются в небольшое количество пакетов, развиваемых сообществами взаимодополняющих друг друга разработчиков.
Инженерная основа
При всех преимуществах программно-определяемых решений нельзя забывать, что они не будут надежно функционировать без качественных инженерных инфраструктур и систем физической безопасности. Сергей Андронов рассказал о результатах обследования инженерной инфраструктуры, которое специалисты компании «Инфосистемы Джет» проводили среди компаний, обладающих собственными коммерческими ЦОД (первичных провайдеров).
Обследование инженерной инфраструктуры было проведено в 187 дата-центрах, большинство из которых (107) расположены в Москве, 42 – в Санкт-Петербурге, остальные – в других городах России. Все владельцы ЦОД, согласившиеся на обследование, заявляют об уровне надежности своих инфраструктур на уровне не ниже Tier III. На деле абсолютное большинство из них достаточно внимания уделяют системам кондиционирования и бесперебойного электропитания, но мало – вопросам контроля доступа и присоединения к внешним распределительным сетям (рис. 2). Поэтому вторичному провайдеру (который развертывает услуги для конечных заказчиков, пользуясь площадками сторонних ЦОД) для повышения надежности стоит пользоваться площадками нескольких первичных провайдеров. Так поступила компания «Инфосистемы Джет» при создании своего виртуального ЦОД. Не исключено, что по мере роста популярности программно-определяемых ЦОД в области SDDC появятся стандарты.
Рис. 2. Состояние инженерной инфраструктуры и физической безопасности в российских ЦОД
Итак, эксперты отметили следующее:
- готового SDDC-решения, пригодного для всех категорий заказчиков, на рынке сегодня нет, и вряд ли оно появится в ближайшей перспективе;
- SDDC-решение – сложное. Для его развертывания и поддержки нужны профессиональные услуги;
- опыт компании «Инфосистемы Джет» позволяет ей работать по направлению программно-определяемых ЦОД с различными категориями заказчиков:
- предоставлять сервисы компаниям, которые не могут/не планируют строить собственные дата-центры;
- выстраивать среду для предоставления услуг по запросу для первичных провайдеров;
- разрабатывать подходы к построению виртуальных ЦОД для корпоративных заказчиков.
