SDS на практике: ключевые сценарии использования программно-определяемых хранилищ
Введение
Объем данных в корпоративном секторе растет по экспоненте. И это требует постоянного внимания ИТ-директоров и архитекторов. Цифровая трансформация, переход на электронный документооборот, требования регуляторов к срокам хранения (иногда до 30 лет) и новые типы контента создают колоссальную нагрузку на ИТ-инфраструктуру.
Традиционный подход «купить еще одну СХД» может потребовать существенных бюджетных затрат, а также ведет к накоплению разнотипных систем хранения и привязке к нескольким вендорам. Поэтому бизнес все активнее начинает смотреть в сторону программно-определяемых хранилищ (Software-Defined Storage, SDS).
В этой статье разберем, как использование SDS помогает среднему и крупному бизнесу решать задачи хранения: от консолидации оборудования до замены ленточных библиотек. В качестве решения рассмотрим Кибер Хранилище — российскую программно-определяемую СХД, которая позволяет строить независимую и масштабируемую инфраструктуру.
Подробнее о хранении данных мы уже писали ранее:
Сценарий 1. Сопровождение быстрого роста объемов данных
Главная проблема классических аппаратных СХД — сложность масштабирования. Когда заканчивается место в хранилище, вам нужно приобретать новое оборудование, часто того же вендора.
SDS предлагает горизонтальное масштабирование. Чтобы увеличить емкость или производительность, вы просто добавляете в кластер новые узлы (это могут быть стандартные серверы x86-64). Например, при тестировании Кибер Хранилище масштабировалось до 64 петабайт — и это не предел.
Преимущества сценария:
1) Независимость от оборудования. Вы не привязаны к конкретному производителю оборудования. В одном кластере хранилища можно использовать серверы разных вендоров.
2) Консолидация ресурсов. У вас есть серверы с простаивающими дисками? Их можно подключить к кластеру и утилизировать емкость.
3) Управление стоимостью. Вы можете создавать хранилища разного типа под конкретные задачи.
Комбинация недорогих HDD и алгоритмов оптимизации хранения обеспечивает конкурентную стоимость и более быстрый доступ к данным.
Сценарий 2. Консолидация всех типов хранения
В крупных компаниях инфраструктура зачастую фрагментирована: для виртуальных сред используют блочные системы хранения, для файлового обмена — сетевые хранилища, а для резервного копирования и разработки — объектные хранилища. Администрировать подобную гетерогенную среду сложно и затратно по ресурсам. Использование SDS позволяет консолидировать все типы нагрузок в рамках одной системы хранения. Вы получаете единую точку управления, мониторинга и обновления.
Рассмотрим 4 ключевых сценария использования программно-определяемых хранилищ в рамках консолидации.
Файловое хранилище
Идеально для общих ресурсов, каталогов и неструктурированного контента. Доступ осуществляется по протоколам SMB/NFS.
- Пример
Крупная финансовая организация работает с миллионами документов: договорами, отчетами и внутренними регламентами. Данные требуют разграничения доступа, соответствия ФЗ-152 и репликации между ЦОДами. - Решение на базе SDS
Файловое хранилище разворачивается поверх объектного слоя, что снимает ограничения на количество файлов, свойственные традиционным системам. - Результат
Снижение TCO за счет отказа от проприетарных NAS, гибкое масштабирование без остановки сервиса и интеграция с корпоративным LDAP/AD для управления правами.
Блочное хранилище
Доступ на уровне «сырых» блоков (iSCSI, FC, NVMe-oF). Хранилище представляется серверу как локальный диск. Это выбор для СУБД, ERP и высокопроизводительной виртуализации.
- Пример
Производственная компания с филиальной сетью использует приложение 1С:ERP, требующее низкой задержки, высоких IOPS и отказоустойчивости. - Решение на базе SDS
Развертывание блочного хранилища в гиперконвергентной инфраструктуре. Это позволяет управлять производительностью, выделяя дополнительные ресурсы конкретному приложению. - Результат
Повышение отказоустойчивости ERP-системы.
Объектное хранилище
Доступ по HTTP API. Данные хранятся как объекты с метатегами в «плоском» пространстве. Идеально для архивов, веб-контента, Big Data и разработки.
- Пример
Телеком-оператор генерирует петабайты логов, медиафайлов и данных IoT. Их нужно хранить с оптимальным соотношением стоимости и надежности. - Решение на базе SDS
Развертывание S3-совместимого хранилища. Поддержка политик Information Lifecycle Management позволяет данным автоматически «остывать», перемещаясь с SSD на HDD. - Результат
Возможность строить системы персонализации, предиктивной аналитики и долгосрочного архивирования без привязки к облачным провайдерам, с контролем над данными и затратами.
Хранилище резервных копий
Специфический сценарий, где важна не столько скорость чтения, сколько скорость записи и надежность.
- Пример
Логистическая компания должна хранить резервные копии растущего объема бизнес-данных. Требуется разделять оперативные копии (быстрый доступ) и архивные (с низкой стоимостью хранения) без изменения архитектуры. - Решение на базе SDS
Использование SDS как целевого хранилища с возможностью нативной интеграции с системами резервного копирования. - Результат
Снижение стоимости хранения архивов и сокращение RTO (времени восстановления) критичных систем.
Сценарий 3. Долговременное хранение данных
Требования регуляторов и бизнеса обязывают хранить данные годами. Стандартом для этой задачи выступают ленточные библиотеки. Однако на сегодняшний день в реестре Минпромторга нет и не предвидится отечественных роботизированных библиотек.
Программно-определяемая СХД может выступать в качестве замены лентам. Хранилище на базе недорогих HDD большой емкости становится рациональной альтернативой. Механизмы репликации и избыточного кодирования защищают данные, позволяя пережить выход из строя нескольких дисков или даже узлов.
У программно-определяемых СХД нет проблем с физическим управлением картриджами и износом считывающих головок. А с учетом дедупликации и компрессии стоимость хранения приближается к ленточной, но с гораздо более удобным управлением.
Сценарий 4. Отказо- и катастрофоустойчивое хранение
Количество киберугроз растет, и вместе с ним растет риск, что бизнес потеряет доступ к своим данным в самый неподходящий момент. Остановка операций, срыв обязательств, финансовые потери — вот цена, которую платят компании без надежного доступа к данным. SDS позволяет гибко настраивать схемы защиты на программном уровне:
- Избыточность: поддержка репликации и избыточного кодирования.
- Домены отказа: настройка системы так, чтобы она переживала неисправность диска, узла, стойки или целой серверной комнаты.
- Георепликация: асинхронная репликация между географически распределенными кластерами. Если один ЦОД отключится, данные будут мгновенно доступны из другого.
Заключение
Выбор в пользу SDS — это выбор в пользу гибкости и оптимизации стоимости хранения.
Преимущества Кибер Хранилища в этих сценариях:
- Простота эксплуатации
Большинство операций (развертывание, обновление, настройка) выполняются через веб-интерфейс. Также есть возможность использования CLI и API для большинства операций. - Безопасность
Продукт создается в рамках процесса безопасной разработки. Поддерживается шифрование данных и трафика, а для защиты данных в объектном хранилище реализован механизм Object Lock. - Понятное лицензирование
Учитывается только полезный объем хранилища. Вы приобретаете постоянную лицензию на объем хранимых данных (10, 50, 100, 500 или 1000 ТБ). Объемы служебных данных, занимаемые механизмами репликации и избыточного кодирования, не учитываются. Типы используемых вами хранилищ не влияют на стоимость лицензии.
На вебинаре «Кибер Хранилище. Ключевые сценарии использования» мы разобрали четыре основных области применения нашего универсального SDS-решения — смотрите запись эфира.
Также вы можете самостоятельно познакомиться с возможностями Кибер Хранилища. У нас на сайте можно скачать пробную версию продукта и изучить документацию. Кибер Хранилище можно развернуть даже на ноутбуке, но для более серьезного знакомства лучше использовать серверные платформы.
Вы успешно подписались на рассылку Киберпротект!
