Конкуренты железных СХД

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

Концепция SDDC предполагает упрощение инфраструктуры ЦОД за счет использования более однородных вычислительных компонентов и назначение им ролей на уровне ПО. При этом допускается как выделение компонентов под роль, так и совмещение нескольких ролей на одном наборе оборудования.

Развитие стандартных вычислительных компонентов, в частности, значительное повышение вычислительной мощности серверов платформы x86, и активное применение облачных технологий дали стимул для развития программно-ориентированных СХД (Software-Defined Storage, SDS). Это решения, в которых за все функции хранения и управления данными отвечает ПО на базе набора стандартных элементов вычислительных сред (серверов, дисковых полок расширения, коммутаторов, контроллеров и т.д.). Их главная особенность – отсутствие специализированных аппаратных средств, полностью или частично обеспечивающих реализацию отдельных функций. В данный момент можно выделить несколько классов программно-ориентированных СХД:

• программно-аппаратные решения, которые архитектурно повторяют классические массивы (EMC XtremIO, IBM FlashSystems и т.д.);
• независимое программное обеспечение для построения решения на базе x86 серверов (EMC ScaleIO, pNFS, RAIDIX, EuroNAS, Open-E и т.д.);
• объектные хранилища данных (Gluster, OpenStack Swift, Ceph, EMC Atmos, HDS HCP, Quantum Lattus, EMC ViPR и т.д.);
• Hadoop-совместимые хранилища (Apache Hadoop HDFS-совместимые решения);
• системы виртуализации дисковых ресурсов (EMC ViPR, IBM SVC, Huawei VIS и т.д.).

Отметим, что эта классификация является условной и зачастую продукты реализуют функции, относящиеся к нескольким классам.

Рис. 1. Верхнеуровневое сравнение традиционной и программно-ориентированной архитектур хранения

ОБЪЕКТивный подход

Производители классических массивов, предугадывая возможные тенденции развития ИТ-инфраструктур и пытаясь оптимизировать расходы на разработку новых продуктов, в последние 7–10 лет начали добавлять SDS-продукты в свои портфели. Они в большинстве повторяют классические системы хранения: обеспечивают доступ к данным по стандартным протоколам (FC, iSCSI, IB, FCoE, CIFS, NFS) и схожий функционал (динамическое управление, репликация, мгновенные снимки, клоны и т.д.).

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

Наибольшие популярность и распространение на данный момент имеют SDS-продукты с объектным принципом хранения данных. Их основные потребители – средние и крупные сервисные провайдеры услуг по облачному хранению: Dropbox, Amazon, Google, Apple и др. В случае частных облаков применение объектного подхода гарантирует унификацию вычислительных компонентов и динамическое расширение инфраструктуры за счет добавления универсальных новых нод (серверов), которые могут обеспечивать сервис хранения одновременно с другими ролями.

В отличие от классических решений, которые отвечают за гарантированное хранение всего массива данных (в рамках одного ресурса), объектный принцип предусматривает хранение множества копий частей массива данных – так называемых объектов. Сохранность данных обеспечивается при доступности хотя бы одного экземпляра из множества. За счет применения объектного хранения стала возможна организация резервирования данных в зависимости от места расположения элементов SDS. Например, можно дублировать объекты на ресурсах разных узлов (серверов – участников SDS), размещенных в разных стойках ЦОД. Исходя из этого, допускается потеря части компонентов при условии сохранения одной или более копий каждого из объектов.

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

Основным недостатком объектных хранилищ является необходимость иметь N-кратный объем ресурсов (N – количество хранимых копий объектов, соответственно, уровень защиты данных) и осуществлять доступ к данным по объектным протоколам (S3, Rest API). Затраты на избыточный объем возмещаются за счет использования компонентов массового производства (серверы, жесткие диски, коммутационное оборудование), которые значительно дешевле специализированного аппаратного обеспечения, выпускаемого небольшими партиями. Проблема с протоколами доступа к данным стоит более остро. Большинство бизнес-приложений и прикладного ПО на данный момент не имеют какой-либо поддержки объектных протоколов. Доработка или замена используемого ПО за приемлемое время и вменяемые деньги очень часто невозможна. В связи с этим основные SDS-продукты на данный момент имеют отдельный компонент (роль) для предоставления ресурсов по классическим протоколам (iSCSI, NFS, CIFS).

Применение объектных или основанных на них систем хранения по сравнению с классическими или подобными им массивами требуют иной, в большинстве случаев более детальной проработки и оценки возможностей решения. Это связано с совершенно другим подходом к организации инфраструктуры, резервированию данных (РК) и комплекса в целом (Disaster Recovery, DR). Допущенные в этом месте ошибки могут дорого обойтись. Одно из возможных последствий – отсутствие постоянной производительности. В зависимости от используемых алгоритмов распределения и кеширования данных может наступить ситуация, когда будет производиться обращение не к локальным ресурсам, а к другим узлам (членам группы хранения единого набора данных) по внутренней сети – Ethernet, InfiniBand, WAN. На рис. 2 показан пример подобного колебания производительности.

Рис. 2. График возможной многонодовой производительности SDS-решения

Красная линия отображает время отклика при выполнении операций ввода\вывода. Пиковые значения приходятся на выполнение операций на удаленном узле. Увеличение времени отклика напрямую влияет на производительность операций (чем больше время выполнения, там меньше операций можно выполнить за определённый период). Как видно из примера, задержка на выполнение удаленных операций не постоянна и может быть причиной значительной деградации общей производительности. Чем продолжительнее выполнение операций на удаленном узле, тем больше будет влияние на суммарную производительность.

Для минимизации влияния этой особенности многоузловых SDS на продуктивные среды необходимо проводить предварительную глубокую проработку конфигурации и оценку принципиальной возможности ее применения.

Основные области и решения, в которых началось активное применение технологий SDS:

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

Программно-определяемые СХД – наиболее гибкие и динамично развивающиеся технологии в группе решений по хранению данных. В них применяются уникальные алгоритмы, за счет которых возможно уменьшение количества используемых компонентов и суммарной стоимости решений. В качестве примера рассмотрим задачу по построению ресурса хранения. Компания имеет 3 ЦОДа в пределах одного города, которые соединены IP-каналами связи достаточной пропускной способности. Есть следующие требования к ресурсам хранения:

• общий объем данных – 100 ТБ;
• обеспечение одновременного доступа на чтение\запись из 3 ЦОДов;
• обеспечение отказоустойчивости до уровня потери одного из ЦОДов.

Решение этой задачи с применением классических дисковых массивов в полной мере невозможно. На текущий момент существуют системы, обеспечивающие одновременный доступ (на чтение\запись) только с 2 технологических площадок (например, HDS G1000 GAD) или из всех ЦОДов к единому хранилищу, расположенному в одном из дата-центров и резервируемому в других. Условным выходом из ситуации можно считать организацию ресурсов хранения с делением на сегменты по площадкам и резервированием этих сегментов между ЦОДами. Пример такой реализации представлен на рис. 3.

Рис. 3. Обобщенная схема решения с применением классических массивов

Подобный подход требует не менее 200 ТБ суммарной полезной емкости для обеспечения хранения и резервирования и ограничивает локальный полный (чтение\запись) доступ объемом локального сегмента. Доступ на запись в удаленные сегменты должен будет производиться через каналы связи между площадками. Эта реализация требует обеспечения работы прикладного ПО с тремя независимыми сегментами данных.

Теперь рассмотрим вариант с использованием SDS-систем с объектным доступом. Возможно построение единого хранилища данных с расположением компонентов (узлов) на 3 площадках. Применение динамических алгоритмов хранения позволяет обеспечить хранение не менее 1 копии на каждой площадке, что гарантирует сохранность данных при потере до 2 из 3 ЦОДов. Этот подход, как и в случае с классическим массивом, требует хранения 3-кратного объема, но использование недорогих компонентов снижает TCO аппаратной части.

В ряде случаев размещение в каждом ЦОДе полного объема требуемого оборудования невозможно (из-за отсутствия места, должного электропитания, охлаждения и т.д.). Выход – применение решения на базе SDS с уникальными (более сложными) алгоритмами распределения данных, например Quantum Lattus. Благодаря ему, хранение данных производится совместно с хранением дополнительной сервисной информации для их восстановления. Наиболее похожее решение – RAID 5 или 6 с использованием данных четности для восстановления массива. Главным отличием Quantum Lattus от классического RAID является возможность регулирования уровня сервисной информации. Это позволяет задавать требуемый уровень сохранности данных при выходе из строя определенного количества компонентов. К примеру, можно задать потерю всех компонентов одной из технологических площадок, в данном случае требуемый объем хранения для обеспечения 100 ТБ полезной емкости составляет ~164 ТБ.

Рис. 4. Обобщенная схема решения с применением SDS

Решение минимизирует используемую емкость для обеспечения хранения данных, но при этом накладывает более жесткие требования к доступности, пропускной способности межплощадочных каналов связи и набору используемого ПО систем резервного копирования и архивирования данных (требуется наличие возможности работы с объектными системами хранения).

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

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

Остается надеяться, что столкновения «в лоб» новых программных и классических продуктов не будет, смена решений произойдет плавно, или же будет найдена точка равновесия, при котором оба вида займут свои ниши и не будут сильно конкурировать. Мы же сегодня можем занять место в круге защитников той или иной технологии либо наблюдать со стороны, используя для своих задач всё самое «вкусное» от них обеих.