kruemel/Crumb-Core-v.1
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
2fd60fdfd5b2afc62a6085dcd6a2c41ac778ffbb
Crumb-Core-v.1/docs/crumbforest/crumb_calculations.md

6.3 KiB
Raw Blame History

Hier ist die nüchterne, belastbare Planung – mit Annahmen, Formeln, Größenordnungen, Kosten und Fallstricken. So kannst du das „Luftschloss“ sauber begründen – und schrittweise hart machen.

Zielbild (kurz)

  • 500 ESP-Cams liefern alle 10 s ein JPEG (SVGA, ≈ 20–30 KB).
  • Collector nimmt an, schreibt Hot-Store (minutenweise JPEGs), erzeugt stündliche/ tägliche H.264-Clips und räumt alte JPEGs per Retention weg.
  • MQTT liefert Heartbeats/Telemetrie.
  • Netz: pro Stockwerk hAP + VLAN, zentraler Broker/Collector; 220 V vorhanden.

1) Annahmen (Baseline)

  • Anzahl Kameras (N) = 500
  • Intervall (T) = 10 s ⇒ 8 640 Bilder/Tag/Kamera
  • Ø JPEG-Größe (S) = 25 KB (eure Messung lag ~23–30 KB)
  • JPEG→H.264-Clip: Reduktionsfaktor (R) = 2–4× (typisch 3×)
  • Collector/NAS: 1 GbE, 220 V Netz, ggf. später PV-Offload
  • Strompreis: 0,25 €/kWh (Beispielwert – anpassen)

2) Dimensionierung

2.1 Speicherbedarf

Pro Tag (nur JPEGs): [ \text{GB/Tag} \approx N \times \frac{S \text{(KB)} \times 8640}{1024} ] Beispiel: (500 \times \frac{25 \times 8640}{1024} \approx \mathbf{108\ GB/Tag})

Wenn JPEGs nach Clip-Erzeugung gelöscht werden: [ \text{GB/Tag (Clips)} \approx \frac{\text{GB/Tag (JPEG)}}{R} ] Beispiel (R = 3): (108/3 \approx \mathbf{36\ GB/Tag})

Retention-Beispiele (nur Clips):

  • 7 Tage: ~250 GB
  • 14 Tage: ~500 GB
  • 30 Tage: ~1,1 TB

Praxis: Hot-JPEGs nur 60 min vorhalten (Echtzeit-Analyse), dann Clip erzeugen und löschen ⇒ Plattenlast und Inodes unter Kontrolle.

2.2 Netzwerk-Last

Durchsatz (Mbit/s): [ \text{Mbit/s} \approx N \times \left(\frac{S\text{(KB)}}{T\text{(s)}}\right) \times \frac{8}{1000} ] Beispiel: (500 \times (25/10) \times 8/1000 \approx \mathbf{10\ Mbit/s}) im Mittel. Mit Jitter (±10 s) die Peaks glätten.

WLAN/APs: 10 s-Intervalle sind airtime-schonend. Ein hAP pro Stockwerk reicht i.d.R., Cams verteilen.

2.3 Rechenleistung

  • Collector: CPU kaum kritisch (I/O-lastig). ffmpeg-Clips stündlich/gestreut erzeugen.
  • NAS/NVMe: Viele kleine Writes (JPEG), dann sequenzielle Writes (Clips). Kleines NVMe-„Spool“ + HDD-Bulk ist ideal.

3) Speicher-Varianten

A) Minimal (Start jetzt): Raspberry Pi 5 + NVMe (2 TB), ohne RAID

  • Puffer:

    • Nur Clips: (2\ \text{TB} / 36\ \text{GB/Tag} \approx \mathbf{55\ Tage}).
    • JPEGs (ohne Löschen): (2\ \text{TB} / 108\ \text{GB/Tag} \approx \mathbf{18\ Tage}).

  • Vorteile: günstig, leise, geringer Strom, schnell betriebsbereit.

  • Risiken: Single Point of Failure, NVMe-Verschleiß bei hohem IOPS-Mix, begrenzter Ersatz bei Ausfall.

Hausnummer Kosten (einmalig):

  • RPi 5 (8 GB) + NVMe-HAT + 2 TB NVMe: 250–350 €
  • Kleine USV: 80–150 €

B) Robust (mittelfristig): NAS 4–6-Bay + RAID

  • z. B. 4× 8 TB RAID10 (≈ 16 TB nutzbar) oder 6× 8 TB ZFS RAIDZ2 (≈ 29–32 TB nutzbar).
  • Vorteile: Platten-Redundanz, IOPS-Reserve, Scale-up, längere Retention.
  • Risiken: höhere Anschaffung, etwas mehr Strom.

Hausnummer Kosten:

  • 4-Bay NAS-Gehäuse: 400–800 €
  • 4× 8 TB HDD: 600–800 €
  • Summe: 1 000–1 600 € (+ USV)

4) Strom & Betriebskosten

4.1 Verbrauch (heute, ohne Schlaf-Tuning)

  • Cam: 0,5–1,0 W Ø → 500 Cams = 250–500 W
  • Backend (NAS/Collector): 100–200 W
  • Gesamt: 350–700 W ⇒ 8,4–16,8 kWh/Tag

4.2 Kosten (0,25 €/kWh)

  • pro Tag: 2,10–4,20 €
  • pro Monat (30 d): 63–126 €
  • pro Jahr: ~760–1 520 €

Spareffekt (später): WLAN-Sleep + JPEG-Qualität optimieren kann Cam-Leistung deutlich senken (z. B. auf 0,3–0,6 W). Das halbiert den größten Kostenblock.

5) VLAN/Segmentierung (Betriebssicherheit)

  • Pro Stockwerk VLAN 50 für ESP-Clients; hAP bridged SSID→VLAN50.

  • Trunk zum Core.

  • Firewall:

    • ESP → Broker (MQTT), ESP → Collector (HTTP POST) erlauben
    • Alles andere sperren (kein East-West zwischen Cams)
    • NTP erlauben (Zeitstempel/Logik)

  • Monitoring: Broker-Topics (retained), Collector-/health, Platte (SMART), Timer-Jobs (systemd).

6) Fallstricke & Gegenmaßnahmen

  • Dateiflut/Inodes: Hot-Store limitiert halten, stündlich clippen, Retention/Logrotate aktiv (schon umgesetzt).
  • Zeitbasis: NTP muss stabil laufen (sonst schiefe Dateinamen/Indizes).
  • Thermik: ESP-Gehäuse nicht dämmen; ggf. 5 V-Mikrolüfter an Hotspots.
  • Strom/USV: Kurz-Ausfälle puffern (USV), saubere Shutdowns → keine FS-Korruption.
  • WLAN-Dichte: AP-Kanalplanung; Heartbeats jittern (last verteilt).
  • Speicher-SPOF (Variante A): Regelmäßige Clipsync (rsync) auf Backup-Ziel (nachts).
  • Wartung: Stücklistenableger, Ersatz-ESP, definierter Flash-Pfad (Make/CLI).

7) Formeln (zum schnellen Rechnen)

  • Bilder/Tag/Kamera: (B = 86400/T)
  • GB/Tag (JPEG): (\text{GB} \approx N \times \frac{S \text{(KB)} \times B}{1024})
  • GB/Tag (Clip): (\text{GB}{\text{clip}} \approx \text{GB}{\text{jpeg}} / R)
  • Dauer-Durchsatz (Mbit/s): ( \approx N \times (S/T) \times 8 / 1000 )
  • Leistung gesamt (W): ( \approx N \times P_{\text{Cam}} + P_{\text{Backend}})
  • Energie/Tag (kWh): ( \text{kWh} \approx W \times 24 / 1000)

8) Antwort auf deine Kernfrage (RPi5 + NVMe „ein paar Tage?“)

  • Ja – sogar Wochen, wenn du die JPEGs nach Clip-Erzeugung löschst.
  • Mit 2 TB NVMe und 36 GB/Tag (Clips) sind ~55 Tage drin (brutto).
  • Wenn du JPEGs behältst: ~18 Tage (2 TB / 108 GB/Tag).
  • Für Produktion > einige Wochen + Redundanz: NAS/RAID einplanen (Variante B).
  • Start pragmatisch mit Variante A – Variante B parallel vorbereiten (Migration per rsync).

9) Konkrete Empfehlung (sofort umsetzbar)

  1. Weiter so mit eurer Toolchain: Hot-JPEG → stündlicher Clip → JPEG weg.
  2. RPi5+NVMe als Collector/Spool jetzt; nächtliches rsync auf ein zweites Laufwerk/Server.
  3. In 4–8 Wochen: NAS (RAID10 oder RAIDZ2) aufsetzen, Retention auf 14–30 Tage erhöhen.
  4. Power-Tuning der ESPs (Sleep, JPEG-Qualität) in Wellen testen – spart Opex am stärksten.
  5. Netz-Hygiene: VLAN strikt, NTP offen, MQTT/HTTP minimal freischalten, Jitter bleibt an.
  6. USV + Monitoring (SMART, df, Timer-Logs) aktiv halten.