SeaweedFS na Unraidu — S3-kompatibilní úložiště

Vyladěný Docker stack proti původnímu příkladu. Hlavní rozdíly a proč:

Změna	Proč
Pin verze image `:4.32` místo `:latest`	reprodukovatelnost, žádné překvapení po `pull`
Master má `-mdir=/data` + namapovaný volume	metadata masteru (kde co leží) jinak po restartu zmizí
Filer má namapovaný `/data`	leveldb s metadaty souborů musí persistovat
`-config=config_s3.json` u s3	bez něj je S3 bez autentizace, otevřené komukoliv v síti
`healthcheck` + `depends_on: service_healthy`	služby nestartují dřív, než je master skutečně nahoře
`restart: unless-stopped`	přežije restart Unraidu
`-ip.bind=0.0.0.0`	dostupnost z LAN, ne jen z kontejneru
Data pod `/mnt/user/appdata/...`	zálohovatelné, ne v anonymním volume

Kam se ukládají data (DŮLEŽITÉ pro Unraid)

Klíčové pravidlo Unraidu: cache není pod paritou → patří tam jen to, co jde snadno obnovit. Rozhoduje tedy ne velikost, ale obnovitelnost:

Co	Obnovitelné?	Kam	Cesta
volume (vlastní obsah)	ne (to jsou ta data)	POLE (parita)	`/mnt/user/seaweedfs/volume`
filer metadata	NE — bez nich jsou bloby slepé	externí DB (Mongo/PG)	`filer.toml`
master metadata	ano — poskládá se z heartbeatů	cache / appdata	`/mnt/user/appdata/seaweedfs/master`
config_s3.json	trivální	vedle compose	`./config_s3.json`

Proč filer metadata nesmí na cache

filer drží mapu název souboru → které chunky na kterém volume. Volume servery ji neumí zrekonstruovat — bloby na poli přežijí, ale ztratíš informaci, co je co. Proto je dáváme do tvé existující DB na 192.168.1.76 (viz filer.toml):

MongoDB (doporučeno) — kolekce v DB seaweedfs se vytvoří sama, žádné schéma.

PostgreSQL — vytvoř DB a tabulku:

CREATE DATABASE seaweedfs;
-- v DB seaweedfs:
CREATE TABLE IF NOT EXISTS filemeta (
  dirhash   BIGINT,
  name      VARCHAR(65535),
  directory VARCHAR(65535),
  meta      BYTEA,
  PRIMARY KEY (dirhash, name)
);

Master metadata na cache nechávám schválně — po ztrátě cache si je master poskládá z hlášení volume serverů, takže spadají do „snadno obnovitelné".

Settings → Shares → Add Share:

Název: seaweedfs
Primary storage: Array (NE cache), Secondary: none — jinak by data tekla zpět na cache a zaplnila ji
Allocation/split dle libosti

Tím vznikne /mnt/user/seaweedfs, kam míří volume vrstva. (Alternativa: napřímo na konkrétní ZFS disk, /mnt/diskX/seaweedfs/volume, když chceš obejít user share.)

Pozn.: Disk 8 (sdd) má v poli 14 223 čtecích chyb — než tam pustíš nová data, mrkni na SMART / zvaž jeho vyřazení. Na takový disk bych volume dir nesměroval.

Spuštění

cd /boot/config/plugins/compose/... # nebo kamkoliv stack uložíš
docker compose -p seaweedfs up -d
docker compose -p seaweedfs ps

Endpoints (nahraď `UNRAID-IP`)

Master UI: http://UNRAID-IP:9333
Filer/web: http://UNRAID-IP:8888
S3 API: http://UNRAID-IP:8333

Před produkcí

Změň klíče v config_s3.json (admin i readonly). Dlouhé náhodné secret keys.
Soubor config_s3.json drž s právy 600.
Zvaž reverzní proxy (SWAG/NPM) s TLS, pokud má být S3 dostupné mimo LAN.
defaultReplication=000 = bez replikace (1 kopie). Pro odolnost přes víc disků/serverů zvyš (např. 001, 010) a přidej volume servery.

Test

# AWS CLI
S3=http://UNRAID-IP:8333 AK=admin SK=tajne ./test_s3.sh

Nebo přes s3cmd, rclone, MinIO client (mc) — vše funguje proti :8333.

Škálování později

Tohle je single-node setup (test / menší nasazení). Pro distribuovaný cluster přidej další volume servery (klidně na jiných strojích) mířící na stejný master a zvyš replikaci. Master + filer mohou zůstat, volume vrstva se škáluje horizontálně.

4.0 KiB Raw Permalink Blame History