TV i video w Internecie

Jak zrobiliśmy CDNa by hostować pliki wideo i transmisje live.

SimpleStorage to system dystrybucji treści (CDN) stworzony przez Divante i IMAGIN IT

Plan prezentacji

• Nasza motywacja• Trochę o tym co chcieliśmy osiągnąć• Jak to zrobiliśmy?

– projekt i założenia– węzły edge i origin– redirector– modelowanie ruchu (mądrze brzmi )– replikacja i zarządzanie plikami– statystyki– live-streaming

• Co już działa, • … a co jeszcze nie i jakie są plany

Nasza motywacja

• Zrobiliśmy wcześniej darmowy videosteam.pl– i już wiedzieliśmy, że wideo w Internecie nie jest

takie proste • Stanęliśmy przed szansą zrobienia dużego

portalu wideo - TiVi.pl• Chcieliśmy, po ludzku, zrobić coś ciekawego

Co chcieliśmy osiągnąć

• Sieć dystrybucji (edge) i storage (origin) w oparciu o zwykłe PCty – jeśli się da - zachowanie niskich cen dla klientów

• Skuteczne rozdzielanie ruchu, dopasowywanie trasy do sieci klienta – na ile się da+ wykorzystanie wielu datacenter

• Replikację danych zamiast backupów+ automatyczne wyłączanie zepsutych serwerów i zastępowanie ich

nowymi• Obsługę nie tylko plików statycznych ale też transmisji na żywo• Chcieliśmy, żeby usługa była zgodna ze standardami (np. HTTP,

WebDAV, RTMP …) – dzięki czemu łatwiejsza w wykorzystaniu

Dlaczego zwykłe PCty? http://www.manageability.org/blog/stuff/economics-google-hardware-infrastructure

• Gdzie się tylko da zapewnić redundancję• Użyć sprawdzonego oprogramowania i je ew.

przerobić/dostosować– Varnish, nginx, Apache, MogileFS

• Dopisać tylko brakujące komponenty – im więcej kodu, tym więcej błędów – redirector, zarządzanie plikami (WebDAV), statystyki,

bilingowanie– Java, Python + WSGI - dopiero gdy będzie trzeba

kluczowe elementy przepisać w C

Założenia

Projekt

Węzły edge i origin

• Postanowiliśmy rozdzielić – może być mniej węzłów storage (origin) – ruch od/do klientów końcowych tu nie dociera, tylko do edge, które są prostsze i może ich być więcej

• Węzły edge działają jako proxy korzystając z przerobionego varnisha i nginxa pobierając dane z originów– potrzebny był soft który przekieruje użytkownika na działający i

nieprzeciążony węzeł• Na originach stosujemy nginxa i MogileFS który replikuje

dane automatycznie odnawia kopie – i robi dużo dobrej roboty, – potrzebny był soft do zarządzania plikami dla użytkownika

• Początkowo węzły edge i origin to mogą być te same maszyny

Redirector• Przyjmuje wszystkie żądania odczytu (pliki i live) na tzw. „klatę” ;)

– przekierowania HTTP – szybsza aktualizacja niż DNS, prostsze niż BGP – przy live specjalna obsługa w playerze

• Ma wiedzę o stanie węzłów edge – stan, obciążenie, limit transferu, obciążenie łącza, load systemu i ich umiejscowieniu (datacenter/ASN/sieć)

• Ma wiedzę o sieciach klientów i ich „odległościach” (ping, hops, ilość ASNów) od DC – wie z której sieci przychodzi klient po adresie IP– na tej podstawie może wybrać najkorzystniejszy względem klienta

serwer i tam przekierować jego zapytania• Działa na minimum 2 węzłach (+ sprzętowy load balancer

dzielący ruch na redirectory), intensywnie korzysta z cache i jest napisany w pythonie + wsgi – udało się nam osiągnąć ok. 2tys. req/s na serwer

• Główne zadanie redirectora• Dla każdego żądania

– bierze adres klienta i sprawdza z której sieci jest klient

– sprawdza wagę/odległość tej sieci od poszczególnych DC i wybiera najkorzystniejsze – wagi są aktualizowane co 5 min. Przez osobne aplikacje uruchomione na węzłach, dodatkowe wagi do ręcznego modelowania ruchu wg. polityk sieciowych

– bierzemy pod uwage hopy, trasę / ilość ASNów po drodze (bardziej istotne), początkowo liczyliśmy odległości od poszczególnych serwerów ale wystarczy od DC

– wybiera grupę serwerów obsługujących dane żądanie (livestreaming, pseudo-streaming, pliki statyczne/buforowane wideo)

– wybiera najmniej obciążony serwer z tej grupy (losowo z wagami) i podaje go klientowi + keszuje na kilkadziesiąt sekund

Modelowanie ruchu

GET /V/plik.flv

GET /V/plik.flv

Redirect HTTP 301

W=1.4 W=0.9 W=0.2

DC1 DC1 DC2

Mój IP: 91.94.61.248

• Replikację zapewnia MogileFS – każdy plik musi być w 2-3 replikach (różne klasy replikacji) – jeśli wypada węzeł, plik jest replikowany na inne serwery

• Zarządzanie plikami – napisaliśmy oprogramowanie w Pythonie dla zapewnienia interfejsu WebDAV tzw. Mostek. W przyszłości chcielibyśmy dodać wsparcie dla S3 API. Mostek mediuje między klientem a MogileFS Trackerem i interfejsem HTTP MogileFS (u nas nginx)

• Mostek zabezpiecza też pliki – udostępnia węzłom brzegowym informacje czy dane pliki są dostępne (tokeny, wygasanie kont klientów – w przyszłości prawa dostępu do plików)

• Mostek działa na dwóch serwerach (+ sprzętowy load balancer) i bazy MySQL (master + kilka slave)

• Mostek oprócz redirectora jest kluczowym elementem, testujemy go automatycznie skryptami wykonującymi podstawowe operacje przez curla zaraz po deployu (przez SVNa)

Replikacja i zarządzanie

Replikacja i zarządzanie

Mostek

Klient wgrywa, listuje, usuwa pliki przez WebDAV

Baza danych o plikach

Master + Slave

węzły origin/storageobsługiwane przez MogileFS

tackery MogileFSdbają o replikację plikówi udzielają informacji gdzie są dane pliki

węzły edge buforują pliki

edge pyta z któregoorigina ma pobrać plik

Statystyki

• Logów jest bardzo dużo (na razie po ok. 50req/s na serwer – wszystko idzie do access logów) – prosty map/reduce

• Zbieramy statystyki z serwerów brzegowych i mostka – zużycie dla klienta (transfer, storage, hity), zużycie streamów (ilość emisji, ilość klientów)

• Musieliśmy napisać kilka programików:– Statystyki są wstępnie przetwarzane przez logalyzer (przy rotowaniu

logów) i w formacie CSV wgrywane na SimpleStorage– logcollector ściąga paczki z logami i wrzuca hurtem do bazy,– statscalc agreguje dane w podsumy, niezagregowane dane usuwamy po

czasie,• W efekcie - na stronie użytkownik widzi zmiany w statystykach z

dokładnością do godziny

Livestreaming• Działa już produkcyjnie• Zgodny z RTMP/RTMPT/RTMPE – gotowy serwer w Javie ze zmianami

(statystyki) zainstalowany na wszystkich węzłach • Rozdzielanie ruchu zrobiliśmy za pomocą proxy na poziomie aplikacji wideo

(kodzik w Javie rozsyła wideo z serwera do którego nadaje klient do serwerów docelowych – możemy dynamicznie wybierać do których dla którego klienta)

• Dodaliśmy autoryzację nadawców (tokeny – obsługiwane przez Mostek)• … oraz oglądających (tokeny – mogą być obsługiwane indywidualnie przez

webservice’y danych usług – np. VoD)• Redirector obsługuje przekierowania do streamingu (wsparcie w playerze

było konieczne) – RTMP nie obsługuje przekierowań• Dobrze byłoby opakowywać też w HTTP – działa wtedy m.in. buforowanie,

nie ma problemów z firewallami– chcielibyśmy wkrótce dodać obsługę smooth-streamingu i streamingu na iphona

(mpeg-ts) – możemy to zrobić przez transkodowanie w locie (prowadziliśmy próby) lub wydzielone serwery typu Wowza, IIS – minusami jest niejednorodne środowisko

Livestreaming

klient z encoderem – np. FMLE nadaje strumienie do primary i backup

węzły odbierają sygnał od nadawcy i publikują go dowęzłów edge

odbiorcy pobierają sygnał z węzłów edge

Plany rozwoju?

– uprawnienia do plików– optymalizacja i usprawnienie algorytmu

modelowania ruchu– streaming przez HTTP i smooth-streaming– streaming na iphone’a– wstawienie kolejnych węzłów – m.in. do PL-IX– rozbudowa i przyspieszenie statystyk– …

Dziękuję za uwagę!

Pytania?pkarwatka@divante.pl

Wersja testowa SimpleStorage: http://simplestorage.pl