Глобальный переход на программно-определяемые СХД (Software Defined Storage, SDS) сегодня уже реальность. Преимущества, которые несут новые решения, осознали многие — и крупные корпорации, и небольшие компании. Теперь они перешли от слов к делу.

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

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

Что такое «новая СХД»?

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

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

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

Признаки «правильных» SDS

Как утверждает в своей статье на портале SDxCentral Ашок Раджагопалан (Ashok Rajagopalan) из компании Datera, чтобы новые СХД можно было по праву называть программно-определяемыми, они должны обладать следующими признаками:

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

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

3. Обеспечивать автоматизацию функций управления и настройки. Управление ресурсами СХД должно вестись через командную строку (CLI) или программный интерфейс (API). Они должны заменить управление вручную через графический интерфейс. В качестве характерного примера, как этот принцип должен быть реализован в SDS, можно привести restful APIs. Этот механизм выстроен так, что для управления могут применять только обычные HTTP-запросы (т. н. «REST-запросы») с передачей всех необходимых вспомогательных данных в качестве параметров этих запросов. Такой подход обеспечивает доступ ко всем функциям управления не только со стороны системы управления, но и делает их доступными непосредственно пользователям. Благодаря restful APIs можно существенно сократить затраты на дальнейшие разработки, упростить эксплуатацию, обеспечить совместимость при любых вариантах взаимодействия с СХД.

4. Осуществлять управление через систему политик и служб. Все параметры работы службы хранения (быстродействие/IOPS, задержки) должны устанавливаться через систему политик. Именно они определяют фактическое качество сервиса хранения, его доступность и восстанавливаемость при инцидентах. Как показывает опыт, правильно выбранная система политик, управляющая СХД, становится ключевым условием для успешной работы. На базе политик реализуется механизм принятия автоматических решений о выборе места для размещения конкретных данных. Благодаря этому обеспечивается оптимальная производительность при управляемых затратах. Механизм политик активно используется также вендорами, которые тем самым обеспечивает полную настройку своих решений под требования конкретного заказчика. В правильно отстроенных SDS через политики описываются любые операции: как должны размещаться данные в системе, как должен предоставляется доступ к ним, как ведется мониторинг, как гарантируется требуемая производительность.

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