Предыстория SDS
Еще недавно считалось, что данные можно хранить двумя способами: локально на серверах (локальные диски); на различных внешних системах хранения данных – с применением разных протоколов, технологий, оборудования. Соответственно и стоимость таких устройств была разной. Но виртуализация, точнее, популяризация нового уровня абстракции – аппаратной абстракции, повлекла за собой создание новых подходов к распоряжению физическими ресурсами оборудования.
Сегодня мы наблюдаем полную стандартизацию и унификацию аппаратных компонентов, тогда как все «волшебство» перемещается в программный код.
По версии Gartner, концепция «Программно-определяемое что угодно» (Software Defined Anything) – это один из десяти основных трендов 2015 г.
Software Defined-концепция развивается в нескольких направлениях: Software Defined Network, Software Defined Storage и др. Более того, классическую серверную виртуализацию можно в определенной степени назвать Software Defined Computing, поскольку программным образом выдаются ресурсы под определенные потребности и существует возможность менять их по необходимости (концепция находится пока на ранних стадиях развития). Эти три ветки формируют более глобальную концепцию – Software Defined Datacenter, т. е. центр обработки данных, в котором любые ресурсы могут быть динамично изменены посредством программного кода.
Абстракция аппаратных ресурсов – это движущая сила, которая ведет к трансформации ИТ-индустрии сегодня.
На самом деле все проще, чем кажется! Мы все привыкли к тому, что система хранения данных – это «закрытая коробка» с проприетарными технологиями компании, которая выпускает данный продукт.
При этом у разных производителей стабильно развивается единый набор функционала СХД, среди которых: тонкое выделение ресурсов, мгновенные копии данных, клоны, репликация… Особо продвинутые компании предлагают функционал, который не является стандартным в данный момент, например дедупликация и компрессия данных, перемещение блоков данных по разным уровням хранения.
Да, мы привыкли к тому, что всё это закрытые коробки, которые работают на проприетарных ОС и дают пользователю возможность только компоновать типы и количество дисков в СХД, включать или не включать определенный функционал, тем самым затачивая их под свои нужды.
Но стоит отметить тот факт, что на аппаратном уровне все производители используют одни и те же компоненты:
- накопители (HDD, SSD);
- x86-процессоры в контроллерах;
- DDR-память на уровне кэша.
То есть по сути своей все СХД являются не чем иным, как кластерными специализированными вычислительными узлами, которые построены на стандартной x86-архитектуре. И если классические Scale-Up СХД были примером аппаратной централизации хранения данных, то почему бы не использовать обычные северы x86-архитектуры как аппаратно-децентрализованную логическую СХД? Однако читатель может поправить нас, сказав, что уже давно существуют примеры децентрализованных логических СХД в виде Scale-Out-платформ, которые расширяются горизонтально. Тем не менее они все равно остаются проприетарными технологиями и требуют жесткой привязки к аппаратным ресурсам.
Концепция SDS направлена на то, чтобы добавить аппаратную абстракцию на уровне хранения данных, а конечный заказчик смог реализовать продвинутый функционал хранения данных на том оборудовании, которое подходит именно ему.
Согласно IBM и IDC, программно-определяемые СХД – это решения, которые предоставляют сервисы хранения данных при помощи программного стека (ПО) и общераспространенного аппаратного обеспечения. Решение может считаться SDS СХД, если оно:
- является чисто программным продуктом и не содержит проприетарных аппаратных компонентов, таких как специализированные аппаратные ускорители (ASIC), чипсеты, память или процессоры;
- предлагает полный спектр сервисов хранения данных, эквивалентный традиционным аппаратным системам, а также позволяет внедрить единый набор функциональных возможностей во всем дата-центре;
- позволяет объединить физические ресурсы хранения из различных источников, будь то локальные диски, системы с твердотельными накопителями, другие внешние системы хранения данных и в скором времени облачные ресурсы.
Развитие концепции SDS, варианты конфигурации
Точного определения SDS в данный момент еще не существует, но почти все мировые производители продуктов хранения данных заявляют от том, что имеют SDS в своем продуктовом портфеле. Давайте рассмотрим, какие подходы к SDS существуют.
Традиционный подход к построению ИТ-инфраструктуры предприятия предполагает размещение серверов, которые хранят данные на внешнем устройстве централизованного хранения (СХД), обмен данными происходит либо по специализированной сети передачи данных – SAN (Storage Area Network, блочный доступ, протоколы FC, iSCSI, SAS), либо по сети общего назначения – LAN (файловый и блочный доступ, протоколы NFS, CIFS и iSCSI, FCoE). Возможная инфраструктура представлена на рис. 1.
Рис. 1. Традиционный (Scale-up или Scale-оut) подход к хранению данных
SDS 1.0. Согласно видению компании IBM, SDS первого поколения – это технологии абстракции ресурсов хранения данных благодаря технологиям виртуализации существующих СХД либо внедрению логических СХД.
Компании, которые располагают большим количеством различных СХД (так называемым зоопарком), может заинтересовать решение, позволяющее виртуализировать и консолидировать за собой данный набор устройств. Отсюда пришел термин «Storage Hypervisor» – «СХД-гипервизор», устройство (кластер устройств), которое дает возможность абстрагировать существующие ресурсы хранения данных компании (рис. 2).
Такое решение позволяет объединить под единым «зонтиком» СХД различных поколений и производительности. Но, самое главное, СХД-гипервизор обеспечивает возможность предоставить компании новый единый набор функций хранения данных, поскольку использует низлежащие системы только как ресурсы для хранения.
Принципиально идея не нова, она уже давно существует на рынке в виде проприетарных технологий виртуализации СХД, которые получили развитие в таких продуктах, как IBM SVC и Storwize, NetApp FAS Series, EMC VPLEX и др.
Сегодняшние решения от уже состоявшихся отличает возможность построить СХД-гипервизоры на базе стандартных серверов без необходимости покупать дорогостоящие контроллеры – «закрытые коробки» от крупных производителей.
Рис. 2. SDS как СХД-гипервизор
При построении новой ИТ-инфраструктуры или переосмыслении существующих мощностей идеальным решением может стать внедрение логической СХД, которая будет использовать серверные ресурсы (диски, контроллеры), вместо того чтобы покупать выделенное централизованное хранилище (рис. 3).
Рис. 3. SDS как логическая СХД
При таких внедрениях используются внутренние ресурсы серверов, которые формируют дополнительный уровень распределенного хранения данных. Подобные проекты могут оказаться экономически более выгодными, поскольку используются менее дорогостоящие компоненты. Яркими представителями данного подхода являются HP StoreVirtual и VMware VSAN.
В последних поколениях программно-определяемых СХД начинает появляться гибридизация двух подходов внедрения, которые относятся к SDS 1.0. Так, в последнем поколении DataCore SANsymphony-V позволяет на единой платформе объединить ресурсы хранения из различных источников, включая локальные ресурсы серверов, различных СХД и облачные ресурсы (рис. 4).
Рис. 4. SDS второго поколения
Таблица. Краткий перечень продуктов SDS
| Вендор / Название продукта | Тип продукта | Особенности |
| IBM / Spectrum Storage | Гибридный | · Целый портфель продуктов· Один из «прародителей» SDS
· Поддержка SnapShot · Синхронная и асинхронная репликации · Поддержка OpenStack и vCloud · Поддержка порталов самообслуживания |
| EMC / ViPR | Гибридный | · Оптимизирован для работы с Big Data· Абстрагирует системы хранения от физических массивов и объединяет их в единый пул
· Интегрируется с массивами других производителей, включая NetApp, HDS и IBM · Интегрируется с облачными стеками, в том числе с VMware, OpenStack и Microsoft |
| NetApp / Clustered DataOntap | Гибридный | · Один из «прародителей» SDS |
| Data Core / SANsymphony-V | Гибридный | · Доступна демо-версия для ознакомления с основным функционалом решения· Позволяет стандартизировать работу с оборудованием различных брендов и моделей
· Добавляет функционал уже существующим решениям |
| HP / StoreVirtual VSA | Логический | · Является ответвлением линейки СХД HP StoreVirtual· «Отвязанность» от аппаратной платформы
· Уже в базовой поставке обладает всеми функциональными возможностями |
| VMware / VSAN | Логический | · Встроенная в гипервизор ESXi· Полностью интегрированная в инфраструктуру vSphere
· Полная привязка к VMware · Имеет ряд требований в аппаратной инфраструктуре · Только файловый доступ (NFS) |
| Nexenta NexentaStor | Логический | · Имеет широкий продуктовый портфель дополнительных решений для полного мониторинга и управления всей инфраструктурой СХД· Блочный и файловый доступ к ресурсам |
Три модели продвижения SDS
Несмотря на то что полная абстракция аппаратного обеспечения кажется панацеей для хранения данных любых объемов, она может привести конечного пользователя не к тем результатам, которые ожидались.
Действительно, абстракция ресурсов предоставляет пользователям больше свободы, гибкости, возможностей выбора средств управления на этапе планирования проекта, а также сулит более низкие капитальные расходы. Но внедрение SDS-проектов потребует от перспективных владельцев большей внимательности, поскольку выбор компонентов ложится именно на их плечи. Несмотря на создание дополнительного уровня абстракции SDS, СХД будут состоять из все тех же компонентов, что и классические хранилища: программного обеспечения (логика СХД, менеджмент), вычислительных мощностей (на которых будет «крутиться» ПО), ресурсов хранения данных.
Не все производители продуктов SDS дают полную свободу выбора своим потребителям. Разные политики и технологические особенности создали три основные модели продвижения SDS на рынке хранения данных.
Полная аппаратная агностика. Данную модель распространения еще можно назвать полностью аппаратно-независимой. Она предоставляет пользователю наибольшую свободу выбора: существующих серверных мощностей или оборудования, приобретенного под проект SDS; перспективной инфраструктуры хранения данных для достижения требуемых уровней надежности; накопителей для выхода на необходимый уровень производительности.
Очевидно, что подобный подход потребует определенных усилий от заказчика, при этом он получает именно то, что считает необходимым. С точки зрения производителя SDS, такая модель позволяет сфокусироваться на программном коде, а не на аппаратном обеспечении, что в некоторых случаях дает возможность быстрее вывести на рынок новый продукт или обновление программного кода платформы.
Определенные требования к аппаратной платформе. Такой подход позволяет внедрять SDS на оборудовании, которое оптимизировано под определенную специфику. Это обеспечивает возможность создавать системы с большей потенциальной эффективностью и производительностью, чем у аппаратно-агностических (независимых) систем, поскольку основные компоненты, которые влияют на общую производительность СХД, заранее тестируются производителем. Впоследствии производитель SDS либо выпускает ряд рекомендаций и требований для перспективных платформ внедрения, либо предлагает приобрести аппаратное обеспечение вместе с самим ПО SDS.
Такой подход наиболее популярен на рынке хранения данных, поскольку, располагая в своей продуктовой линейке аппаратными решениями, заказчики могут производить их модификации или использовать как основу для рекомендуемой платформы.
Стоит отметить, что данная модель распространения может оказаться наиболее подходящей в тех проектах, где заказчику необходимо использовать флэш-технологии, поскольку аппаратная платформа может быть специально рассчитана (и протестирована) производителем SDS для поддержки флэш-технологий различного уровня вместо «железа», в котором специальные алгоритмы работы с твердотельными накопителями не заложены.
Комплексы SDS. Такой подход объединяет программное обеспечение и стандартизированные серверные системы. Поставляются в виде готовых комплексов, которые рассчитаны на запуск программной платформы определенного производителя.
Как правило, такие системы выступают в роли СХД-гипервизоров и рассчитаны на то, чтобы использовать существующие СХД или дисковые полки (JBOD) в роли дисковых ресурсов. Основным преимуществом данной модели является то, что конечному потребителю не надо задумываться о правильной архитектуре решения, поскольку в большинстве случаев он получает решение, готовое к разносторонней интеграции.
Для производителей эта модель продвижения содержит меньше рисков, ведь рассчитать производительность таких систем проще, чем у полностью агностических платформ. Более того, покупка такого комплекса оборудования, как правило, обходится дешевле, поскольку существует возможность вторичного использования существующих систем.
Требования к ИТ-инфраструктуре заказчика
В данный момент концепция SDS только начинает набирать популярность. Внедрение технологий программно-определяемых СХД выдвигает перед инфраструктурой конечного заказчика ряд требований.
Среди основных требований, над которыми стоит задуматься, следует выделить следующие.
- Сетевая инфраструктура – существующие SDS-решения (в подавляющем большинстве) используют в качестве сетей передачи данных и синхронизации НОД (участников SDS) обычную LAN-сеть, что приводит к особым требованиям к LAN-инфраструктуре, ее производительности и задержкам (Latency) в работе. Так, минимальным требованием к сети является пропускная способность на уровне не менее 1 Гб/с (желательно 10 Гб/с). Также стоит отметить, что данную сеть рекомендуется отделить от основной продуктивной сети, поскольку трафик системы хранения очень чувствителен к задержкам и потерям данных.
- Вычислительные мощности – в случае использования программно-определяемого хранилища данных, использующего в качестве конечных хранилищ дисковые подсистемы каждого отдельного участника кластера (сервера), само SDS-решение реализуется с применением систем виртуализации и размещения виртуальной машины (контроллера) на каждом из участников, что, в свою очередь, влечет за собой дополнительное потребление ресурсов под задачи хранения данных (как ЦПУ, так и ОЗУ) на каждой НОДе.
- Дисковая подсистема – лишь недавно производители оборудования обновили свои модельные ряды и вывели на рынок серверы нового формата. Большинство основных вендоров представили новинки с возможностью размещения более 20 дисков на один сервер. Что касается устаревших серверов – остается лишь возможность замены старых дисков более емкими. Но не стоит забывать и о других вариантах построения SDS с возможностью использования существующих СХД в качестве дисковой подсистемы (внедрение СХД-гипервизоров).
- Управление инфраструктурой – как и любая система, SDS имеет свои интерфейсы мониторинга и управления, которые, к сожалению, не всегда возможно интегрировать с уже существующими системами. Следовательно, некоторым компаниям придется пройти обучение по основным возможностям работы и поддержки такой инфраструктуры.
Хотя SDS и имеет ряд преград, это не мешает ему развиваться и занимать нишу рынка при построении новых инфраструктур и построении инфраструктур под конкретные задачи. Так, SDS постепенно набирает обороты при построении VDI-решений. В данном случае технологии SDS позволяют увеличить общую производительность системы путем децентрализации аппаратных нагрузок на дисковую подсистему, что достигается за счет размещения «горячих» данных на локальных дисках каждого из серверов и организации локального кэша (FlashCache или SSD Cache) на каждом из участников инфраструктуры (сервере).
Децентрализация хранения данных позволяет снизить риски, связанные с «Boot штормом», доступностью системы и возможностью потери данных. Последние два пункта реализуются благодаря тому, что данные хранятся минимум в двух копиях, размещенных на независимых НОДах (серверах), использование же большого количества НОДов (серверов, участников SDS-кластера) позволяет обеспечить полную доступность данных при выходе из строя одного из участников, а также во время режима обслуживания инфраструктуры.
Вместо заключения
Программно-определяемые системы хранения данных – молодой, но очень популярный тренд у всех разработчиков, которые связаны с хранением данных. Благодаря SDS мы наблюдаем становление новых специализированных компаний, которые наверняка проявят себя новыми изобретениями. Ведь любая SDS СХД и состоит из трех основополагающих компонентов: программного обеспечения, вычислительных мощностей и ресурсов хранения данных. Но способов объединить эти компоненты в единую платформу огромное количество!
Распространение SDS обеспечивает широкую свободу выбора и гибкость, однако чревато и дополнительными сложностями и непредсказуемостью при внедрении. Так, готовые комплексы от ведущих вендоров предлагают наивысшие показатели производительности и простоты внедрения, в то время как разработчики агностических платформ помогают построить проекты, наиболее привлекательные по стоимости.
Какой из подходов выбрать? Ответ на этот вопрос во многом зависит от конечных целей проекта. Не стоит забывать о том, что сегодня наблюдается метаморфозное развитие данного технологического направления.
