С. Платонов “ПОД КАПОТОМ У SDS: ПОЕДЕТ ИЛИ НЕТ?”. Специально для журнала Сonnect

Обращаем внимание, что для ознакомления с материалом на сайте http://www.connect-wit.ru/ требуется регистрация.

На сайте RAIDIX.ru он находится в свободном доступе!

Сегодня нельзя дать точное определение Software Defined Storage, поскольку у производителей нет единого понимания о функционировании подобных продуктов, а также в связи с большим количеством спекуляций вокруг термина – это признают большинство ИТ-экспертов. Storage Network Industry Association (SNIA) относительно недавно создали рабочую группу, которая занялась разработкой «идеального» представления SDS.

Мы можем дать три определяющие характеристики программно-определяемых СХД:

SDS являются интеллектуальным компонентом, «мозгами» сети хранения данных, и они отделены от аппаратного обеспечения, которое относится к «органам-исполнителям»;
SDS позволяет значительно упростить администрирование сети хранения данных. Где будут расположены данные физически, как они будут перемещаться со временем, как будет организована защита данных, решает этот самый «мозг», а не администратор. Администратор создает политики, на основе которых принимаются решения;
SDS по своей природе имеет кластерную (Scale-Out) архитектуру и позволяет масштабировать производительность и объем «на лету». При этом добавление в кластер шестого узла и 2057-го узла не отличаются по своей сложности.

По мнению SNIA, программно-определяемая СХД должна обладать:

средствами автоматизации – все операции управления должны быть максимально упрощены и идти от задачи;
стандартным интерфейсом управления – API для управления, выделения ресурсов и обслуживания устройств хранения и их сервисов;
виртуализированным потоком данных (Data Path) – блочный, файловый или объектный интерфейс, который будет использовать приложение для доступа к данным;
средствами масштабирования ресурсов – возможностью наращивать ресурсы без прерывания доступа к данным и потерь производительности.

SNIA предлагает использовать CDMI в качестве интерфейса взаимодействия с приложениями и SMI-S API для управления сторонними серверами.

Классификация

SDS-решения можно разделить на два основных класса:

программное обеспечение, отвечающее за создание универсального уровня управления ресурсами хранения. Это программное обеспечение непосредственно не реализует функции хранения, а только виртуализирует имеющиеся и управляет виртуальными пулами на основе заданных политик (типичным примером ПО подобного класса является EMC ViPR);
программное обеспечение, не только отвечающее за функции управления, но и берущее на себя все функции СХД, будучи развернутым на стандартном x86 (или ARM64) оборудовании (чаще всего это ПО объединяется с гипервизорами).

Кроме того, SDS могут подразделяться в зависимости от модели развертывания:

решения, развертываемые в виде виртуальных машин;
решения, устанавливаемые непосредственно на «железо».

Что предопределит успех SDS?

Облачные технологии и экспоненциальный рост объемов данных заставляют провайдеров ИT-услуг пересматривать подход к построению архитектуры.

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

Слова подтверждаются цифрами: IDC предсказывает рост интегрированных систем с 5,4 млрд в 2013 г. до 14 млрд в 2017-м.

Компании любых размеров рано или поздно сталкиваются с необходимостью наращивания инфраструктурных мощностей. Традиционные NAS- и SAN-решения все еще находят место в машинных залах предприятий, но программно-определяемые системы хранения данных предоставляют совершенно иные уровни доступности данных, масштабирования ресурсов и простоты обслуживания.

Почему же гиперковергентные инфраструктуры и SDS набирают популярность?

Каждая СХД требует конфигурирования и настройки. Администратор должен создать RAID-группы и тома (при этом выбрав необходимые параметры исходя из ожидаемого типа нагрузки), выполнить назначение томов на хосты, определить, подходит ли для решения задачи возможность включения дедупликации данных, технологии виртуализации СХД (thin provisioning), настроить группы согласованности (консистентности) данных, произвести перенастройку SAN-сети (автор был свидетелем того, как у одного из заказчиков проблема низкой производительности SAN решалась посредством полугода работы нескольких инженеров).

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

Стоимость SAN значительно выше, чем у Direct Attached Storage, а новое программное обеспечение позволяет нивелировать практически любые недостатки DAS. При этом масштабирование SDS намного дешевле, чем у SAN, а масштабировать ресурсы хранения, поверьте, в последнее время приходится всем. Стоит ли напоминать, что такие компании, как Amazon и Facebook, никогда не использовали SAN?

Типичная архитектура SDS

Для того чтобы разобраться в архитектуре типичной SDS, определим основные атрибуты подобных решений.

Software Defined Storage представляют собой исключительно программные решения, не требующие для своего функционирования специальных компонентов и разворачивающиеся на стандартном x86 оборудовании. Также ряд решений поддерживает архитектуру ARM64. Уровень управления строго отделен от аппаратного обеспечения. SDS могут поставляться пользователю в составе комплексного аппаратно-программного решения или быть развернутыми на уже имеющемся оборудовании.
Потоки управления (Control Path) и хранения (Data Path) разделены между собой.
Все ресурсы хранения абстрагированы от пользователя и объединены в виртуальные пулы хранения. SDS позволяют использовать как локальные ресурсы хранения (DAS), так и классические СХД различных типов (SAN и NAS).
Управление ресурсами происходит на основе заранее предопределенных политик и максимально автоматизировано. Политики создаются и изменяются администраторами виртуальной инфраструктуры.
SDS эластично масштабируется до тысяч узлов, отвечающих за функции хранения, петабайтных объемов и производительности доступа, выражающейся в миллионах операций ввода-вывода.
Программно-определяемые СХД ориентированы на предоставление ресурсов хранения серверным гипервизорам.
Обеспечение набора гарантированных уровней обслуживания и возможности перемещения данных между уровнями.
SDS предоставляет интерфейс самообслуживания для потребителей ресурсов хранения. В идеале этим интерфейсом должен пользоваться не человек, а приложение.

Все программно-определяемые системы хранения данных не имеют общего хранилища данных, представляют собой shared nothing кластер, все узлы которого не имеют общих компонентов и объединены лишь сетью. Данная архитектура при правильном подходе позволяет нивелировать практически все физические ограничения на масштабируемость.

На пути разработчиков распределенных систем всегда встает теорема Брюера: распределенные системы не могут в равной степени обладать более чем двумя из перечисленных свойств:

согласованность данных (англ. consistency) – во всех вычислительных узлах в один момент времени данные не противоречат друг другу;
доступность (англ. availability) – любой запрос к распределенной системе завершается корректным откликом;
устойчивость к разделению (англ. partition tolerance) – расщепление распределенной системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций.

В SDS приоритет отдан первым двум свойствам.

Напомним, что существуют три типа основного связующего элемента кластера хранения:

распределенная файловая система;
объектное хранилище (key/value storage);
сетевой RAID.

Например, Nutanix использует распределенную файловую систему Nutanix Distributed Filesystem (NDFS).

Рис. 1. Организация данных в Nutanix

Файловые системы, имеющие POSIX-интерфейс, показывают неплохой уровень производительности, но их возможности по масштабированию ограничены.

При работе с большими кластерами используются основанные на объектном хранении архитектуры. Ceph организован как раз поверх объектного хранилища.

Каждый узел имеет локальную файловую систему, и в ней содержатся файлы, эмулирующие object storage device (OSD). OSD обладают плоской структурой адресов и могут масштабироваться до огромного объема. За расположение данных в OSD отвечают сервер метаданных и специализированный алгоритм CRUSH. Файлы разбиваются на слайсы и распределяются по OSD на множестве серверов. Главная задача такого распределения – обеспечить доступность данных при отказах накопителей, узлов или сегментов сети.

Для защиты данных от отказа компонентов используются два основных подхода – репликация данных и помехоустойчивое кодирование (erasure coding).

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

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

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

Важным аспектом работы распределенного хранилища является строгая консистентность данных и метаданных. В соответствии с отчетом Google, в парке из 1800 серверов мы будем встречаться с тремя различными типами отказов ежедневно! Кроме того, среда передачи данных между узлами может искажать информацию. И вот при таких условиях мы должны гарантировать получение согласованного результата всеми участниками кластера. Выделяют два типа отказов: явный отказ компонента и «византийская», скрытая, ошибка. «Византийская» ошибка заключается в передаче компонентом кластера некорректной информации без какого-либо признака ошибочной работы. Находить такие ошибки весьма не просто. Чаще всего для этого используется алгоритм Paxos, предложенный в 1990-х гг.

Отдельной группой ПО являются менеджеры кластера, объединяющие все узлы, определяющие их роли, распространяющие конфигурации и запускающие и останавливающие кластер. В качестве таких менеджеров используются решения с открытым программным кодом, например zookeper и corosynс, и проприетарные подходы. Опыт подсказывает, что, несмотря на огромную базу инсталляций, corosync является нестабильным решением, и при его упоминании у некоторых архитекторов начинает дергаться глаз. Zookeeper изначально разрабатывался для управления большим парком серверов, и он прекрасно с этим справляется, но иногда его функциональности недостаточно, тогда данное решение приходится комбинировать с другими.

ПО мониторинга работает на всех узлах, определяет статус кластера и отвечает за выполнение политик хранения: отслеживает «здоровье» компонентов, уровень нагрузки и соответствие уровня сервиса определенной политике, а при необходимости изменяет параметры кластера, перераспределяет ресурсы или переносит данные. При возможности использования сторонних СХД модуль мониторинга выполняет управление ими через SMI-S API и OpenStack Cinder API.

Практически все SDS имеют модульную структуру и позволяют добавлять новые интерфейсы ввода-вывода по мере необходимости.

Рис. 2. Набор интерфейсов Сeph

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

Сегодня на рынке SDS не менее 20 «имен», треть из которых – продукты с открытым исходным кодом. Нельзя сказать, что существует идеальное решение, которое могло бы, с одной стороны, полностью заменить и превзойти функции крупных промышленных СХД, а с другой – обладать всеми возможностями по автоматизации. Но начало положено, и если верить аналитикам, в более чем половине ЦОД, построенных после 2017 г., мы не встретим отдельных «островов» СХД и SAN-сеть.

Март 2015

Сергей Платонов

Руководитель Отдела Развития

RAIDIX