III DALIS: VIRTUALIZACIJOS EKOSISTEMA (PROXMOX + GO2RTC + JELLYFIN)

LXC vs VM: Kodėl kameroms pasirinkai būtent LXC

Virtualizacijos pasaulyje egzistuoja dvi pagrindinės paradigmos: pilnos virtualios mašinos (VM) su savo branduoliu ir aparatinės įrangos emuliacija, bei konteineriai (LXC), kurie naudoja pagrindinės sistemos branduolį, bet turi atskirą vartotojo erdvę. Kodėl stebėjimo kameroms pasirinktas būtent LXC?

Atsakymas slypi efektyvume. Kamerų srautams apdoroti reikia mažai procesoriaus resursų, bet jie reikalauja greitos prieigos prie tinklo ir mažo delsos. LXC konteineriai turi beveik nulinį papildomą kaštą (overhead) – jie naudoja tą patį branduolį kaip ir pagrindinė sistema, todėl nereikia emuliuoti aparatinės įrangos ar rezervuoti atminties iš anksto.

Be to, LXC leidžia lengvai perduoti tinklo sąsajas iš pagrindinės sistemos. Konteineris gali turėti tiesioginę prieigą prie kamerų VLANo per virtualų tiltą (vmbr1), o VM tam reikėtų sudėtingos bridinimo konfigūracijos. LXC taip pat yra lengvesnis atsarginių kopijų atžvilgiu – jį galima klonuoti, atkurti ar migruoti per kelias sekundes, nes jis yra tik keletas failų pagrindinėje sistemoje.

Konkrečiai kameras valdantis LXC konteineris turi tokią konfigūraciją:

bash# LXC konfigūracija /etc/pve/lxc/100.conf
arch: amd64
cores: 2
memory: 2048
swap: 512
unprivileged: 1
lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.net.0.flags: up
lxc.net.0.type: veth
lxc.net.0.link: vmbr1 # Atskiras tiltas kamerų tinklui

O štai kodėl Jellyfin ir kitiems sunkiasvoriams servisams pasirinkta VM:

Jellyfin VM buvo pasirinkta ne dėl našumo, o dėl galimybės atlikti PCIe passthrough – perduoti visą Tesla P4 vaizdo plokštę tiesiogiai virtualiai mašinai, kad ji galėtų naudoti NVIDIA tvarkykles ir NVENC aparatinį kodavimą be jokių apribojimų.

go2rtc inžinerija: Kaip išvengti transkodavimo ir išlaikyti 0% CPU apkrovą

"go2rtc" yra modernus, parašytas "Go" kalba, srautų peradresavimo įrankis, kuris tapo neatsiejama šios architektūros dalis. Jo genialumas slypi tame, kad jis NEtranskaduoja vaizdo. Dauguma stebėjimo sistemų (pvz., "MotionEye", "Shinobi", net "Frigate") transkaduoja srautus, kad pritaikytų juos naršyklėms, o tai sunaudoja daug CPU resursų ir prideda delsos. "go2rtc" vietoj to peradresuoja originalius srautus, naudodamas WebRTC arba MSE (Media Source Extensions) naršyklėje, kuri pati atsakinga už dekodavimą.

Kaip tai veikia praktiškai:

1. Kameros per atskirą "Xiaomi" WiFi tinklą siunčia RTSP srautą (pvz., rtsp://192.168.100.101:554/stream1).
2. "go2rtc", veikiantis LXC konteineryje, priima šį srautą per virtualų tiltą vmbr1 ir padaro jį prieinamą per WebRTC (kuri naudoja UDP) arba per MSE (kuri naudoja HTTP segmentuotą srautą).
3. Naršyklė gauna originalų H.264/H.265 srautą ir dekoduoja jį naudodama aparatinį pagreitį (GPU).
4. Rezultatas – 0% CPU apkrovos serveryje, net su 8 kameromis vienu metu.

"go2rtc" konfigūracijos pavyzdys (go2rtc.yaml):

yamlapi:
listen: ":1984"
username: "admin"
password: "your_secure_password"

streams:
kiemas1: rtsp://admin:[email protected]:554/stream1
kiemas2: rtsp://admin:[email protected]:554/stream1
vidus1: rtsp://admin:[email protected]:554/stream1
vidus2: rtsp://admin:[email protected]:554/stream1

webrtc:
listen: ":8555"
candidates:
- "stun:stun.l.google.com:19302" # NAT traversal
- "10.10.10.10:8555" # Lokalus IP

mse:
listen: ":8556"

Prieiga naršyklėje tampa paprasta: atidarome http://kameros.tavo-domenas.lt:1984/api/stream?src=kiemas1 ir gauname WebRTC srautą su beveik nuliniu delsos laiku. Nereikia jokių papildomų kodekų ar naršyklės plėtinių. O kadangi "go2rtc" netranskaduoja, visas procesoriaus resursas lieka laisvas kitiems uždaviniams.

Jellyfin ir Tesla P4: Tikroji transkodavimo galia

Nors "go2rtc" išmaniai vengia transkodavimo kamerų srautams, medijos turinys (filmai, serialai, asmeniniai vaizdo įrašai) yra visiškai kitas reikalas. Čia į sceną žengia "Jellyfin" – atviro kodo medijos serveris, kuris gali transkoduoti vaizdo turinį į įvairius formatus, kad jis būtų atkuriamas įvairiuose įrenginiuose (telefonuose, televizoriuose, planšetėse).

Ir čia atsiskleidžia tikrasis šios architektūros genialumas: transkodavimui naudojama NVIDIA Tesla P4 vaizdo plokštė. Tai ne žaidimų GPU, o profesionalus, žemos galios (75 W TDP) įrenginys, sukurtas būtent duomenų centrams. Jis turi NVENC (NVIDIA Encoder) ir NVDEC (NVIDIA Decoder) aparatinius blokus, kurie gali transkoduoti kelis 4K srautus vienu metu, beveik neapkraunant pagrindinio procesoriaus.

Kodėl Tesla P4, o ne vartotojiška vaizdo plokštė?

Kaip tai integruota:

1. Tesla P4 yra įdiegta serveryje per PCIe lizdą.
2. Proxmox atlieka PCIe passthrough – perduoda visą vaizdo plokštę tiesiogiai Jellyfin virtualiai mašinai.
3. Jellyfin VM konfigūruojama naudoti NVIDIA tvarkykles ir NVENC aparatinį kodavimą.
4. Kai vartotojas žiūri filmą per naršyklę ar mobilųjį įrenginį, Jellyfin automatiškai nusprendžia, ar reikia transkodavimo (jei originalus formatas nesuderinamas su įrenginiu), ir šį darbą atlieka Tesla P4, o ne CPU.

Jellyfin VM konfigūracija Proxmox:

bash# /etc/pve/qemu-server/101.conf (Jellyfin VM)
agent: 1
boot: order=scsi0;net0
cores: 4
hostpci0: 0000:01:00.0,pcie=1 # Tesla P4 passthrough
memory: 8192
name: jellyfin
net0: virtio=XX:XX:XX:XX:XX:XX,bridge=vmbr0
scsi0: local-lvm:vm-101-disk-0,size=100G
scsihw: virtio-scsi-pci
smbios1: uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
sockets: 1
vga: std

Jellyfin transkodavimo nustatymai:

bash# /etc/jellyfin/encoding.xml (ištrauka)
<EncodingOptions>
<HardwareAccelerationType>Nvidia</HardwareAccelerationType>
<EncoderPreset>p5</EncoderPreset>
<EnableHardwareEncoding>true</EnableHardwareEncoding>
<EnableHardwareDecoding>true</EnableHardwareDecoding>
<EnableSubtitleExtraction>true</EnableSubtitleExtraction>
<NvidiaDevice>/dev/dri/renderD128</NvidiaDevice>
</EncodingOptions>

Ši architektūra sukuria aiškų atsakomybių pasiskirstymą:

• go2rtc (LXC): Tiesioginis kamerų srautų perdavimas be transkodavimo – 0% CPU.
• Jellyfin (VM) + Tesla P4: Medijos turinio transkodavimas, kai to reikia – darbas atliekamas aparatūriniu pagreičiu, neapkraunant pagrindinio procesoriaus.
• Kiti LXC konteineriai: Atskiri konteineriai kitiems servisams (pi-hole, home assistant, ir kt.), kad būtų išlaikyta modulinė architektūra.

Tokia modulinė virtualizacijos architektūra leidžia kiekvienam servisui dirbti efektyviausiu būdu. Tačiau net ir pati geriausia sistema reikalauja nuolatinio tobulinimo, atsarginių kopijų ir, svarbiausia, inžinieriaus, kuris nepameta motyvacijos – šias temas užbaigsime paskutinėje dalyje.