Объектное хранилище и NAS: в чём разница и когда NFS достаточно

1. Короткий ответ

Одно правило: если приложение говорит на S3 — берите объектное хранилище; если приложение ждёт файловые операции (open/read/write/rename) — берите NAS. Смешивать эти модели «на всякий случай» дороже, чем выбрать одну.

2. Почему это вообще разные вещи

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

Объектное хранилище держит неизменяемые объекты: у объекта есть ключ (строка), тело и метаданные. Запись — это «положи объект целиком» (или multipart-частями). Изменение — это новая версия объекта. Нет seek, нет rename, нет «папок» — есть только префиксы ключей. Зато такая модель:

• легко распараллеливается: разные ключи обслуживаются разными нодами;
• не требует, чтобы объект целиком лежал на одном диске;
• позволяет держать метаданные отдельно и очень быстро (HEAD по ключу — это доступ к метаданным, а не к данным);
• позволяет переносить тело объекта в другой класс хранения, не меняя ключ.

Именно эта архитектура (метаданные отдельно, данные отдельно) даёт масштаб, которого нет у файловых систем на контроллере.

3. Что это значит на практике

3.1 Миллиарды объектов

Файловая система хранит метаданные в дереве и индексах; при десятках миллионов файлов начинают расти времена ls, stat, восстановления после аварии. У объектного хранилища метаданные — это записи в отдельном слое (у ActiveScale — на NVMe), и количество объектов масштабируется вместе с ним: вендор для минимальной конфигурации Z200 заявляет до 50 млрд объектов при 100 TB NVMe под объекты.

3.2 Параллельные клиенты

NFS с одним сервером упирается в контроллер: все клиенты идут через одни и те же процессоры и кэш. S3-шлюз ActiveScale обслуживается несколькими нодами; клиенты могут обращаться к разным нодам и разным ключам одновременно. Это не значит «быстрее всегда» — сеть и клиент остаются узкими местами, — но потолок задаёт не один контроллер.

3.3 Мультиплощадочность

NAS обычно живёт в одной площадке; репликация — отдельный продукт (DR, snapmirror и т.п.). ActiveScale по datasheet поддерживает три схемы: один сайт, два сайта (репликация) и три сайта (3GEO DDP). Фрагменты и чётность распределяются так, что потеря площадки не означает потерю объекта.

3.4 Холодный архив

Полка с лентами — это не NAS и не объектное хранилище, а третья модель: ручное управление, файловые «тома», свои каталоги. ActiveScale закрывает Cold-класс внутри той же системы: объект в namespace переходит в Glacier-класс по lifecycle, а клиент по-прежнему видит S3-ключ.

4. NFS v3 у ActiveScale: что это на самом деле

В datasheet ActiveScale NFS v3 указан наряду с S3: продукт умеет отдавать файловые тома. Это удобно, когда:

• приложение не умеет S3, а переписывать его дорого;
• нужно временно смонтировать данные для миграции;
• нужен простой доступ «по путям» к небольшому набору объектов.

Но NFS-доступ у ActiveScale — не основной сценарий, и это важно понимать до проектирования:

1. Файловая семантика поверх объектной модели — это трансляция. Часть привычных вещей (блокировки, атомарный rename, произвольная запись по смещению, жёсткие права POSIX) ведёт себя не так, как на локальной ФС; поведение зависит от клиента и его опций монтирования.
2. Производительность и модель отказа рассчитаны на объекты: большие последовательные чтения — хорошо, тысячи мелких случайных операций — хуже.
3. NFS-сценарий не отменяет S3: один и тот же namespace может использоваться обоими способами, но нагрузка складывается.

Не проектируйте NFS как замену NAS в 100% случаев. Если рабочая нагрузка — это POSIX (базы данных, домашние каталоги, сборка, общие каталоги пользователей), берите NAS или файловую систему. Объектное хранилище выбирают тогда, когда модель данных — уже объекты.

5. Таблица выбора: что брать под задачу

6. Типичные ошибки перехода с NAS

1. Ждать от S3 файловых операций. «Почему нет rename?» — в S3 переименование это копия + удаление. Если приложению нужен rename, оно спроектировано под ФС.
2. Использовать один «каталог» на миллионы мелких объектов. Мелкие объекты (меньше порога small_file_threshold, по умолчанию 512 KiB в наших настройках) упаковываются в small-files политику — это влияет на usable и на политику DSS; см. Формулу политики DSS.
3. Считать raw = usable. У объектного хранилища чётность erasure coding съедает часть ёмкости; NAS с RAID1 тоже, но привычка считать «диски минус один» не переносится напрямую.
4. Оставлять бэкап на NAS «потому что привычно». Если бэкап-система умеет S3, отдавать её на NAS — терять версионирование, Object Lock и масштаб.
5. Игнорировать совместимость S3-клиента. «S3-совместимость» — это набор операций; проверяйте свою цепочку на 501/400 заранее, а не после миграции. См. S3-совместимость.

7. Как выглядит миграция с NAS

Порядок, который не зависит от вендора:

1. Инвентаризация. Сколько объектов, какой средний и максимальный размер, какие приложения читают/пишут, есть ли rename и блокировки.
2. Разделение. Данные, у которых есть S3-клиент, выносим в объектное хранилище; POSIX-данные оставляем на файловой системе.
3. Пилот. Один бакет, один класс задач, измерение пропускной способности на своём канале (не «по datasheet»).
4. Политика и ёмкость. До миграции посчитать usable и число блоксторов; см. Планирование ёмкости.
5. Приёмка. Проверить PUT/GET/LIST/DELETE, multipart, версионирование, права IAM.

8. Источники

• ActiveScale Datasheet DS00546A (2026-11-07)
• ActiveScale Z200 Datasheet (2026-11-07)
• Практика нашей команды: кластеры ActiveScale 7.3.1.2, включая работу с NFS-томами как вспомогательным путём.