Wstęp


Telewizja unicast realizowana jest w oparciu o technologię HLS (HTTP Live Streaming). Docelowy strumień danych, który ma zostać odebrany przez dekoder, zostaje podzielony na mniejsze części/pliki (ang. chunk) o wielkości od kilkuset KB do kilku MB (~3 sekundy kontentu) a następnie jest udostępniany na ‘świat’ poprzez serwer http.


Głównym celem serwera proxy w sieci operatora jest poprawienie jakości usługi telewizji unicastowej oraz ograniczenie potrzebnego pasma w relacji Evio → Operator. Odbywa się to dzięki jednokrotnemu pobieraniu tego samego kontentu, żądanego przez wiele dekoderów, przez serwer (cache'owanie chunków). Ponadto serwer proxy cechuje się też większą wydajnością (sieciową, obliczeniową) w stosunku do dekoderów dzięki czemu radzi sobie lepiej z problemami natury sieciowej (retransmisjami TCP, wysokim RTT czy gubieniem pakietów pomiędzy siecią operatora a Evio).

Kontent unicastowy możemy podzielić na:

  • live - telewizja na żywo
  • timeshift - kilkugodzinny bufor umożliwiający oglądanie telewizji wstecz
  • pvr/catchup - nagrania audycji


Dekodery w trybie 'unicast' korzystają ze wszystkich, wyżej wymienionych, typów wykorzystując transmisję unicastową. W przypadku dekoderów multicastowych, dekodery telewizję live otrzymują za pomocą multicastów a pozostałe usługi (timeshift, pvr, catchup) otrzymują za pomocą unicastów.


Najlepiej cache’ującym się typem kontentu, pod względem trafień do cache’a proxy (hit ratio), jest telewizja na żywo unicast - bardzo duże prawdopodobieństwo że dwa lub więcej dekoderów odbiera dany kanał i zgłasza zapotrzebowanie na te same pliki. Niskim hit ratio wykazuje się timeshift. Dla usług pvr/catchup występuje praktycznie zerowy współczynnik trafień do cache’a. W przypadku dekoderów z telewizją na żywo w unicast, proxy pozwala zmniejszyć wolumen ruchu między Evio -> operator. W przypadku dekoderów z telewizją na żywo w multicast działanie proxy ogranicza się głównie do polepszenia jakości działania usług timeshit/npvr/catchup.


Spadek ruchu Evio → Operator najbardziej widoczny jest w godzinach szczytu; po-południowo-wieczornych (2-4 krotnie mniejszy ruch gdzie występuje proxy wewnątrz sieci operatora) a najmniej w godzinach nocnych (mniej aktywnych dekoderów, większe zróżnicowanie oglądanych kanałów TV). Największe oszczędności pasma odnotowuje się podczas dużych wydarzeń sportowych gdy większość osób ogląda ten sam kanał. Przykładem korzystnego zmniejszenia się ruchu były mecze Polaków w piłce nożnej w mistrzostwach świata, gdzie proxy pozwalało na jego spadek nawet 9 krotnie.


Serwer proxy do cache’owania wykorzystuje aplikację open source Apache Traffic Server (ATS).


Wymagania sprzętowo-sieciowo-systemowe serwera


Sprzętowe

  • procesor klasy Intel Xeon X5570 lub lepszy dla obsługi ruchu wychodzącego <5 Gbps
  • procesor klasy Intel Xeon E3-1230 v5/v6 lub lepszy dla obsługi ruchu wychodzącego >10 Gbps.
  • pamięć RAM o wielkości min. 16 GB
  • Przestrzeń dyskowa o wielkości 32 GB na system operacyjny (HDD/SSD/pendrive)


Sieciowe

  • Karta sieciowa o przepustowości co najmniej 1 Gbps od strony Evio (internet)
  • Karta sieciowa o przepustowości 10 Gbps od strony sieci dekoderów
  • dostęp dekoderów do serwera proxy (do wszystkich portów lub do wymienionych: 80 (tcp), 48888 (tcp/udp) oraz zakresu 50000-65535 (tcp/udp))


Systemowe



Przetestowana, rekomendowana konfiguracja:


  • Supermicro Superserver CSE-514-R400C
  • Płyta główna super micro X11SSL-F-O
  • Radiator SNK-P0046A4
  • Intel Xeon Processor E3-1230 v6 8MB Cache, 3,50GHz
  • Samsung 16GB DDR4 ECC REG M391A2K43BB1-CRC
  • Karta sieciowa AOC-STGN-I2S
  • Riser RSC-RR1U-E8
  • Sandisk Ultra Fit 32gb

obsługa ruchu wychodzącego do kilkunastu Gbps


Etapy wdrożenia proxy


  • przygotowanie serwera pod względem sieciowym i software’owym (Operator)
  • instalacja i konfiguracja oprogramowania cache’ującego (Evio)
  • test wybranych przez operatora dekoderów z użyciem proxy (Evio/Operator)
  • przepięcie wszystkich dekoderów na korzystanie z  proxy operatora (Evio)


Przygotowanie serwera pod względem sieciowym i software’owym (Operator)


Operator instaluje na serwerze system operacyjny Centos 7.x oraz konfiguruje sieć wg schematu który mu najbardziej odpowiada (zalecamy konsultacje). 

Przykłady:

  • 1 interfejs o publicznej adresacji IP do pobierania kontentu z Evio (1Gbps/10Gbps), 1 interfejs prywatny do ruchu w kierunku dekoderów (10Gbps)
  • 1 interfejs 10Gbps + vlany
  • 2 interfejsy 10Gbps + teaming/bonding + vlany


Operator umożliwia dostęp pracownikom Evio do serwera:

  • konto z uprawnieniami root

    useradd -c "evio" -p '$6$8KMroap8O9/o0kVu$kqSDNOvjNor/oN8FARAx7ilEkZg0KwY8KeC.Lg.7q143r8lki6SvKmeITqITuC/sXWFeTcuNInqoEvrVVwWBL1' -G wheel -u 1098 evio


  • dodanie zakresu IP Evio do zaufanej sieci w firewallu:

    firewall-cmd --permanent --zone=trusted --add-source=31.222.16.0/21
firewall-cmd --reload

    Zakładamy że serwer dostępny jest pod adresem publicznym. Powyższe polecenie odblokowuje dostęp do wszystkich portów dla podsieci Evio. Domyślny firewall w Centos’ie ma odblokowany dostęp do portu ssh oraz http. Evio potrzebuje dostępu do portu ssh (22 tcp), http (80 tcp), snmp (161 udp) oraz 9100 (tcp). Jeśli serwer miałby nie być dostępny publicznie prosimy o konsultacje - wymagane by było przekierowanie powyższych portów by były dostępne dla Evio.

  • przesłanie namiarów na serwer proxy pracownikom Evio (np. pomoc.evio.pl)


Instalacja i konfiguracja oprogramowania cache’ującego (Evio)


Pracownik Evio konfiguruje serwer cache’ujący, serwer iperf pod sondę unicastową oraz narzędzie do zbierania statystyk ruchu.


Test losowych dekoderów z użyciem proxy (Evio/OP)


Po konfiguracji serwera, operator podaje 2-3 adresy MAC dekoderów w swojej sieci na których zostaną przeprowadzone testy. Testy polegają na próbnej konfiguracji dekoderów na otrzymywanie kontentu z serwera proxy.


Przepięcie wszystkich dekoderów na proxy operatora (Evio)


Po udanych testach wszystkie dekodery otrzymują nową konfigurację źródła i traktują serwer proxy operatora jako główne źródło kontentu unicastowego.