TV i video w Internecie

3,057 views
2,957 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,057
On SlideShare
0
From Embeds
0
Number of Embeds
1,559
Actions
Shares
0
Downloads
10
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

TV i video w Internecie

  1. 1. TV i video w Internecie<br />Jak zrobiliśmy CDNaby hostować pliki wideo i transmisje live.<br />SimpleStorage to system dystrybucji treści (CDN) stworzony przez Divante i IMAGIN IT<br />
  2. 2. Plan prezentacji<br />Nasza motywacja<br />Trochę o tym co chcieliśmy osiągnąć<br />Jak to zrobiliśmy?<br />projekt i założenia<br />węzły edge i origin<br />redirector<br />modelowanie ruchu (mądrze brzmi  )<br />replikacja i zarządzanie plikami<br />statystyki<br />live-streaming<br />Co już działa, <br />… a co jeszcze nie i jakie są plany<br />
  3. 3. Nasza motywacja<br />Zrobiliśmy wcześniej darmowy videosteam.pl<br />i już wiedzieliśmy, że wideo w Internecie nie jest takie proste <br />Stanęliśmy przed szansą zrobienia dużego portalu wideo - TiVi.pl<br />Chcieliśmy, po ludzku, zrobić coś ciekawego<br />
  4. 4. Co chcieliśmy osiągnąć<br />Sieć dystrybucji (edge) i storage (origin) w oparciu o zwykłe PCty – jeśli się da - zachowanie niskich cen dla klientów<br />Skuteczne rozdzielanie ruchu, dopasowywanie trasy do sieci klienta – na ile się da<br />+ wykorzystanie wielu datacenter<br />Replikację danych zamiast backupów<br />+ automatyczne wyłączanie zepsutych serwerów i zastępowanie ich nowymi<br />Obsługę nie tylko plików statycznych ale też transmisji na żywo<br />Chcieliśmy, żeby usługa była zgodna ze standardami (np. HTTP, WebDAV, RTMP …) – dzięki czemu łatwiejsza w wykorzystaniu<br />Dlaczego zwykłe PCty? http://www.manageability.org/blog/stuff/economics-google-hardware-infrastructure<br />
  5. 5. Gdzie się tylko da zapewnić redundancję<br />Użyć sprawdzonego oprogramowania i je ew. przerobić/dostosować<br />Varnish, nginx, Apache, MogileFS<br />Dopisać tylko brakujące komponenty <br />im więcej kodu, tym więcej błędów <br />redirector, zarządzanie plikami (WebDAV), statystyki, bilingowanie<br />Java, Python + WSGI - dopiero gdy będzie trzeba kluczowe elementy przepisać w C<br />Założenia<br />
  6. 6. Projekt<br />
  7. 7. Węzły edge i origin<br />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<br />Węzły edge działają jako proxy korzystając z przerobionego varnisha i nginxa pobierając dane z originów<br />potrzebny był soft który przekieruje użytkownika na działający i nieprzeciążony węzeł<br />Na originach stosujemy nginxa i MogileFS który replikuje dane automatycznie odnawia kopie – i robi dużo dobrej roboty, <br />potrzebny był soft do zarządzania plikami dla użytkownika<br />Początkowo węzły edge i origin to mogą być te same maszyny<br />
  8. 8. Redirector<br />Przyjmuje wszystkie żądania odczytu (pliki i live) na tzw. „klatę” ;)<br />przekierowania HTTP – szybsza aktualizacja niż DNS, prostsze niż BGP – przy live specjalna obsługa w playerze<br />Ma wiedzę o stanie węzłów edge – stan, obciążenie, limit transferu, obciążenie łącza, load systemu i ich umiejscowieniu (datacenter/ASN/sieć)<br />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<br />na tej podstawie może wybrać najkorzystniejszy względem klienta serwer i tam przekierować jego zapytania<br />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<br />
  9. 9. Modelowanie ruchu<br />Redirect HTTP 301<br />Główne zadanie redirectora<br />Dla każdego żądania<br />bierze adres klienta i sprawdza z której sieci jest klient<br />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<br />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<br />wybiera grupę serwerów obsługujących dane żądanie (livestreaming, pseudo-streaming, pliki statyczne/buforowane wideo)<br />wybiera najmniej obciążony serwer z tej grupy (losowo z wagami) i podaje go klientowi + keszuje na kilkadziesiąt sekund<br />GET /V/plik.flv<br />Mój IP: 91.94.61.248<br />GET /V/plik.flv<br />W=1.4<br />W=0.9<br />W=0.2<br />DC1<br />DC1<br />DC2<br />
  10. 10. Replikacja i zarządzanie<br />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<br />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)<br />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)<br />Mostek działa na dwóch serwerach (+ sprzętowy loadbalancer) i bazy MySQL (master + kilka slave)<br />Mostek oprócz redirectora jest kluczowym elementem, testujemy go automatycznie skryptami wykonującymi podstawowe operacje przez curla zaraz po deployu (przez SVNa)<br />
  11. 11. Replikacja i zarządzanie<br />Baza danych <br />o plikach<br />Master + Slave<br />Klient wgrywa, listuje, usuwa pliki przez WebDAV<br />Mostek<br />węzły origin/storage<br />obsługiwane przez MogileFS<br />tackeryMogileFS<br />dbają o replikację plików<br />i udzielają informacji gdzie <br />są dane pliki<br />węzły edge<br />buforują pliki<br />edge pyta z którego<br />origina ma pobrać plik<br />
  12. 12. Statystyki<br />Logów jest bardzo dużo (na razie po ok. 50req/s na serwer – wszystko idzie do access logów) – prosty map/reduce<br />Zbieramy statystyki z serwerów brzegowych i mostka – zużycie dla klienta (transfer, storage, hity), zużycie streamów (ilość emisji, ilość klientów)<br />Musieliśmy napisać kilka programików:<br />Statystyki są wstępnie przetwarzane przez logalyzer(przy rotowaniu logów)i w formacie CSV wgrywane na SimpleStorage<br />logcollector ściąga paczki z logami i wrzuca hurtem do bazy,<br />statscalc agreguje dane w podsumy, niezagregowane dane usuwamy po czasie,<br />W efekcie - na stronie użytkownik widzi zmiany w statystykach z dokładnością do godziny<br />
  13. 13. Livestreaming<br />Działa już w wersji BETA<br />Zgodny z RTMP/RTMPT/RTMPE– gotowy serwer w Javie ze zmianami (statystyki) zainstalowany na wszystkich węzłach <br />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)<br />Dodaliśmy autoryzację nadawców (tokeny – obsługiwane przez Mostek)<br />… oraz oglądających (tokeny – mogą być obsługiwane indywidualnie przez webservice’y danych usług – np. VoD)<br />Redirector obsługuje przekierowania do streamingu (wsparcie w playerze było konieczne) – RTMP nie obsługuje przekierowań<br />Dobrze byłoby opakowywać też w HTTP – działa wtedy m.in. buforowanie, nie ma problemów z firewallami<br />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<br />
  14. 14. Livestreaming<br />klient z encoderem – np. FMLE <br />nadaje strumienie do primary i backup<br />węzły odbierają sygnał od <br />nadawcy i publikują go do<br />węzłów edge<br />odbiorcy pobierają sygnał z węzłów edge<br />
  15. 15. To o czym powiedziałem :)<br />Infrastruktura na razie obsługuje ruch na poziomie 3.5 Gbit/s w tym 900Mbit/s do TPSA <br />prowadziliśmy testy obciążeniowe z zaprzyjaźnionych DataCenter<br />Co już działa?<br />
  16. 16. … a co jeszcze nie?<br />Dużo do zrobienia (to dobrze)<br />uprawnienia do plików<br />optymalizacja i usprawnienie algorytmu modelowania ruchu<br />streaming przez HTTP i smooth-streaming<br />streaming na iphone’a<br />wstawienie kolejnych węzłów – m.in. do PL-IX<br />rozbudowa i przyspieszenie statystyk<br />…<br />
  17. 17. Dziękuję za uwagę!<br />Pytania?<br />pkarwatka@divante.pl<br />Wersja testowa SimpleStorage: http://simplestorage.pl<br />

×