ActiveScaleинженерная практика

Планирование холодного тира: лента, кассеты и бюджет restore

Проектирование cold-storagetapeglaciercassettesafetycapacity

Коротко. Холодный класс ActiveScale хранит объекты на ленте и совместим с S3 Glacier: запись идёт автоматически по политике, чтение требует restore. Планировать надо не только «сколько петабайт влезет», но и число кассет, наличие свободных под ротацию, достижимость safety и сколько времени займёт массовый возврат данных. Лента — не бэкап: удаление и lifecycle работают и там.

1. Что даёт холодный класс

Параметр Значение (по данным Quantum)
Совместимость S3 Glacier-класс в том же namespace, что и активный
Защита 2D erasure coding, а не репликация/две копии
Overhead от 15%
Эффективность до 40% эффективнее репликации или двух копий
Массив RAIL — Redundant Array of Independent Libraries
Патент US11216196
Стоимость вендор заявляет снижение стоимости холодного хранения до 80%

Ключевое: классы живут в одном namespace. Приложение пишет объект с классом GLACIER (или его переводит lifecycle по возрасту) и дальше не думает, где объект лежит физически.

2. Что планируется помимо объёма

Пять чисел, без которых проект «архив на ленте» разваливается на эксплуатации:

  1. Объём архива и скорость роста — сколько уходит в холодный класс в месяц.
  2. Число кассет — с учётом ёмкости поколения LTO и того, что кассета — единица ротации, а не «файл».
  3. Свободные кассеты под staging и ротацию. Без запаса свободных кассет safety падает в ноль, и архивация встаёт — см. TAPE SAFETY = 0.
  4. Число приводов — определяет параллелизм записи и чтения, а значит и время.
  5. Бюджет restore — сколько данных может понадобиться вернуть одновременно и за какое время.

Пункт 5 чаще всего забывают. Архив, который «дешевле», но возвращается неделю, в аварии оказывается дороже активного хранения.

3. Кассеты: что важно знать до закупки

  • Штрихкод — идентификатор кассеты в системе. Продукт нормализует его, отрезая LTO-суффикс, а реестр кассет может хранить штрихкод как есть. Из-за этого «кассета есть, а система её не видит» — см. «Пропавшие» кассеты.
  • Кассета не бесконечна. В 7.3 появилось Tape Space Reclamation — повторное использование ёмкости кассет после удаления объектов, работает ретроспективно и автоматически. До этого ёмкость кассеты с удалёнными объектами считалась занятой.
  • Поколения LTO не смешиваются в одной партиции произвольно: 7.3 поддерживает LTO-10, и разные поколения можно держать в разных партициях библиотек.
  • Маркировка. Формат штрихкода выбирается один раз и дальше соблюдается на всех кассетах; «кто как наклеил» — это не про аккуратность, а про работоспособность реестра.

4. Лента и S3: где границы

Что делает система:

  • ставит объект в очередь на архивацию;
  • собирает объект в том, проходит staging, получает маркер архивации;
  • оркестратор выдаёт запрос библиотеке; привод пишет на кассету;
  • объект остаётся доступным «логически», но чтение требует restore.

Что важно понимать:

  1. restore возвращает объект в активный/staging-слой — только после этого его можно читать как обычный. С 7.1 поддержан ranged restore (часть объекта), с 7.2 restore стал заметно быстрее (вендор заявляет до 5×), в 7.3 — ещё быстрее из warm-staging.
  2. Cold Storage QoS (7.3) позволяет резервировать приводы под archive и restore — настраивается через поддержку. Это ответ на ситуацию «массовый restore съел все приводы, архивация встала».
  3. MPF (Multi-Path Failover) — альтернатива APF для control-path между Tape Connector и Scalar; новые установки по умолчанию на MPF. При проектировании надо знать, какой путь у вас.
  4. Лента — не бэкап. Object Lock и версионирование настраиваются отдельно, а ошибка приложения («удалили не то») придёт и в архив.

5. Как считать

Простой расчёт, который стоит делать до закупки:

нужно кассет = ceil(объём архива × (1 + overhead) / ёмкость кассеты) + резерв на ротацию
  • overhead — от 15% (2D erasure coding);
  • резерв на ротацию — минимум 10–20% сверху, чтобы было куда писать при переполнении группы;
  • отдельно считаются кассеты под staging, если профиль нагрузки предполагает частые записи.

Дальше проверяется, что:

  1. Число приводов даёт приемлемое время архивации месячного объёма.
  2. Время массового restore укладывается в целевое окно (RTO), а не «когда-нибудь».
  3. safety в группах достижима при текущем числе кассет — иначе система честно скажет «не могу обеспечить защиту».
  4. Есть регламент ротации: какая кассета когда выводится, кто проверяет, что данные на ней читаются.

6. Частые ошибки

  1. Считать только ёмкость. Без приводов и свободных кассет архив не работает.
  2. Не планировать restore. Проверяют только запись — а авария всегда про чтение.
  3. Забыть про Lifecycle. Объекты копятся в активном классе, если политика перехода не задана.
  4. Игнорировать reclamation. На версиях до 7.3 ёмкость кассет с удалёнными объектами считалась занятой.
  5. Смешивать поколения LTO в одной партиции без понимания последствий.
  6. Планировать «на глаз» по числу кассет в шкафу — вместо расчёта по объёму и профилю.

7. Источники

Связанное

Нужен инженер? Разберу вашу ситуацию и скажу, что делать — по шагам, с проверками.

Обсудить задачу