Na www.securityinfowatch.com pojawił się ciekawy artykuł poruszający kilka ważnych dylematów związanych z zagadnieniem projektowania sieci komputerowych (szczególnie tych rozleglejszych) w ujęciu telewizji przemysłowej (Video and data are not created equal, czyli w przybliżeniu Video i zwykłe dane to nie to samo). Autorem tekstu jest David Brent z Boscha. Poniżej znajdziecie esencję jego przemyśleń. Zapraszam do lektury.


Jak widać sam tytuł oryginału sugeruje, że video to zupełnie inny twór niż większość płynących sieciami LAN danych. Z tego też powodu początkowo David Brent stara się uzmysłowić czytelnikowi o jakich skalach jest mowa. Podaje cztery przykłady:

  • baza danych dla transakcji w punkcie sprzedaży (POS) ze 100 milionami rekordów zajmuje około 80GB (w zależności od implementacji). Wszelkie operacje (dodanie, usunięcie, zmiana) odbywać się będą mnie więcej na tym samym obszarze.
  • Microsoft Exchange Server, 2000 kont, każde po 150MB. Z protego rachunku wynika, iż potrzeba nam blisko 300GB przestrzeni dyskowej.
  • jedna kamera generująca 30kl/s w H.264 oraz rozdzielczości 4CIF to pasmo w okolicach 2000kb/s. Jeśli założymy pracę ciągłą przez 30 dni w miesiącu, to potrzebujemy na to sporo powyżej 600GB.
  • instalacja na średnim lotnisku. 300 kamer, 15kl/s, H.263/MPEG4, bitrate na poziomie od 1200 do 1500kb/s, archiwizacja przez 30 dni. Wychodzi 135TB, do tego 20TB jako backup, czyli łącznie 155TB. Sporo.

Te przykłady dość dosadnie pokazują, z jakimi ilościami danych mamy do czynienia w systemach CCTV. We wspomnianym przykładzie lotniska szczytowa wartość zajmowanego pasma może sięgnąć 439Mb/s. Dzisiejsze sieci wyposażone są standardowo w interfejsy 1Gb/s, więc wszystko wygląda dobrze. Czy rzeczywiście?

Nie do końca. Trzeba pamiętać, że rozpatrujemy tu tylko obciążenie wynikające z transmisji od kamer do punktu rejestracji. Nie wzięto w ogóle pod uwagę ewentualnej transmisji w drugą stronę, czyli na przykład do centrum monitoringu. Jeśli w centrum tym znajdzie się 10 stacji roboczych, każda z podglądem 10-15 kamer, do tego 3 ściany monitorów 5×5, to obciążenie wzrośnie o kolejne 366Mb/s. Łącznie mamy już 805Mb/s, czyli jesteśmy na pograniczu przepustowości interfejsów. Co możemy zrobić?

Oczywiście zastosować koncepcję opartą o monitoring bez punktu centralnego, stosując na przykład macierze iSCSI i redukując tym samym zapotrzebowanie na pasmo sieciowe oraz ograniczając ryzyko utraty danych w razie awarii.

Od jakiegoś już czasu zauważalna jest tendencja do wspomnianej decentralizacji, jednakże zdaniem autora dopiero stosowanie na krawędzi urządzeń z wbudowaną „logiką” pozwala w pełni korzystać z zalet takiej architektury. Użycie standardowych videoserwerów niesie za sobą pewne korzyści (awaria videoserwera eliminuje nam jeden tylko kanał), jednakże nadal obciążenie sieci stanowi spory problem, gdyż rejestrator znajduje się w punkcie centralnym. Jeśli wszelkie operacje wykonane zostaną w samej kamerze/enkoderze (detekcja ruchu, obróbka, kompresja itp.), a strumień danych trafi do macierzy, problem obciążenia sieci zostaje znacząco ograniczony, zmniejsza się ogólny koszt systemu (nie potrzeba osobnych serwerów dla potrzeb analizy).

W przypadku iSCSI system staje się niemal bezobsługowy, pod warunkiem, iż jest są to macierze przetestowane i spełniające ostre warunki stawiane przez systemy CCTV, w przeciwnym wypadku można spodziewać się problemów, stąd też autor uczula na dwa rozwiązania pseudo-iSCSI:

  • NVR oparty o system Windows z podpiętą macierzą iSCSI. To nadal monitoring z punktem centralnym.
  • urządzenie oparte na Linuxie, do tego Windows Server na wirtualnej maszynie typu VMWare i na nim zainstalowane oprogramowanie NVR. Wady jak wyżej + masa innych potencjalnych punktów zapalnych. (rzeczywiście ktoś tak kombinuje?)

Aby zapewnić pełną decentralizację, należy zapomnieć o centralnej rejestracji i obróbce. Rozrzucone po obiekcie kamery/videoserwery przypisane są konkretnym macierzom – serwer centralny nie ma wpływu na funkcjonowanie tego układu.

Jak więc wybrać odpowiednie urządzenie iSCSI dla swoich potrzeb?

Na rynku jest ponad stu producentów zajmujących się macierzami iSCSI. Często zdarza się tak, iż podczas projektowania instalacji istnieje pokusa, aby wykorzystać istniejące urządzenia dyskowe. Zazwyczaj nie jest to dobra droga. Raz, że często ilość obsługiwanych jednocześnie sesji jest zbyt mała (6-30, a zalecane jest 60-255), druga sprawa to zastosowane dyski – w CCTV zapis ma charakter ciągły i użycie niedostosowanych do tego celu urządzeń zwiększa ryzyko awarii. Warto też zwrócić uwagę na ogólną wydajność macierzy w trybie odbudowywania danych (dla potrzeb CCTV minimum 200Mb/s).

Ostatecznie David Brent przytacza sytuację z realnej instalacji, gdzie ze względu na oszczędności wybrano macierz z niskiej półki, choć w projekcie było inne urządzenie. W praniu okazało się, iż urządzenie zupełnie się nie sprawdziło, gdyż nie umożliwiło zapisu obrazu (bezpośrednia przyczyna jest tu drugorzędna). A konkluzja jest taka, że zawsze warto przy tego typu instalacjach skonsultować się z kimś obeznanym, gdyż łatwiej zbudować od początku porządną instalację, niż łatać później tę wykonaną źle.

Może zainteresują Cię również poniższe wpisy: