Popis problému

U stárnoucí generace video serverů EVS XT2 začalo být poměrně častým jevem selhávání interních SCSI disků. Na disky serveru je typicky v tzv. "loop" módu neustále ukládán komprimovaný signál že všech vstupních kanálů (v případě serverů XT2 obvykle 4 - 5 paralelních video streamů).

V roce 2025 - dva ze tří serverů jsou stále aktivně využívány)

V případě broadcastového nasazení ve formátu HD 1080i50 je datový tok na výstupu každého kodéru cca 100 - 185 mbps. Činnost serveru spočívá v konstatním zápisu dat (komprimovaný A/V signál) při paralelním čtení těchto dat ať už operátorem serveru či jiným serverem v SDTI síti.

Raid serveru umožňuje spolehlivý chod při selhání jednoho jediného HDD. V případě selhání více disků je narušena integrita dat a ta už nelze obnovit.

K selhávání disků typicky docházelo během reálného nasazení. V "laboratorních" podmínkách byly servery schopné bez jediné chyby pracovat i několik dní v kuse.

Pohled na část "raidové" desky serveru

Řešení

Každý server disponuje několika sériovými porty pro komunikaci s ovládacím prvkem, kterým je obvykle tzv. "remote" tedy kontrolní panel vyvinutý speciálně pro tento typ serverů.

Každý port bylo ve verzi 11.x.x možné nastavit na jeden z těchto komunikačních protokolů:

  • Harris VDCP
  • Odetics
  • Sony BVW75
  • Thompson 35-XtenDD
  • EVS AVSP

Backplate serveru XT2

K nativnímu EVS AVSP se mi nikdy nepodařilo dohledat dokumentaci (bohužel nepomohl ani officiální support výrobce). Některé protokoly nebyly zřejmě nikdy volně uvolněny pro veřejnost.

K protokolu Harris VDCP (Video Disk Communication Protocol) se nakonec dokumentaci najít přecijen podařilo (jedná se o tento dokument). Podle pravidel VDCP byl následně sestaven ovládací script, který na serveru emuloval práci 2 operátorů.

Náhradní kontroler

Script byl spuštěn na Raspberry Pi. Sériový port byl na Raspberry přidán obyčejným adaptérem RS422 - USB

Server byl nastaven do módu 4 vstupů a 2 výstupů - všechny porty byly tudíž používány. Pro každý port byl v rámci scriptu spuštěn thread. Thready pro vstupní kanály měly za úkol v nekonečné smyčce ukládal klip ze "svého" vstupu v náhodně generované délce (x až y sekund). Výstupní thready měly za úkol náhodně vybrat jakýkoli z uložených klipů, ten načíst (tj. zobrazit na výstup) a poté přetočit. Přetočením se rozumí 20ti násobně zrychlené přehrání ze začátku nakonec a poté zpátky.

Použití všech dostupných kanálů a neustálé ukládání klipů při souběžném přetáčení tam a zpět mělo udžovat server v extrémní zátěži a definitivně prokázat / vyvrátit stabilitu.