Программно-определяемые хранилища как абстракция над аппаратной средой хранения существовали и раньше. Однако воплотить в жизнь новые подходы к хранению данных, такие как распределенный между серверами Erasure Coding, стало возможно относительно недавно — с увеличением скоростей ЛВС и процессорных мощностей. При этом с ростом популярности облаков системы хранения должны обеспечивать объектное хранение данных и быть гипермасштабируемыми. В данной статье мы рассмотрим существующие сегодня технологии SDS (software defined storage): их характеристики, составляющие цены и сценарии применения.
ЛВС как транспорт
Передача данных на высоких скоростях при малых задержках всегда были прерогативой SAN и в особенности Fibre Channel. Однако появление доступных 10 Гбит/с Ethernet-коммутаторов сделало возможной передачу данных между сервером и хранилищем по ЛВС на сравнимых с SAN скоростях. Появились даже конвергентные решения, использующие Ethernet для транспорта FC.
Дальнейшие изменения произошли, когда скорость Ethernet выросла до 100 Гбит/с, а у протокола появились расширения iWARP и RoCE. Даже чувствительные к задержкам приложения перестали ощущать разницу между скоростью доступа к SSD в соседнем сервере по сети и скоростью доступа к локальному накопителю, подключенному к PCIe-шине.
Теперь можно строить программно-определяемые СХД, распределенные по множеству узлов, при этом на порядок увеличив объемы хранилища без ущерба для производительности. И если раньше (в пределах сервера) точкой отказа был диск, то теперь быстрая сеть позволяет рассматривать сервер целиком (или блейд-шасси, или даже всю стойку) как потенциально сбойный компонент с соответствующей защитой.
СХД в виде серверов с дисками
SATA-интерфейсы с возможностью горячей замены, совместимость SATA-дисков с SAS-контроллерами — все это позволило создавать хранилище из дешевых SATA-дисков в недорогих же серверах. Благодаря такой возможности стоимость хранения данных у Amazon и Microsoft колеблется в пределах
Технологии NVMe и NVMe over Fabrics наряду с увеличением объемов SSD-накопителей до HDD позволят и вовсе отказаться от дисковых массивов. Программно-определяемые системы хранения смогут обслуживать даже самые требовательные к скорости и задержкам приложения. При этом в SDS можно организовать многоуровневое хранение, например, включив туда устройства NVDIMM, NVMe и HDD. Такая архитектура избавит от проблемы избытка емкости при нехватке скорости (и наоборот).
Характеристики типовых SDS
Объектное хранение данных и масштабируемость. В большинстве своем программно-определяемые СХД — это объектные хранилища, в которых по названию объекта можно получить его содержание. При таком подходе нет необходимости индексировать содержимое (либо эта процедура существенно упрощена). Если количество узлов СХД заранее известно, для поиска объекта нужно хэшировать его название и, грубо говоря, поделить результат на число узлов. Остаток от деления как раз и укажет на сервер с искомым объектом. Таким образом можно равномерно распределять данные между узлами хранения, не создавая точек отказа в виде выделенных серверов метаданных. Объекты большого размера можно разделить на несколько одинаковых блоков и распределить их между всеми узлами СХД.
Объектное хранилище позволяет также предоставлять блочные или файловые системы. И то, и другое преобразуется в объекты, распределяемые между всеми узлами СХД. Однако в данном случае речь все-таки о дополнительном уровне абстракции, а не об основном функционале. В некоторых объектных хранилищах такая возможность отсутствует либо находится в стадии развития.
Erasure Coding вместо RAID. Для защиты от аппаратных сбоев на уровне отдельных устройств или узлов программно-определяемых СХД, как правило, используются репликация данных между двумя или тремя узлами и Erasure Coding. Репликация дает лучшую производительность, но при этом в разы сокращает полезное дисковое пространство. Например, при защите от одновременного выхода из строя двух узлов полезная дисковая емкость составит всего 33% от «сырой».
В основе Erasure Coding — математический алгоритм генерации из K исходных блоков данных M блоков избыточной информации таким образом, что исходные данные могут быть восстановлены из K любых получившихся блоков. При M=1 и M=2 получаются конструкции, похожие на RAID5 и RAID6 соответственно. При M=3 (и K=7, например) система защищается от одновременного выхода из строя трех узлов, при этом полезная дисковая емкость составит уже 70% от «сырой», в отличие от 33% при трехкратной репликации.
В программно-определяемых СХД и кодирование, и репликация подразумевают распределение данных по всем узлам СХД независимо от соотношения K/M или кратности репликации. Благодаря этому при выходе узла из строя избыточность восстанавливается не на выделенный spare-диск (что долго, а с дисками больше 4 Тб даже опасно), а на свободное пространство всех оставшихся узлов. Как результат — сокращение времени восстановления во много раз.
Адаптивная производительность. Ранее размер уровней многоуровневого хранилища рассчитывался вручную. Сегодня появляются технологии, которые на основе заявленных требований к скорости и надежности хранения автоматизируют размещение данных на нужном количестве узлов и носителей. В будущем приложения будут обращаться за ресурсами к СХД напрямую, без привлечения человека.
Кроме того, некоторые программно-определяемые СХД способны «запоминать» последовательность обращения к тем или иным данным и переносить наиболее востребованные из них на быстрый уровень. Таким образом можно сэкономить на хранении, размещая на быстрых дисках только необходимую в ближайшее время часть данных и все это без существенного влияния на производительность.
Хранилище в эпоху облаков
Одним из стимулов к развитию программно-определяемых СХД стал Amazon Web Services с его хранилищем S3 (Simple Storage Services), созданным в
S3 отличается гипермасштабируемостью — буквально до размеров Интернета. В этом причина его популярности. Именно такое хранилище нужно облачным приложениям — надежное, быстрое, безопасное, недорогое и доступное из любого уголка Интернета. Само облачное приложение масштабируется путем увеличения или уменьшения числа запущенных экземпляров, при этом хранилище его данных растет или уменьшается автоматически — в зависимости от количества запросов.
Стоимость: из чего она складывается?
Как правило о создании SDS задумываются, когда назрела необходимость снизить стоимость хранилища. Но все не так однозначно, как может показаться.
Сеть. Для эффективной работы SDS и быстрого восстановления в случае сбоя требуются, как минимум, 10-Гбит/с сетевые соединения. Иногда есть смысл создать выделенную межузловую сеть, чтобы уменьшить зависимость клиентских запросов от возможных ребалансировок. Однако часто в инфраструктуре есть только гигабитные порты доступа, и модернизация с добавлением 10-Гбит/с коммутаторов может существенно увеличить общую стоимость программно-определяемой СХД. Это будет особенно заметно в случае с дорогими сетевыми брендами.
Серверы и диски. С серверами несколько проще — их цена у разных вендоров сопоставима. Но есть два нюанса.
Во-первых, серверов потребуется много — десятки, а то и сотни. Даже в минимальной конфигурации их стоимость может превысить стоимость дисков. Одно из решений проблемы — использовать одни и те же серверы и как вычислительное оборудование, и как СХД. В некоторых конфигурациях приложение от этого только выиграет, т. к. будет читать данные с локального хранилища, не задействуя сетевую передачу.
Во-вторых, многие вендоры ревниво относятся к установке в их серверах дисков других производителей. Одни это запрещают в принципе, другие продают салазки для установки в слоты только вместе со своими дисками. От такой наценки на диски в 100, 200 и более процентов хранилище становится в разы дороже. Если вы хотите сделать максимально бюджетную SDS, то диски (и, возможно, серверы) стоит брать у лояльных к этому вендоров.
Программное обеспечение. Для построения SDS современный рынок предлагает в основном только коммерческое ПО. Многие разработки — своего рода «швейцарские ножики», способные организовать и объектное, и блочное, и файловое хранилища, причем сразу по нескольким протоколам. Здесь стоит сказать несколько слов о рынке производителей этого ПО. Ряд стартапов в сфере SDS были куплены ИТ-гигантами — их программные решения поставляются теперь только в вместе с оборудованием. Другие разработчики заключили партнерство с производителями серверов, которые также предлагают комплексные решения на своем оборудовании. Есть и относительно свободные коммерческие решения, но сложность применяемых технологий и статус амбициозного стартапа не добавляют уверенности в их надежности. Что касается цены, то все коммерческое ПО ориентировано на широкий спектр задач, и создание дешевого хранилища — не в их числе.
Некоммерческого ПО не так много, и оно, как правило, менее функционально. Но здесь вполне реально найти решение под конкретную задачу, в том числе с вендорской поддержкой. В этом случае вы получаете недорогое хранилище без жесткой привязки к конкретному производителю (как ПО, так и железа).
Области применения
Хранилище как услуга. В этом случае СХД должна обеспечивать:
изоляцию пользователей (компаний, подразделений, отдельных бизнес-пользователей) и приложений друг от друга;
изоляцию нагрузок каждого из пользователей и между ними;
разделение сетевых подключений в пересекающихся адресных пространствах;
масштабирование хранилища без изменения конфигурации приложений.
Среди классических СХД такие решения нужно еще поискать. В SDS же данный функционал уже заложен изначально либо несложно реализуется.
Гиперконвергентные системы. Если приложение занимает более одного сервера (с виртуализацией или без) и требует значительных дисковых ресурсов, программно-определяемая СХД поможет снизить общую стоимость системы. Кроме того, можно будет масштабировать приложение и хранилище, добавляя или удаляя узлы с нужным объемом вычислительных или дисковых ресурсов.
Облачное хранилище для облачных приложений. Для облачного приложения хранилище должно быть доступным из любой точки запуска, масштабируемым и надежным. Яркий пример — контейнеры. Все данные контейнерного приложения размещены во внешнем хранилище, которое либо доступно приложению по сети, либо динамически подключается к контейнеру при его запуске. Современные SDS легко справляются с этими задачами, т. к., по сути, для них и создавались.
Архивное/холодное хранилище петабайтного масштаба. Классическая СХД на пару петабайт для холодного хранения данных? Она выйдет «золотой» и будет лишь греть воздух. А через несколько лет стоимость ее поддержки станет «платиновой», и данные придется мигрировать на новый «золотой» массив. После сбоя сервера потребуется не один день на проверку файловой системы такого объема — все это время хранилище будет недоступно.
На таких объемах объектная SDS обойдется значительно дешевле. С помощью Erasure Coding (12+6, например) достигается требуемая отказоустойчивость (показатель сохранности данных — 99,9999999999999%). Если распределить данные между тремя и более ЦОДами, то отключение одного из них не повлияет на доступность СХД. При этом решение лишено такого недостатка классической репликации, как кратное дублирование дискового пространства .
Технологии SDS хорошо подходят для создания архивов медиаконтента, записей переговоров в call-центрах, записей систем видеонаблюдения, почтовых архивов и т. д. То есть везде, где речь идет о длительном хранении больших объемов информации, которая не подвергается постоянной оперативной обработке, но должна быть легко доступна при необходимости.
Хранилище для систем резервного копирования. Производители СРК уже предоставляют услугу поддержки объектных хранилищ на базе своих продуктов. Некоторые из них уже научились работать с хранилищами как по протоколу S3, так и по специальным протоколам отдельных объектных хранилищ.
***
Программно-определяемые СХД пока еще кажутся экзотикой, но уже сегодня они позволяют решать множество задач — от архивного хранения до высокоскоростной обработки. При этом стоимость SDS-решений ниже или сопоставима со стоимостью использования классических СХД. Наконец, SDS можно масштабировать до размеров Интернета, в то время как стандартные дисковые массивы все еще с трудом выходят за пределы ЦОДа.
Автор статьи — системный архитектор Центра проектирования вычислительных комплексов компании «Инфосистемы Джет».
