Объектное хранилище S3: развёртывание MinIO и Ceph RGW, управление и практика использования

Что такое объектное хранилище S3 и когда оно оправдано

Amazon S3 открылся для публичного доступа в марте 2006 года, а сегодня его HTTP API повторяют больше десятка реализаций: MinIO, Ceph RADOS Gateway, SeaweedFS, Garage, TrueNAS S3. Когда инженер говорит «у меня S3», речь идёт про протокол доступа и модель данных, а не про конкретный продукт.

Модель данных устроена просто. Данные лежат в бакете (bucket) в виде объектов. Объект состоит из тела, которое после записи не меняется, ключа (key, полный путь строкой, например photos/2026/09/cover.jpg), системных и пользовательских метаданных, ETag и идентификатора версии. Каталогов нет: иерархия эмулируется префиксами и разделителем «/». Имя бакета уникально в пределах кластера и состоит из 3-63 символов: строчные латинские буквы, цифры, дефис, точка. Весь доступ идёт по HTTP через S3 API, поэтому клиентом может быть curl, aws-cli, boto3, s3cmd, rclone или приложение с SDK.

Технические лимиты стоит знать до проектирования: максимальный размер объекта 5 ТБ, один запрос PUT принимает до 5 ГБ, крупные файлы загружаются multipart-ом до 10 000 частей, минимальный размер части 5 МБ (последняя часть может быть меньше). Частичная перезапись объекта невозможна, любое изменение это загрузка новой версии целиком. Блокировок файлов на уровне ФС нет, поэтому приложения, которые правят файл на месте, с S3 не работают.

Согласованность: AWS S3 даёт strong read-after-write с декабря 2020 года. MinIO и Ceph RGW также отдают актуальные данные при чтении сразу после записи. Eventual consistency встречается в старых реализациях и в момент репликации между площадками, когда копия в удалённом регионе догоняет источник.

Операции API, IAM-политики, ACL и версионирование на уровне запросов разобраны отдельно в руководстве по S3-протоколу, архитектуре API и настройке клиентов.

Чем S3 отличается от файлового и блочного хранения

Три модели решают разные задачи, и путаница между ними приводит к неудачным внедрениям. Ниже сравнение по параметрам, которые определяют выбор.

Практические следствия. PostgreSQL или MySQL ставят на блочное устройство: СУБД нужны произвольная запись блоками и fsync с предсказуемой задержкой. Общий каталог с документами отделу из 20 человек держат на NFS или SMB: там важны иерархия, права и блокировки файлов. Бэкапы, медиафайлы, артефакты сборки и логи кладут в S3, потому что доступ идёт крупными потоками, а метаданные и версии объектов удобно хранить рядом с данными.

Ограничения S3 заметны в трёх случаях: нет частичной перезаписи, нет блокировок, листинг миллиона объектов стоит дороже, чем чтение одного файла. Для каталога с сотнями тысяч мелких файлов, которые часто перезаписываются, файловое хранилище дешевле и быстрее.

Ключевые сценарии использования S3 в инфраструктуре

• Резервное копирование. restic, borg, pgBackRest, Velero и Veeam пишут напрямую в S3-совместимый target. Объекты неизменяемы, что упрощает защиту от шифровальщиков.
• Артефакты CI/CD. GitLab хранит artifacts, container registry и LFS в объектном хранилище. Nexus и Harbor поддерживают S3 как blob store и снимают нагрузку с локальных дисков.
• Статика и origin для CDN. Сборка фронтенда заливается одним aws s3 sync, CDN забирает файлы по HTTP.
• Логи и метрики. Grafana Loki хранит чанки, Thanos и Mimir складывают блоки, ClickHouse использует S3 как tiered storage для холодных партиций.
• Data lake и аналитика. Parquet-файлы в S3 читают Spark, Trino и ClickHouse, табличные форматы Iceberg и Delta Lake опираются на объектное хранилище как на основной слой.
• Медиа. Изображения, видео и превью отдаются через presigned URL или CDN, оригиналы лежат в отдельном бакете.
• Диски в Kubernetes. CSI-драйверы с S3-бэкендом и Mountpoint for Amazon S3 дают доступ к объектам как к файлам, но только для сценариев без случайной записи.
• Terraform state. Бэкенд S3 хранит файл состояния. С версии Terraform 1.10 блокировка работает через отдельный lock-файл в том же бакете, а не через DynamoDB, что упростило self-hosted схемы.

Типовой пример: сборочный конвейер публикует 400 МБ артефактов на NFS и получает очереди блокировок и рост времени отклика. Перенос артефактов в S3 убирает блокировки, даёт версионирование сборок и позволяет удалять старые версии политикой жизненного цикла без участия инженера.

Развёртывание MinIO на собственных серверах

MinIO это один бинарник на Go, который поднимает S3-совместимый endpoint. Для тестового стенда хватает 2 vCPU, 4 ГБ RAM и SSD. Для продакшена с erasure coding закладывайте от 4 ядер на узел, 16-32 ГБ RAM и диски, которые видны как отдельные устройства.

Жёсткое правило: MinIO не использует RAID. Каждый диск форматируется в XFS и передаётся как отдельный каталог или устройство. Избыточность даёт erasure coding на уровне объекта: N дисков делятся на k блоков данных и m блоков чётности, по умолчанию m = N/2. Кластер из 16 дисков с чётностью 8+8 даёт около 50% полезной ёмкости и переживает отказ до 8 дисков. Режим single-node multi-drive защищает от смерти диска, но не от падения сервера: тома живут на одной машине.

Топологии три: single-node single-drive для тестов и мелких сервисов, single-node multi-drive для бэкапов среднего размера, distributed из 4 и более узлов для продакшена с реальной отказоустойчивостью.

Установка MinIO через Docker и systemd

Вариант с Docker, одна нода, один том:

docker run -d --name minio \
  -p 9000:9000 -p 9001:9001 \
  -e MINIO_ROOT_USER=admin \
  -e MINIO_ROOT_PASSWORD=S3cr3t-ChangeMe \
  -v /mnt/data/minio:/data \
  -v /etc/minio/certs:/root/.minio/certs \
  --restart unless-stopped \
  minio/minio server /data --console-address ":9001"

Порт 9000 отдаёт S3 API, порт 9001 это веб-консоль. Ключи MINIO_ROOT_USER и MINIO_ROOT_PASSWORD задайте до первого запуска: дефолтная пара minioadmin/minioadmin даёт полный доступ любому, кто дотянулся до порта.

Вариант с systemd: бинарник кладём в /usr/local/bin/minio, создаём системного пользователя minio-user с оболочкой /sbin/nologin, каталог /mnt/data/minio отдаём ему во владение. Файл /etc/default/minio:

MINIO_VOLUMES="/mnt/data/minio"
MINIO_OPTS="--address :9000 --console-address :9001"
MINIO_ROOT_USER=admin
MINIO_ROOT_PASSWORD=S3cr3t-ChangeMe

Unit-файл /etc/systemd/system/minio.service содержит Type=notify, User=minio-user, EnvironmentFile=/etc/default/minio, ExecStart=/usr/local/bin/minio server $MINIO_OPTS $MINIO_VOLUMES, Restart=always и LimitNOFILE=65536. После systemctl daemon-reload включаем сервис и проверяем готовность запросом curl http://127.0.0.1:9000/minio/health/live.

Распределённый режим запускается одной командой на всех узлах, например minio server https://node{1...4}/data{1...4}. Команда должна совпадать символ в символ, иначе узлы не соберутся в кластер. Доступные диски задаются явно, а не маской каталогов, иначе расширение кластера перестанет работать.

Каталог данных MinIO нельзя бэкапить копированием файлов: состояние распределено по дискам и завязано на erasure coding. Конфигурацию бакетов, IAM и политик выгружают через mc admin config export, данные реплицируют через mc mirror или site replication в отдельный кластер.

Настройка TLS и reverse proxy для MinIO

MinIO читает сертификаты из каталога ~/.minio/certs для пользователя, от которого работает, то есть из /etc/minio/certs при запуске от minio-user. Нужны два файла с фиксированными именами: public.crt с цепочкой сертификатов и private.key с ключом. Подойдут сертификаты Let's Encrypt или внутреннего CA, если он есть в доверенных на всех клиентах.

Конфигурация Nginx для проксирования S3 API:

server {
  listen 443 ssl;
  server_name s3.example.com;
  ssl_certificate /etc/letsencrypt/live/s3.example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/s3.example.com/privkey.pem;
  client_max_body_size 0;
  ignore_invalid_headers off;
  proxy_buffering off;
  proxy_request_buffering off;
  location / {
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://127.0.0.1:9000;
    proxy_read_timeout 300;
    proxy_connect_timeout 300;
  }
}

Директива client_max_body_size 0 обязательна: со значением по умолчанию Nginx ответит 413 на multipart-загрузку крупного файла. Заголовок Host пробрасывается без изменений, потому что подпись SigV4 считается с учётом хоста. Виртуальный стиль адресации (bucket.s3.example.com) требует wildcard-сертификата и DNS-записи *.s3.example.com. Без них включайте path-style: s3.example.com/bucket/key.

Создание бакета, пользователя и политик доступа

Базовые операции после установки выполняются клиентом mc:

mc alias set s3 https://s3.example.com ACCESS_KEY SECRET_KEY
mc mb s3/backups
mc admin user add s3 app-backup BackupSecretKey
mc admin policy attach s3 readwrite --user app-backup
mc ls s3/backups
mc cp ./dump.sql.gz s3/backups/db/dump.sql.gz

Политику с ограничением по префиксу описывают в JSON и подключают командой mc admin policy create s3 backup-only backup-only.json. Принцип наименьших привилегий: сервису бэкапа нужны s3:PutObject, s3:GetObject и s3:ListBucket по одному префиксу, а не readwrite на весь кластер. Консоль администратора не публикуйте в интернет, доступ к ней закрывайте VPN или списком адресов.

Пошаговая установка MinIO в Docker и Kubernetes с erasure coding, бакетами, IAM-политиками и интеграцией с CDN разобрана в отдельном руководстве по S3-совместимому хранилищу изображений на MinIO.

Развёртывание Ceph RGW: когда нужен масштабируемый S3

Ceph RGW (RADOS Gateway) ставит S3 API поверх RADOS, того же слоя, где работают RBD для блочных устройств и CephFS для файловых. Главный смысл RGW в объединении: один кластер обслуживает блочный, файловый и объектный доступ, а сохранность данных обеспечивает CRUSH-репликация или erasure coding.

Минимальный продакшен-кластер: три узла с мониторами для кворума, три и более OSD, отдельная сеть для репликации, SSD или NVMe под WAL и DB в BlueStore. Один диск под OSD в кластер на 100 ТБ не ставят: восстановление после отказа запускает массовое перераспределение, которое загружает сеть на часы.

Подготовка кластера Ceph и установка RGW

Установка через cephadm начинается с одного узла:

cephadm bootstrap --mon-ip 10.0.0.11 --initial-dashboard-user admin
ceph orch host add ceph-02 10.0.0.12
ceph orch host add ceph-03 10.0.0.13
ceph orch apply osd --all-available-devices
ceph orch apply rgw main --placement="3 ceph-01 ceph-02 ceph-03" --port 7480

Состояние проверяют командами ceph orch ls и ceph orch ps --daemon-type rgw. Дальше создают realm и зоны, если планируется мультисайтовая репликация: radosgw-admin realm create --rgw-realm=main --default, затем zonegroup и zone. Для одного сайта достаточно значений по умолчанию, создаваемых при первом старте RGW.

Три и более экземпляра RGW закрывают отказ одного узла. Перед ними ставят HAProxy или keepalived с виртуальным адресом, иначе клиенты привяжутся к конкретному хосту и потеряют доступ при обновлении.

Создание S3-пользователя и бакета в Ceph RGW

Пользователя и ключи создают через radosgw-admin, ключи можно задать явно или получить сгенерированными:

radosgw-admin user create --uid=app-backup --display-name="Backup App" \
  --access-key=AKIAEXAMPLE123 --secret-key=SecretExample456
radosgw-admin user info --uid=app-backup
radosgw-admin quota set --quota-scope=bucket --uid=app-backup --max-size=10T
aws --endpoint-url http://rgw.example.com:7480 s3 mb s3://backups

Для виртуального стиля адресации нужна DNS-запись *.rgw.example.com, указывающая на балансировщик. Без неё работайте в path-style: клиент обращается к http://rgw.example.com:7480/backups/key. Квоты на бакет и пользователя стоит выставить сразу, иначе один неаккуратный скрипт заберёт весь пул.

Сравнение MinIO и Ceph RGW: что выбрать

Состав функций community-редакции MinIO менялся в 2025 году, поэтому перед внедрением проверьте возможности выбранного релиза. У Ceph RGW набор шире по инфраструктурной части: мультисайтовая репликация между кластерами, привязка классов хранения к пулам, интеграция с внешними системами аутентификации.

Матрица решений с тестами и требованиями к железу собрана в обзоре выбора S3-совместимого хранилища: MinIO, Ceph RGW и TrueNAS S3.

Управление жизненным циклом объектов, версионирование и политики хранения

Данные в объектном хранилище растут быстрее, чем диски, поэтому правила удаления и архивации настраивают в первый месяц работы, а не через год. Инструменты для этого три: версионирование, lifecycle-политики и Object Lock.

Версионирование объектов: включение и управление

Версионирование сохраняет каждую запись объекта под отдельным version id. Включается одной командой:

aws --endpoint-url https://s3.example.com s3api put-bucket-versioning \
  --bucket backups --versioning-configuration Status=Enabled
mc version enable s3/backups

После включения удаление объекта без указания версии не стирает данные, а создаёт delete marker: объект исчезает из обычного листинга, но предыдущие версии остаются на диске. Восстановление выполняется удалением маркера или копированием нужной версии: aws s3api copy-object --copy-source backups/dump.sql.gz?versionId=3HL4kq --bucket backups --key dump.sql.gz.

Версионирование увеличивает объём хранения, иногда кратно. Планируйте правило удаления старых версий вместе с включением функции, иначе бакет с ежедневными бэкапами вырастет в разы за пару месяцев. Приостановка версионирования (Status=Suspended) сохраняет уже созданные версии и перестаёт создавать новые.

Настройка lifecycle-политик для экономии и соответствия

Политика жизненного цикла описывает переходы между классами и сроки удаления. Пример правила для бакета с бэкапами: переход в STANDARD_IA через 30 дней, удаление через 365 дней, удаление неактуальных версий через 30 дней, очистка незавершённых multipart-загрузок через 7 дней.

{
  "Rules": [
    {
      "ID": "backups-tiering",
      "Status": "Enabled",
      "Filter": { "Prefix": "db/" },
      "Transitions": [ { "Days": 30, "StorageClass": "STANDARD_IA" } ],
      "Expiration": { "Days": 365 },
      "NoncurrentVersionExpiration": { "NoncurrentDays": 30 },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

Применяется командой aws s3api put-bucket-lifecycle-configuration --bucket backups --lifecycle-configuration file://lifecycle.json. Работает политика асинхронно: задачи выполняет фоновый сканер, поэтому удаление объекта может произойти через несколько часов после наступления срока, а первые проходы по большому бакету занимают сутки и больше.

Переходы между классами поддерживают не все self-hosted реализации. MinIO переводит данные на удалённый S3-совместимый уровень через ILM transition, а классы как носители разных типов дисков не эмулирует. Ceph RGW привязывает классы хранения к пулам через настройки placement. Проверяйте поведение на тестовом бакете с сотней объектов, прежде чем включать правило на продакшене.

Object Lock и retention: защита от удаления

Object Lock превращает бакет в WORM-хранилище: объект нельзя удалить или перезаписать до истечения срока хранения. Функция включается только при создании бакета:

aws --endpoint-url https://s3.example.com s3api create-bucket \
  --bucket immutable-logs --object-lock-enabled-for-bucket
aws s3api put-object-retention --bucket immutable-logs --key audit/2026-09.log \
  --retention Mode=COMPLIANCE,RetainUntilDate=2027-09-12T00:00:00Z

Режимы два. GOVERNANCE разрешает снятие блокировки пользователю с правом s3:BypassGovernanceRetention. COMPLIANCE не позволяет сократить срок никому, включая root-доступ: ошибочно выставленный срок в 10 лет придётся выдерживать. После включения Object Lock отключить его нельзя, только удалить бакет после истечения всех сроков. MinIO и Ceph RGW поддерживают оба режима, но требуют включённого версионирования и достаточной версии ПО.

Стратегия защиты медиахранилища на десятки терабайт с Object Lock, репликацией и проверкой целостности описана в материале про резервное копирование по схеме 3-2-1 на MinIO, Ceph и ZFS.

Практика работы с S3: aws-cli, s3cmd и boto3

Для self-hosted S3 обязательны два параметра: endpoint URL своей площадки и path-style адресация. Без них клиент уйдёт на amazonaws.com или сломается на подписи.

Настройка aws-cli для self-hosted S3

Профиль описывают в ~/.aws/config, чтобы не передавать флаги в каждой команде:

[profile minio]
region = us-east-1
endpoint_url = https://s3.example.com
s3 =
    addressing_style = path

Ключи хранятся в ~/.aws/credentials с правами 600. Регион указывать нужно даже для локального кластера: SigV4 подписывает запрос с учётом региона, и большинство реализаций принимают us-east-1.

AWS_PROFILE=minio aws s3 ls s3://backups/db/
AWS_PROFILE=minio aws s3 cp dump.sql.gz s3://backups/db/
AWS_PROFILE=minio aws s3 sync ./dist s3://static/site/ --delete
AWS_PROFILE=minio aws s3 presign s3://reports/2026-09.pdf --expires-in 3600
AWS_PROFILE=minio aws s3api list-objects-v2 --bucket backups --prefix db/ --max-keys 100

Крупные файлы aws s3 cp разбивает на части автоматически. Для прерываемых загрузок используйте aws s3api create-multipart-upload с последующим upload-part и complete-multipart-upload, тогда после сбоя не придётся начинать с нуля.

Использование s3cmd: конфигурация и основные команды

Файл ~/.s3cfg для работы с MinIO или Ceph RGW:

[default]
access_key = AKIAEXAMPLE123
secret_key = SecretExample456
host_base = s3.example.com
host_bucket = %(bucket)s.s3.example.com
use_https = True
signature_v2 = False
multipart_chunk_size_mb = 64

При path-style адресации в host_bucket указывают только домен без префикса бакета. Для старых шлюзов, которые понимают лишь SigV2, ставят signature_v2 = True.

s3cmd ls s3://backups
s3cmd put -r ./data s3://backups/data/
s3cmd get s3://backups/db/dump.sql.gz .
s3cmd sync ./logs s3://logs/ --delete-removed
s3cmd setacl s3://static/index.html --acl-public
s3cmd du -H s3://backups

s3cmd удобен в shell-скриптах и cron-задачах, где не хочется тянуть Python-зависимости. Вывод команд стабильнее, чем у aws-cli, и проще парсится.

Работа с S3 через boto3: примеры кода

import boto3
from boto3.s3.transfer import TransferConfig
from botocore.config import Config

s3 = boto3.client(
    "s3",
    endpoint_url="https://s3.example.com",
    aws_access_key_id="AKIAEXAMPLE123",
    aws_secret_access_key="SecretExample456",
    region_name="us-east-1",
    config=Config(signature_version="s3v4",
                  s3={"addressing_style": "path"},
                  retries={"max_attempts": 10, "mode": "standard"}),
)

cfg = TransferConfig(multipart_threshold=64 * 1024 * 1024,
                     multipart_chunksize=16 * 1024 * 1024,
                     max_concurrency=8)
s3.upload_file("dump.sql.gz", "backups", "db/dump.sql.gz", Config=cfg)

url = s3.generate_presigned_url(
    "get_object",
    Params={"Bucket": "reports", "Key": "2026-09.pdf"},
    ExpiresIn=3600,
)

Практические детали: download_file и upload_file сами управляют multipart-загрузкой по порогам из TransferConfig; для мелких объектов потоки только замедляют работу, поэтому max_concurrency снижают до 2-4. Ошибки ловят через botocore.exceptions.ClientError и проверяют код в response["Error"]["Code"], например NoSuchKey или AccessDenied. Ретраи botocore стоит включать явно: временные 500 и 503 от самодельного шлюза встречаются чаще, чем в AWS.

Производительность и ограничения self-hosted S3

Скорость объектного хранилища определяется четырьмя факторами: типом дисков, сетью, процессором и размером объектов. Ошибочно оптимизировать один из них, забывая про остальные.

Факторы, влияющие на производительность S3

• Диски. SATA HDD 7200 rpm даёт около 150-200 IOPS на произвольном доступе и 150-250 МБ/с на последовательном. NVMe SSD выдаёт сотни тысяч IOPS. Под OSD в Ceph ставят NVMe или SSD под WAL и DB, иначе запись тормозит на BlueStore.
• Сеть. 1 GbE даёт максимум около 118 МБ/с, 10 GbE около 1,1-1,2 ГБ/с, 25 GbE около 2,8-3 ГБ/с с учётом накладных расходов HTTP и TLS.
• Процессор. TLS, erasure coding и сжатие нагружают CPU. AES-NI ускоряет шифрование до нескольких ГБ/с на ядро, а расчёт Reed-Solomon на слабых ядрах упирается в 1-2 ГБ/с на узел.
• Размер объектов. Объекты больше 64 МБ ограничены пропускной способностью, объекты 4-64 КБ ограничены IOPS и задержкой. Загрузка миллиона файлов по 10 КБ упрётся в метаданные и сетевые запросы, а не в объём дисков.
• Параллелизм. Один поток клиента редко утилизирует 10 GbE. Для насыщения канала нужно 8-32 параллельных соединения с нескольких клиентов.

Инструменты и методики тестирования производительности

Тестировать нужно со стороны клиента и с реалистичной смесью операций:

warp client --host s3.example.com:9000 --access-key AKIAEXAMPLE123 \
  --secret-key SecretExample456 --tls
warp mixed --duration=5m --concurrent=32 --obj.size=1MiB --bucket=bench
warp get --duration=5m --concurrent=64 --obj.size=64KiB --bucket=bench

Для отдельных сценариев берут s3bench с параметрами по числу клиентов, количеству сэмплов и размеру объекта, а также встроенный тест mc support perf, который проверяет диск, сеть и объектный доступ выбранного алиаса. Диски под будущие OSD и каталоги MinIO прогоняют через fio с блоками 4 КБ для IOPS и 1 МБ для последовательной записи.

Осторожно с кэшами: page cache сервера, буферизация Nginx и кэш клиента завышают цифры на коротких тестах. Минимальная длительность честного теста пять минут, объём данных от нескольких десятков гигабайт. Сравнивать разные решения по задержке на мелких объектах удобно по готовым замерам на 10 и 100 млн объектов из сравнения MinIO, Ceph RADOS Gateway, SeaweedFS и TrueNAS SCALE.

Типичные ограничения self-hosted S3

• Состав API отличается от AWS: S3 Select, Object Lambda, полноценный Glacier как сервис доступны не везде, и приложение с редкой операцией может получить NotImplemented.
• Число бакетов ограничено практикой, а не только кодом: сотни бакетов в MinIO работают, тысячи требуют запаса по памяти.
• Резервное копирование не сводится к копированию каталогов. Нужны mc mirror, site replication в Ceph или выгрузка в отдельный кластер.
• Обновления требуют плана: MinIO перезапускает узлы по одному, Ceph обновляет демоны с проверкой здоровья после каждого шага, и без мониторинга легко получить деградацию.
• Erasure coding съедает ёмкость: чётность 8+8 оставляет 50% полезного места, пул Ceph 8+3 около 72%.
• Мониторинг обязателен: у MinIO есть endpoint /minio/v2/metrics/cluster для Prometheus, у Ceph модуль mgr prometheus. Контролировать нужно свободное место, ошибки 5xx, состояние дисков и скорость восстановления.

Перед продакшеном проверьте сценарий отказа: погасите один узел или диск на стенде и посмотрите, сколько времени занимает восстановление и как падает скорость в это время. На реальных нагрузках восстановление кластера Ceph из 100 ТБ занимает от нескольких часов до суток.

Классы доступа и экономика хранения в S3

Классы доступа снижают стоимость хранения за счёт меньшей доступности и платы за извлечение. Разница в цене между активными и архивными классами достигает двадцати раз.

Основные классы доступа и их назначение

Цифры даны как порядок величин для us-east-1, перед расчётом берите актуальный прайс. Для классов IA и Glacier действует минимальная оплата объекта, эквивалентная 128 КБ: миллион мелких файлов в архиве обойдётся дороже, чем в STANDARD.

Настройка переходов между классами через lifecycle

Переход задаётся правилом с полем Transitions, как в примере выше. Для self-hosted порядок другой: сначала настраивают целевой пул или удалённый S3, потом описывают правило. В MinIO холодный уровень подключают командой mc ilm tier add и указывают в политике переход на этот tier. В Ceph RGW класс хранения привязывают к пулу с нужным типом дисков через настройки placement в zonegroup.

Экономия складывается из трёх частей: удаления просроченных данных, удаления неактуальных версий и перевода редких данных на медленные диски. Переходы происходят асинхронно и после изменения правила не отменяются автоматически, поэтому тестируйте политику на отдельном бакете как минимум неделю.

Безопасность и разграничение доступа в S3

Публичный бакет это самая частая причина утечек в объектном хранилище. Закрывайте доступ политиками, шифруйте данные и не выдавайте root-ключи приложениям.

Управление доступом: IAM и bucket policies

Политика бакета выдаёт права конкретному пользователю только на чтение одного префикса и запрещает работу без TLS:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": ["arn:aws:iam:::user/report-reader"] },
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::reports/*",
      "Condition": { "Bool": { "aws:SecureTransport": "true" } }
    },
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::reports", "arn:aws:s3:::reports/*"],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    }
  ]
}

В MinIO пользователей и политики ведут через mc admin user и mc admin policy, в Ceph RGW через radosgw-admin. Принцип наименьших привилегий применяйте буквально: сервису отчётов нужен только s3:GetObject, сервису приёма логов только s3:PutObject. Presigned URL выдавайте с коротким сроком жизни, от 5 минут до часа, вместо раздачи постоянных ключей.

Шифрование данных в S3

Передача защищается TLS 1.2 и выше на reverse proxy и самом шлюзе. Хранение закрывают тремя схемами. SSE-S3 шифрует объекты ключом, которым управляет хранилище, это минимально достаточный уровень для большинства задач. SSE-KMS использует внешний сервис управления ключами: MinIO работает с KES, Ceph RGW с HashiCorp Vault или другим KMS. SSE-C передаёт ключ с каждым запросом и не хранит его на сервере.

Включение шифрования увеличивает нагрузку на CPU незначительно, если процессор поддерживает AES-NI. Требовать шифрование на уровне бакета можно политикой с условием на заголовок s3:x-amz-server-side-encryption: запросы без нужного заголовка будут отклоняться с AccessDenied.

Ключи доступа храните в секретах Kubernetes, в Vault или в менеджере секретов CI, ротацию делайте не реже раза в год, а для сервисных аккаунтов привязывайте ключи к отдельным пользователям, чтобы отозвать доступ точечно.

Когда self-hosted S3 не нужен: альтернативы и критерии выбора

Свой S3-кластер требует обслуживания: обновления, мониторинг, замена дисков, проверка восстановления. Если этим некому заниматься, managed-хранилище обходится дешевле.

Сравнение self-hosted S3 с облачными решениями

Ориентировочный расчёт для 100 ТБ. В облаке стандартный класс стоит около 2300 $ в месяц, архивный около 100 $. Свой кластер на 16 дисков по 12 ТБ с чётностью 12+4 даёт около 144 ТБ полезной ёмкости: сервер и диски обойдутся примерно в 7000 $ разово, электричество около 25-30 $ в месяц при 300 Вт потребления. Железо окупается за считаные месяцы, но в расчёт не входят труд инженера, второй сайт для георезерва и время на инциденты.

Облачные и managed-провайдеры выигрывают в трёх случаях: объём до 50-100 ТБ, нужна глобальная доступность или геораспределение, нет экспертизы по Ceph и MinIO. Для размещения агентов, прокси и сервисов рядом с хранилищем подойдёт арендованная инфраструктура, например Timeweb Cloud: серверы, базы данных и объектное хранилище в одном контуре упрощают схему, когда часть данных допустимо держать вне своей площадки.

Когда лучше выбрать файловое или блочное хранилище

• NFS и SMB. Общие документы с блокировками, домашние каталоги, каталоги сборки, куда пишут несколько процессов одновременно. Приложение использует mmap или fcntl, и S3 его не заменит.
• Блочное (iSCSI, NVMe-oF). Базы данных, диски виртуальных машин, кластерные ФС с малой задержкой. Здесь объектный протокол добавит миллисекунды там, где нужны микросекунды.
• Локальные диски с репликацией. Высоконагруженные СУБД и кэши: сеть добавляет задержку, а данные и так реплицируются средствами самой СУБД.

Критерий выбора простой. Если данные читают и пишут целиком, объём растёт до сотен терабайт, а приложению нужен HTTP-доступ из любой точки, берите S3. Если данные правят на месте, нужны блокировки или задержка ниже миллисекунды, остаются файловые и блочные решения. Если нет желания обслуживать кластер, managed-хранилище снимет операционную нагрузку, оставив только работу с API.

Для ML-пайплайнов, которые читают датасеты из объектного хранилища, полезно держать рядом единый доступ к моделям: агрегатор вроде AiTunnel даёт один API к десяткам нейросетей и избавляет от разрозненных ключей и VPN в скриптах обработки.

Начните с малого: поднимите MinIO в Docker на одном сервере, перенесите туда бэкапы одного сервиса, включите версионирование и Object Lock на бакете с критичными данными, добавьте метрики в Prometheus. Через месяц эксплуатации станет понятно, хватает ли single-node схемы, нужен ли распределённый кластер или облачное хранилище закрывает задачу с меньшими затратами.