Opbygning af Linux-baserede NVR’er

Overblik

Denne artikel beskriver de almindelige trin for en partner, der ønsker at lave et NVR-lignende hardwareprodukt – en indbygget computer (her kaldet en “NVR”) med et forudinstalleret serverprogram. Typisk er en sådan NVR en Linux-baseret computer med en ARM-CPU.

De grundlæggende trin for at fremstille et sådant produkt omfatter følgende:

  • Vælg hardware
    • Platform
    • Storage
  • Vælg Linux-smag
  • Installerer Server-applikation
  • Indfører ekstra funktioner
  • Etablerer en supportpolitik

Disse trin er beskrevet detaljeret nedenfor.

Vælg hardware

For at få et produkt til at blive en succes skal det være omkostningseffektivt og give den nødvendige ydeevne – understøtte det ønskede antal kameraer med den ønskede bitrate/opløsning. Den anvendte hardware bør have mindst 1 GB RAM og et ARM Cortex A7-chipsæt eller højere.

Det anbefales først at undersøge ydeevnen for de understøttede ARM-platforme (se ARM Support Policy for listen over sådanne platforme) og derefter vælge en platform, der ligger tættest på dine krav.

Platform

Den valgte understøttede ARM-platform kan anvendes som en af følgende:

  • en færdigkøbt computer (f.eks. et standard Raspberry Pi-mainboard), eventuelt med et tilpasset kabinet og strømforsyningsenhed;
  • en reference til udformning af en tilpasset computer med mainboardet, der kan rumme yderligere hardwarekomponenter som f.eks. perifere grænseflader eller harddisccontrollere.

Hvis NVR’en forventes at have yderligere software onboard ud over serverapplikationen, f.eks. en webserver, der leverer en webgrænseflade til brugeren, videoanalysesoftware (f.eks. et VMS-plugin og/eller dets backend) eller lignende, skal du sørge for at tilføje tilstrækkelig RAM og CPU-behandlingskraft til at dække dette.

Video-omkodning understøttes ikke på ARM-enheder på grund af begrænset regnekraft. Derudover kan nogle afhængigheder som OpenSSL have kompatibilitetsproblemer. Hvis den indledende analyse viser, at en typisk ARM-baseret platform ikke vil give den nødvendige ydeevne, kan en x64-platform overvejes.

Platformens lagerydelse bør være god nok til den planlagte belastning. Det er f.eks. kendt, at løsninger som SATA-over-USB kan føre til dårlig HDD-ydelse, som er utilstrækkelig til at optage det nødvendige antal kameraer.

Platformens netværksydelse skal være god nok til den planlagte belastning. Det er f.eks. kendt, at sådanne løsninger som softwarebaseret Ethernet-implementering kræver mange CPU-ressourcer og derfor kan føre til frame drops under optagelse af kameraer eller streaming til klienter eller andre problemer. Desuden kan hardwaremodeller, der implementerer ethernet via USB-hub, have mindre end den annoncerede netværksbåndbredde.

Platformen bør være udstyret med en Real-Time Clock (RTC)-hardware, og/eller tidssynkronisering via netværket (f.eks. ved hjælp af NTP-protokollen) bør være aktiveret – for at VMS kan fungere korrekt, skal OS-dato og -tid være korrekte. Hvis der ikke er nogen hardware-RTC, og den eneste dato/tidskilde er planlagt til at være netværket, anbefales det, at enheden nægter at starte overhovedet, hvis den ikke kan synkronisere dato/tid.

Storage

Sørg for, at der er plads nok på filsystemet til, at VMS’et kan fungere korrekt. Serveren bruger følgende lagerpladser:

  • VMS-installation – binære filer og dynamiske biblioteker (.so-filer)
    • Lokaliseret på /opt/<leverandør>/mediaserver/
    • Krævet plads: kan beregnes ved at måle den samlede størrelse af de respektive filer i distributionen med en vis tilføjet margen; jo højere margen – jo mindre chance for problemer med opdatering til fremtidige versioner. Generelt anbefales en margen på 30 %.
    • Hvis der ikke er tilstrækkelig plads på /opt, kan .so-filer flyttes via symlinks til en anden placering, herunder FAT32-lagring (men i dette tilfælde kan kun filer, der ikke er symlinks, flyttes).
  • Serverdatabasefiler – gemmer oplysninger om kameraer og andre servere, hændelseslogfiler osv.
    • Legger typisk på /opt/<vendor>/mediaserver/var/; kan ændres i Serverkonfigurationsfilen.
    • Kræver ext4-filsystem
    • Kræver pladsbehov: Afhænger af antallet af kameraer og Servere i VMS-systemet, men generelt anbefales mindst 500 MB.
  • Server Analytics-database – lagrer Video Analytics-metadata, der genereres af Analytics-plugins
    • Ligger typisk på /opt/<vendor>/mediaserver/var/data; kan ændres i Serverkonfigurationsfilen.
    • Krævet plads: Afhænger af, om Analytics-plugins er i brug på denne server, og hvor mange metadata pluginsne vil sende. Generelt anbefales 20 % af videoarkivets lagerpladsstørrelse, hvis Analytics Plugins bruges på denne Server.
  • Serverlogs
    • Ligger på /opt/<vendor>/mediaserver/var/log/
      • Kan flyttes via mediaserver.conf.
    • Logs overskrives automatisk i en sløjfe.
    • Krævet plads: Mindst 260 MB anbefales.
    • BEMÆRK: Vi har bemærket, at på bestemte ARM-enheder (f.eks, Raspberry Pi 3), den interne flash-hukommelse (Micro SD i det tilfælde) ikke var god nok til at acceptere logfiler. Systemet ville fryse i op til 4 sekunder. Vi anbefalede at omdirigere logs til den samme placering som videoarkivet for sådanne enheder.
  • Videoarkiv – gemmer den optagede video fra kameraer
    • Typisk placeret på /opt/<vendor>/mediaserver; kan ændres i Serverkonfigurationsfilen.
    • Systempartitionen vil sandsynligvis blive begrænset fra optagelse som standard, medmindre der er mindst 10 GB ledig plads.
    • Intern flashhukommelse (eMMC) eller SD-kort
        • Vurder, hvor mange skrivecyklusser hukommelsen kan acceptere. Videoarkivet overskriver automatisk sig selv i en sløjfe, og derfor kan varigheden af en enkelt skrivecyklus beregnes ved at dividere den frie plads med den kombinerede bitrate for alle kameraer, der optages på serveren.
        • Sørg for, at hukommelsesgennemstrømningen er tilstrækkelig til den kombinerede bitrate for alle kameraer, der optages på serveren, med en sikkerhedsmargin på 30 %.
    • Intern HDD eller SSD
        • Sørg for, at diskgennemstrømningen er tilstrækkelig til den kombinerede bitrate for alle kameraer, der optages på serveren, med en sikkerhedsmargin på 30 %.
    • Ekstern NAS
          • Sørg for, at netværksadapterens faktiske båndbredde er tilstrækkelig til den kombinerede bitrate for alle kameraer, der optages på serveren, ganget med 2 (fordi kameraerne formodentlig sender deres streams til serveren ved hjælp af den samme netværksadapter), med en sikkerhedsmargin på 30 %.
  • Opdateringsfiler til Serverprogrammet
    • For at kunne opdatere skal Serverprogrammet downloade sin nyere version og udpakke den.
    • Lokaliseret på /tmp/
    • Krævet plads: Den samlede størrelse af den pakkede Server-distributionsfil multipliceret med 2,6; dette inkluderer margenen. Mere plads kan anbefales for at minimere chancerne for problemer med opdatering til fremtidige versioner.

  • Temporære OS-filer
    • Typisk placeret på /tmp/
    • Krævet plads: mindst 100 MB anbefales, uden at medregne den krævede plads til Server-programopdateringsfilerne (se ovenfor).

De fleste af de ting, der er anført ovenfor, kan tildeles til at blive gemt et andet sted i Server-konfigurationsfilen: /opt/<vendor>/mediaserver/etc/mediaserver.conf

Da den typiske SD-kortlagring ikke er pålidelig og kendt for at fejle under intensive skrive- og læseoperationer, anbefaler vi at installere operativsystemet og gemme videoarkivet på en eller flere harddiske. Hvis en SSD/harddisk eller et SD-kort overvejes til lagring af videoarkivet, skal du vurdere dens kapacitet til flere omskrivningsoperationer ved hjælp af den typiske bitrate for et ønsket understøttet kamera multipliceret med det ønskede antal understøttede kameraer.

For eksempel for Raspberry Pi 3 B+:

    • Brug USB-SATA-adapter og ekstern harddisk til arkivet.
    • Installer OS (Raspbian) på en ekstern harddisk. Se artiklen Sådan starter du din Raspberry Pi fra en USB-masselagerenhed for at få flere oplysninger. Denne proces bør automatiseres afhængigt af, hvordan ARM-enhederne skal distribueres: med eller uden harddisk:
      • Med harddisk – lav et forudkonfigureret image med VMS installeret og klon det til harddiske.
      • Og uden harddisk – du skal oprette et sæt scripts, der formaterer HDD, kopierer OS og foretager alle de nødvendige justeringer. Dette er en ret kompleks og tidskrævende opgave.

Vælg Linux-smag

Der er normalt flere muligheder for Linux OS på en given NVR:

  • “Busybox” – blot Linux-kernen og det grundlæggende sæt af kommandolinjeværktøjer; bruges på NVR’er med relativt lav ydeevne, såsom “edge”-kameraer (kameraer med VMS-serveren kørende på dem).
  • Standard Debian, eller en af dens varianter som Ubuntu.
  • Modificeret version af Debian eller en anden Linux-distribution, som regel modificeret af enhedsleverandøren (f.eks, Raspbian til Raspberry Pi).

Generelt anbefales det at vælge en Linux-variant, som er det oprindelige valg for den platform, som NVR’en er baseret på. Hvis man f.eks. udvikler en NVR, der hardware-mæssigt ligner Raspberry Pi (eller endda bruger det nøjagtige Raspberry Pi-mainboard), anbefales det at vælge Raspbian.

Hvis der er flere Linux-distributioner med forskellige sæt pakker til enheden, anbefales det at vælge den mindst tunge af dem. Hvis der f.eks. ikke er planer om at vise GUI på NVR’en, er der ikke behov for X Window System.

Sørg for, at Linux-versionen og dens sæt af pakker opfylder kravene til VMS’et. For ARM-baserede enheder skal du konsultere de OS-detaljer, der er angivet i ARM Support Policy.

Installer Server-applikationen

Når NVR’en er indlæst med et passende Linux OS, skal Server-applikationen installeres på NVR’en. Der er grundlæggende to muligheder:

  1. For Debian-baserede OS: Installer den officielle .deb-pakke fra VMS-distributionen ved hjælp af dpkg.
  • Se de detaljerede instruktioner for installation af VMS på en enhed: ARM SBC-installationsvejledning
  • For Busybox-baseret OS: Udpak de nødvendige filer fra VMS .deb-pakken til den ønskede mappe, og tag manuelt hånd om følgende aspekter:
    • Hvordan serveren skal startes ved opstart, og hvis system.d-understøttelse fra distributionen ikke er egnet?
    • Hvor skal serveren tage .so-biblioteker, der mangler i den installerede Linux?
    • Vil standard VMS automatiske opdateringssystem være aktiveret?

    For mindre typiske OS-opsætninger kan en kombination af mulighed 1 og 2 være nødvendig.

    Implementer ekstra funktioner

    Typisk er en NVR ikke bare en standard Linux-computer med Server-applikationen installeret – den giver ofte brugeren ekstra funktioner:

    • Hardwareknapper, LED’er eller endda integrerede skærme.
    • En webgrænseflade, som giver dig mulighed for at tilpasse NVR’en ud over blot at konfigurere Server-applikationen via dens egen webgrænseflade, f.eks.
      • netværksindstillinger: IP-adresse, undernet osv.;
      • systemtid og tidszone;
    • Videoudgang (f.eks, HDMI), der viser en GUI eller i det mindste en velkomstskærm med grundlæggende konfigurationsværdier som f.eks. NVR’ens IP-adresse;
    • Yderligere software, der kører parallelt med VMS, f.eks. en konfigurationsdæmon eller et backend til videoanalyse.
      • Hvis den ekstra software har en adgangskodebaseret godkendelse for slutbrugeren, bør du overveje at implementere synkronisering af adgangskoder, så adgangskoden til VMS-serveren altid er den samme som til den ekstra software. Hvis ssh tilbydes brugeren for at få adgang til NVR’en, skal du også overveje at synkronisere dens adgangskode.
    • Yderligere justeringer, som f.eks. minimering af videohukommelse (GPU). For Raspberry Pi 3 B+ skal du f.eks. indstille GPU-hukommelsen til 16 MB. Se Raspberry Pi-dokumentationen for nærmere oplysninger.

    For at implementere sådanne funktioner kan det være nødvendigt at skrive eller ændre scripts, der styrer Server-applikationen, eller skrive yderligere programmer i C/C++.

    Tidssynkronisering

    Sørg for, at NVR’en har et indbygget CMOS-batteri for at forhindre, at dens ur nulstilles i tilfælde af strømsvigt. Raspberry Pi 3 B+ har f.eks. ikke et indbygget CMOS-batteri. Hvis enheden genstartes, vil tiden blive nulstillet, og det vil resultere i forkert arkivskrivning. For at undgå dette er der nogle muligheder:

    • Sørg for, at den er forbundet til internettet for at synkronisere tiden.
    • Hvis det er et lukket netværk, skal du opsætte en NTP-server.
    • Føj et Real-Time Clock-modul (RTC) til kortet, og forkonfigurer det. Se Tilføjelse af et realtidsur til din Raspberry Pi.

    Find/byg et kabinet til din NVR

    Det er nødvendigt at finde eller designe et kabinet, der passer til al den ovennævnte hardware.

    Udfør omfattende belastnings-/stress-test

    For at sikre, at alt fungerer sammen, er det nødvendigt at planlægge en intensiv stresstest for at sikre, at der ikke er overophedning eller fejlfunktion i komponenterne. Testen skal kunne belaste alle systemkomponenter som CPU, hukommelse, harddisk(e), netværk og Wi-Fi (om nødvendigt) osv.

    Etabler en supportpolitik

    NVR’en vil blive leveret til slutbrugerne, og de vil helt sikkert have brug for en form for teknisk support. VMS-leverandørens supportteam kan ikke yde sådanne tjenester til slutbrugerne, og der bør derfor udvikles en politik for levering af en sådan support, som f.eks. en online supportdesk, et fællesskabsforum eller lignende.

    Når NVR-leverandørens supportteam er sikker på, at det pågældende problem ikke er relateret til selve NVR’en, men snarere er et problem i VMS’et, kan det anmode om support fra VMS-leverandøren i henhold til ovennævnte ARM-supportpolitik og derefter bruge resultatet af denne supportsag til at imødekomme en slutbrugerens supportanmodning.

    Spørgsmål

    Hvis du har spørgsmål i forbindelse med dette emne, eller hvis du ønsker at dele dine erfaringer med andre medlemmer af fællesskabet eller vores team, kan du besøge og deltage i vores supportfællesskab eller kontakte din lokale forhandler.

    Skriv et svar

    Din e-mailadresse vil ikke blive publiceret.