janssen/SeaweedFS

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é".

Nejdřív založ share na poli

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í

1. Změň klíče v config_s3.json (admin i readonly). Dlouhé náhodné secret keys.
2. Soubor config_s3.json drž s právy 600.
3. Zvaž reverzní proxy (SWAG/NPM) s TLS, pokud má být S3 dostupné mimo LAN.
4. 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ě.