Durability и erasure coding

1. Чем erasure coding отличается от RAID

RAID защищает от отказа диска внутри одной полки. Erasure coding защищает от отказа диска, ноды и (при geospreading) площадки — потому что фрагменты и чётность распределены шире.

Разница не только в ширине, но и в стоимости отказа. В RAID5 потеря второго диска во время rebuild означает потерю массива: rebuild читает все оставшиеся диски и длится часами, а окно уязвимости растёт вместе с объёмом диска. В распределённой схеме ремонт идёт не «всем массивом», а конкретными фрагментами: пересчитывается только утраченная часть, остальные ноды продолжают обслуживать чтение. Поэтому вендор заявляет 19 девяток: расчёт опирается на скорость ремонта и на запас (N − (w+s)), а не на «надёжность диска» как таковую.

2. Как считается политика

Обозначения:

• w — ширина полосы (spread width), сколько фрагментов данных;
• s — сколько фрагментов чётности (safety);
• N — число блоксторов.

Требование: w + s ≤ N. Иначе раскладка не помещается, и запись встаёт с 507, даже если диски свободны.

Usable: (w − s) / w.

Примеры:

Стоковые пресеты (balanced 13/4, lowest_overhead 15/4, 2site_replicated 12/2) рассчитаны на большие полки — на 8 дисках они не влезают. Для малых конфигураций нужна ветка custom с подходящими w/s.

Обратите внимание на строку 16: 10/2 даёт 80% usable, но запас — четыре блокстора. Строка 20: 12/4 даёт 67%, зато переживает четыре одновременных отказа. Это не «хуже» и «лучше», это два разных ответа на вопрос «что для меня дороже — ёмкость или окно ремонта».

Подробнее: Формула политики DSS.

3. 2D erasure coding для Cold

Обычное EC распределяет фрагменты «в одном измерении» (по дискам/нодам). 2D EC добавляет второе измерение: чётность внутри и между кассетами, приводами, библиотеками и площадками.

• Восстановление обычно требует одной кассеты (локальные коды).
• Overhead — от 15% (вендор), что эффективнее репликации/двух копий (до 40% лучше).
• Патент US11216196 (у Quantum).

Смысл второго измерения — не «больше чётности», а меньше движений: утрата одной кассеты восстанавливается по локальным кодам, не поднимая остальные. Для ленты это критично — каждое движение означает загрузку кассеты в привод и минуты латентности.

4. Что такое rebuild и чем он отличается от rebalance

Эти два процесса часто путают, потому что оба «двигают данные» и оба видны в мониторинге как фоновая нагрузка. По смыслу они противоположны.

Rebuild (ремонт, в продукте — Dynamic Data Repair, DDR) — восстановление утраченного. Причина: отказ диска, ноды, кассеты или повреждение фрагмента. Механизм: продукт постоянно мониторит целостность, находит недостающие или битые фрагменты, пересчитывает их по чётности из живых фрагментов и раскладывает заново. Ключевое: ремонт не ждёт замены диска. DDR работает фоном и восстанавливает избыточность даже тогда, когда физически менять ещё нечего — например, когда диск ещё «на месте», но данные с него уже не читаются.

Rebalance (перебалансировка) — перераспределение живых данных. Причина: изменилась топология или ёмкость — добавили ноды, добавили полку, вывели диск из раскладки штатным decommission. Механизм: DSS перекладывает фрагменты так, чтобы раскладка снова соответствовала политике и нагрузка распределилась по новым блоксторам. Ключевое: данные при этом целы, ничего не восстанавливается — меняется только их местоположение.

Практическая разница — в том, что можно делать во время процесса. Ремонт трогать нельзя: это аварийный режим, любое дополнительное выпадение уменьшает запас. Перебалансировку планируют в спокойное окно — она добавляет нагрузку на сеть и диски. Отсюда правило: decommission и расширение — работы в окно; ремонт — в любой момент, но без самодеятельности вокруг.

Отдельно стоит Dynamic Data Placement (DDP): по документации раскладка при расширении не требует обязательного rebalance — новые данные размещаются с учётом новой топологии, старые остаются на месте. Это снимает «переливание всего» после добавления ноды, но не отменяет decommission: при выводе диска его данные всё равно переносят. Вывод старого железа целиком — отдельный сценарий (Migration and Decommission, 7.3): фоновая миграция данных и метаданных, для S3 и Glacier прозрачная, запускается специалистами вендора.

5. География: 1/2/3 сайта и что это меняет в раскладке

По документации geospreading поддерживает три конфигурации, и они дают разный уровень защиты.

Один сайт. Все ноды в одной площадке. Erasure coding защищает от отказа диска и ноды; отказ площадки (питание, сеть, пожар, затопление) не переживается вообще. Это нормальная конфигурация для рабочих данных и бэкапов, но в план аварийного восстановления надо честно записывать: потеря площадки — потеря данных. Резервная копия в этом сценарии обязательна и должна лежать вне площадки.

Два сайта. Вторая площадка получает копию через репликацию. Здесь важно понимать, что это другая механика: не «половина фрагментов там, половина здесь», а репликация объектов между системами. Пресет 2site_replicated в политике рассчитан на такой сценарий. Плюс: переживается потеря сайта. Минус: платите за полную копию, а не за чётность; и вопрос «кто главный при одновременной записи в оба сайта» надо решать до ввода в строй, а не в аварию.

Три сайта (3GEO DDP). Фрагменты и чётность распределяются так, чтобы пережить потерю одной площадки без полной копии. Это самая эффективная по ёмкости схема отказоустойчивости и самая требовательная к сети: между сайтами нужна предсказуемая полоса и латентность, иначе запись деградирует. Три сайта — это ещё и три комплекта эксплуатации: питание, охлаждение, доступ, обслуживание.

Что меняется в раскладке при переходе от одного сайта к трём:

• растёт требование к N — фрагменты должны физически помещаться в разные домены отказа;
• растёт чувствительность к сети — часть записи идёт через WAN, и это уже не «внутренняя» сеть;
• меняется окно ремонта — восстановление после потери сайта идёт по WAN и измеряется в другом масштабе времени, чем локальный ремонт диска;
• появляется кворумный вопрос — при потере связи между сайтами система должна решить, какая сторона продолжает принимать запись.

Наши стенды — три ноды в одной площадке, поэтому выводы про несколько сайтов мы берём из публичной документации, а не из собственного опыта. Полезно помнить, читая любые «полевые» советы: они почти всегда про один сайт.

6. Что значит «19 девяток»

99.99999999999999999% — расчётная вероятность сохранности при модели отказов. Это не гарантия, что данные не потеряются при:

• логической ошибке (удаление, шифровальщик);
• ошибке приложения;
• потере метаданных/БД;
• катастрофе, не входящей в модель.

Поэтому нужны версионирование, Object Lock, репликация/3GEO, бэкап метаданных и регламент.

7. Что durability НЕ покрывает

Erasure coding отвечает на вопрос «что будет, если железо откажет». Он не отвечает на вопрос «что будет, если данные испортят изнутри». Это разные классы рисков, и закрываются они разными средствами.

Логическое удаление. DeleteObject — штатная операция, и она выполняется. Durability тут ни при чём: фрагменты целы, чётность в порядке, объекта просто нет. Закрывается версионированием (удаление ставит delete-маркер, прежняя версия остаётся) и Object Lock (WORM: объект нельзя удалить или перезаписать до истечения срока). И то и другое надо включить до инцидента: включённое после удаления вернёт только то, что успело попасть в историю.

Шифровальщик. Классический сценарий: процесс с валидными ключами перезаписывает объекты «мусором». С точки зрения системы всё корректно — запись прошла, коды сошлись, избыточность восстановится. Данные при этом потеряны. Закрывается тем же Object Lock (в режиме compliance объект нельзя перезаписать) плюс версионированием и ограничением прав: ключ, которым пишет бэкап-агент, не должен уметь удалять. Дополнительно — MFA для администраторов (появилась в 7.2 для UI/CLI/REST), потому что шифровальщики часто идут через скомпрометированные учётки.

Потеря метаданных. Самый недооценённый риск: данные на дисках и лентах, фрагменты целы, но нет ответа, из каких фрагментов состоит объект X. Метаданные в ActiveScale — отдельный слой: модель в modeldb, метастор DSS (arakoon), конфиги раскладки; erasure coding их не защищает. Закрывается бэкапом конфигурации и метаданных — модель, очередь установки, group_vars, конфиги DSS, базы метастора. Это два разных бэкапа: лёгкий (модель и конфиги, часто) и тяжёлый (базы метастора, перед работами по DSS).

Ошибка приложения. Запись ушла не туда и не та — избыточность это размножит, а не исправит. Закрывается версионированием, отдельным бакетом под проверенную запись и регламентом.

Катастрофа вне модели. Пожар в единственной площадке, ошибочно выданная команда на удаление бакета, потеря ключа шифрования. Модель отказов такие события не считает. Закрывается географией (2/3 сайта) и внешней копией.

8. Практические выводы

1. Считайте w+s ≤ N до установки, а не после первого 507.
2. Не ставьте политику «занимает ровно N»: при отказе диска запаса не останется.
3. Проверяйте барометр DSS (ok) и заполнение NS.
4. Для Cold планируйте кассеты так, чтобы safety была достижима (не 0).
5. Тестируйте restore, а не только запись.
6. Разделяйте в мониторинге ремонт и перебалансировку: у них разная причина и разный режим работ.
7. Durability не заменяет версионирование, Object Lock и бэкап метаданных — это четыре разных средства против четырёх разных рисков.

9. Источники

• ActiveScale Datasheet DS00546A
• Cold Storage Tech Brief
• Release Notes 7.3