Współczesna sieć jest prawie nie do pomyślenia bez treści medialnych: prawie każda babcia ma smartfon, wszyscy korzystają z sieci społecznościowych, a przestoje w utrzymaniu są kosztowne dla firm. Oto zapis historii firmy o tym, jak zorganizowała dostarczanie zdjęć za pomocą rozwiązania sprzętowego, jakie problemy wydajnościowe napotkała w procesie, co było ich przyczyną i jak te problemy rozwiązała za pomocą rozwiązania programowego opartego na Nginx, zapewniając jednocześnie odporność na awarie na wszystkich poziomach (). Dziękujemy autorom historii Olega Efimova i Alexandra Dymova, które podzieliły się swoimi doświadczeniami na konferencji .
— Zacznijmy od krótkiego wprowadzenia na temat przechowywania i buforowania zdjęć. Mamy warstwę, w której je przechowujemy, i warstwę, w której buforujemy zdjęcia. Jednocześnie, jeśli chcemy osiągnąć wysoki współczynnik trików i zmniejszyć obciążenie pamięci, ważne jest dla nas, aby każde zdjęcie indywidualnego użytkownika znajdowało się na jednym serwerze buforującym. W przeciwnym razie musielibyśmy zainstalować tyle razy więcej dysków, ile mamy serwerów. Nasz wskaźnik sztuczek wynosi około 99%, co oznacza, że zmniejszamy obciążenie naszej pamięci masowej 100 razy i aby tego dokonać 10 lat temu, kiedy to wszystko było budowane, mieliśmy 50 serwerów. W związku z tym, aby obsłużyć te zdjęcia, potrzebowaliśmy zasadniczo 50 domen zewnętrznych, które obsługują te serwery.
Naturalnie od razu pojawiło się pytanie: jeśli jeden z naszych serwerów ulegnie awarii i stanie się niedostępny, jaką część ruchu tracimy? Przyjrzeliśmy się temu, co było na rynku i zdecydowaliśmy się kupić sprzęt, który rozwiązałby wszystkie nasze problemy. Wybór padł na rozwiązanie firmy działającej w sieci F5 (która, nawiasem mówiąc, niedawno kupiła NGINX, Inc): BIG-IP Local Traffic Manager.
Co robi ten element sprzętu (LTM): jest to router Iron, który zapewnia redundancję Iron dla swoich portów zewnętrznych i umożliwia kierowanie ruchu w oparciu o topologię sieci, przy niektórych ustawieniach, a także przeprowadza kontrolę stanu. Ważne było dla nas, aby ten element sprzętu można było zaprogramować. W związku z tym moglibyśmy opisać logikę serwowania zdjęć konkretnego użytkownika z określonej pamięci podręcznej. Jak to wygląda? Istnieje sprzęt, który przegląda Internet w jednej domenie, jednym adresie IP, odciąża protokół SSL, analizuje żądania http, wybiera numer pamięci podręcznej z IRule, dokąd się udać i przepuszcza tam ruch. Jednocześnie sprawdza stan i w przypadku niedostępności jakiejś maszyny, zadbaliśmy o to, aby ruch trafiał na jeden serwer zapasowy. Z punktu widzenia konfiguracji istnieją oczywiście pewne niuanse, ale ogólnie wszystko jest dość proste: rejestrujemy kartę, korespondencję określonego numeru z naszym adresem IP w sieci, mówimy, że będziemy nasłuchiwać na portach 80 i 443, mówimy, że jeśli serwer jest niedostępny, to należy skierować ruch na serwer zapasowy, w tym przypadku 35-ty, i opisujemy całą logikę, w jaki sposób należy zdemontować tę architekturę. Jedynym problemem było to, że językiem, w którym zaprogramowano sprzęt, był Tcl. Jeśli ktoś to w ogóle pamięta... ten język jest bardziej przeznaczony tylko do zapisu niż język wygodny do programowania:
Co otrzymaliśmy? Otrzymaliśmy sprzęt, który zapewnia wysoką dostępność naszej infrastruktury, kieruje całym naszym ruchem, zapewnia korzyści zdrowotne i po prostu działa. Co więcej, działa dość długo: w ciągu ostatnich 10 lat nie było na niego żadnych skarg. Na początku 2018 roku wysyłaliśmy już około 80 tys. zdjęć na sekundę. To około 80 gigabitów ruchu z obu naszych centrów danych.
Jednakże…
Na początku 2018 roku na listach przebojów zaobserwowaliśmy brzydki obraz: czas przesyłania zdjęć wyraźnie się wydłużył. I przestało nam to odpowiadać. Problem w tym, że takie zachowanie było widoczne tylko w godzinach szczytu ruchu – dla naszej firmy jest to noc z niedzieli na poniedziałek. Ale przez resztę czasu system zachowywał się normalnie, bez oznak awarii.
Niemniej jednak problem trzeba było rozwiązać. Zidentyfikowaliśmy możliwe wąskie gardła i zaczęliśmy je eliminować. Przede wszystkim oczywiście rozbudowaliśmy uplinki zewnętrzne, przeprowadziliśmy pełny audyt uplinków wewnętrznych i znaleźliśmy wszystkie możliwe wąskie gardła. Ale to wszystko nie dało oczywistego rezultatu, problem nie zniknął.
Innym możliwym wąskim gardłem była wydajność samych pamięci podręcznych. I uznaliśmy, że być może problem leży po ich stronie. Cóż, rozszerzyliśmy wydajność - głównie porty sieciowe na pamięciach podręcznych. Ale znowu nie zaobserwowano wyraźnej poprawy. Ostatecznie zwróciliśmy szczególną uwagę na wydajność samego LTM i tutaj zobaczyliśmy smutny obraz na wykresach: obciążenie wszystkich procesorów zaczyna przebiegać płynnie, ale potem nagle dochodzi do plateau. Jednocześnie LTM przestaje odpowiednio reagować na kontrole stanu i łącza nadrzędne i zaczyna je losowo wyłączać, co prowadzi do poważnego spadku wydajności.
Oznacza to, że zidentyfikowaliśmy źródło problemu, zidentyfikowaliśmy wąskie gardło. Pozostaje zdecydować, co zrobimy.
Pierwszą, najbardziej oczywistą rzeczą, jaką moglibyśmy zrobić, byłoby unowocześnienie samego LTM. Ale są tu pewne niuanse, ponieważ ten sprzęt jest dość wyjątkowy, nie pójdziesz do najbliższego supermarketu i go nie kupisz. To osobna umowa, osobna umowa licencyjna i zajmie dużo czasu. Druga opcja to zacząć myśleć samodzielnie, wymyślić własne rozwiązanie wykorzystując własne komponenty, najlepiej korzystając z programu o otwartym dostępie. Pozostaje tylko zdecydować, co dokładnie w tym celu wybierzemy i ile czasu poświęcimy na rozwiązanie tego problemu, ponieważ użytkownicy otrzymywali za mało zdjęć. Dlatego musimy to wszystko zrobić bardzo, bardzo szybko, można by powiedzieć wczoraj.
Ponieważ zadanie brzmiało jak „zrobić coś tak szybko, jak to możliwe i wykorzystując sprzęt, który mamy”, pierwszą rzeczą, o której pomyśleliśmy, było po prostu usunięcie z przodu kilku niezbyt wydajnych maszyn i umieszczenie tam Nginx, za pomocą którego wiemy, jak to zrobić pracować i próbować wdrożyć całą tę samą logikę, co sprzęt. Czyli tak naprawdę zostawiliśmy nasz sprzęt, zainstalowaliśmy jeszcze 4 serwery, które musieliśmy skonfigurować, utworzyliśmy dla nich zewnętrzne domeny, podobnie jak to było 10 lat temu… Straciliśmy trochę dostępność, gdyby te maszyny upadły, ale co więcej, rozwiązali problem naszych użytkowników lokalnie.
W związku z tym logika pozostaje ta sama: instalujemy Nginx, może on odciążyć SSL, możemy w jakiś sposób zaprogramować logikę routingu, kontrolę stanu w konfiguracjach i po prostu powielić logikę, którą mieliśmy wcześniej.
Usiądźmy do napisania konfiguracji. Na początku wydawało się, że wszystko jest bardzo proste, ale niestety bardzo trudno jest znaleźć instrukcje do każdego zadania. Dlatego nie zalecamy po prostu googlowania „jak skonfigurować Nginx do zdjęć”: lepiej zapoznać się z oficjalną dokumentacją, która pokaże, których ustawień należy dotknąć. Ale lepiej samemu wybrać konkretny parametr. No cóż, wtedy wszystko jest proste: opisujemy serwery, które posiadamy, opisujemy certyfikaty... Ale tak naprawdę najciekawsza jest sama logika routingu.
Na początku wydawało nam się, że po prostu opisujemy naszą lokalizację, dopasowując do niej numer naszej pamięci podręcznej zdjęć, za pomocą rąk lub generatora, aby opisać, ile upstreamów potrzebujemy, w każdym upstream wskazujemy serwer, do którego ma być kierowany ruch go i serwer zapasowy - jeśli serwer główny nie jest dostępny:
Ale prawdopodobnie, gdyby wszystko było takie proste, po prostu wrócilibyśmy do domu i nic nie powiedzieli. Niestety, przy domyślnych ustawieniach Nginx, które generalnie były tworzone przez wiele lat rozwoju i nie do końca nadają się do tego przypadku... konfiguracja wygląda następująco: jeśli jakiś serwer nadrzędny ma błąd żądania lub przekroczono limit czasu, Nginx zawsze przełącza ruch na następny. Co więcej, po pierwszej awarii w ciągu 10 sekund serwer również zostanie wyłączony, zarówno przez pomyłkę, jak i przez przekroczenie limitu czasu - tego nawet nie da się w żaden sposób skonfigurować. Oznacza to, że jeśli usuniemy lub zresetujemy opcję limitu czasu w dyrektywie upstream, to chociaż Nginx nie przetworzy tego żądania i odpowie jakimś niezbyt dobrym błędem, serwer się wyłączy.
Aby tego uniknąć, zrobiliśmy dwie rzeczy:
a) zabronili Nginxowi robienia tego ręcznie - i niestety jedynym sposobem, aby to zrobić, jest po prostu ustawienie maksymalnych ustawień niepowodzeń.
b) przypomnieliśmy sobie, że w innych projektach używamy modułu, który pozwala nam na sprawdzanie stanu zdrowia w tle - w związku z tym przeprowadzaliśmy dość częste kontrole stanu, aby przestoje w razie wypadku były minimalne.
Niestety to też nie wszystko, bo dosłownie pierwsze dwa tygodnie działania tego schematu pokazały, że sprawdzanie kondycji TCP też jest rzeczą zawodną: na serwerze nadrzędnym może to nie być Nginx, lub Nginx w stanie D, a w w tym przypadku jądro zaakceptuje połączenie, kontrola stanu przejdzie pomyślnie, ale nie będzie działać. Dlatego natychmiast zastąpiliśmy to http sprawdzającym stan zdrowia, zrobiliśmy konkretny, który jeśli zwróci 200, to wszystko działa w tym skrypcie. Możesz zastosować dodatkową logikę - np. w przypadku serwerów buforujących sprawdź czy system plików jest poprawnie zamontowany:
I to by nam odpowiadało, z tym wyjątkiem, że w tej chwili obwód całkowicie powtórzył to, co zrobił sprzęt. Chcieliśmy jednak wypaść lepiej. Wcześniej mieliśmy jeden serwer zapasowy i to chyba nie jest zbyt dobre rozwiązanie, bo jeśli mamy sto serwerów, to gdy kilka na raz ulegnie awarii, to jeden serwer zapasowy raczej nie poradzi sobie z obciążeniem. Dlatego zdecydowaliśmy się rozdzielić rezerwację na wszystkie serwery: po prostu stworzyliśmy kolejny oddzielny serwer nadrzędny, zapisaliśmy tam wszystkie serwery z określonymi parametrami zgodnie z obciążeniem, jakie mogą obsłużyć, dodaliśmy te same kontrole stanu, które mieliśmy wcześniej:
Ponieważ nie da się przejść do innego upstream w obrębie jednego upstream, konieczne było upewnienie się, że jeśli główny upstream, w którym po prostu zapisaliśmy poprawną, niezbędną pamięć podręczną zdjęć, był niedostępny, po prostu przeszliśmy przez stronę błędów do powrotu, z gdzie udaliśmy się do kopii zapasowej powyżej:
I dosłownie dodając cztery serwery otrzymaliśmy to: zastąpiliśmy część obciążenia - usunęliśmy je z LTM na te serwery, zaimplementowaliśmy tam tę samą logikę, używając standardowego sprzętu i oprogramowania, i od razu otrzymaliśmy premię, jaką te serwery mogą być skalowane, ponieważ można je po prostu dostarczyć w takiej ilości, w jakiej jest to potrzebne. Cóż, jedynym minusem jest to, że straciliśmy wysoką dostępność dla użytkowników zewnętrznych. Ale w tym momencie musieliśmy to poświęcić, ponieważ konieczne było natychmiastowe rozwiązanie problemu. Usunęliśmy więc część obciążenia, było to wtedy około 40%, LTM działało dobrze i dosłownie dwa tygodnie po rozpoczęciu problemu zaczęliśmy wysyłać nie 45 tys. żądań na sekundę, a 55 tys. Tak naprawdę urosliśmy o 20% – jest to ewidentnie ruch, którego nie daliśmy użytkownikowi. A potem zaczęli myśleć o tym, jak rozwiązać pozostały problem - zapewnić wysoką dostępność zewnętrzną.
Mieliśmy chwilę przerwy, podczas której zastanawialiśmy się, jakie rozwiązanie w tym celu zastosujemy. Pojawiły się propozycje zapewnienia niezawodności przy użyciu DNS, za pomocą domowych skryptów, protokołów routingu dynamicznego… Opcji było wiele, ale już stało się jasne, że aby naprawdę niezawodne dostarczanie zdjęć trzeba wprowadzić kolejną warstwę, która będzie to monitorować. Nazwaliśmy te maszyny fotoreżyserami. Oprogramowanie, na którym polegaliśmy, to Keepalive:
Zacznijmy od tego, z czego składa się Keepalive? Pierwszym z nich jest powszechnie znany networkerom protokół VRRP, umiejscowiony na sprzęcie sieciowym, który zapewnia odporność na awarie zewnętrznego adresu IP, z którym łączą się klienci. Druga część to IPVS, wirtualny serwer IP, służący do równoważenia routerów fotograficznych i zapewnienia odporności na awarie na tym poziomie. I po trzecie – kontrole stanu zdrowia.
Zacznijmy od części pierwszej: VRRP – jak to wygląda? Istnieje pewien wirtualny adres IP, który ma wpis w dns badoocdn.com, gdzie łączą się klienci. W pewnym momencie mamy adres IP na jednym serwerze. Pakiety Keepalive biegają pomiędzy serwerami przy użyciu protokołu VRRP i jeśli master zniknie z radaru – serwer się zrestartował lub coś innego, to serwer zapasowy automatycznie przejmie ten adres IP – nie są wymagane żadne ręczne działania. Różnica między masterem a kopią zapasową to przede wszystkim priorytet: im wyższy, tym większa szansa, że maszyna stanie się masterem. Bardzo dużą zaletą jest to, że nie trzeba konfigurować adresów IP na samym serwerze, wystarczy je opisać w konfiguracji, a jeśli adresy IP wymagają jakichś niestandardowych reguł routingu, jest to opisane bezpośrednio w konfiguracji za pomocą opcji taka sama składnia jak opisana w pakiecie VRRP. Nie spotkasz żadnych nieznanych rzeczy.
Jak to wygląda w praktyce? Co się stanie, jeśli jeden z serwerów ulegnie awarii? Gdy tylko master zniknie, nasza kopia zapasowa przestanie otrzymywać reklamy i automatycznie stanie się masterem. Po pewnym czasie naprawiliśmy master, zrestartowaliśmy, podnieśliśmy Keepalive - reklamy przychodzą z wyższym priorytetem niż kopia zapasowa, a kopia zapasowa automatycznie się przywraca, usuwa adresy IP, nie trzeba wykonywać żadnych ręcznych działań.
W ten sposób zapewniliśmy odporność zewnętrznego adresu IP na błędy. Następną częścią jest w jakiś sposób zrównoważenie ruchu z zewnętrznego adresu IP do routerów fotograficznych, które już go kończą. Wszystko jest całkiem jasne dzięki protokołom równoważącym. Jest to albo proste działanie okrężne, albo nieco bardziej złożone rzeczy, wrr, połączenie z listą i tak dalej. Zasadniczo jest to opisane w dokumentacji, nie ma w tym nic specjalnego. Ale sposób dostawy... Tutaj przyjrzymy się bliżej, dlaczego wybraliśmy jedną z nich. Są to NAT, routing bezpośredni i TUN. Faktem jest, że od razu planowaliśmy dostarczyć 100 gigabitów ruchu z witryn. Jeśli szacujesz, potrzebujesz 10 kart gigabitowych, prawda? 10 kart gigabitowych w jednym serwerze już wykracza poza zakres przynajmniej naszej koncepcji „wyposażenia standardowego”. I wtedy przypomnieliśmy sobie, że nie dajemy tylko ruchu, rozdajemy zdjęcia.
Co jest specjalnego? — Ogromna różnica pomiędzy ruchem przychodzącym i wychodzącym. Ruch przychodzący jest bardzo mały, ruch wychodzący jest bardzo duży:
Jeśli spojrzysz na te wykresy, zobaczysz, że w tej chwili reżyser otrzymuje około 200 MB na sekundę, jest to bardzo zwyczajny dzień. Oddajemy 4,500 MB na sekundę, nasz stosunek wynosi około 1/22. Wiadomo już, że aby w pełni zapewnić ruch wychodzący na 22 serwery robocze, potrzebny jest nam tylko taki, który akceptuje to połączenie. Tutaj z pomocą przychodzi nam algorytm bezpośredniego routingu.
Jak to wygląda? Nasz fotoreżyser, według swojej tabeli, przekazuje połączenia do routerów fotograficznych. Ale routery fotograficzne wysyłają ruch zwrotny bezpośrednio do Internetu, wysyłają go do klienta, nie wraca on przez fotoreżyser, dlatego przy minimalnej liczbie maszyn zapewniamy pełną tolerancję na awarie i pompowanie całego ruchu. W konfiguracjach wygląda to tak: podajemy algorytm, w naszym przypadku jest to prosty rr, podajemy metodę bezpośredniego routingu i następnie zaczynamy wypisywać wszystkie rzeczywiste serwery, ile ich mamy. Które określą ten ruch. Jeśli mamy tam jeden, dwa serwery więcej, lub kilka serwerów, pojawia się taka potrzeba - po prostu dodajemy tę sekcję do konfiguracji i nie przejmujemy się zbytnio. Od strony prawdziwych serwerów, od strony fotoroutera ta metoda wymaga jak najmniejszej konfiguracji, jest doskonale opisana w dokumentacji i nie ma w niej żadnych pułapek.
Co szczególnie miłe, takie rozwiązanie nie oznacza radykalnej przebudowy sieci lokalnej, było to dla nas ważne, musieliśmy to rozwiązać minimalnymi kosztami. Jeśli spojrzysz , wtedy zobaczymy jak to będzie wyglądać. Tutaj mamy pewien serwer wirtualny, na porcie 443, nasłuchuje, akceptuje połączenie, wszystkie działające serwery są wymienione i widać, że połączenie jest, dawaj lub bierz, takie samo. Jeśli spojrzymy na statystyki tego samego serwera wirtualnego, mamy przychodzące pakiety, połączenia przychodzące, ale absolutnie żadnych wychodzących. Połączenia wychodzące trafiają bezpośrednio do klienta. OK, udało nam się to wyrównoważyć. A co się stanie, jeśli jeden z naszych routerów fotograficznych ulegnie awarii? W końcu żelazo to żelazo. Może wpaść w panikę jądra, może się zepsuć, może przepalić się zasilacz. Wszystko. Dlatego potrzebne są kontrole stanu zdrowia. Mogą one być tak proste, jak sprawdzenie, jak port jest otwarty, lub coś bardziej złożonego, aż po domowe skrypty, które sprawdzą nawet logikę biznesową.
Zatrzymaliśmy się gdzieś pośrodku: mamy żądanie https do konkretnej lokalizacji, skrypt zostaje wywołany, jeśli odpowie 200-tą odpowiedzią, wierzymy, że z tym serwerem wszystko jest w porządku, że żyje i da się całkiem włączyć łatwo.
Jak to znowu wygląda w praktyce? Wyłączmy serwer w celu konserwacji - na przykład flashowania BIOS-u. W logach od razu mamy timeout, widzimy pierwszą linijkę, po czym po trzech próbach zostaje ona oznaczona jako „nieudana” i po prostu zostaje usunięta z listy.
Możliwa jest również druga opcja zachowania, gdy VS jest po prostu ustawione na zero, ale jeśli zdjęcie zostanie zwrócone, nie działa to dobrze. Pojawia się serwer, uruchamia się tam Nginx, kontrola stanu natychmiast rozumie, że połączenie działa, że wszystko jest w porządku, a serwer pojawia się na naszej liście i natychmiast zaczyna się do niego przykładać obciążenie. Ze strony administratora dyżurnego nie są wymagane żadne ręczne działania. Serwer restartował się w nocy - dział monitoringu nie dzwoni do nas w tej sprawie w nocy. Informują, że tak się stało, wszystko jest w porządku.
Zatem w dość prosty sposób, przy pomocy niewielkiej liczby serwerów, rozwiązaliśmy problem odporności na uszkodzenia zewnętrzne.
Pozostaje tylko powiedzieć, że należy to wszystko oczywiście monitorować. Osobno należy zauważyć, że Keepalivede, jako oprogramowanie napisane dawno temu, ma wiele sposobów monitorowania, zarówno przy użyciu kontroli poprzez DBus, SMTP, SNMP, jak i standardowy Zabbix. Poza tym on sam wie, jak pisać listy na prawie każde kichnięcie i szczerze mówiąc, w pewnym momencie nawet pomyśleliśmy, żeby to wyłączyć, bo pisze mnóstwo listów za włączenie dowolnego ruchu, włączenie, dla każdego połączenia IP, i tak dalej . Oczywiście, jeśli jest dużo serwerów, możesz przytłoczyć się tymi literami. Monitorujemy nginx na routerach fotograficznych standardowymi metodami, a monitorowanie sprzętu nie zniknęło. Oczywiście radzilibyśmy jeszcze dwie rzeczy: po pierwsze, zewnętrzne kontrole stanu i dostępność, ponieważ nawet jeśli wszystko działa, w rzeczywistości być może użytkownicy nie otrzymują zdjęć z powodu problemów z zewnętrznymi dostawcami lub z czegoś bardziej złożonego. Zawsze warto mieć gdzieś w innej sieci, w Amazonie czy gdzie indziej, oddzielną maszynę, która może pingować Twoje serwery z zewnątrz, warto też skorzystać albo z wykrywania anomalii, dla tych, którzy wiedzą, jak wykonać skomplikowane uczenie maszynowe, albo z prostego monitorowania przynajmniej w celu sprawdzenia, czy liczba wniosków gwałtownie spadła, czy też przeciwnie, wzrosła. Może się również przydać.
Podsumujmy: tak naprawdę zastąpiliśmy żelazne rozwiązanie, które w pewnym momencie przestało nam odpowiadać, dość prostym systemem, który robi wszystko tak samo, czyli zapewnia zakończenie ruchu HTTPS i dalsze inteligentne routing za pomocą niezbędne badania stanu zdrowia. Zwiększyliśmy stabilność tego systemu, czyli nadal mamy wysoką dostępność dla każdej warstwy, a dodatkowo mamy ten bonus, że dość łatwo jest to wszystko skalować na każdej warstwie, ponieważ jest to standardowy sprzęt ze standardowym oprogramowaniem, czyli , uprościliśmy diagnozowanie ewentualnych problemów.
Z czym skończyliśmy? Mieliśmy problem podczas styczniowych wakacji 2018 roku. W ciągu pierwszych sześciu miesięcy od uruchomienia tego schematu rozszerzyliśmy go na cały ruch, aby usunąć cały ruch z LTM, zwiększyliśmy ruch tylko w jednym centrum danych z 40 gigabitów do 60 gigabitów i jednocześnie dla przez cały 2018 rok mogliśmy przesyłać niemal trzykrotnie więcej zdjęć na sekundę.
Źródło: www.habr.com