Нормативная документация

Предисловие к платформе для создания программно-определенных систем хранения данных EMC ViPR

28 апреля 2015 г. | Категория: Теория и практика SDDC, Программно-определяемые системы хранения

На протяжении последних 2-3 лет обнаруживается прелюбопытный феномен: почти все компании, так или иначе связанные с созданием "программно-ориентированного всего" (Software-Defined Everything, SDE), выпускают в больших количествах публикации, где в разных формах истолковывается скрытое содержание инноваций в области SDE. Скрытое в том смысле, что оно не слишком доступно человеку, вооруженному сложившимися представлениями и обращающемуся к традиционной технической документации. Показательно, что и мегавендоры и стапт-апы разродились множеством брошюр из серии "для чайников" (For Dummies), среди них есть посвященные SDDC, SDN, SDS и другие.

К платформе EMC ViPR можно отнести вышесказанное, поэтому в дополнение к существующим документам (на русском языке есть весьма содержательная статья Александра Виноградова "EMC ViPR 2.1 – управление данными "третьей платформы", в журнале Storage News” No 1 (61), 2015) тоже имеет смысл сделать разъясняющее введение. 

В мае 2013 года на конференции EMC WORLD корпорация EMC объявила о выпуске EMC ViPR Software-Defined Storage Platform, платформы для создания программно-определенных систем хранения данных. Software-Defined Storage или SDS явление новое и еще не слишком хорошо известное. С программно-определенными сетями Software-Defined Network (SDN), которые появившись на несколько лет раньше, новую платформу EMC ViPR объединяют не только два слова Software-Defined в названии, но и близкое по внутренней логике деление всей платформы на два инфраструктурных слоя. Один из слоев, нижний, служит непосредственно для хранения данных Data Plane, а второй — верхний Control Plane обеспечивает управление процессами работы c данными.

Заметим, что далеко не все решения относящиеся к классу SDS имеют именно такое решение с явно выраженным делением на два слоя (plane) как в SDN. Такое разделение на уровни (его называют Decoupling) является ключевым моментом, выделяющим в EMC ViPR на общем фоне, оно позволяет отделить функции менеджмента данными от накопителей и передать все управление в серверы, преобразовав его из аппаратного в программное. Соответственно двум слоям платформа EMC ViPR складывается из двух основных компонентов: функционал первой Control Plane реализуется посредством EMC ViPR Controller, а Data Plane — посредством EMC ViPR Data Services.

Функциональность EMC ViPR Controller поддерживается технологиями виртуализации, они позволяют выполнять все необходимые задачи управления хранением независимо от физической природы тех или иных подключенных накопителей, рассматривая их как объединенный пул хранения. В ViPR реализован универсальный или обобщенный подход к управлению (single point-and-click approach), он позволяет освободить пользователя от знания специфики того или иного устройства. Этот подход реализован в форме портала с самообслуживанием, обращаясь к нему пользователь может выбрать те сервисы хранения, которые наилучшим способом соответствуют требованиям того или иного приложения. К тому же этот подход упрощает взаимодействие между подразделениями ИТ и бизнеса и позволяет заблаговременно подготовиться к переходу в облачные среды. EMC ViPR Controller менее революционен чем EMC ViPR Data Services, поэтому в уже сложившихся на предприятиях традиционных инфраструктурах хранения, где переход на сервисную модель затруднителен, может быть использован только лишь уровень Control Plane, в таком случае преимущество EMC ViPR Controller в возможности упростить и унифицировать управление сложной инфраструктурой.

Платформа создана с запасом в расчете на два типа нагрузки — существующий и перспективный. Первый традиционный, где данные представляются в виде классических файлов или блоков. Статистика говорит, что объем данных этого типа нагрузки отнюдь не уменьшается, он растет с высокой скоростью, в среднем 70% в год. Но есть и другой тип нагрузки, эти нагрузки вызваны большими данными (Big Data), их объемы существенно больше и они возрастают быстрее, со скоростью на порядок выше. Вот в расчете на этот тип нагрузки были задуманы сервисы ViPR Object Data Services, совместимые с методами доступа REST API и HDFS . ViPR Object Data Services поддерживает массивы EMC Atmos, EMC VNX и EMC Isilon. В будущем EMC предполагает расширять список сервисов платформы ViPR.

Намечающаяся миграция на SDS и появление таких продуктов как ViPR радикально изменяют представления СХД. Весьма интересны рассуждения на эту тему, публикуемые в своем блоге Чаком Холлисом, человеком, который почти двадцать лет оставался самой интересной "говорящей головой" в корпорации EMC. Хотя сейчас он формально перешел в VMware, но его блог по-прежнему остается уникальным источником, к которому стоит обратиться, если есть желание понять существо той или новации, предлагаемой корпорацией. Автор данной статьи имел возможность лично беседовать с Холлисом и должен признать, что равного ему по харизме среди технологических евангелистов встречать не приходилось. Вот как он пишет о новизне и значении ViPR: "Стоит признать существование проблемы особого рода, она связана с формированием представления о качественно новые технологиях и изделиях. Скажем, Google Glass, в них столько новизны, что об этих очках нельзя говорить просто как о развитии идеи смартфона, разумеется есть какие-то общие черты, но доминируют в создании о них принципиально новые свойства. Можно привести еще множество примеров, когда старые мерки с трудом подходят к новому. Нечто подобное можно сказать и о ViPR, да, здесь присутствуют хорошо известные элементы СХД, но в целом перед нами качественно новое явление. В силу определенных стереотипов мышления сегодня многие из нас готовы воспринять лишь ту часть свойств ViPR, которая им ближе, поэтому я говоря ViPR, стремлюсь показать не только те преимущества, которые актуальны сегодня, но и то, что мы сможем в полной мере оценить завтра."

Безусловно, для того, чтобы понять ViPR, как явление во всей его полноте, пожалуй, следует начать с прочтения десяти записей из блога Чака Холлиса, объединенных в сериал "Software-Defined Storage Series". В них он рассуждает в общих категориях об SDS.

Концептуальная модель и две ее реализации

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

Однако это время простых моделей уходит, поскольку системы усложняются и возникает потребность в моделях иного свойства, логически предшествующих архитектурной модели. Задачи моделирования выходят на первый план, их называют по-разному, в некоторых случаях говорят об операционной модели, в EMC отдают предпочтение понятию "концептуальная модель". В нашем случае внутренняя логика разделение на Control Plane и Data Plane сформулирована в терминах концептуальной модели, а реализована, разумеется в архитектурной модели. Если упустить из виду концептуальную модель и остаться на уровне более привычной для ИТ-специалистов архитектурной модели, то полноценно понять внутреннюю логику ViPR можно, но сложно и не в полной мере, поскольку в архитектурной модели логика отражена, но неявно.

Новые приложения, использующие новые данные предъявляют новые требования к СХД, она должна быть производительной, безотказной и адаптируемой (efficient, effective and responsive), к тому же она должна быстро реагировать на изменяющиеся обстоятельства. Для обеспечения этих качеств должна быть разработана такая концептуальная модель, которая позволяла бы собирать разнообразные конструкции из ограниченного набора компонентов. Модель должна воплощать в себе свойство которое по-английски называют composability, будем переводить его как сочетаемость.

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

Выработанная концептуальная модель может быть переведена в архитектурную модель с использованием компонентов Software-Defined Storage, связанных по интерфейсу REST (Representational State Transfer). В этой модели на уровне Control Plane создать сервисы, поддерживающие доступ к данным со стороны приложений.

Хранение данных и предоставление сервисов данных (Data Services) осуществляется на уровне Data Plane, вызов сервисов осуществляется из приложений. В число сервисов входят: создание моментальных снимков (snaps), клонирование (clones), удаленная репликация (remote replication), федерация (federation), географическое распределение (geo-dispersion), кэширование (caching), распределение по уровням хранения и по накопителям (tiering, striping), дедупликация (dedupe), компрессия (compression), динамическое резервирование (thin provisioning), создание резервных и архивных копий (backups, archiving), шифрование (encryption) и другие. В слое Data Plane осуществляется поддержка всех этих сервисов и сборка из них групп, что-то наподобие макрокоманд а ассемблере. Отделение сервисов от того как на самом деле хранятся данные и как выполняются над ними те или иные действия упрощает доступ к ресурсам.

Устройство ViPR

Переходя непосредственно к разбору внутреннего устройства ViPR обратимся к еще одной записи Чака Холлиса "Introducing EMC ViPR: A Breathtaking Approach To Software-Defined Storage" по поводу объявления ViPR. Это на самом деле увлекательное чтение, использование слова Breathtaking (захватывающим дух) не случайно.

Холлис считает, что по степени готовности к трансформации своих СХД предприятия можно разделить на три категории. Значительный процент, в некоторых регионах вообще большинство предприятий виртуализовало серверы или виртуализует их, но по отношению к СХД сохраняет привязанность к физическим устройствам и традиционным нагрузкам. С другой стороны есть предприятия, которые уже завершили процесс серверной виртуализации и приступили к реализации новой модели работы с данными. И есть небольшая группа уже прошедших и эту перестройку (post-transformation), они полностью освоили облачный стиль. Чтобы стать успешным в качестве средства, позволяющего перейти к облачной модели, EMC ViPR должно быть адаптировано к потребность всех перечисленных разновидностей и поэтому предлагается в трех ипостасях, Чак называет их backet, буквально "ведро", а в данном случае скорее "упаковка" .


Первое ведро можно представить как гипервизор для систем хранения, оно абстрагирует физические ресурсы и представляет их как логические. Такое решение упрощает реализацию модели "as-a-service". Оно явно заинтересует тех, у кого есть зоопарк устройств хранения и есть желание внедрить более разумную модель потребления данных и управления системами хранения. Второе ведро — ViPR обладает способностью "видеть" хранимые объекты как файлы, что ускоряет работу по сравнению с объектными системами хранения данных и наличие ViPR HDFS Data Service, системы, которая позволяет осуществлять аналитику по всей гетерогенной системе хранения (in-place analytics). Третье ведро наиболее продвинутое, оно позволит создавать системы хранения, ориентированные на определенные приложения (application-specific storage), предоставляющие сервисы по облачной модели.

Переход от ведра к ведру можно разделить на три этапа, реализуемых связанными между собой компонентами ViPR. Первый значимый компонент ViPR позволяет усовершенствовать Control Plane существующих массивов хранения, как произведенных EMC, так и другими компаниями. Для этого ViPR просматривает и анализирует существующие накопители и сети (файлы и блоки), каталогизирует их свойства (емкость, производительность и другие особенности) и конструирует из них виртуальные массивы (virtual storage arrays), абстрагированные от физических массивов. Эти виртуальные массивы представлены через посредство каталогов сервисов, предоставляемых администраторам и конечным пользователям. По запросам осуществляется оркестровка сервисов, вводится необходимая метрика, все это тоже часть функциональности ViPR. ViPR выступает в роли посредника или своего рода торгового автомата (vending machine) по отношению существующим системам хранения.

Второй компонент ViPR является представительным (representational), он меняет форму представления данных в зависимости от требования приложений. В ряде случаев данные хранятся в одной форме, а требуются приложениям в другой. Допустим есть данные файловой системе NFS на массивах Isilon или VNX, в приложения используют объектный интерфейс REST (object-oriented REST) или для Hadoop нужны данные в файловой системе HDFS. В отсутствие ViPR пришлось необходимые собирать на каком-то ином стеке хранения, ViPR, где реализована концепция "хранить единожды, использовать по-разному" (Store once, access many) позволяет избежать размножения данных. В нем реализованы модели object-over-NFS и HDFS-over-NFS. Разумеется эмуляция снижает эффективность, но эти издержки компенсируются удобством.

Свою запись в блоге Холлис завершает вопросом: "Можно ли назвать ViPR средством для тотальной виртуализации систем хранения?" И дает на него осторожный ответ: "It's certainly a very strong candidate", считая ViPR серьезным претендентом. Хотя ViPR реализует все необходимые для виртуализации функции, а именно: он обнаруживает ресурсы, объединяет их в пулы, обеспечивает абстрагирование и автоматизацию управления, но общепризнанное определение виртуализации систем хранения в отличие от серверов еще не установилось и из соображений добросовестности стоит проявлять осторожность в оценках.

Ответы на типичные вопросы можно найти в Frequently Asked Questions: EMC ViPR Software-Defined Storage Software-Defined Storage.

Как внешне выглядит работа EMC ViPR с практической точки зрения? 

В первую очередь администратор, отвечающий за СХД, создает набор виртуальных массивыъов, которыми он потом будет управлять на виртуальном же уровне с использованием автоматизированных правил (политик). Затем из них он формирует виртуальные пулы (Virtual Storage Pools), соответствующие по своим показателям производительности и емкости требованиям актуальных нагрузок. Сервисы данных работают поверх платформы, они воплощают в себе уникальные атрибуты виртуальных пулов и массивов. Переход на ViPR позволяет централизовать менеджмент с использованием единого интерфейса для физических и виртуальных устройств. ViPR открыт для расширеня, пользователь может подключать СХД других производителей, разрабатывать собственные сервисы данных, интегрировать с облачными стеками VMware, Microsoft и OpenStack. ViPR поддерживает открытые интерфейсы API, включая AmazonS3, EMC Atmos и OpenStack Swift.

Чем отличается ViPR от более ранних систем виртуализации СХД?

Главное — разделение на Сontrol path и Data Path, из него следуют другие отличия. Далее, ViPR Controller работает на вируальном уровне, что позволяет собирать виртуальные пулы в разнообразные виртуальные массивы, это напоминает разделение сервера на виртуальные машины. Разделение дает возможность - централизовать управление потоками данных и менеджмент СХД. Функциональность ViPR, в отличие от более простых систем виртуализации может расширяться за счет новых сервисов данных. Сравним ViPR со структурным (fabric-based) виртуализационным решением Invista, там есть виртуализационное ПО, оно размещено в коммутаторе Brocade или Cisco и но оно работает в режиме In-band, то есть разбивает пакеты данных на фрагменты и направляет на разные устройства. Область действия такого решения ограничена СХД типа DAS и накопителями EMC, в то время как ViPR может работать с СХД третьих производителей.

Что такое глобальные сервисы данных (global data service)?

В данном контексте под сервисами данных понимаются абстрактные представления, отражающие типы данных (файл, объект или блок), протоколы доступа (iSCSI, NFS, REST, etc.) и такие характеристики как длительность хранения, готовность, безопасность (мгновенные снимки, репликация). В концепции Software-Defined, такого рода физические сущности заменяются программного определенными сервисами данных (software-defined data service). В ViPR предусмотрена возможность расширения, то есть администратор или разработчик могут создать новые сервисы, распространяющиеся на гибридные типы данны такие как "объект на файле" (objects-on-file). Глобальными называют абстракции, образованные из гибридных типов данных. Наличие в ViPR объектных сервисов данных позволяет тем приложениям, которые написаны для файловых систем, работать с объектами, и обеспечивает обратное.

Какие файловые массивы поддерживает EMC ViPR?

Прежде всего ViPR поддерживает продуктовую линейку EMC, включающую Isilon, VNX, VMAX, VPLEX и Isilon, а также накопители компании NetApp.

Автор: Леонид Черняк

Теги: SDE, EMC, SDDC, ViPR, SDN, SDS