Коротко. Quantum ActiveScale — объектное хранилище для больших объёмов неструктурированных данных. Оно даёт S3-совместимый доступ, два класса хранения (активный и холодный на ленте) в одном namespace, erasure coding с высокой durability и масштабирование добавлением нод без обязательного rebalance. Это не NAS и не «просто RAID».
1. Простыми словами
Представьте склад, где вместо полок с коробками — объекты. У каждого есть номер (ключ), этикетка (метаданные) и содержимое. Вы обращаетесь к складу по HTTP: «положи объект», «отдай объект», «покажи список». Склад сам решает, на какой диск/ноду/ленту положить коробку, и хранит несколько копий/фрагментов, чтобы потеря одной полки не потеряла товар.
ActiveScale — такой склад. Его особенности:
- S3-совместимый API — с ним умеют работать бэкап-системы, приложения, аналитика.
- Два класса — активные данные (NVMe/HDD) и холодные (лента, S3 Glacier-совместимый).
- Один namespace — приложение не думает, где лежит объект; переход между классами — по политике.
- Erasure coding — данные защищены фрагментами и чётностью, а не только RAID.
- Масштаб — добавляете ноды/полки; вендор заявляет расширение без rebalance.
2. Чем отличается от NAS
| NAS | ActiveScale | |
|---|---|---|
| Доступ | файлы/папки (NFS/SMB) | объекты по S3 API |
| Масштаб | ограничен контроллером | добавление нод |
| Метаданные | в файловой системе | отдельный слой на NVMe |
| Миллиарды объектов | больно | штатный сценарий |
| Версионирование/Object Lock | зависит от ФС | встроено |
| Холодный тир | отдельное решение | в той же системе |
NFS-доступ у ActiveScale есть, но это не основной сценарий: для POSIX-нагрузок лучше файловая система, для объектов — ActiveScale.
3. Из чего состоит
клиенты → Access Layer (метаданные NVMe) → Data Layer (NVMe/HDD/лента)
- Ноды — серверы, объединённые в кластер; минимум три (X200 — четыре).
- Блоксторы — единицы раскладки данных на дисках; их число определяет политику.
- Колонка — логическая группа нод/дисков.
- DSS — подсистема хранения (раскладка, чётность, ремонт).
- Модель — база описания системы (машины, сети, диски, приложения), из неё продукт рендерит конфиги.
- Tape Connector — управление ленточной библиотекой для холодного класса.
4. Зачем нужен
- Бэкапы и архив: S3-совместимость, версионирование, Object Lock, холодный тир.
- Дата-лейк для аналитики/AI: параллельный доступ, метаданные на NVMe.
- Частное S3-облако: IAM, квоты, репликация.
- Медиа: большие объекты, потоковый доступ, дешёвый архив.
5. Что важно понимать до покупки
- Политика DSS должна влезать в число блоксторов (
w+s ≤ N), иначе507. - Холодный тир — отдельная инфраструктура: библиотека, приводы, коннектор, кассеты.
- Обслуживание нужно: диски, лента, часы, сеть, обновления.
- S3-совместимость не 100% AWS: проверяйте клиентов и операции.
- Durability «19 девяток» — расчётная величина вендора, не гарантия при любых сценариях.
6. Кому и когда не нужен ActiveScale
Объектное хранилище — не универсальная замена любому СХД, и честный ответ «вам это не нужно» экономит заказчику больше денег, чем любой расчёт ёмкости.
Малые объёмы и медленный рост. Продукт проектируется как кластер от трёх нод (у X200 — четыре), с лицензируемой активной ёмкостью от 100 TB и минимальным холодным классом от 1 PB. Если у вас единицы терабайт и рост 10–20% в год, стоимость трёх серверов, двух data-свичей, стоечного места и обслуживания не окупается: NAS или сервер с RAID закроют задачу дешевле и проще. ActiveScale выигрывает на объёме, который больно бэкапить и больно расширять.
Чисто файловые нагрузки. SMB продукт не предоставляет вовсе, NFS v3 есть, но это не основной
сценарий. Если приложению нужна POSIX-семантика — блокировки, mmap, атомарный rename,
жёсткие ссылки, права и владельцы, — ему нужна файловая система, а не объекты. Попытка
«прикрутить» такое приложение к S3 через FUSE-прослойку обычно заканчивается жалобами на
поведение и производительность, а не решением задачи.
Нет S3-клиентов. Если нагрузки не умеют S3 и нет готового адаптера или шлюза, хранилище останется пустым. Проверять надо не «есть ли S3 в продукте», а «умеет ли конкретная версия конкретного приложения работать с S3-совместимым endpoint»: часть клиентов требует path-style, часть — виртуальный хостинг, часть — конкретный набор заголовков.
Блочные сценарии. Базы данных, виртуальные машины, высокая доля случайного доступа к мелким блокам — не сюда. Объектный слой оптимизирован под крупные последовательные потоки и множество объектов, а не под IOPS на блок.
Нет ресурсов на эксплуатацию. Диски, лента и кассеты, часы и NTP, сеть, обновления ПО с health-check — всё это требует людей и регламента. Хранилище без обслуживания деградирует тихо: сначала растёт число событий, потом встаёт запись.
7. С чем его путают
| Путают с | Что на самом деле | Ключевая разница |
|---|---|---|
| NAS | файловый сервер с деревом каталогов | плоское пространство ключей против иерархии; нет rename папки и блокировок; масштаб метаданных другой |
| Распределённой ФС (CephFS, Gluster, Lustre) | кластерная файловая система | наружу POSIX-файлы, а не HTTP-объекты; другой способ монтирования и другой профиль нагрузки |
| «Просто RAID в сервере» | защита внутри одного шасси | erasure coding по нодам и полкам переживает отказ ноды, а не только диска |
| S3-шлюзом к обычному NAS | трансляция API поверх файлов | шлюз даёт совместимость, но не даёт масштаба метаданных и ремонта без простоя |
| Бэкап-апплаенсом | хранилище под бэкап | нет расписаний и каталога версий приложений; версионирование и Object Lock есть |
| «Ленточной библиотекой» | один из классов хранения | лента — холодный тир, а не весь продукт |
Отдельная путаница — «RAID в сервере достаточно». RAID защищает от отказа диска, пока шасси живо, и не защищает от отказа контроллера, полки или площадки. Здесь данные разложены фрагментами и чётностью по разным нодам, а Dynamic Data Repair проверяет целостность в фоне и восстанавливает утраченное, не дожидаясь физической замены диска. Это другой класс отказа, который RAID не закрывает.
8. Как выглядит типовой ландшафт
Хранилище почти никогда не бывает «для всего». В живой инсталляции обычно два-три разных потребителя с противоположным профилем.
| Сценарий | Кто пишет | Кто читает | Профиль | Класс |
|---|---|---|---|---|
| Бэкап | бэкап-сервер по расписанию | почти никто, пока не нужен restore | крупные последовательные записи, много объектов | активный |
| Аналитика и AI | ETL/пайплайн | вычислители, параллельно | множество параллельных чтений, важны метаданные на NVMe | активный |
| Медиа | ingest, камеры, MAM | монтаж, транскодинг | большие объекты, потоковое чтение | активный + холодный |
| Архив и регуляторика | раз в квартал | почти никогда | запись пачками, доступ по требованию | холодный (лента) |
| Частное S3-облако | приложения-тенанты | они же | смешанный, важен IAM и квоты | активный |
Из этой таблицы видно, почему нельзя проектировать «в среднем». У бэкапа и у аналитики противоположные требования: первому нужна immutability и предсказуемая запись, второму — параллельное чтение и низкая латентность метаданных. Архив вообще оценивается не скоростью записи, а временем восстановления: если объект лежит на ленте, restore измеряется часами и планируется окном, а не «по клику».
Практический вывод для расчёта: сначала выпишите, кто пишет, кто читает, средний и максимальный
размер объекта, долю чтения и допустимое время восстановления. И только потом считайте w, s
и usable. И проверьте сеть: в наших замерах на стенде S3 давал 110–175 МБ/с, а через лишний
L3-хоп — 51 МБ/с при канале 0.67 Gbit/s. Узкое место часто не хранилище.
9. Источники
- Quantum ActiveScale Object Storage (2026-11-07)
- ActiveScale Datasheet DS00546A
- Cold Storage Tech Brief