Коротко. Quantum ActiveScale — объектное хранилище для больших объёмов неструктурированных данных. В одной системе живут активный класс (S3 Standard) и холодный (S3 Glacier-совместимый, на ленте). Метаданные вынесены на NVMe, данные — на NVMe/HDD/ленту; масштабирование без обязательного rebalance. «AMUR» в нашей практике — имя установочной платформы/образа, не отдельный продукт вендора.
1. Зачем нужно объектное хранилище
Файловая система хорошо работает, пока данных десятки терабайт и миллионы файлов. Когда речь идёт о миллиардах объектов и эксабайтах, начинаются проблемы: каталоги, права, бэкапы метаданных, перебалансировка. Объектное хранилище решает это иначе:
- данные — объекты с ключом и метаданными, а не файлы в иерархии;
- доступ — по HTTP/S3 API, а не по POSIX;
- масштаб — добавлением нод, без «перестроения всего»;
- целостность — erasure coding и фоновый ремонт, а не RAID-контроллер.
ActiveScale — один из таких продуктов. Его особенность: активные и холодные данные в одном namespace, с общими политиками и мониторингом.
2. Два класса хранения
| Active | Cold | |
|---|---|---|
| Носитель | NVMe / HDD | Лента (RAIL-архитектура) |
| Доступ | мгновенный | минуты (restore) |
| S3-класс | S3 Standard | S3 Glacier-совместимый |
| Для чего | рабочие данные, бэкапы, аналитика | архив на годы/десятилетия |
| Экономика | выше стоимость TB | ниже стоимость TB, вендор заявляет до −80% |
Переход между классами — через lifecycle-политики; восстановление из холодного класса — через
restore, после чего объект снова доступен как обычный.
3. Архитектура: два слоя
клиенты (S3 / NFS)
│
Access Layer — метаданные на NVMe, балансировка по нодам
│
Data Layer — активные данные (NVMe/HDD) + холодные (лента)
- Access Layer хранит метаданные объектов и обслуживает запросы; метаданные на NVMe — поэтому листинг и точечные запросы не упираются в диски.
- Data Layer хранит сами данные; активная часть — NVMe/HDD, холодная — лента через Tape Connector и библиотеки.
- Один namespace: приложение не знает, на каком носителе лежит объект, пока не нужно
restore.
3.1 Erasure coding и durability
Данные раскладываются по дискам/нодам/площадкам с избыточностью. Вендор заявляет до 19 девяток durability для активного и холодного классов. Для холодного тира используется 2D erasure coding: чётность распределяется внутри и между кассетами, приводами, библиотеками и площадками; overhead — от 15%, что эффективнее репликации и двух копий (вендор заявляет до 40% лучше).
3.2 Dynamic Data Placement и Dynamic Data Repair
- DDP раскладывает данные по доступным ресурсам по политике; при добавлении нод не требует «перебалансировки всего» — новые данные просто учитывают новую ёмкость.
- DDR постоянно проверяет целостность и чинит повреждённые фрагменты, не дожидаясь замены диска. Замена диска становится рутиной, а не аварией.
3.3 Консистентность и география
- Strong consistency: после успешной записи все ноды видят актуальные данные.
- Geospreading: один сайт, два сайта (репликация), три сайта (3GEO DDP) — для защиты от отказа площадки.
4. Доступ к данным
| Протокол | Что даёт | Ограничения |
|---|---|---|
| S3 API | основной путь: бакеты, объекты, версии, lifecycle, Object Lock, IAM | S3-совместимость не 100% AWS: проверять конкретные операции |
| NFS v3 | файловые тома для приложений без S3 | не основной сценарий; на scaled-out нодах есть нюансы |
| GUI / CLI / REST | управление системой, мониторинг, автоматизация | GUI — не замена API для автоматизации |
4.1 IAM и безопасность
- Аккаунты, пользователи, группы, политики; resource policy на бакет.
- Шифрование in flight (TLS) и at rest (AES-256); FIPS 140-2 — опционально.
- MFA (TOTP) для администраторов — с версии 7.2.
- Object Lock и версионирование — для защиты от удаления/шифровальщиков.
5. Для каких задач
| Задача | Почему подходит |
|---|---|
| Бэкап и восстановление | S3-совместимость, версионирование, Object Lock, холодный тир |
| Архив на годы | Cold Storage на ленте, lifecycle, restore по требованию |
| AI/ML и аналитика | параллельный доступ, метаданные на NVMe, масштаб по ёмкости |
| Медиа и видео | большие объекты, потоковый доступ, холодный архив |
| Частное облако / S3-сервис | IAM, квоты, репликация, мультитенантность |
6. Чего система не делает
- Это не файловая система общего назначения: не ждите POSIX-семантики и «папок».
- Это не «просто RAID»: политика раскладки — отдельная сущность, её надо считать.
- Это не «поставил и забыл»: нужны регламент, обновления, замена дисков и ленты, контроль времени и сети.
- Это не замена облаку «один в один»: часть операций S3 отличается, клиентов надо проверять.
7. Где используется
- Бэкап-хранилище для СУБД, виртуализации, корпоративных систем.
- Архив документов, медиа, научных данных — с холодным тиром.
- Дата-лейк для аналитики и AI-пайплайнов.
- Частное S3-облако для внутренних команд и клиентов.
8. Источники
- Quantum, ActiveScale Object Storage (дата доступа 2026-11-07).
- Quantum, ActiveScale Object Storage Datasheet DS00546A.
- Quantum, Cold Storage Tech Brief.
- Quantum, Software Documentation Center 7.3.
Частые вопросы
Чем ActiveScale отличается от обычного NAS? NAS отдаёт файлы и папки по NFS/SMB, и его масштаб упирается в контроллер и файловую систему. ActiveScale отдаёт объекты по S3-совместимому API, а метаданные держит отдельным слоем на NVMe — поэтому миллиарды объектов для него штатный сценарий, а не предельный. Версионирование, Object Lock, lifecycle-переходы и квоты работают на уровне бакета, а холодный класс живёт в том же пространстве имён, что и активный.
Нужен ли ActiveScale, если у нас 50 ТБ данных? Обычно нет: на таких объёмах файловая система или обычная полка дешевле и проще в обслуживании. Объектное хранилище раскрывается там, где данных сотни терабайт и больше, где много объектов, где нужен S3-доступ из приложений и где часть данных пора переводить в архив на ленту. Если задача — «просто файлы по NFS», ActiveScale будет избыточен.
Данные нужно переписывать под S3? Да, приложение должно уметь работать с S3 API: «положи объект», «отдай объект», «покажи список». Готовые клиенты — бэкап-системы, аналитические платформы, SDK — обычно уже это умеют. Для файловых нагрузок есть NFS v3, но это не основной сценарий. Миграцию с NAS планируют отдельным этапом: не «переключить точку монтирования», а перенести данные и переписать доступ.
Что значит «19 девяток» durability? Это расчётная вероятность сохранности данных при отказах по модели, заявленная вендором: erasure coding раскладывает фрагменты и чётность по дискам, нодам и, при необходимости, площадкам. Это не гарантия от логических ошибок: удаление объектов, шифровальщик, сбой приложения или потеря метаданных не входят в модель отказов. Поэтому версионирование, Object Lock и бэкап метаданных нужны отдельно.
Можно ли расширять систему без простоя?
Вендор заявляет расширение добавлением нод и полок без обязательного rebalance, а также непрерывные
rolling-апгрейды. Практический нюанс: число блоксторов задаёт допустимую политику защиты, поэтому
перед расширением пересчитывают w + s ≤ N и проверяют запас. Расширение — плановая работа со своим
окном и проверками, а не «просто вставили ноду».