Функционал ActiveScale: что система умеет на практике

1. Защита данных

1.1 Erasure coding

Данные режутся на фрагменты и дополняются чётностью; фрагменты распределяются по дискам, нодам и (при 3GEO) площадкам. Потеря диска/ноды не останавливает доступ: недостающее восстанавливается из чётности.

• Для активного класса — конфигурируемая политика (spread/safety).
• Для холодного — 2D erasure coding: чётность внутри и между кассетами, приводами, библиотеками и площадками.
• Вендор заявляет до 19 девяток durability для обоих классов.

Практика: политика должна влезать в число блоксторов (w+s ≤ N). Иначе запись встанет с 507, хотя диски свободны. Это не «баг», а математика раскладки.

1.2 Dynamic Data Placement (DDP)

Раскладка по доступным ресурсам по политике. При добавлении нод не требует «перебалансировки всего»: новые данные учитывают новую ёмкость, старые не переписываются.

Практика: расширение становится предсказуемым, но политику всё равно надо пересчитывать под итоговое число блоксторов.

1.3 Dynamic Data Repair (DDR)

Фоновая проверка целостности и починка повреждённых фрагментов — без ожидания замены диска.

Практика: замена диска — рутина; но «зелёный» статус не отменяет проверку SMART и событий.

2. Консистентность и география

• Strong consistency — после успешной записи данные видны всем нодам.
• Один сайт — стандарт.
• Два сайта — репликация бакетов (включая Object Lock и холодный класс).
• Три сайта (3GEO) — DDP с защитой от отказа площадки.

Практика: география — это не «бэкап». Репликация защищает от отказа площадки, но не от логической ошибки/удаления; для этого нужны версионирование, Object Lock и отдельная копия.

3. S3 API и классы

• S3-совместимый REST API; S3 Standard и S3 Glacier-совместимый холодный класс.
• Основные операции: PUT/GET/HEAD/DELETE, multipart, листинг, копирование, presigned URL.
• Checksums: MD5; с 7.3 — CRC32, CRC32C, SHA-1, SHA-256 через x-amz-checksum-*.
• Lifecycle-политики: переход в холодный класс, expiration.
• Версионирование бакета.
• Object Lock (WORM) — защита от удаления/изменения.
• Bucket replication — в другой кластер/площадку.
• Квоты аккаунтов (hard/soft) — на бакеты и NFS-тома.

Практика: S3-совместимость не означает «любой AWS-клиент заработает без проверки». Проверяйте подпись (SigV4), кодирование не-ASCII ключей, query-параметры, стиль адресации (path-style vs virtual-hosted).

4. IAM и доступ

• Аккаунты, пользователи, группы, политики.
• Resource policy на бакет — без неё клиент получает AccessDenied даже с валидными ключами.
• IAM conditions и переменные (с 7.1) — ограничения по IP, времени, классу, Object Lock.
• S3-домен и IAM-домен настраиваются отдельно; IAM по IP-адресу не работает — нужен FQDN.
• MFA (TOTP) для администраторов (с 7.2).

Практика: «ключи есть, а доступа нет» — почти всегда отсутствие resource policy, а не неверный секрет.

5. Безопасность

• Шифрование in flight: TLS (AES-256).
• Шифрование at rest: AES-256.
• FIPS 140-2 — опционально (уточнять у вендора).
• Сертификаты S3 и GUI — через модель (ConfigRule haproxy_ssl / samurai_ssl), не правкой файла.
• Аудит действий, журналы, события.

Практика: самоподписанный сертификат без SAN ломает S3-клиентов — они проверяют имя хоста. Нужен сертификат с SAN (apex + wildcard), установленный через GUI/модель.

6. Файловый доступ

• NFS v3 — файловые тома для приложений без S3.
• Не основной сценарий; на scaled-out нодах есть ограничения (уточнять в документации версии).

7. Управление и мониторинг

Практика: GUI показывает состояние, но не всё. Латентность модели, содержимое services.cfg, остатки процессов и реальные порты проверяются руками/CLI — см. базу знаний.

8. Обновления и расширение

• Rolling-апгрейды без остановки доступа (по документации вендора).
• Расширение нодами и полками; политика пересчитывается.
• 7.3: Migration and Decommission (Disk Only) — вывод старого железа с переносом данных.
• Даунгрейд после апгрейда — нет; перед апгрейдом — health check и снятие обходов.

Практика: апгрейд — отдельный проект с окном, бэкапом конфигурации и проверкой после.

9. Границы и честные оговорки

• Часть функций (QoS ленты, миграция) запускается через поддержку вендора.
• Полного публичного списка known issues нет — сверяйтесь с release notes и поддержкой.
• «19 девяток» — расчётная durability, а не гарантия при любых сценариях.
• Поведение S3-клиентов зависит от их реализации; проверять на своём стеке.

10. Источники

• ActiveScale Object Storage Datasheet DS00546A
• Z200 datasheet
• ActiveScale Software 7.3 Release Notes
• Управление системой (GUI)

Частые вопросы

Что здесь главное, если сравнивать с обычным хранилищем? Три вещи: erasure coding вместо RAID внутри полки, отдельный слой метаданных на NVMe и два класса хранения в одном пространстве имён. Плюс Dynamic Data Placement — раскладка без обязательного rebalance при расширении, и Dynamic Data Repair — фоновый контроль целостности с восстановлением без ожидания замены диска. Именно эти четыре механизма дают то, что обычно называют «durability и масштаб».

S3 у вас настоящий? Любой клиент заработает? API S3-совместимый: бакеты, объекты, multipart, версионирование, Object Lock, lifecycle, квоты, репликация, IAM. Но «совместимый» не значит «любой AWS-клиент без проверки»: подпись SigV4, стиль адресации (path-style или virtual-hosted), DNS и сертификат с SAN надо проверить на конкретном клиенте. С 7.3 добавлены контрольные суммы CRC32/CRC32C/SHA-1/SHA-256 — часть клиентов их использует.

Что с шифрованием и требованиями безопасности? Шифрование в полёте по TLS/AES-256 и на диске AES-256; FIPS 140-2 — опционально, по данным вендора. Отдельно настраиваются IAM-политики, Object Lock для неизменяемых данных и MFA для администраторов (с 7.2). Шифрование и Object Lock — разные вещи: первое закрывает чтение посторонним, второе запрещает удаление и перезапись даже владельцу.

Есть ли файловый доступ, или только объекты? Есть NFS v3, но это не основной сценарий: система оптимизирована под объектный доступ. Для POSIX-нагрузок файловая система обычно остаётся разумнее. Если приложение сегодня работает с файлами, а завтра — с объектами, планируйте это как два разных режима, а не как «одно и то же через разные протоколы».

Как это обновляется и расширяется? Вендор заявляет непрерывные rolling-апгрейды и расширение добавлением нод. Практика: апгрейд — плановая работа с pre-upgrade health check, даунгрейда после апгрейда нет, а обходы известных проблем надо снять до него. Расширение пересчитывает число блоксторов, а значит и допустимую политику защиты — это проверяют до, а не после.