Wprowadziliśmy nowe usługi, ruch wzrastał, wymienialiśmy serwery, podłączaliśmy nowe platformy i przebudowywaliśmy centra danych – teraz opowiemy tę historię, z którą zapoznawaliśmy Was pięć lat temu..
Pięć lat to typowy czas na podsumowanie osiągnięć. Dlatego postanowiliśmy opowiedzieć o rozwoju naszej infrastruktury, która w ciągu pięciu lat przeszła niezwykle interesującą drogę, z której jesteśmy dumni. Wprowadzone przez nas ilościowe zmiany przerodziły się w jakościowe, a teraz infrastruktura może pracować w trybach, które w połowie minionej dekady wydawały się fantastyką.
Zajmujemy się obsługą złożonych projektów z ekstremalnymi wymaganiami co do niezawodności i obciążeń, wśród których znajdują się PREMIER i Match TV. Przy transmisjach sportowych i premierach popularnych seriali wymagane jest wydawanie ruchu w terabitach/s, co realizujemy z łatwością, a tak często, że praca z takimi prędkościami stała się dla nas rutyną. A pięć lat temu najcięższym projektem działającym na naszych systemach był Rutube, który od tego czasu rozwijał się, zwiększał objętość i ruch, co musieliśmy uwzględnić przy planowaniu obciążeń.
Mówiliśmy o tym, jak rozwijaliśmy "sprzęt" naszej infrastruktury () i rozwijaliśmy system odpowiedzialny za dostarczanie wideo (), ale od momentu napisania tych tekstów minęło wiele czasu, stworzono i wdrożono wiele innych rozwiązań, których efekty pozwalają nam spełniać współczesne wymagania i być wystarczająco elastycznymi, aby przeorganizowywać się na nowe zadania.
Jądro sieciowe nawet wciąż się rozwija. Przeszliśmy na sprzęt Cisco w 2015 roku, o czym wspominaliśmy jeszcze w poprzednim artykule. Wtedy były to te same 10/40G, ale z oczywistego powodu już po kilku latach zmodernizowaliśmy istniejące chasis, i teraz aktywnie wykorzystujemy również 25/100G.
Połączenia 100G od dawna nie są ani luksusem (raczej to pilna potrzeba czasów w naszej branży), ani rzadkością (coraz więcej operatorów oferuje takie prędkości). Jednak 10/40G nadal ma swoje miejsce: przez te połączenia wciąż łączymy operatorów z niewielkim ruchem, dla których obecnie nie jest opłacalne wykorzystanie portów o większej przepustowości.
Stworzone przez nas rdzenie sieciowe zasługują na osobne omówienie i wkrótce staną się tematem osobnego artykułu. Tam zagłębimy się w szczegóły techniczne i omówimy logikę naszych działań przy ich tworzeniu. Ale teraz kontynuujemy rysowanie infrastruktury bardziej schematycznie, ponieważ Państwa uwaga, drodzy czytelnicy, nie jest nieskończona.
Serwery do odtwarzania wideo ewoluują szybko, dlatego wkładamy wiele wysiłku w rozwój. Jeśli wcześniej korzystaliśmy głównie z serwerów 2U z 4-5 kartami sieciowymi z dwoma portami 10G każda, to teraz większość ruchu jest realizowana z serwerów 1U, w których znajduje się 2-3 karty z dwoma portami 25G każda. Ceny kart 10G i 25G praktycznie się zrównały, a szybsze rozwiązania pozwalają przekazywać dane zarówno przez 10G, jak i 25G. Rezultatem jest очевидna oszczędność: mniej komponentów serwera i kabli do podłączenia – niższe koszty (i większa niezawodność), komponenty zajmują mniej miejsca w szafie – dzięki czemu możliwe stało się umieszczenie większej liczby serwerów na tej samej powierzchni, a co za tym idzie, koszty wynajmu są niższe.
Ale ważniejszy jest zysk w prędkości! Teraz z serwera 1U możemy przekazywać ponad 100G! A to w sytuacji, gdy niektóre duże rosyjskie projekty nazywają «osiągnięciem» przekazanie 40G z 2U. Chcielibyśmy ich problemów!
Zauważmy, że generacja kart sieciowych, które mogą pracować tylko na 10G, wciąż jest przez nas używana. Ten sprzęt działa niezawodnie i jest nam dobrze znany, dlatego go nie wyrzuciliśmy, a znaleźliśmy dla niego nowe zastosowanie. Te komponenty zainstalowaliśmy w serwerach do przechowywania wideo, którym do efektywnej pracy zdecydowanie brakuje jednego lub dwóch interfejsów 1G, w tym przypadku karty 10G okazały się aktualne.
Systemy przechowywania danych także rosną. W minionej pięciolatce przeszły z dwunastodyskowych (12x HDD 2U) na trzydziestosześciodyskowe (36x HDD 4U). Tak pojemne „obudowy” niektórzy obawiają się używać, ponieważ w przypadku awarii jednego z takich szaf może pojawić się zagrożenie dla wydajności – a nawet funkcjonalności! – całego systemu. Ale u nas to się nie zdarzy: zapewniliśmy redundancję na poziomie geograficznie rozproszonych kopii danych. Rozmieściliśmy szafy w różnych centrach danych – korzystamy z trzech – co wyklucza powstawanie problemów zarówno podczas awarii szaf, jak i przy upadku lokalizacji.
Oczywiście, takie podejście uczyniło zbytecznym sprzętowy RAID, z którego zrezygnowaliśmy. Odrzucając redundancję, jednocześnie zwiększyliśmy niezawodność systemu, upraszczając rozwiązanie i eliminując jeden z potencjalnych punktów awarii. Przypomnijmy, że nasze storages są „samorobione”. Podjęliśmy tę decyzję całkowicie świadomie i efekt nas całkowicie zadowolił.
Centra danych w ciągu ostatnich pięciu lat zmienialiśmy kilka razy. Od momentu napisania poprzedniego artykułu nie zmienialiśmy tylko jednego centrum danych – DataLine – pozostałe wymagały wymiany w miarę rozwoju naszej infrastruktury. Wszystkie przeprowadzki między lokalizacjami były zaplanowane.
Dwa lata temu migrowaliśmy wewnątrz MMTS-9, przechodząc do lokalizacji z nową jakością remontu, dobrą systemem chłodzenia, stabilnym zasilaniem i bez kurzu, który wcześniej gromadził się grubymi warstwami na wszystkich powierzchniach, a także obficie zatykał wnętrza naszego sprzętu. Wybór na rzecz jakości usług – i braku kurzu! – był powodem naszej przeprowadzki.
Prawie zawsze „jedna przeprowadzka równa się dwóm pożarom”, ale problemy podczas migracji za każdym razem są inne. Tym razem główną trudnością przeprowadzki w ramach jednego centrum danych były optyczne złącza – ich międzykondygnacyjna obfitość bez zestawienia w jednolitą strukturę ze strony operatorów. Proces aktualizacji i przebudowy tych złączy (w czym pomogli nam inżynierowie MMTS-9) był chyba najtrudniejszym etapem migracji.
Druga migracja miała miejsce rok temu, w 2019 roku przenieśliśmy się z niezbyt dobrego centrum danych do O2xygen. Powody przeprowadzki były podobne do wcześniej omówionych, ale dołączył do nich problem z nieatrakcyjnością pierwotnego centrum danych dla operatorów – wielu dostawców musieliśmy 'doganiać' własnymi siłami do tego punktu.
Migracja 13 szafek do wysokiej jakości lokalizacji w MMTS-9 pozwoliła rozwijać tę lokalizację nie tylko jako operator (para-trzy szafek i 'przekazy' operatorów), ale również wykorzystać ją jako jedną z głównych. Umożliwiło to nieco uprościć migrację z niezbyt dobrego centrum danych – większość sprzętu stamtąd przenieśliśmy na inną lokalizację, a O2xygen odegrał rolę rozwijającego się, wysyłając tam 5 szafek z wyposażeniem.
Dziś O2xygen to już pełnoprawna lokalizacja, do której 'przybyli' niezbędni nam operatorzy i nadal dołączają nowi. Dla operatorów O2xygen również okazał się atrakcyjny pod kątem strategicznego rozwoju.
Główną fazę przeprowadzki obowiązkowo realizujemy w jedną noc, i podczas migracji wewnątrz MMTS-9 oraz do O2xygen trzymaliśmy się tej zasady. Podkreślamy, że zasada 'przeprowadzka w jedną noc' jest przez nas ściśle przestrzegana niezależnie od liczby szafek! Był nawet przypadek, kiedy przenieśliśmy 20 szafek i także zrealizowaliśmy to w jedną noc. Migracja to dość prosty proces, wymagający staranności i skuteczności, ale i tu są pewne sztuczki zarówno w procesie przygotowania, jak i podczas przeprowadzki, oraz przy uruchamianiu w nowej lokalizacji. O migracji w szczegółach jesteśmy gotowi opowiedzieć, jeśli będzie zainteresowanie.
Wyniki Piątki rozwoju nam się podobają. Zakończyliśmy budowę nowej infrastruktury odpornej na awarie, rozdzielonej na trzy centra przetwarzania danych. Znacznie zwiększyliśmy gęstość przekazywanego ruchu – jeśli niedawno cieszyliśmy się 40-80G z 2U, to teraz normą jest dla nas oddać 100G z 1U. Teraz i terabit ruchu postrzegamy jako codzienność. Jesteśmy gotowi dalej rozwijać naszą infrastrukturę, która okazała się elastyczna i skalowalna.
Pytanie: O czym opowiedzieć Wam w następnych tekstach, drodzy czytelnicy? O tym, dlaczego zaczęliśmy tworzyć własne systemy przechowywania danych? O rdzeniu sieciowym i jego cechach? O sztuczkach i niuansach migracji między centrami danych? O optymalizacji rozwiązań w zakresie wydajności poprzez dobór komponentów i precyzyjne dostosowanie parametrów? O tworzeniu odpornych rozwiązań dzięki wielokrotnemu zapasowaniu i horyzontalnym możliwością skalowania wewnątrz centrum danych, zrealizowanych w strukturze trzech centrów danych?
Autor: Piotr Winogradow — Dyrektor Techniczny Uma.Tech
Źródło: habr.com
