Степени свободы программно-определяемого хранения

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

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

Диктатура и вольности SDS

По большому счету, все современные системы хранения можно отнести к классу SDS – они сделаны на стандартном серверном оборудовании и отличатся специфическим программным слоем.  Kaminario, Pure, Tegile, Infinidat и другие поставщики новой волны дают пользователю то же, что и старожилы рынка СХД – готовые коробки. От гиперконвергентных Nutanix и HPE Simplivity заказчик получает даже больше, чем хранение – полную среду исполнения приложений. Все достаточно просто управляется и хорошо масштабируется, своими наборами  строительных блоков. При всем комфорте для пользователя, в этом нет ни прозрачности, ни экономии.

Полной свободы программной определяемости не бывает. Есть степени свободы, определяемые «толщиной» слоя абстракции и охватом задач. К примеру, VMware VSAN, Datacore или Microsoft S2D распространяются в виде ПО. Интегратор ставит их на серверы, с учетом практик и ограничений разработчиков. Конечный пользователь получает набор серверов, с некоторой прозрачностью и люфтом по оснастке. Сообщества Ceph или ZFS предлагают множество программных сборок для блочного, файлового или объектного хранения. Такие серверы и кластеры работают на типовых платформах и компонентах, но требуют достаточной квалификации для развертывания и сопровождения на клиенте.

Предустановленные на серверах SDS-решения удобны корпоративному потребителю: включай и работай. Его не устраивают вмененные ограничения (vendor lock-in). Ладно бы дело касалось только сервисной привязки. Мало кому нравится инфраструктурная и компонентная зависимость от  одного поставщика.

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

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

Модульное хранение

Open-E JovianDSS, программное обеспечение систем хранения на Linux/ZFS для создания масштабируемых хранилищ - пример подхода к SDS, когда интегратор и его клиенты получают достаточную свободу маневра - программными сервисами и вариантами физической реализации. Инструменты коррекции ошибок, резервного копирования и аварийного восстановления есть в базе. Предметом выбора являются протокол и среда подключения, наполнение управляющих серверов,  комбинации дисков, уровни защиты данных. Средствами различных кластерных топологий обеспечивается непрерывность доступа к данным.

В простейшем случае, единица хранения под управлением Open-E JovianDSS – это стандартный сервер х86, c подобранными под нагрузки CPU / RAM /  SSD / HDD / сетевыми адаптерами. Разделение сервера на управляющую голову и подключенный к ней по SAS стандартный JBOD c дисками дает перспективу модульного расширения.

Под головы хранения подходят типовые 1U-платформы, они есть у всех производителей серверов. В зависимости от нагрузок данные размещаются в JBOD (на HDD) или JBOF (на SSD).  Программная лицензия состоит из двух частей: на узел и на объем хранения.

Для кластера высокой доступности из двух серверов с общим JBOD докупается второй узел, лицензия к нему и High Availability Cluster Feature pack. Отказ одного из узлов управления не прерывает постоянный доступ к данным.

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

HA–кластер зеркалирует диски двух JBOD, напрямую подключенных к двум узлам. C использованием MPIO решение становится еще более устойчивым к авариям. Объем хранения расширяется каскадированием JBOD. Сдерживает развитие таких схем только ограничение SAS на длину соединений 10 метров (лучше – меньше).

Для катастрофоустойчивого хранения используют растянутые (stretched) кластеры хранения (метрокластеры). Управляющие узлы таких систем разнесены по локациям. Open-E JovianDSS позволяет синхронизировать данные двух хранилищ на площадках, связанных по Ethernet, на удалении до 80 км. Для этого докупается лицензия Advanced Metro High Availability Cluster Feature pack.

Кластер работает почти как локальный, с перекрестным подключением JBOD к узлам по SAS – за тем исключением, что один узел обращается к дискам напрямую, а второй – через Ethernet, с внутренним преобразованием протокола и с небольшими задержками (при настройке следят, чтобы уровень сетевых задержек не превышал 5 мс).  Все узлы видят все диски, «чужие» помечены как Remote Disks. Устойчивость к отказам достигается зеркалированием локальных и удаленных дисков.

Такой двухузловой кластер позволяет балансировать нагрузку протоколов SMB, NFS и iSCSI между узлами, благодаря активным пулам данных на обоих. При аварии на одном из них, пулы немедленно активируются на втором.  

Уровни страхового покрытия

В сервисной модели работы с данными возникающие риски отражаются средствами противодействия. Пользователь взвешивает угрозы, затраты на защиту от них и принимает решение о трансформации хранения. Программная среда управления хранением Open-E JovianDSS начинена противоядиями, но встроенные программные средства нейтрализуют только часть угроз. Для страховки от тяжелых отказов оборудования, техногенных катастроф и человеческого фактора требуется модульное расширение инфраструктуры.

Предположим,  у нас есть данные и их копия на основном высокопроизводительном хранилище.

 Карта рисков и защит выглядит так:

Уверенности добавляет покупка дополнительного модуля хранения – еще одного сервера с Open-E JovianDSS.

Карта рисков «зеленеет», появляется дополнительный уровень страховки данных:

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

В такой инфраструктуре «зеленая карта» покрывает все разумные риски:

Между умными и красивыми

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

Данных много, данные разные, место найдется всем. Был бы порядок в головах.