Как установить и настроить SeaweedFS на VPS

MAATRIX

Если у вас растёт коллекция мелких файлов — превью, аватарки, чанки видео, вложения из чата — обычная файловая система на ext4 или XFS рано или поздно упирается в лимит inode или начинает тормозить на ls и du. MinIO в такой ситуации тоже не спасает: он проектировался под объекты покрупнее, и метаданные на миллион мелких файлов съедают память непропорционально. SeaweedFS — распределённое хранилище, которое Chris Lu написал специально под задачу Facebook Haystack: миллиарды маленьких файлов, минимум накладных расходов на метаданные, S3-совместимый API поверх. Разберём, как поднять его на одном VPS и подготовить к росту до кластера.

Что такое SeaweedFS и когда он нужен

SeaweedFS устроен иначе, чем классические распределённые ФС вроде Ceph или GlusterFS. Идея в двух слоях:

• Master — держит только метаданные о том, какие volume-серверы существуют и сколько на них свободного места. Он не знает про отдельные файлы.
• Volume server — хранит сами данные. Каждый volume — это большой файл (по умолчанию до 30 ГБ), внутри которого лежат десятки тысяч мелких файлов подряд, как в логе. Метаданные о конкретном файле — это просто смещение (offset) и размер внутри volume-файла.

За счёт этого на один файл тратится порядка 40 байт метаданных вместо сотен байт inode в обычной ФС. Именно поэтому SeaweedFS вытягивает миллиарды объектов там, где ext4 или NFS начинают деградировать.

Сверху есть два опциональных слоя:

• Filer — REST/POSIX-подобный доступ с полноценным деревом каталогов, метаданные которого хранятся в отдельной БД (LevelDB, MySQL, PostgreSQL, Redis и др.).
• S3 API — совместимый с AWS S3 интерфейс, работает через filer, понимает aws-cli, rclone, mc и большинство S3-совместимых SDK.

Когда SeaweedFS оправдан: миллионы мелких файлов (превью, тайлы карт, вложения), горячее хранилище для CDN-подобной раздачи, S3-совместимый бэкенд для приложения без привязки к облаку. Когда не оправдан: одна база данных с парой десятков крупных файлов — там хватит обычного диска или rclone поверх внешнего хранилища.

Требования к серверу и подготовка VPS

Для тестового/боевого старта на одном узле достаточно скромной конфигурации, но раскладка ресурсов зависит от объёма данных:

Важный нюанс: SeaweedFS сам не резервирует место под volume-файлы, он просто пишет на диск до тех пор, пока хватает свободного пространства — поэтому на проде стоит выделить под данные отдельный диск или хотя бы отдельный раздел, чтобы переполнение хранилища не убило системный /.

Перед установкой обновите систему и откройте нужные порты:

apt update && apt upgrade -y
apt install -y wget tar ufw

Порты, которые понадобятся: 9333 (master), 8080 (volume), 8888 (filer), 8333 (S3 API). Если фаервол ещё не настроен — см. статью про UFW на VPS, там же объяснено, как открывать порты выборочно, а не гасить фаервол целиком.

ufw allow 22/tcp
ufw allow 9333/tcp
ufw allow 8080/tcp
ufw allow 8888/tcp
ufw allow 8333/tcp
ufw enable

Если вы разворачиваете кластер из нескольких VPS в одной приватной сети, порты между узлами можно оставить открытыми только внутри VPC/приватной подсети, а наружу пробрасывать только 8333 (S3 API) и 8888 (filer), да и то через reverse-proxy с TLS.

Установка SeaweedFS

Официальный способ — скачать готовый бинарник с GitHub Releases. Проверьте актуальную версию на странице релизов проекта (chrislusf/seaweedfs) и подставьте её вместо <VERSION>:

cd /tmp
wget https://github.com/seaweedfs/seaweedfs/releases/download/<VERSION>/linux_amd64_full.tar.gz
tar -xzvf linux_amd64_full.tar.gz
mv weed /usr/local/bin/
chmod +x /usr/local/bin/weed
weed version

Для ARM-серверов есть отдельные архивы (linux_arm64_full.tar.gz) — если арендован ARM-инстанс, важно не перепутать архитектуру, иначе бинарник просто не запустится. Собирать из исходников через Go имеет смысл только если нужна свежая master-ветка — для продакшена надёжнее релизный бинарник, протестированный мейнтейнерами.

Создайте пользователя и рабочие директории — запускать хранилище от root на постоянку не стоит:

useradd -r -s /usr/sbin/nologin -d /opt/seaweedfs seaweed
mkdir -p /opt/seaweedfs/{master,volume,filer}
chown -R seaweed:seaweed /opt/seaweedfs

Запуск master, volume и filer

Проще всего для одного узла — команда weed server, которая поднимает master, volume и filer одним процессом. Для теста запустите вручную:

sudo -u seaweed weed server \
  -dir=/opt/seaweedfs/master \
  -volume.dir=/opt/seaweedfs/volume \
  -volume.max=0 \
  -master.port=9333 \
  -volume.port=8080 \
  -filer=true \
  -filer.port=8888 \
  -ip=127.0.0.1 \
  -ip.bind=0.0.0.0

Флаг -volume.max=0 означает «без ограничения по количеству volume-файлов, ограничивается только свободным местом на диске» — удобно для старта, но на проде разумно посчитать явный лимит, чтобы не съесть весь диск одним хранилищем.

Проверка, что всё поднялось:

curl http://127.0.0.1:9333/cluster/status
curl http://127.0.0.1:8888/

Если оба ответа приходят без ошибок — master и filer видят друг друга. Для раздельного запуска (что понадобится при масштабировании на несколько узлов) процессы разносятся так: weed master, weed volume -mserver=<master-ip>:9333, weed filer -master=<master-ip>:9333 — каждый в своём systemd-юните.

Пример unit-файла для master (/etc/systemd/system/seaweedfs-master.service):

[Unit]
Description=SeaweedFS Master
After=network.target

[Service]
Type=simple
User=seaweed
ExecStart=/usr/local/bin/weed master -mdir=/opt/seaweedfs/master -port=9333 -ip.bind=0.0.0.0
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

И volume-сервер (/etc/systemd/system/seaweedfs-volume.service):

[Unit]
Description=SeaweedFS Volume Server
After=network.target seaweedfs-master.service

[Service]
Type=simple
User=seaweed
ExecStart=/usr/local/bin/weed volume -dir=/opt/seaweedfs/volume -mserver=127.0.0.1:9333 -port=8080 -ip.bind=0.0.0.0 -max=0
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Filer аналогично, с зависимостью After=seaweedfs-master.service seaweedfs-volume.service. После создания юнитов:

systemctl daemon-reload
systemctl enable --now seaweedfs-master seaweedfs-volume seaweedfs-filer
systemctl status seaweedfs-master

Настройка filer и метаданных

По умолчанию filer хранит метаданные в LevelDB прямо на диске узла — этого достаточно для одного сервера, но не переживёт потерю диска и плохо параллелится при высокой нагрузке. Конфигурация БД задаётся в filer.toml:

mkdir -p /etc/seaweedfs
weed scaffold -config=filer > /etc/seaweedfs/filer.toml

Для продакшена стоит переключить filer на внешнюю БД — например, PostgreSQL, если он уже есть в инфраструктуре:

[postgres2]
enabled = true
hostname = "127.0.0.1"
port = 5432
username = "seaweedfs"
password = "your-strong-password"
database = "seaweedfs_filer"
sslmode = "disable"
connection_max_idle = 5
connection_max_open = 20

Секцию [leveldb2] при этом лучше отключить (enabled = false), чтобы filer не писал в оба хранилища одновременно. После правки перезапустите filer (systemctl restart seaweedfs-filer) и проверьте веб-интерфейс на порту 8888 — там видно дерево каталогов и можно загрузить файл вручную для теста.

Включение S3 API

S3-совместимый интерфейс работает поверх filer и требует отдельного процесса weed s3 (либо флага -s3=true при запуске через weed server). Сначала создайте конфиг с ключами доступа:

cat > /etc/seaweedfs/s3.json <<'EOF'
{
  "identities": [
    {
      "name": "app",
      "credentials": [
        {
          "accessKey": "AKIAEXAMPLEKEY",
          "secretKey": "your-secret-key-generated-locally"
        }
      ],
      "actions": [
        "Admin",
        "Read",
        "Write"
      ]
    }
  ]
}
EOF
chmod 600 /etc/seaweedfs/s3.json

Ключи сгенерируйте сами (например, openssl rand -hex 20 для secretKey) — не используйте значения из примеров документации в проде.

Запуск S3-шлюза:

weed s3 -filer=127.0.0.1:8888 -port=8333 -config=/etc/seaweedfs/s3.json

Или системным юнитом по аналогии с предыдущими. Проверка с aws-cli:

aws configure set aws_access_key_id AKIAEXAMPLEKEY --profile seaweed
aws configure set aws_secret_access_key your-secret-key-generated-locally --profile seaweed

aws --endpoint-url http://127.0.0.1:8333 --profile seaweed s3 mb s3://test-bucket
aws --endpoint-url http://127.0.0.1:8333 --profile seaweed s3 cp ./file.txt s3://test-bucket/
aws --endpoint-url http://127.0.0.1:8333 --profile seaweed s3 ls s3://test-bucket/

Если приложение уже написано под S3 API (боты, backend-сервисы, media-пайплайны) — миграция сводится к смене endpoint_url в конфиге клиента, без переписывания логики. Это удобно сравнивать с MinIO: оба дают S3 API, но SeaweedFS выигрывает именно на масштабе мелких объектов, а MinIO проще в администрировании для типовых кейсов с файлами среднего размера.

Для публикации S3-эндпоинта наружу с TLS поставьте перед ним nginx или Caddy как reverse-proxy — так же, как для любого другого API-сервиса на VPS; голый HTTP наружу для продакшн-хранилища с ключами доступа — плохая идея.

Резервное копирование и обслуживание

SeaweedFS даёт встроенные инструменты для бэкапа и репликации, но на одном узле это всё равно физически один диск — точка отказа остаётся. Варианты защиты данных:

• Volume replication — при развёртывании нескольких volume-серверов можно задать фактор репликации (-volume.replication=001 — одна дополнительная копия на другом узле).
• weed backup — инкрементальный бэкап volume-файлов на удалённый filer.
• Экспорт через S3 API в другое хранилище — например, синхронизация бакета через rclone в объектное хранилище на другой площадке, что закрывает риск потери всего VPS целиком.

Пример команды бэкапа volume на удалённый сервер:

weed backup -dir=/opt/seaweedfs/backup -source.filer=127.0.0.1:8888 -collection=""

Регулярность зависит от скорости роста данных — раз в сутки через cron достаточно для большинства сценариев, но при строгих RPO-требованиях интервал нужно сократить и проверить время самого бэкапа на реальном объёме: оно растёт нелинейно с числом volume-файлов.

SeaweedFS не остановится сам при заполнении диска — он просто начнёт получать ошибки записи. Мониторинг свободного места через Zabbix или Prometheus избавит от ситуации «диск заполнился ночью, приложение легло».

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