TV i video w Internecie

TV i video w Internecie
Jak zrobiliśmy CDNaby 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 loadbalancer 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

Modelowanie ruchu
Redirect HTTP 301
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 uwagehopy, 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
GET /V/plik.flv
Mój IP: 91.94.61.248
GET /V/plik.flv
W=1.4
W=0.9
W=0.2
DC1
DC1
DC2

Replikacja i zarządzanie
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 MogileFSTrackeremi 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 loadbalancer) 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
Baza danych
o plikach
Master + Slave
Klient wgrywa, listuje, usuwa pliki przez WebDAV
Mostek
węzły origin/storage
obsługiwane przez MogileFS
tackeryMogileFS
dbają o replikację plików
i udzielają informacji gdzie
są dane pliki
węzły edge
buforują pliki
edge pyta z którego
origina 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ż w wersji BETA
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 do
węzłów edge
odbiorcy pobierają sygnał z węzłów edge

To o czym powiedziałem :)
Infrastruktura na razie obsługuje ruch na poziomie 3.5 Gbit/s w tym 900Mbit/s do TPSA
prowadziliśmy testy obciążeniowe z zaprzyjaźnionych DataCenter
Co już działa?

… a co jeszcze nie?
Dużo do zrobienia (to dobrze)
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

http://wiki.simplestorage.pl	389
http://ideas2action.pl	381
http://ecommerce.inwestycje.pl	45
http://www.slideshare.net	16
http://market.grupadivante.pl	6
http://feeds.feedburner.com	4
http://facebook.slideshare.com	1
http://translate.googleusercontent.com	1

TV i video w Internecie

by Divante on May 12, 2010

Accessibility

Tags

Upload Details

Usage Rights

8 Embeds 843

Statistics

TV i video w Internecie — Presentation Transcript