Обзор функционала SDS

А с увеличением скоростей Ethernet вплоть до 100 Гбит/с и появлением таких расширений протокола, как iWARP и RoCE, даже для чувствительных к задержкам приложений скорость доступа к SSD-накопителю в соседнем сервере по сети стала сравнимой (а порой даже равной) скорости доступа к локальным накопителям, подключенным к PCIe-шине.

Программно-определяемые СХД получили возможность стать распределенными по множеству узлов, теперь можно на порядок увеличить объемы хранилища без ущерба для производительности. И если раньше (в пределах сервера) точкой отказа был диск, то теперь быстрая сеть позволяет рассматривать сервер целиком (или блейд-шасси, или даже всю стойку) как потенциально сбойный компонент с соответствующей защитой.

Серверы с внутренними дисками как узлы распределенного хранилища

Появление SATA-интерфейсов с возможностью горячей замены и совместимость SATA-дисков с SAS-контроллерами позволили использовать для организации хранилища дешевые SATA-диски в недорогих же серверах. Все это вместе позволяет таким компаниям, как Amazon и Microsoft, предлагать клиентам хранение данных по ценам $10–30 за 1 ТБ/мес.

Появление же таких технологий, как NVMe, NVMe over Fabrics, вместе с ростом объемов SSD-накопителей до HDD позволит и вовсе отказаться от использования дисковых массивов. Таким образом, запросы самых требовательных по скорости и задержкам приложений будут удовлетворены программно-определяемой СХД.

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

Характеристики типовых SDS

Объектное хранение данных и масштабируемость

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

Иногда объектное хранилище используется для предоставления блочных устройств или файловых систем. И то, и другое будет преобразовано в объекты с распределением между всеми узлами СХД. Здесь нужно отметить, что блочный/файловый доступ для объектного хранилища – это все-таки дополнительный уровень абстракции и не основной функционал. В некоторых объектных хранилищах их нет вовсе, где-то этот функционал только развивается.

Erasure Coding вместо RAID

Для защиты от выхода из строя устройства хранения или целиком узла в программно-определяемых СХД обычно используются 2 механизма – репликация данных между несколькими узлами (обычно хранятся 2 или 3 копии данных) и Erasure Coding. Репликация обеспечивает лучшую производительность, но ценой кратного сокращения полезного дискового пространства. Например, при защите от одновременного выхода из строя двух узлов полезная дисковая емкость составит всего 33% от «сырой».

Erasure Coding представляет собой математический алгоритм генерации из K исходных блоков данных M блоков избыточной информации таким образом, что исходные данные могут быть восстановлены из K любых получившихся блоков. При M=1 и M=2 получаются конструкции, похожие на RAID5 и RAID6 соответственно. При M=3 (и K=7, например) система защищается от одновременного выхода из строя трех узлов, при этом полезная дисковая емкость составит уже 70% от «сырой», в отличие от 33% при 3-кратной репликации.

Как репликация, так и кодирование в программно-определяемых СХД обычно реализованы таким образом, что данные распределяются по всем узлам СХД независимо от кратности репликации или соотношения K/M. Из-за этого восстановление избыточности при выходе узла из строя происходит не на выделенный spare-диск (это долго и с дисками больше 4 ТБ может быть опасным), а на свободное пространство всех оставшихся узлов. В итоге время восстановления сокращается во много раз.

Адаптивная производительность

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

Также некоторые программно-определяемые СХД могут «запоминать» последовательности обращения к разным данным в разное время и переносить на быстрый уровень данные, которые скоро понадобятся, в том объеме, в котором они понадобятся. Это позволяет удешевить СХД, храня на быстром уровне не весь объем «горячих» данных, а лишь его часть (необходимую сейчас и в течение ближайшего времени) без существенного влияния на производительность.

Хранилище для облачного века

Драйвером развития программно-определяемых СХД можно считать Amazon Web Services с его хранилищем S3 (Simple Storage Services), появившимся в 2006–2007 годах. S3 – это распределенное объектное хранилище, доступное поверх протокола HTTP. В настоящий момент S3-интерфейс стал де-факто стандартом для работы с объектами и поддерживается практически всеми объектными хранилищами других вендоров.

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

Составляющие стоимости

Идея создания SDS обычно приходит в ответ на требование о снижении стоимости хранилища. Но здесь есть подводные камни.

Сеть

Для возможности быстрого восстановления избыточности при выходе из строя каких-либо компонент требуются, как минимум, 10 Гбит/с сетевые соединения. Поэтому в определенных конфигурациях предпочтительнее создать даже выделенную межузловую сеть, чтобы снизить влияние ребалансировки на клиентские запросы. Но зачастую в имеющейся инфраструктуре порты доступа только гигабитные, и стоимость модернизации участка сети с добавлением 10 Гбит/с коммутаторов может ощутимо увеличить общую стоимость программно-определяемой СХД. Особенно в случае приверженности к дорогим сетевым брендам.

Серверы и диски

С выбором серверов все довольно просто: они в значительной мере уже стали потребительским товаром, их стоимость у разных производителей примерно одинаковая. Но есть 2 нюанса.

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

Второй нюанс – многие производители серверов ревниво относятся к установке в них «чужеродных» дисков. Некоторые прямо это запрещают, другие просто не продают салазки для установки дисков в слоты отдельно от самих дисков. Все бы ничего, но подобная наценка на диски в 100, 200 и более % удорожает хранилище в разы. Другими словами, если ваша цель – сделать SDS максимально дешевой, то диски (и, возможно, серверы) должны приобретаться у лояльных к этому компаний.

Программное обеспечение

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

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

Решаемые задачи

Хранилище как услуга

Для организации хранилища в виде услуги СХД должна обеспечивать базовые функции:

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

Среди классических СХД подобные решения придется поискать. В SDS же эти функции обычно заложены изначально, либо они несложно реализуются.

Гиперконвергентные системы

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

Облачное хранилище для облачных приложений

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

Архивное/холодное хранилище петабайтного масштаба

Дисковый массив на пару петабайт для холодного хранения данных? Он получится «золотым» и будет лишь греть воздух. А через несколько лет стоимость его поддержки станет «платиновой», и будет открыт проект по миграции данных на новый «золотой» массив. Файловая система подобного объема после сбоя сервера будет проверяться не один день, при этом хранилище будет недоступно.

Объектное программно-определяемое хранилище на таких объемах выходит значительно дешевле классических СХД. С помощью Erasure Coding (12+6, например) достигается необходимая отказоустойчивость (показатель сохранности данных – 99,9999999999999%). А при распределении этих данных между тремя и более ЦОД отключение одного из них не вызовет недоступности СХД. При этом отсутствуют недостатки классической репликации в виде кратного дублирования дискового пространства.

Хранилище для СРК

Производители СРК уже включили поддержку объектных хранилищ в свои продукты. И Veritas NetBackup, и CommVault Simpana научились работать с хранилищами как по протоколу S3, так и по специальным протоколам отдельных объектных хранилищ.

Технологии SDS как нельзя лучше подходят для создания систем холодного/архивного хранения данных, например архивов медиа-контента, записей переговоров в call-центрах, записей систем видеонаблюдения, почтовых архивов и т.д. Одним словом, использование программно-определяемых СХД оптимально, когда речь идет о длительном хранении больших объёмов информации, которые не подвергаются постоянной оперативной обработке, но должны быть легко доступны при необходимости.

Отдельно стоит отметить, что использование программно-определяемого хранилища возможно даже для Oracle ASM с суб-миллисекундным доступом. На стенде в нашей компании мы протестировали конфигурацию программно-определяемой СХД, в которой SSD-диски каждого сервера по выделенной сети были предоставлены остальным серверам в виде блочных устройств. На протестированных дисках разницы между сетевым и локальным обращением к SSD для приложения не было. То есть для Oracle ASM (и Oracle RAC, в частности) с современными объемами SSD-накопителей необязательно покупать разделяемый дисковый массив. Достаточно сделать внутренние диски серверов доступными другим серверам кластера по сети.

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