Zpět na domů

Projektování videonadzorování podle proudů do 150 kamer

Článek rozebírá projektování systémů videonadzorování s ohledem na reálnou zátěž z proudů. Popsány architektury pro rozsahy 5–150 kamer, od monolitních po multiserverové, s důrazem na síť a analýzu. Klíč – minimalizace duplikování videa a oddělení rolí.

Architektura CCTV: od 5 do 150 kamer bez přetížení
Advertisement 728x90

Architektura videohodnocení: návrh podle datových toků místo jednotlivých kamer

Moderní systémy videohodnocení vyžadují zohlednění počtu datových toků a jejich tras, nikoli pouze počtu kamer. Každá kamera generuje minimálně dva toky: hlavní pro archivní záznam a detailní prohlížení a vedlejší pro monitorování v síti, vzdálený přístup a základní analýzu. U projektu s 10 kamerami je skutečná zátěž ekvivalentní 20–40 současným tokům, pokud jsou zapojeny záznam, několik pracovních míst, analýza a cloudová replikace.

Správný návrh začíná analýzou uživatelů toků: serverů záznamu, klientských stanic, modulů analýzy a mobilních aplikací. To umožňuje vyhnout se přetížení sítě a CPU, kdy by se toky duplikovaly bez nutnosti.

Škálování od 5 do 15 kamer: jednoduchá lokální architektura

Pro malé objekty – dům, kancelář, obchod – je optimální monolitická schéma: jeden VMS server s lokální sítí na bázi gigabitového switche. Hlavní tok se zaznamenává na disk, vedlejší se používá pro prohlížení. Klíčové doporučení:

Google AdInline article slot
  • Nastavení bitové rychlosti podle profilů pro snížení zátěže.
  • Vzdálený přístup pouze prostřednictvím VMS, bez přímých připojení k kamery.
  • Priorita na spolehlivé disky a RAM s rezervou 20–30 %.

Tato konfigurace zajišťuje předvídatelnost: zátěž sítě nepřesahuje 100–200 Mbit/s při plném současném prohlížení. Vyhněte se rozdělení na více serverů – zvyšuje to počet bodů selhání bez výhody.

Systémy 15–40 kamer: distribuce klientského přístupu

S rostoucím počtem kamer a uživatelů (2–5 pracovních míst) se zavádí pravidlo centrální distribuce videa prostřednictvím VMS. Přímé připojení k kamerám je zakázáno: vytvářejí chaos v RTSP relacích a přetěžují zařízení.

Doporučená schéma:

Google AdInline article slot
  • Hlavní server pro záznam a správu.
  • Logické rozdělení rolí: záznam na rychlé disky (RAID 5/6), prohlížení přes vyrovnávací paměť.
  • Pro vzdálené klienty – samostatný restreamovací modul.

Zátěž sítě: hlavní tok H.265 4–8 Mbit/s na kameru, vedlejší 1–2 Mbit/s. U 30 kamer a 4 klientů dosahuje vrcholová šířka pásma až 1 Gbit/s v lokální síti.

Velké instalace 40–80 kamer: lokalizace zpracování

U systémů s několika zónami (budovy, areály) je hrubá výkonnost serveru menší než dobrá architektura. Lokálně přenášejte pouze metadata, události a záznamy poplachů, plné archivy uchovávejte u zdroje.

Výhody distribuovaného záznamu:

Google AdInline article slot
  • Snížení provozu mezi areály o 10–20 % oproti původnímu stavu.
  • Samostatnost zón při výpadku hlavní sítě.
  • Škálovatelnost bez aktualizace centrálního uzlu.

Uvnitř objektu – 10 Gbit/s backbone, mezi nimi – optimalizované protokoly (např. RTP přes UDP s multicastem). Je to efektivnější než jediný server s 128 jádry.

Multiserverové systémy 80–150 kamer: funkční rozdělení

Pro velmi zatížené scénáře s analýzou (rozpoznávání tváří, čísel, zvuků >500 typů, transkripce řeči) je třeba klastrovat:

  • Uzly záznamu (po 20–40 kamerách, SSD RAID).
  • Analytické servery (GPU pro inference).
  • Klientské brány (restream, autentizace).

Jediný bod selhání se eliminuje failover-klastry. Obsluha roste, ale odolnost proti výpadkům a škálovatelnost kompenzují: uptime >99,9 % proti 95 % u monolitu.

Důležité:

  • Počítání toků, nikoli kamer, zabrání 70 % incidentů přetížení.
  • Lokální zpracování snižuje síťovou zátěž o 50–80 %.
  • Rozdělení rolí zvyšuje škálovatelnost bez přímého růstu nákladů.
  • Předvídatelnost architektury je důležitější než vrcholový výkon.
  • Zvuková analýza přidá 10–20 % zátěže na CPU, vyžaduje samostatné okruhy.

— Editorial Team

Advertisement 728x90

Číst dál