Коротко. Заявленная ёмкость дисков (raw) никогда не равна ёмкости, которую увидит приложение. Часть съедает erasure coding, часть — метаданные на NVMe, часть — запас под ремонт и рост. Считать надо в три шага: raw → usable по политике ((w − s) / w) → рабочий запас. Ошибка «умножить число дисков на их объём» приводит к обещанию заказчику ёмкости, которой не будет.
1. Три числа, которые нельзя путать
| Термин | Что означает | Кто его называет |
|---|---|---|
| Raw | суммарный объём дисков данных до любой раскладки | вендор, отдел закупки |
| Usable | ёмкость, доступная приложению после erasure coding | расчёт по политике |
| Рабочий запас | usable минус резерв на ремонт, служебные операции и рост | проектировщик |
Приложение видит только usable. Raw — это про железо; usable — про политику; запас — про эксплуатацию. Все три нужны в проектной записке, иначе спор «сколько у нас места» будет бесконечным.
2. Шаг 1: raw — что реально стоит в стойке
Считается по факту установленных дисков, а не по спецификации:
- диски данных (blockstore) — NVMe или HDD в зависимости от платформы;
- отдельно диски ОС и отдельно NVMe под метаданные: они не входят в ёмкость данных;
- заявленная вендором ёмкость дисков всегда больше фактической: производители считают в десятичных единицах (TB = 10¹² байт), ОС — в двоичных.
Публичные ориентиры по платформам (для оценки, не для закупки):
| Платформа | Форм-фактор | Минимум нод |
|---|---|---|
| P200 | 1U12 | 3 |
| X200 | 4U90 | 3 (базовая конфигурация — 4 сервера по два модуля) |
| Z200 | 1U10 | 3 |
- У Z200 минимальная конфигурация из трёх нод — 30 NVMe по 15.36 TB, то есть 460.8 TB raw, при этом минимальная лицензируемая активная ёмкость — 100 TB.
Точные цифры — из действующего datasheet и site planning; они меняются от поколения к поколению.
3. Шаг 2: usable по политике
Формула та же, что и при выборе политики:
usable = raw × (w − s) / w
w— ширина полосы (сколько фрагментов данных),s— число фрагментов чётности.
Пример: 24 TB raw и политика 6/2 → usable = 24 × (6 − 2) / 6 = 16 TB. При этом политика 6/2 занимает 8 блоксторов из доступных — то есть на 8 дисках она вообще не поместится.
Практические значения:
| Политика | Usable от raw | Комментарий |
|---|---|---|
| 2/1 | 50% | минимум для малого стенда, запас блоксторов 1 |
| 4/2 | 50% | две единицы запаса, разумный компромисс для 8 дисков |
| 6/2 | 67% | выше эффективность, нужен запас по числу блоксторов |
| 10/2 | 80% | эффективно, но требует много блоксторов |
| 12/4 | 67% | безопаснее по отказам, дороже по ёмкости |
Стоковые пресеты вендора рассчитаны на большие полки: balanced (13/4), lowest_overhead (15/4),
2site_replicated (12/2). Для небольших конфигураций штатный слот — ветка custom. Подробнее —
Формула политики DSS.
4. Шаг 3: рабочий запас
Usable — это арифметика раскладки, а не разрешение залить всё до последнего байта.
Что забирает место помимо данных:
- Ремонт и перестройка. При отказе диска фрагменты восстанавливаются в свободное место. Если его нет, запись встаёт раньше, чем кончится ёмкость «по счётчику».
- Малые объекты. У них overhead выше: метаданные и служебные структуры занимают непропорционально больше места. Политика учитывает порог малых файлов отдельным параметром.
- Версионирование и Object Lock. Каждая версия объекта — отдельные данные; включённое версионирование на «горячем» бакете удваивает и утраивает занимаемое место.
- Квоты и «пустое» место бакета. Квота ограничивает сверху, но не освобождает; удалённые объекты в бакете с версионированием остаются.
- Staging холодного класса. Объект, уходящий на ленту, какое-то время занимает место в активном слое.
Практическое правило: рабочий запас 15–20% от usable. Запас меньше 10% — приглашение к
инциденту 507 в самый неудобный момент.
5. Где смотреть фактические цифры
Не по спецификации, а по системе:
- барометр DSS — общий индикатор заполнения (
ok/full); еслиfullпри свободных дисках, это не про ёмкость, а про политику — см. S3 507 при свободных дисках; - заполнение неймспейсов — по каждому namespace отдельно, потому что квоты и классы разные;
- ёмкость по колонке — сколько блоксторов реально в раскладке (
N), а не сколько дисков физически стоит; - занятое место по бакетам — через GUI или CLI продукта.
Расхождение «в GUI меньше, чем в расчёте» — нормально, если считать без учёта метаданных, служебных структур и запаса. Расхождение «в GUI больше raw» — повод разбираться: обычно это версии объектов или незавершённые multipart-загрузки.
6. Пример расчёта (без привязки к площадке)
Задача: кластер из трёх нод, по 8 дисков данных на ноду, диск 14 TB.
- Raw: 3 × 8 × 14 = 336 TB (в десятичных единицах; в двоичных будет меньше).
- Блоксторы: 24 → политика 14/4 занимает 18, запас 6. Usable = 336 × (14−4)/14 = 240 TB.
- Рабочий запас 15%: 240 × 0.85 = 204 TB доступно приложению.
- Проверка: если нагрузка предполагает версионирование на половине данных, реальная ёмкость под «полезные» объекты падает ещё сильнее — версии занимают место наравне с текущей.
Итог для заказчика: не «336 TB», а «около 200 TB полезной ёмкости с учётом защиты и запаса». Такая формулировка снимает половину будущих споров.
7. Частые ошибки
- Считать в TB дисков, не в usable. Классика: обещали raw, получили usable.
- Выбирать политику «ровно по числу блоксторов». Запас 0 → первый отказ диска останавливает запись.
- Забыть про NVMe под метаданные. Отдельные диски — отдельная строка бюджета, и они не увеличивают ёмкость данных.
- Игнорировать профиль объектов. Миллиард мелких объектов и тысяча больших при одинаковом объёме ведут себя по-разному.
- Планировать «до заполнения». Хранилище живёт не до 100%, а до момента, когда ремонт перестаёт помещаться.
- Не пересчитывать после расширения. Добавили диски —
Nизменилось, политика может стать другой, а старые экстенты остаются как были.
8. Источники
- ActiveScale Datasheet DS00546A (доступ 2026-11-07)
- ActiveScale Z200 Datasheet (доступ 2026-11-07)
- P200 Site Planning (доступ 2026-11-07)
- Наша практика: расчёты политик под реальное число блоксторов на лабораторных стендах; цифры примера — учебные, не замер конкретной инсталляции.
- Обновлено: 2026-11-07.