1. 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

2. 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

3. 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

4. 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

5. 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

6. Projekt

7. 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

8. 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

9. 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

10. 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)

11. 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

12. 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

13. 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

14. 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

15. 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 …

16. Dziękuję za uwagę! Pytania? pkarwatka@divante.pl Wersja testowa SimpleStorage: http://simplestorage.pl