SDS как новый уровень абстракции

Концепция SDDC предусматривает вовлеченность в «программную определяемость» всех элементов ЦОД без исключения, иначе нарушается необходимая связность между ними. Одной из важнейших частей этого пазла и является программно-определяемая система хранения данных (Software Defined Storage, SDS).Поскольку понятие достаточно новое, не существует единственно верного мнения по поводу того, что за ним стоит. Каждый новый игрок на «поляне» SDS старается привнести что-то своё в данную тему. Но мы не можем продолжать разговор без разбора того, что же понимается сегодня под этой аббревиатурой.

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

Во-вторых, в качестве SDS рассматривают такой тип сервиса хранения данных, при котором физическая составляющая СХД (массивы, диски, контроллеры, порты и т.д.) специально отделена от логической и организационной (логические тома, сервисы, политики доступа и т.п.). Скорее, здесь правильнее будет говорить не просто об отделении, а об очередном уровне аппаратной абстракции (HAL – Hardware Abstraction Layer), который потребовался для эффективной поддержки виртуализации и сервиса хранения в рамках всего программно-определяемого ЦОД. Взаимодействие между уровнями осуществляется через программные интерфейсы и протоколы прикладного уровня, которые сегодня переживают «трудный» период стандартизации. Единства пока нет.

И в-третьих, так как процесс формирования направления SDS начался совсем недавно, то, по своей сути, программно-определяемая СХД дня сегодняшнего и ближайшего будущего (до 3 лет минимум) на 90% состоит из виртуализованной СХД и на 10% – из программного инструментария, позволяющего эффективно управлять ею и взаимодействовать с ней всем компонентам SDDC.

На рис. 1 мы отразили «усреднённый» вариант основных уровней и компонентов SDS, которые сегодня принято различать. Снизу-вверх:

• Традиционные СХД (1.1). Это те самые системы хранения данных, которые сейчас представлены в 100% ЦОД компаний – дисковые массивы от младшего класса до Hi-End-оборудования. Здесь необходимо отметить, что те компании, которые применяют «универсальный доступ» к данным через сеть (Network Attached Storage) или постепенно «дрейфуют» в эту сторону, находятся в более выигрышной ситуации по сравнению с пользователями «старорежимного» SAN и тем более Direct-attached устройств хранения. Это связано с тем, что сеть является основным транспортом взаимодействия в SDDC.
• Распределённые программные СХД (1.2), построенные на «commodity»-оборудовании. Здесь речь идёт о таких СХД и «гиперконвергентных» решениях, как Ceph, GPFS, Gluster, VSAN, Nutanix, Scale, SimpliVity и т.д. Также здесь могут использоваться облачные ресурсы хранения, например, Amazon.
• Если понятия, описанные в тексте выше, представляют собой некоторое развитие и усовершенствование идеи виртуализации СХД, то следующий и все остальные слои – это уже тот самый «пятый элемент», который делает из виртуализованной СХД программно-определяемую. Уровень 1.3 (HAL) задаёт, по сути, «язык», на котором осуществляются взаимодействие и управление.
• Уровень сервисов хранения 1.4. Здесь из нижележащих виртуализованных СХД создаются и «живут» виртуальные логические устройства хранения – тома, массивы и т.д. Виртуальный том, созданный на этом уровне, совершенно «отвязан» от физической среды и может располагаться сразу на нескольких физических устройствах разного типа, а также, например, в облаке Google Drive.
• Уровни 1.5 и 1.6 отвечают за презентацию сервиса хранения SDS потребителям, за управление его жизненным циклом, контроль и мониторинг его уровня доступности, учёт количества потреблённых ресурсов (например, для выставления счёта) и т.д. В общем, все эти понятия нам хорошо знакомы по описанию любого облачного сервиса.

Рис. 1. Уровни программно-определяемой СХД

Что несёт SDS ?

Реализация концепции SDS может дать компании несколько преимуществ. Это полная независимость от конкретных аппаратных решений. При таком уровне абстракции прикладные системы и платформы виртуализации серверов абсолютно независимы от подсистемы хранения. Более того, она ещё и самостоятельно заботится о себе.

В то же время компания сокращает затраты на СХД. За счёт развитой программной логики функционал, ранее существовавший только в Hi-End (например, синхронная репликация, дедупликация), становится доступен даже для самых недорогих классов хранения. За счёт унификации ресурсов, среды доступа к ним, сильно «поумневших» устройств хранения и упрощения процедур администрирования должны сокращаться операционные затраты, а капитальные – возникать не скачкообразно, а равномерно в течение года.

Рис. 2. Схема стенда для тестирования VSAN

В лаборатории нашей компании мы проводили тестирование ряда компонентов программно-определяемых СХД. Мы рассматривали решения GlusterFS, Ceph, IBM GPFS, VMware VSAN в качестве платформ под транзакционную СУБД. Анализировалось их применение под нагрузкой разного типа (OLTP/DSS) в тестах разной интенсивности. Для примера на рис. 2 приведена схема стенда для VSAN. Результаты тестирования сейчас обрабатываются, и пока рано делать громкие заявления.

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

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

Поживём – увидим

К сожалению, виртуализация вычислительных, сетевых ресурсов и виртуализация ресурсов хранения данных хоть и называются очень похоже, но имеют совершенно разную природу. Виртуализация вычислительных ресурсов, так же, как и SDN (Software Defined Network), подразумевает взаимодействие и оперирование копиями вашей информации (принцип on execution), но при этом «не отвечает» за сохранность её оригинала. Важнейшей же ролью СХД всегда было и будет обеспечение сохранности оригинала информации (принцип persistence), без которого все остальные компоненты ИТ-инфраструктуры, хоть традиционные, хоть программно-определяемые, теряют свой смысл.

В то же время распределённые программные СХД постепенно становятся похожи на комплексы для распределённых вычислений, а это приводит нас в область действия «коварной» теоремы Брюера (CAP-теорема). Она утверждает, что в любой реализации распределённых вычислений можно обеспечить не более двух из трёх свойств:

1. согласованность данных (consistency) – во всех вычислительных узлах в один момент времени данные не противоречат друг другу;
2. доступность (availability) – любой запрос к распределённой системе завершается корректным откликом;
3. устойчивость к разделению (partition tolerance) – расщепление распределённой системы на несколько изолированных секций не приводит к некорректности отклика каждой из них.

То есть практическое применение распределённых программных СХД на сегодняшнем этапе развития технологий – это своего рода искусство лавирования в маленькой бухте с ценным грузом. Оно требует не только знания возможностей судна – от капитана, фарватера – от лоцмана, но и финансовых вложений (порой значительных), чтобы застраховать риски утери груза – оригинала информации. К сожалению, последнее обстоятельство иногда становится неожиданностью для сторонников открытого (читай – «бесплатного») программного обеспечения и «самосборных» узлов системы, сформированных из самых дешёвых компонентов.

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