{"id":52389,"date":"2019-11-07T00:00:00","date_gmt":"2019-11-06T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/kak-realizuetsya-otkazoustojchivaya-veb-arhitektura-v-platforme-mail-ru-cloud-solutions"},"modified":"2020-02-18T14:00:05","modified_gmt":"2020-02-18T11:00:05","slug":"kak-realizuetsya-otkazoustojchivaya-veb-arhitektura-v-platforme-mail-ru-cloud-solutions","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/kak-realizuetsya-otkazoustojchivaya-veb-arhitektura-v-platforme-mail-ru-cloud-solutions","title":{"rendered":"Jak wdra\u017cana jest architektura odporna na awarie w platformie Mail.ru Cloud Solutions.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Jak
\n
\nCze\u015b\u0107, Habr! Jestem Artem Karamyszev, kierownik zespo\u0142u administracji systemowej. Rozwi\u0105zania chmurowe Mail.Ru (MCS)<\/a><\/noindex>. W ci\u0105gu ostatniego roku mieli\u015bmy wiele premier nowych produkt\u00f3w. Chcieli\u015bmy, aby us\u0142ugi API by\u0142y \u0142atwo skalowalne, odporne na awarie i gotowe na szybki wzrost obci\u0105\u017cenia u\u017cytkownik\u00f3w. Nasza platforma jest zrealizowana na OpenStack, a ja chcia\u0142bym opowiedzie\u0107, jakie problemy z odporno\u015bci\u0105 komponent\u00f3w musieli\u015bmy rozwi\u0105za\u0107, aby uzyska\u0107 system odporny na awarie. My\u015bl\u0119, \u017ce b\u0119dzie to interesuj\u0105ce dla tych, kt\u00f3rzy r\u00f3wnie\u017c rozwijaj\u0105 produkty na OpenStack.<\/p>\n

Og\u00f3lna odporno\u015b\u0107 platformy sk\u0142ada si\u0119 z odporno\u015bci jej komponent\u00f3w. Przeto stopniowo przejdziemy przez wszystkie poziomy, na kt\u00f3rych zidentyfikowali\u015bmy ryzyka i je wyeliminowali\u015bmy.<\/p>\n

Wersj\u0119 wideo tej historii, kt\u00f3rej \u017ar\u00f3d\u0142em by\u0142a prezentacja na konferencji Uptime Day 4, zorganizowanej przez ITSumma<\/a><\/noindex>, mo\u017cna obejrze\u0107 na kanale YouTube Uptime Community.<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Odporno\u015b\u0107 architektury fizycznej<\/h2>\n

\nPubliczna cz\u0119\u015b\u0107 chmury MCS obecnie bazuje w dw\u00f3ch centrach danych poziomu Tier III, mi\u0119dzy nimi znajduje si\u0119 w\u0142asne w\u0142\u00f3kno ciemne, zarezerwowane na poziomie fizycznym r\u00f3\u017cnymi trasami, o przepustowo\u015bci 200 Gbit\/s. Poziom Tier III zapewnia wymagany poziom odporno\u015bci fizycznej infrastruktury. <\/p>\n

W\u0142\u00f3kno ciemne zosta\u0142o zarezerwowane zar\u00f3wno na poziomie fizycznym, jak i logicznym. Proces rezerwacji kana\u0142\u00f3w by\u0142 iteracyjny, pojawi\u0142y si\u0119 problemy i ci\u0105gle doskonalimy \u0142\u0105czno\u015b\u0107 mi\u0119dzy centrami danych. <\/p>\n

Na przyk\u0142ad, niedawno podczas prac w studzience obok jednego z centr\u00f3w danych, koparka przebi\u0142a rur\u0119, a wewn\u0105trz tej rury znajdowa\u0142y si\u0119 zar\u00f3wno g\u0142\u00f3wny, jak i zapasowy kabel optyczny. Nasz odporny na awarie kana\u0142 komunikacji z centrum danych okaza\u0142 si\u0119 wra\u017cliwy w jednym punkcie, w studzience. W zwi\u0105zku z tym stracili\u015bmy cz\u0119\u015b\u0107 infrastruktury. Wyci\u0105gn\u0119li\u015bmy wnioski, podj\u0119li\u015bmy szereg dzia\u0142a\u0144, w tym po\u0142o\u017cyli\u015bmy dodatkow\u0105 optyk\u0119 w s\u0105siedniej studzience.<\/p><\/blockquote>\n

\nW centrach danych znajduj\u0105 si\u0119 punkty obecno\u015bci dostawc\u00f3w \u0142\u0105czno\u015bci, do kt\u00f3rych przesy\u0142amy nasze prefiksy za po\u015brednictwem BGP. Dla ka\u017cdego kierunku sieci wybierana jest najlepsza metryka, co pozwala zapewni\u0107 r\u00f3\u017cnym klientom najwy\u017csz\u0105 jako\u015b\u0107 po\u0142\u0105czenia. Je\u015bli po\u0142\u0105czenie przez jednego dostawc\u0119 zostaje przerwane, dostosowujemy nasz\u0105 tras\u0119 przez dost\u0119pnych dostawc\u00f3w.<\/p>\n

W przypadku awarii dostawcy automatycznie prze\u0142\u0105czamy si\u0119 na nast\u0119pnego. W przypadku awarii jednego z centr\u00f3w danych posiadamy lustrzan\u0105 kopi\u0119 naszych us\u0142ug w drugim centrum, kt\u00f3re przejmuje ca\u0142y ruch.<\/p>\n

\"Jak
\nOdporno\u015b\u0107 infrastruktury fizycznej<\/i><\/p>\n

Czego u\u017cywamy do zapewnienia odporno\u015bci na poziomie aplikacji<\/h2>\n

\nNasz serwis oparty jest na szeregu komponent\u00f3w open source. <\/p>\n

ExaBGP<\/b> \u2014 serwis, kt\u00f3ry realizuje szereg funkcji z u\u017cyciem protoko\u0142u dynamicznego routingu opartego na BGP. Aktywnie go wykorzystujemy do og\u0142aszania naszych publicznych adres\u00f3w IP, przez kt\u00f3re u\u017cytkownicy uzyskuj\u0105 dost\u0119p do API.<\/p>\n

HAProxy<\/b> \u2014 wysokoobci\u0105\u017cony balancer, kt\u00f3ry umo\u017cliwia ustawianie bardzo elastycznych regu\u0142 balansowania ruchu na r\u00f3\u017cnych poziomach modelu OSI. U\u017cywamy go do balansowania przed wszystkimi naszymi us\u0142ugami: bazami danych, brokerami wiadomo\u015bci, us\u0142ugami API, us\u0142ugami webowymi, naszymi projektami wewn\u0119trznymi \u2014 wszystko to jest obs\u0142ugiwane przez HAProxy.<\/p>\n

API application<\/b> \u2014 aplikacja webowa napisana w Pythonie, za pomoc\u0105 kt\u00f3rej u\u017cytkownik zarz\u0105dza swoj\u0105 infrastruktur\u0105 i swoimi us\u0142ugami.<\/p>\n

Worker application <\/b>(dalej po prostu worker) \u2014 w us\u0142ugach OpenStack to demon infrastrukturalny, kt\u00f3ry pozwala na przesy\u0142anie polece\u0144 API do infrastruktury. Na przyk\u0142ad, tworzenie dysku odbywa si\u0119 w\u0142a\u015bnie w workerze, a zapytanie o utworzenie \u2014 w aplikacji API. <\/p>\n

Standardowa architektura OpenStack Application<\/h2>\n

\nWi\u0119kszo\u015b\u0107 us\u0142ug opracowywanych dla OpenStack stara si\u0119 pod\u0105\u017ca\u0107 jednolit\u0105 paradygmat\u0105. Us\u0142uga zwykle sk\u0142ada si\u0119 z dw\u00f3ch cz\u0119\u015bci: API i worker\u00f3w (wykonawc\u00f3w backendu). Zazwyczaj API to aplikacja WSGI napisana w Pythonie, kt\u00f3ra dzia\u0142a jako niezale\u017cny proces (daemon) lub za pomoc\u0105 gotowego serwera webowego Nginx, Apache. API przetwarza zapytanie u\u017cytkownika i przekazuje dalsze instrukcje do realizacji aplikacji worker. Przekazanie odbywa si\u0119 za po\u015brednictwem brokera wiadomo\u015bci, kt\u00f3rym zazwyczaj jest RabbitMQ, inne s\u0105 s\u0142abo wspierane. Gdy wiadomo\u015bci trafiaj\u0105 do brokera, s\u0105 przetwarzane przez worker\u00f3w i w razie potrzeby zwracaj\u0105 odpowied\u017a. <\/p>\n

Ten paradygmat zak\u0142ada izolowane wsp\u00f3lne punkty awarii: RabbitMQ i baz\u0119 danych. Jednak RabbitMQ jest izolowany w ramach jednej us\u0142ugi i w teorii mo\u017ce by\u0107 indywidualny dla ka\u017cdej us\u0142ugi. Dlatego w MCS maksymalnie dzielimy te us\u0142ugi, dla ka\u017cdego oddzielnego projektu tworzymy osobn\u0105 baz\u0119, oddzielny RabbitMQ. Takie podej\u015bcie jest dobre, poniewa\u017c w przypadku awarii w niekt\u00f3rych wra\u017cliwych punktach nie psuje si\u0119 ca\u0142a us\u0142uga, a tylko jej cz\u0119\u015b\u0107.<\/p>\n

Liczba aplikacji worker nie jest niczym ograniczona, dlatego API mo\u017ce \u0142atwo skalowa\u0107 si\u0119 horyzontalnie za balancerami w celu zwi\u0119kszenia wydajno\u015bci i odporno\u015bci na awarie.<\/p>\n

W niekt\u00f3rych us\u0142ugach konieczna jest koordynacja wewn\u0105trz serwisu \u2014 gdy zachodz\u0105 z\u0142o\u017cone, sekwencyjne operacje mi\u0119dzy API a workerami. W takim przypadku u\u017cywane jest centralne miejsce koordynacji, system klastrowy typu Redis, Memcache, etcd, kt\u00f3ry pozwala jednemu workerowi powiedzie\u0107 drugiemu, \u017ce to zadanie jest przypisane do niego (\u201eprosz\u0119, nie bierz go\u201d). U\u017cywamy etcd. Z regu\u0142y workerzy aktywnie komunikuj\u0105 si\u0119 z baz\u0105 danych, zapisuj\u0105 i odczytuj\u0105 z niej informacje. Jako baz\u0119 danych u\u017cywamy mariadb, kt\u00f3ra znajduje si\u0119 w klastrze wielomistrzowskim.\n<\/p><\/blockquote>\n

\nTaka klasyczna pojedyncza us\u0142uga jest zorganizowana w powszechnie akceptowany spos\u00f3b dla OpenStack. Mo\u017cna j\u0105 traktowa\u0107 jako zamkni\u0119ty system, dla kt\u00f3rego sposoby skalowania i odporno\u015bci na awarie s\u0105 do\u015b\u0107 oczywiste. Na przyk\u0142ad, aby zapewni\u0107 odporno\u015b\u0107 na awarie, przed API wystarczy umie\u015bci\u0107 balancer. Skalowanie worker\u00f3w osi\u0105ga si\u0119 poprzez zwi\u0119kszenie ich liczby. <\/p>\n

S\u0142abym punktem ca\u0142ej konstrukcji s\u0105 RabbitMQ i MariaDB. Ich architektura zas\u0142uguje na osobny artyku\u0142. W tym artykule chcia\u0142bym skupi\u0107 si\u0119 na odporno\u015bci na awarie API.<\/p>\n

\"Jak
\nArchitektura Openstack Application. Balansowanie i odporno\u015b\u0107 na awarie platformy chmurowej<\/i><\/p>\n

Tworzymy odporno\u015b\u0107 na awarie dla balancer\u00f3w HAProxy z pomoc\u0105 ExaBGP<\/h2>\n

\nAby nasze API by\u0142y skalowalne, szybkie i odporne na awarie, postawili\u015bmy przed nimi balancer. Wybrali\u015bmy HAProxy. Moim zdaniem, posiada on wszystkie wymagane cechy dla naszego zadania: balansowanie na wielu poziomach OSI, interfejs zarz\u0105dzania, elastyczno\u015b\u0107 i skalowalno\u015b\u0107, du\u017c\u0105 liczb\u0119 metod balansowania, wsparcie dla tabel sesji.<\/p>\n

Pierwszy problem, kt\u00f3ry nale\u017ca\u0142o rozwi\u0105za\u0107, to odporno\u015b\u0107 samego balancera. Proste zainstalowanie balancera r\u00f3wnie\u017c tworzy punkt awarii: balancer si\u0119 psuje \u2014 serwis pada. Aby do tego nie dopu\u015bci\u0107, u\u017cyli\u015bmy HAProxy wraz z ExaBGP.<\/p>\n

ExaBGP pozwala na realizacj\u0119 mechanizmu sprawdzania stanu serwisu. U\u017cyli\u015bmy tego mechanizmu do monitorowania sprawno\u015bci HAProxy i w przypadku problem\u00f3w wy\u0142\u0105czali\u015bmy serwis HAProxy z BGP. <\/p>\n

Schemat ExaBGP+HAProxy<\/b><\/p>\n

    \n
  1. Instalujemy potrzebne oprogramowanie, ExaBGP i HAProxy, na trzech serwerach. <\/li>\n
  2. Na ka\u017cdym z serwer\u00f3w tworzymy interfejs loopback.<\/li>\n
  3. Na wszystkich trzech serwerach przypisujemy do tego interfejsu ten sam publiczny adres IP.<\/li>\n
  4. Publiczny adres IP jest og\u0142aszany w internecie przez ExaBGP. <\/li>\n<\/ol>\n

    \nOdporno\u015b\u0107 na awarie osi\u0105gamy poprzez og\u0142aszanie tego samego adresu IP ze wszystkich trzech serwer\u00f3w. Z punktu widzenia sieci jeden i ten sam adres jest dost\u0119pny z trzech r\u00f3\u017cnych next hop\u00f3w. Router widzi trzy identyczne trasy, wybiera najbardziej priorytetow\u0105 wed\u0142ug w\u0142asnej metryki (zwykle to ta sama opcja) i ruch kierowany jest tylko do jednego z serwer\u00f3w. <\/p>\n

    W przypadku problem\u00f3w z dzia\u0142aniem HAProxy lub awarii serwera, ExaBGP przestaje og\u0142asza\u0107 tras\u0119, a ruch p\u0142ynnie prze\u0142\u0105cza si\u0119 na inny serwer. <\/p>\n

    W ten spos\u00f3b osi\u0105gn\u0119li\u015bmy odporno\u015b\u0107 na awarie dla balancer\u00f3w.<\/p>\n

    \"Jak
    \nOdporno\u015b\u0107 na awarie balancer\u00f3w HAProxy<\/i><\/p>\n

    Schemat okaza\u0142 si\u0119 niedoskona\u0142y: nauczyli\u015bmy si\u0119 rezerwowa\u0107 HAProxy, ale nie nauczyli\u015bmy si\u0119 rozk\u0142ada\u0107 obci\u0105\u017cenia wewn\u0105trz serwis\u00f3w. Dlatego nieco rozszerzyli\u015bmy t\u0119 konstrukcj\u0119: przeszli\u015bmy do balansowania pomi\u0119dzy kilkoma publicznymi adresami IP.<\/p>\n

    Balansowanie na bazie DNS plus BGP<\/h2>\n

    \nProblem z \u0431\u0430\u043b\u0430\u043d\u0441\u0438\u0440\u043e\u0432\u043a\u043e\u0439 obci\u0105\u017cenia przed naszymi HAProxy nadal pozostaje nierozwi\u0105zany. Niemniej jednak, mo\u017cna go do\u015b\u0107 prosto rozwi\u0105za\u0107, tak jak zrobili\u015bmy to u siebie.<\/p>\n

    Do balansowania trzech serwer\u00f3w potrzebne b\u0119d\u0105 3 bia\u0142e adresy IP i dobry stary DNS. Ka\u017cdy z tych adres\u00f3w jest przypisywany do interfejsu loopback ka\u017cdego HAProxy i og\u0142aszany w internecie. <\/p>\n

    W OpenStack do zarz\u0105dzania zasobami u\u017cywany jest katalog us\u0142ug, w kt\u00f3rym definiowany jest punkt ko\u0144cowy API danej us\u0142ugi. W tym katalogu zapisujemy nazw\u0119 domeny \u2014 public.infra.mail.ru, kt\u00f3ra resolwuje si\u0119 przez DNS za pomoc\u0105 trzech r\u00f3\u017cnych adres\u00f3w IP. W rezultacie uzyskujemy rozk\u0142ad obci\u0105\u017cenia pomi\u0119dzy trzema adresami za pomoc\u0105 DNS. <\/p>\n

    Jednak\u017ce, poniewa\u017c og\u0142aszaj\u0105c bia\u0142e adresy IP, nie zarz\u0105dzamy priorytetami wyboru serwera, wci\u0105\u017c nie jest to balansowanie. Zazwyczaj wybierany b\u0119dzie tylko jeden serwer na podstawie wy\u017cszo\u015bci adresu IP, podczas gdy dwa inne b\u0119d\u0105 bezczynne, poniewa\u017c nie podano \u017cadnych metryk w BGP.<\/p>\n

    Zacz\u0119li\u015bmy og\u0142asza\u0107 trasy przez ExaBGP z r\u00f3\u017cnymi metrykami. Ka\u017cdy balansuj\u0105cy og\u0142asza wszystkie trzy bia\u0142e adresy IP, ale jeden z nich, g\u0142\u00f3wny dla danego balansuj\u0105cego, jest og\u0142oszony z minimaln\u0105 metryk\u0105. Tak wi\u0119c, p\u00f3ki wszystkie trzy balansuj\u0105ce s\u0105 w akcji, zapytania do pierwszego adresu IP trafiaj\u0105 do pierwszego balansuj\u0105cego, zapytania do drugiego do drugiego, a do trzeciego do trzeciego.<\/p>\n

    Co si\u0119 dzieje w momencie, gdy jeden z balansuj\u0105cych pada? W przypadku awarii jakiegokolwiek balansuj\u0105cego, jego podstawowy adres wci\u0105\u017c jest og\u0142aszany przez dw\u00f3ch pozosta\u0142ych, a ruch mi\u0119dzy nimi jest redystrybucjonowany. W ten spos\u00f3b przekazujemy u\u017cytkownikowi przez DNS od razu kilka adres\u00f3w IP. Dzi\u0119ki balansowaniu za pomoc\u0105 DNS i r\u00f3\u017cnym metrykom uzyskujemy r\u00f3wnomierny rozk\u0142ad obci\u0105\u017cenia na wszystkie trzy balansuj\u0105ce. I przy tym nie tracimy odporno\u015bci na awarie.<\/p>\n

    \"Jak
    \nBalansowanie HAProxy na bazie DNS + BGP<\/i><\/p>\n

    Interakcja mi\u0119dzy ExaBGP a HAProxy<\/h2>\n

    \nZrealizowali\u015bmy wi\u0119c odporno\u015b\u0107 na awarie w przypadku odej\u015bcia serwera, opart\u0105 na zaprzestaniu og\u0142aszania tras. Jednak HAProxy mo\u017ce si\u0119 wy\u0142\u0105czy\u0107 z innych powod\u00f3w ni\u017c awaria serwera: b\u0142\u0119dy administracyjne, awarie w obr\u0119bie us\u0142ugi. Chcemy usun\u0105\u0107 uszkodzony balansuj\u0105cy z obci\u0105\u017cenia i w tych przypadkach potrzebny jest inny mechanizm. <\/p>\n

    Dlatego, rozwijaj\u0105c wcze\u015bniej przedstawiony schemat, wdro\u017cyli\u015bmy heartbeat mi\u0119dzy ExaBGP a HAProxy. To programowa implementacja interakcji mi\u0119dzy ExaBGP a HAProxy, gdzie ExaBGP wykorzystuje niestandardowe skrypty do sprawdzania statusu aplikacji.<\/p>\n

    W tym celu w konfiguracji ExaBGP nale\u017cy skonfigurowa\u0107 health checker, kt\u00f3ry b\u0119dzie w stanie sprawdza\u0107 status HAProxy. W naszym przypadku skonfigurowali\u015bmy health backend w HAProxy, a z strony ExaBGP sprawdzamy to za pomoc\u0105 prostego zapytania GET. Je\u015bli og\u0142oszenie przestaje mie\u0107 miejsce, oznacza to, \u017ce HAProxy prawdopodobnie nie dzia\u0142a i nie nale\u017cy go og\u0142asza\u0107. <\/p>\n

    \"Jak
    \nHAProxy Health Check<\/i><\/p>\n

    HAProxy Peers: synchronizacja sesji <\/h2>\n

    \nNast\u0119pnie, co by\u0142o konieczne do zrobienia, to synchronizacja sesji. Przy pracy przez rozproszone load balancery trudno zorganizowa\u0107 przechowywanie informacji o sesjach klient\u00f3w. Jednak HAProxy jest jednym z nielicznych load balancer\u00f3w, kt\u00f3re potrafi\u0105 to zrobi\u0107 dzi\u0119ki funkcjonalno\u015bci Peers \u2014 mo\u017cliwo\u015bci transferu tablic sesji mi\u0119dzy r\u00f3\u017cnymi procesami HAProxy. <\/p>\n

    Istniej\u0105 r\u00f3\u017cne metody balansowania: proste, takie jak round-robin<\/a><\/noindex>, oraz zaawansowane, kiedy zapami\u0119tywana jest sesja klienta, a on za ka\u017cdym razem trafia na ten sam serwer, co wcze\u015bniej. Chcieli\u015bmy wdro\u017cy\u0107 drug\u0105 opcj\u0119.<\/p>\n

    W HAProxy do przechowywania sesji klienta wykorzystuje si\u0119 mechanizm stick-tables. Zachowuj\u0105 one pierwotny adres IP klienta, wybrany adres docelowy (backend) oraz pewne informacje pomocnicze. Zwykle stick-tables s\u0105 u\u017cywane do przechowywania par source-IP + destination-IP, co jest szczeg\u00f3lnie przydatne dla aplikacji, kt\u00f3re nie mog\u0105 przekazywa\u0107 kontekstu sesji u\u017cytkownika przy prze\u0142\u0105czaniu na inny load balancer, na przyk\u0142ad \u2014 w trybie balansowania RoundRobin.<\/p>\n

    Je\u015bli stick-table nauczy si\u0119 przemieszcza\u0107 mi\u0119dzy r\u00f3\u017cnymi procesami HAProxy (mi\u0119dzy kt\u00f3rymi odbywa si\u0119 balansowanie), nasze load balancery b\u0119d\u0105 mog\u0142y pracowa\u0107 z jednym zestawem stick-tables. To umo\u017cliwi bezproblemowe prze\u0142\u0105czanie sieci klienta przy awarii jednego z load balancer\u00f3w, a praca z sesjami klient\u00f3w b\u0119dzie kontynuowana na tych samych backendach, kt\u00f3re zosta\u0142y wybrane wcze\u015bniej.<\/p>\n

    Aby dzia\u0142a\u0142o to prawid\u0142owo, nale\u017cy rozwi\u0105za\u0107 problem adresu IP \u017ar\u00f3d\u0142owego load balancera, z kt\u00f3rego nawi\u0105zana jest sesja. W naszym przypadku jest to dynamiczny adres na interfejsie loopback. <\/p>\n

    Prawid\u0142owe dzia\u0142anie peers osi\u0105ga si\u0119 jedynie w okre\u015blonych warunkach. To znaczy, \u017ce czasy oczekiwania TCP musz\u0105 by\u0107 wystarczaj\u0105co d\u0142ugie, a prze\u0142\u0105czenie wystarczaj\u0105co szybkie, aby sesja TCP nie zd\u0105\u017cy\u0142a si\u0119 zerwa\u0107. Niemniej jednak pozwala to na p\u0142ynne prze\u0142\u0105czanie. <\/p>\n

    W naszym IaaS mamy us\u0142ug\u0119 opart\u0105 na tej samej technologii. To Load Balancer jako us\u0142uga dla OpenStack<\/a><\/noindex>, kt\u00f3ra nazywa si\u0119 Octavia. Opiera si\u0119 ona na dw\u00f3ch procesach HAProxy, w kt\u00f3rych od pocz\u0105tku zaimplementowano wsparcie dla peers. W tej us\u0142udze sprawdzi\u0142y si\u0119 one doskonale.<\/p>\n

    Na rysunku schematycznie przedstawiono przenoszenie tabel peers mi\u0119dzy trzema instancjami HAProxy, zaproponowano konfiguracj\u0119, jak mo\u017cna to ustawi\u0107:<\/p>\n

    \"Jak
    \nHAProxy Peers (synchronizacja sesji)<\/i><\/p>\n

    Je\u015bli b\u0119dziesz wdra\u017ca\u0107 taki sam schemat, trzeba dok\u0142adnie przetestowa\u0107 jego dzia\u0142anie. Nie ma pewno\u015bci, \u017ce zadzia\u0142a w ten sam spos\u00f3b w 100% przypadk\u00f3w. Niemniej jednak przynajmniej nie stracisz tabel stick, kiedy trzeba zapami\u0119ta\u0107 adres IP \u017ar\u00f3d\u0142a klienta.<\/p>\n

    Limit liczby r\u00f3wnoczesnych zapyta\u0144 od jednego i tego samego klienta<\/h2>\n

    \nWszystkie us\u0142ugi dost\u0119pne publicznie, w tym nasze API, mog\u0105 by\u0107 nara\u017cone na lawiny zapyta\u0144. Powody mog\u0105 by\u0107 ca\u0142kowicie r\u00f3\u017cne, od b\u0142\u0119d\u00f3w u\u017cytkownik\u00f3w, po celowe ataki. Regularnie jeste\u015bmy DDoS-owani po adresach IP. Klienci cz\u0119sto myl\u0105 si\u0119 w swoich skryptach, powoduj\u0105c mini-DDoSy.<\/p>\n

    W ka\u017cdym razie konieczne jest przewidzenie dodatkowej ochrony. Oczywistym rozwi\u0105zaniem jest ograniczenie liczby zapyta\u0144 do API i nie marnowanie czasu procesora na przetwarzanie z\u0142o\u015bliwych zapyta\u0144.<\/p>\n

    Aby wdro\u017cy\u0107 takie ograniczenia, stosujemy limity szybko\u015bci, zorganizowane na bazie HAProxy, przy pomocy tych samych tabel stick. Limity ustawia si\u0119 do\u015b\u0107 \u0142atwo i pozwala to ograniczy\u0107 u\u017cytkownika pod wzgl\u0119dem liczby zapyta\u0144 do API. Algorytm zapami\u0119tuje adres IP \u017ar\u00f3d\u0142a, z kt\u00f3rego wysy\u0142ane s\u0105 zapytania, i ogranicza liczb\u0119 r\u00f3wnoczesnych zapyta\u0144 od jednego u\u017cytkownika. Oczywi\u015bcie obliczyli\u015bmy \u015bredni profil obci\u0105\u017cenia API dla ka\u017cdej us\u0142ugi i ustawili\u015bmy limit \u2248 10 razy wi\u0119kszy od tej warto\u015bci. Nadal uwa\u017cnie monitorujemy sytuacj\u0119, maj\u0105c r\u0119k\u0119 na pulsie.<\/p>\n

    Jak to wygl\u0105da w praktyce? Mamy klient\u00f3w, kt\u00f3rzy regularnie korzystaj\u0105 z naszego API do automatycznego skalowania. Tworz\u0105 oko\u0142o dwustu-trzystu maszyn wirtualnych przed po\u0142udniem, a nast\u0119pnie usuwaj\u0105 je p\u00f3\u017anym popo\u0142udniem. Dla OpenStack stworzenie maszyny wirtualnej, a tak\u017ce z us\u0142ugami PaaS, to co najmniej 1000 zapyta\u0144 API, poniewa\u017c interakcja mi\u0119dzy us\u0142ugami r\u00f3wnie\u017c odbywa si\u0119 za po\u015brednictwem API. <\/p>\n

    Takie przenoszenie zada\u0144 generuje do\u015b\u0107 du\u017c\u0105 obci\u0105\u017cenie. Oszacowali\u015bmy to obci\u0105\u017cenie, zebrali\u015bmy dzienne szczyty, zwi\u0119kszyli\u015bmy je dziesi\u0119ciokrotnie, co sta\u0142o si\u0119 naszym limitem rate. Mamy r\u0119k\u0119 na pulsie. Cz\u0119sto widzimy boty, skanery, kt\u00f3re pr\u00f3buj\u0105 sprawdzi\u0107, czy mamy jakie\u015b skrypty CGA, kt\u00f3re mo\u017cna uruchomi\u0107, intensywnie je eliminujemy.<\/p>\n

    Jak aktualizowa\u0107 baz\u0119 kodu bez zauwa\u017cania przez u\u017cytkownik\u00f3w<\/h2>\n

    \nRealizujemy odporno\u015b\u0107 na awarie tak\u017ce na poziomie proces\u00f3w wdra\u017cania kodu. Przy wdro\u017ceniach zdarzaj\u0105 si\u0119 awarie, ale ich wp\u0142yw na dost\u0119pno\u015b\u0107 us\u0142ug mo\u017cna zminimalizowa\u0107.<\/p>\n

    Nieustannie aktualizujemy nasze us\u0142ugi i musimy zapewni\u0107 proces aktualizacji bazy kodu bez wp\u0142ywu na u\u017cytkownik\u00f3w. Zrealizowali\u015bmy to, wykorzystuj\u0105c mo\u017cliwo\u015bci zarz\u0105dzania HAProxy oraz implementacj\u0119 Graceful Shutdown w naszych us\u0142ugach.<\/p>\n

    Aby rozwi\u0105za\u0107 ten problem, trzeba zapewni\u0107 zarz\u0105dzanie load balancerem i \"prawid\u0142owe\" wy\u0142\u0105czanie us\u0142ug:<\/p>\n