СХД для облачной инфраструктуры: масштабирование и мультитенантность
Для облачной ИТ-инфраструктуры с множеством арендаторов подходит СХД с ролевой моделью доступа (RBAC), QoS на уровне томов и линейным масштабированием без остановки сервиса. У NIMBUS это линейки «Гром» (SAS4, до 4 модулей расширения, до 2,7 ПБ) и «Молния» (All-Flash NVMe, до 2 модулей расширения) под управлением ПО «Юпитер» в режиме Active/Active. Изоляция тенантов достигается через RBAC, группы консистентности и лимиты производительности на уровне тома.
Облачный провайдер живёт по другим законам, чем корпоративный дата-центр: тут не один заказчик, а десятки арендаторов на общей ёмкости, и каждый требует своего SLA. Инженеры ЦОД знают — стоит одному тенанту запустить тяжёлый batch-job без лимитов, и соседи начинают жаловаться на латентность. Разберём, какая архитектура хранилища снимает эту проблему на уровне СХД, а не приложения.
Мультитенантность на уровне СХД
Изоляция арендаторов начинается не с виртуализации, а с самого хранилища. На практике мы видим три опорные точки: разграничение прав, лимиты производительности и логическая сегментация данных.
- Ролевая модель доступа (RBAC) — разграничивает права администраторов и тенантов на управление томами и снепшотами.
- QoS на уровне томов — позволяет установить ограничения производительности для конкретного тома, не давая одному арендатору выесть IOPS у остальных.
- Группы консистентности (CG) — согласованные снепшоты набора томов одного тенанта, что упрощает резервное копирование по клиентам отдельно.
- VLAN и агрегирование сетевых портов — сетевая изоляция трафика между тенантами и повышение отказоустойчивости каналов.
Active/Active архитектура для облачных нагрузок
Обе линейки СХД под ПО «Юпитер» работают в режиме Active/Active с поддержкой ALUA/SLUA — оба контроллера параллельно обслуживают запросы, без простоя при отказе одного узла. Для блочного доступа реализован High Availability, для файлового — Protect Network Ports. Такая схема критична там, где облачная платформа не может позволить себе окно обслуживания.
- Онлайн-миграция томов — перенос данных между дисковыми группами без остановки виртуальных машин арендаторов.
- Зеркалируемый кэш и его защита от потери данных при сбое питания.
- RESTful API — программное управление ресурсами хранилища из оркестратора облачной платформы.
- Интеграция с Active Directory, LDAP, Zabbix и Grafana — единая точка аутентификации и мониторинг рядом с остальной инфраструктурой оркестрации.
Масштабирование ёмкости без остановки сервиса
Облако растёт неравномерно — сегодня десять тенантов, через год сто. На практике важно, чтобы прирост ёмкости не требовал миграции существующих томов на новую систему.
| Параметр | Гром 230 | Молния 230 |
|---|---|---|
| Тип накопителей | SAS4 SSD/HDD, 2,5″ (SFF), полки расширения SFF/LFF | NVMe SSD, 2,5″ (SFF) |
| Кэш на контроллер | 2048 ГБ | 2048 ГБ |
| Модули расширения | До 4 модулей (24 или 90 дисков каждый) | До 2 модулей NVMe (24 накопителя каждый) |
| Максимальная ёмкость модуля | До 2,7 ПБ (модуль на 90 дисков, накопители 30,72 ТБ) | До 720 ТБ (модуль на 24 накопителя, диски 30,72 ТБ) |
| Front-end порты | 10/25 Гбит/с Ethernet, 16/32 Гбит/с Fibre Channel | 10/25/100 Гбит/с Ethernet, 16/32 Гбит/с Fibre Channel |
| Лицензия (мультитенантность) | Data-Center: репликация, Метрокластер (привязка RBAC, QoS и CG к конкретному тарифу требует уточнения у вендора) | Data-Center: репликация, Метрокластер (привязка RBAC, QoS и CG к конкретному тарифу требует уточнения у вендора) |
Гром или Молния для облачной платформы
Для IaaS-платформ с преобладанием файловых сервисов, резервного копирования и умеренных требований к латентности логичнее взять Гром — гибридная архитектура даёт больше ёмкости на модуль расширения. Для облака с базами данных, аналитикой в реальном времени или тенантами, критичными к задержке, нужен All-Flash Молния с интерфейсами до 100 Гбит/с Ethernet.
Практический кейс: изоляция тенантов у облачного провайдера
Типовая схема: провайдер выделяет каждому крупному клиенту отдельную группу томов с индивидуальным QoS-лимитом и своей ролью в RBAC, а группы консистентности используются для расписания бэкапов по клиентам без пересечения окон. При росте базы клиентов ёмкость наращивается подключением дополнительного модуля расширения без остановки уже работающих томов. Для расчёта конфигурации под конкретную плотность тенантов можно обратиться к каталогу систем хранения данных NIMBUS, где приведены актуальные параметры моделей.
Частые вопросы про СХД для облака
Как СХД предотвращает «шумного соседа» среди тенантов?
Через QoS на уровне томов — администратор задаёт лимит IOPS или пропускной способности для конкретного тома, ограничивая влияние одного арендатора на остальных.
Можно ли добавить ёмкость без остановки облачной платформы?
Да, подключение модулей расширения и онлайн-миграция томов между дисковыми группами выполняются без прерывания работы виртуальных машин.
Подходит ли Гром для чисто виртуализационного облака?
Да, виртуализация и контейнеризация прямо указаны в областях применения Гром, а гибридная архитектура с SSD-кэшированием обеспечивает приемлемую латентность для большинства IaaS-сценариев.
Как реализована сетевая изоляция между тенантами?
Через VLAN и агрегирование сетевых портов на уровне ПО «Юпитер», что разделяет трафик разных арендаторов на общей физической инфраструктуре.
Поддерживает ли СХД интеграцию с системами оркестрации облака?
Да, RESTful API позволяет управлять ресурсами хранилища программно, а интеграция с Active Directory, LDAP, Zabbix и Grafana закрывает вопросы аутентификации и мониторинга.
Гром
система хранения данных
В реестре
Оптимально подходит для организаций среднего и крупного бизнеса, которым требуется надежное, масштабируемое и эффективное решение для хранения данных с возможностью адаптации к различным типам нагрузок
Молния
система хранения данных
В реестре
Решение премиум-класса для организаций, чей бизнес зависит от скорости обработки данных и требует инфраструктуры хранения с высокой пропускной способностью. Подходит для отраслей: телекоммуникации, финансы, госучреждения и производство