W 2010 roku firma posiadała 50 serwerów i prostą strukturę sieciową: backend, frontend i zaporę. Liczba serwerów rosła, a model stawał się coraz bardziej skomplikowany: stagingi, izolowane VLAN z ACL, potem VPN z VRF, VLAN z ACL na L2, VRF z ACL na L3. Zawroty głowy? Będzie jeszcze ciekawiej.
Kiedy liczba serwerów osiągnęła 16 000, praca bez łez w takiej ilości różnorodnych segmentów stała się niemożliwa. Dlatego wymyślono inne rozwiązanie. Wzięto stos Netfilter, dodano do niego Consul jako źródło danych, powstała szybka, rozproszona zapora. Zastąpiono nią ACL na routerach i używano jako zapory zewnętrznej i wewnętrznej. Aby dynamicznie zarządzać narzędziem, opracowano system BEFW, który wdrożono wszędzie: od zarządzania dostępem użytkowników do sieci produkcyjnej po izolację segmentów sieci od siebie.
Jak to wszystko działa i dlaczego warto zwrócić uwagę na ten system, opowie Ivan Agarkov () — lider grupy bezpieczeństwa infrastruktury w dziale Utrzymania w Mińskim Centrum Rozwoju firmy. Ivan jest fanem SELinux, uwielbia Perla, pisze kod. Jako lider grupy IB regularnie pracuje z logami, kopiami zapasowymi i R&D, aby chronić Wargaming przed hakerami i zapewnić działanie wszystkich serwerów gier w firmie.
Kontekst historyczny
Zanim opowiem, jak to robiliśmy, przedstawię, jak w ogóle do tego doszło i dlaczego to było potrzebne. W tym celu przenieśmy się 9 lat wstecz: 2010 rok, właśnie pojawiły się World of Tanks. Firma Wargaming miała około 50 serwerów.
Wykres wzrostu serwerów firmy.
Mieliśmy model sieciowy. Jak na tamte czasy, był optymalny.
Model sieciowy w 2010 roku.
Na frontendzie żyją źli ludzie, którzy chcą nas złamać, ale jest tam zapora. Na backendzie nie ma zapory, ale są tam 50 serwerów, które wszyscy znamy. Wszystko działa dobrze.
W ciągu 4 lat liczba serwerów wzrosła 100 razy, do 5000. Pojawiły się pierwsze izolowane sieci — stagingi: nie mogą one przechodzić do produkcji, a często kręciły się tam rzeczy, które mogły być niebezpieczne.
Model sieciowy w 2014 roku.
Z przyzwyczajenia korzystano z tych samych urządzeń, a cała praca odbywała się na izolowanych VLAN: do VLAN pisane są ACL, które pozwalają lub zabraniają jakiegoś połączenia.
W 2016 roku liczba serwerów osiągnęła 8000. Wargaming przejmował inne studia, pojawiły się dodatkowe sieci partnerskie. Wydają się być nasze, ale nie do końca: dla partnerów VLAN często nie działa, konieczne jest korzystanie z VPN z VRF, izolacje się komplikują. Mieszanka izolacji ACL rosła.
Model sieciowy w 2016 roku.
Na początku 2018 roku flota maszyn wzrosła do 16000. Było 6 segmentów, pozostałych nie liczyliśmy, w tym zamkniętych, w których przechowywane były dane finansowe. Pojawiły się sieci kontenerowe (Kubernetes), DevOps, sieci chmurowe połączone przez VPN, na przykład z IWS. Reguł było bardzo dużo — to bolało.
Model sieciowy i sposoby izolacji w 2018 roku.
Do izolacji używaliśmy: VLAN z ACL na L2, VRF z ACL na L3, VPN i wielu innych. Zbyt wiele.
Problemy
Wszyscy żyją z ACL i VLAN. Co właściwie jest nie tak? Na to pytanie odpowie Harold, ukrywający ból.
Było wiele problemów, ale masowych — pięć.
- Geometryczny wzrost ceny dla nowych reguł. Każda nowa reguła dodawana była dłużej niż poprzednia, ponieważ najpierw trzeba było sprawdzić, czy nie ma już takiej reguły.
- Brak firewalla wewnątrz segmentów. Segmenty oddzieliły się jakoś od siebie, wewnątrz już brakuje zasobów.
- Reguły stosowane były długo. Jedną lokalną regułę operatorzy mogli napisać ręcznie w ciągu godziny. Globalna zajmowała kilka dni.
- Trudności z audytem reguł. Dokładniej, był niemożliwy. Pierwsze reguły były pisane już w 2010 roku, a większość ich autorów już nie pracowała w firmie.
- Niski poziom kontroli nad infrastrukturą. To główny problem — źle wiedzieliśmy, co w ogóle się u nas dzieje.
Tak wyglądał inżynier sieciowy w 2018 roku, kiedy słyszał: „Jeszcze trochę ACL”.
Rozwiązania
Na początku 2018 roku postanowiono coś z tym zrobić.
Cena integracji stale rośnie. Punktem wyjścia było to, że duże centra danych przestały wspierać izolowane VLAN i ACL, ponieważ skończyła się pamięć na urządzeniach.
Rozwiązanie: wyeliminowanie czynnika ludzkiego i maksymalizacja automatyzacji dostępu.
Nowe reguły stosowane są długo. Rozwiązanie: przyspieszenie stosowania reguł, uczynienie go rozproszonym i równoległym. W tym celu potrzebny jest system rozproszony, aby reguły były dostarczane same, bez rsync lub SFTP na tysiąc systemów.
Brak firewalla wewnątrz segmentów. Zapora ogniowa w segmentach zaczęła do nas docierać, gdy w ramach jednej sieci pojawiały się różne usługi. Rozwiązanie: użyć zapory ogniowej na poziomie hosta - firewalle oparte na hoście. Prawie wszędzie mamy Linuxa, a wszędzie są iptables, to nie jest problem.
Trudności z audytowaniem reguł. Rozwiązanie: przechowywać wszystkie reguły w jednym miejscu dla przeglądu i zarządzania, w ten sposób będziemy mogli wszystko audytować.
Niski poziom kontroli nad infrastrukturą. Rozwiązanie: przeprowadzić inwentaryzację wszystkich usług i dostępów między nimi.
To bardziej proces administracyjny niż techniczny. Czasami mamy 200-300 nowych wydań w tygodniu, szczególnie w czasie promocji i świąt. Przy tym to tylko dla jednego zespołu naszych DevOps. Przy takiej liczbie wydań niemożliwe jest zrozumienie, jakie porty, IP, integracje są potrzebne. Dlatego potrzebowaliśmy specjalnie przeszkolonych menedżerów usług, którzy pytali zespoły: 'Co właściwie macie i po co to uruchomiliście?'
Po wszystkim, co uruchomiliśmy, inżynier sieciowy w 2019 roku wyglądał już tak.
Consul
Zdecydowaliśmy, że wszystko, co znaleźliśmy za pomocą menedżerów usług, umieścimy w Consulu i stamtąd będziemy pisać reguły iptables.
Jak zdecydowaliśmy to zrobić?
- Zbierzemy wszystkie usługi, sieci i użytkowników.
- Na ich podstawie stworzymy reguły iptables.
- Zautomatyzujemy kontrolę.
- ….
- ZYSK.
Consul to nie zdalne API, może działać na każdym węźle i pisać w iptables. Pozostaje tylko wymyślić automatyczne środki kontroli, które będą usuwały zbędne elementy, a większość problemów zostanie rozwiązana! Resztę dopracujemy w procesie.
Dlaczego Consul?
Dobrze się sprawdził. W latach 2014-15 używaliśmy go jako backendu dla Vault, w którym przechowujemy hasła.
Nie gubi danych.Podczas korzystania z Consula nie utracono danych w żadnej awarii. To ogromny plus dla systemu zarządzania zaporą ogniową.
Połączenia P2P przyspieszają rozprzestrzenianie zmian.Dzięki P2P wszystkie zmiany przychodzą szybko, nie trzeba czekać godzinami.
Wygodne REST API. Rozważaliśmy także Apache ZooKeeper, ale nie ma on REST API, trzeba byłoby wprowadzać obejścia.
Działa zarówno jako magazyn kluczy (KV), jak i jako katalog (Odkrywanie usług).Można przechowywać od razu usługi, katalogi, centra danych. To wygodne nie tylko dla nas, ale i dla sąsiednich zespołów, ponieważ budując globalną usługę, myślimy w skali.
Napisany w Go, który wchodzi w skład stosu Wargaming. Uwielbiamy ten język, mamy wielu programistów Go.
Potężny system ACL. W Consulu za pomocą ACL można zarządzać tym, kto i co może pisać. Gwarantujemy, że zasady zapory ogniowej nie będą się ze sobą krzyżować i nie będziemy z tym mieli problemów.
Jednak Consul ma również wady.
- Nie skalowalny w ramach centrum danych, jeśli nie masz wersji biznesowej. Skalowalny tylko przez federację.
- Bardzo zależny od jakości sieci i obciążenia serwerów. Consul nie będzie działał poprawnie jako serwer na obciążonym serwerze, jeśli w sieci są jakieś opóźnienia, na przykład niestabilna prędkość. Jest to związane z połączeniami P2P i modelami dystrybucji aktualizacji.
- Trudności z monitorowaniem dostępności. W statusie Consula może mówić, że wszystko dobrze, a on już od dawna nie działa.
Większość tych problemów rozwiązaliśmy podczas eksploatacji Consula, dlatego go wybraliśmy. Firma ma plany na alternatywny backend, ale nauczyliśmy się radzić sobie z problemami i na razie żyjemy z Consulem.
Jak działa Consul
W przyporządkowanym centrum danych zainstalujemy serwery — od trzech do pięciu. Jeden lub dwa serwery się nie sprawdzą: nie będą w stanie zorganizować kworum i ustalić, kto ma rację, gdy dane się nie zgadzają. Więcej niż pięć nie ma sensu, wydajność spadnie.
Klienci łączą się z serwerami w dowolnej kolejności: to ci sami agenci, tylko z flagą server = false.
Po tym klienci otrzymują listę połączeń P2P i tworzą między sobą powiązania.
Na poziomie globalnym łączymy kilka centrów danych. One również łączą się P2P i komunikują.
Kiedy chcemy pobrać dane z innego centrum danych, zapytanie idzie od serwera do serwera. Taki schemat nazywa się protokołem Serf. Protokół Serf, podobnie jak Consul, jest rozwijany przez HashiCorp.
Kilka ważnych faktów o Consulu
Consul ma dokumentację opisującą swoją pracę. Przytoczę tylko wybrane fakty, które warto znać.
Serwery Consula wybierają lidera spośród głosujących. Consul wybiera lidera z listy serwerów dla każdego centrum danych i wszystkie zapytania idą tylko do niego, niezależnie od liczby serwerów. Zawieszenie lidera nie prowadzi do nowych wyborów. Jeśli lider nie jest wybrany — zapytania nie są obsługiwane przez nikogo.
Chciałeś skalowania horyzontalnego? Przykro mi, nie ma takiej opcji.
Zapytanie do innego centrum danych jest przekazywane od mastera do mastera, niezależnie od tego, na którym serwerze się pojawiło. Wybrany master otrzymuje 100% obciążenia, z wyjątkiem obciążenia na przekierowane zapytania. Aktualna kopia danych jest dostępna dla wszystkich serwerów centrum danych, ale odpowiada tylko jeden.
Jedynym sposobem na skalowanie jest włączenie trybu stale na kliencie.
W trybie stale można odpowiadać bez kworum. To tryb, w którym rezygnujemy z spójności danych, ale czytamy nieco szybciej niż zwykle, a odpowiedzieć może każdy serwer. Oczywiście zapis odbywa się tylko przez mastera.
Consul nie kopiuje danych między centrami danych.Podczas zbierania federacji każdy serwer będzie miał tylko własne dane. Po inne zawsze zwraca się do kogoś innego.
Atomowość operacji nie jest gwarantowana poza transakcjami.Pamiętaj, że zmieniać coś mogą nie tylko wy. Jeśli chcesz inaczej, przeprowadź transakcję z blokadą.
Operacje blokujące nie gwarantują blokady.Zapytanie odbywa się od mastera do mastera, a nie bezpośrednio, dlatego nie ma gwarancji, że blokada zadziała, gdy dokonujesz blokady, na przykład w innym centrum danych.
ACL również nie gwarantuje dostępu (w wielu przypadkach).ACL może nie działać, ponieważ jest przechowywana w jednym centrum danych federacji — w centrum danych ACL (Primary DC). Jeśli DC ci nie odpowie, ACL nie będzie działać.
Jeden zawieszony master spowoduje zawieszenie całej federacji.Na przykład, w federacji 10 centrów danych, a w jednym zła sieć, jeden master pada. Wszyscy, którzy się z nim komunikują, będą zawieszeni w cyklu: odbywa się zapytanie, nie ma odpowiedzi, wątek się zawiesza. Nie da się przewidzieć, kiedy to się wydarzy, po prostu za godzinę lub dwie cała federacja padnie. Nic z tym nie zrobisz.
Status, kworum i wybory są przetwarzane osobnym wątkiem. Nie nastąpią nowe wybory, status nic nie pokaże. Myślisz, że masz aktywny Consul, pytasz, a nic się nie dzieje — nie ma odpowiedzi. Status pokazuje, że wszystko jest w porządku.
Spotkaliśmy się z tym problemem, musieliśmy przebudować konkretne części centrów danych, aby go uniknąć.
W wersji biznesowej Consul Enterprise brak niektórych wymienionych wcześniej wad.Ma ona wiele przydatnych funkcji: wybór głosujących, rozdzielanie, skalowanie. Jest tylko jeden "ale" — system licencyjny dla systemu rozproszonego jest bardzo drogi.
Lifehack: rm -rf /var/lib/consul — lekarstwo na wszelkie problemy agenta. Jeśli coś nie działa, po prostu usuń swoje dane i załaduj dane z kopii. Najprawdopodobniej Consul zacznie działać.
BEFW
Teraz porozmawiajmy o tym, co dodaliśmy do Consul.
— to akronim od BackEndFireWwszystko. Musiałem jakoś nazwać produkt, gdy tworzyłem repozytorium, aby umieścić w nim pierwsze testowe commity. Taka nazwa i pozostała.
Szablony reguł
Reguły są napisane w składni iptables.
- -N BEFW
- -P INPUT DROP
- -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
- -A INPUT -i lo -j ACCEPT
- -A INPUT -j BEFW
Wszystko idzie do łańcucha BEFW, z wyjątkiem ESTABLISHED, RELATED i localhost. Szablon może być dowolny, to tylko przykład.
Jak przydatny jest BEFW?
Usługi
Mamy usługę, w której zawsze jest port oraz węzeł, na którym działa. Z własnego węzła możemy lokalnie zapytać agenta i dowiedzieć się, że mamy jakąś usługę. Można także dodawać tagi.
Każda usługa, która jest uruchomiona i zarejestrowana w Consul, zamienia się w regułę iptables. Mamy SSH — otwieramy port 22. Skrypt bash jest prosty: curl i iptables, nic więcej nie potrzeba.
Klienci
Jak otworzyć dostęp nie wszystkim, a selektywnie? Zbierając IP do przechowalni KV po nazwie usługi.
Na przykład, chcemy, aby wszyscy z dziesiątej sieci mogli łączyć się z usługą SSH_TCP_22. Dodajemy jedno małe pole TTL? i teraz mamy tymczasowe zezwolenia, na przykład na dobę.
Dostępy
Łączymy usługi i klientów: mamy usługę, dla każdej gotowe jest przechowalnia KV. Teraz dajemy dostęp nie wszystkim, a selektywnie.
Grupy
Jeśli za każdym razem będziemy pisać tysiące IP do dostępów, to się zmęczymy. Wymyślimy grupy — oddzielny subset w KV. Nazwiemy go Alias (lub grupy) i będziemy przechowywać tam grupy według tego samego zasad.
Łączymy: teraz możemy otworzyć SSH nie konkretnie na P2P, a na całą grupę lub kilka grup. Tak samo mamy TTL — można tymczasowo dodawać i usuwać z grupy.
Integracja
Naszym problemem jest czynnik ludzki i automatyzacja. Na razie rozwiązaliśmy to w ten sposób.
Pracujemy z Puppet i przekazujemy mu wszystko, co dotyczy systemu (kod aplikacji). W puppetdb (zwykły PostgreSQL) przechowywana jest lista uruchomionych usług, które można znaleźć według typu zasobu. Tam również można sprawdzić, kto do czego się odwołuje. Mamy także system pull requestów i merge requestów do tego.
Napisaliśmy befw-sync — najprostsze rozwiązanie, które pomaga przenosić dane. Najpierw sync cookies kierują zapytania do puppetdb. Tam skonfigurowane jest API HTTP: żądamy, jakie mamy usługi i co trzeba zrobić. Następnie wykonują zapytanie do Consul.
Czy istnieje integracja? Tak: napisaliśmy zasady, pozwoliliśmy na akceptację Pull Requestów. Potrzebny jest jakiś port lub dodanie hosta do jakiejś grupy? Pull Request, przegląd — żadnych „Znajdź 200 innych ACL i spróbuj coś z tym zrobić”.
Optymalizacja
Ping localhost z pustym łańcuchem reguł zajmuje 0,075 ms.
Dodamy do tego łańcucha 10 000 adresów iptables. W rezultacie ping zwiększy się 5 razy: iptables jest całkowicie liniowe, przetwarzanie każdego adresu zajmuje trochę czasu.
Dla zapory, do której migrujemy tysiące ACL, mamy dużo reguł, co wprowadza opóźnienia. To jest złe dla protokołów gier.
Ale jeśli umieścimy 10 000 adresów w ipset ping nawet się zmniejszy.
Sens polega na tym, że „O” (złożoność algorytmu) dla ipset zawsze wynosi 1, niezależnie od tego, ile tam jest reguł. Istnieje ograniczenie — nie może być więcej niż 65535 reguł. Na razie z tym żyjemy: można je kombinować, rozszerzać, tworzyć dwa ipset w jednym.
Przechowywanie
Logiczną kontynuacją procesu iteracji jest przechowywanie informacji o klientach dla usługi w ipset.
Teraz mamy ten sam SSH, i nie wpisujemy od razu 100 IP, tylko podajemy nazwę ipset, z którym trzeba się skontaktować, i następną regułę DROP. Można to przekształcić w jedną regułę „Kto nie tutaj, ten DROP”, ale tak wygląda to bardziej czytelnie.
Teraz mamy reguły i zestawy. Główne zadanie to utworzenie zestawu przed napisaniem reguły, ponieważ w przeciwnym razie iptables nie zapisze reguły.
Ogólny schemat
W postaci schematu wszystko, co opowiedziałem, wygląda tak.
Potwierdzamy w Puppet, wszystko wysyłane jest na hosta, usługi są tutaj, ipset tam, a kto tam nie jest zapisany, ten nie jest wpuszczany.
Zezwól i zabroń
Aby szybko ratować świat lub szybko kogoś odłączyć, na początku wszystkich łańcuchów stworzyliśmy dwa ipset: rules_allow i rules_deny. Jak to działa?
Na przykład, ktoś generuje obciążenie na naszym serwisie za pomocą botów. Kiedyś trzeba było znaleźć jego IP w logach, przekazać to inżynierom sieciowym, aby znaleźli źródło ruchu i zablokowali je. Teraz wygląda to inaczej.
Wysyłamy do Consul, czekamy 2,5 s i gotowe. Ponieważ Consul szybko rozprowadza dzięki P2P, działa wszędzie, w każdej części świata.
Kiedyś całkowicie zatrzymałem WOT przez pomyłkę z firewallem. rules_allow — to nasze ubezpieczenie od takich przypadków. Jeśli gdzieś popełniliśmy błąd z firewallem i coś zostało zablokowane, zawsze możemy wysłać warunkowy 0.0/0, aby szybko wszystko przywrócić. Potem naprawimy to ręcznie.
Inne zestawy
Można dodawać dowolne inne zestawy w przestrzeni $IPSETS$.
Po co? Czasami ktoś potrzebuje ipset, na przykład, aby emulować wyłączenie jakiejś części klastra. Każdy może przynieść dowolne zestawy, nadać im nazwy, a one będą pobierane z Consul. Zestawy mogą brać udział w regułach iptables, a także być jakby komendą NOOP: spójność będzie utrzymywana przez demona.
Użytkownicy
Kiedyś było tak: użytkownik łączył się z siecią i przez domenę otrzymywał parametry. Przed pojawieniem się nowej generacji firewalli Cisco nie potrafiła rozpoznać, gdzie jest użytkownik, a gdzie IP. Dlatego dostęp był wydawany tylko przez hostname maszyny.
Co zrobiliśmy? Wkręciliśmy się w momencie uzyskiwania adresu. Zwykle to dot1x, Wi-Fi lub VPN — wszystko przechodzi przez RADIUS. Dla każdego użytkownika tworzymy grupę o nazwie użytkownika i umieszczamy w niej IP z TTL, który jest równy jego dhcp.lease — gdy tylko wygasa, reguła znika.
Teraz możemy otwierać dostęp do usług, jak i dla innych grup, na podstawie nazwy użytkownika. Pozbyliśmy się bólu z hostname, gdy się zmieniają, oraz odciążamy inżynierów sieciowych, ponieważ nie potrzebują już Cisco. Teraz inżynierowie sami definiują dostęp na swoich serwerach.
Izolacja
Równolegle zaczęliśmy zajmować się izolacją. Menedżerowie usług przeprowadzili inwentaryzację, a my przeanalizowaliśmy wszystkie nasze sieci. Podzielimy je na takie same grupy, a na odpowiednich serwerach dodaliśmy grupy, na przykład, do deny. Teraz ta sama izolacja stagingowa trafia do rules_deny w produkcji, ale nie w samej produkcji.
Schemat działa szybko i prosto: usuwamy wszystkie ACL z serwerów, odciążamy sprzęt, zmniejszamy liczbę izolowanych VLANów.
Kontrola integralności
Dawniej mieliśmy specjalny wyzwalacz, który informował, kiedy ktoś ręcznie zmieniał zasady zapory. Napisałem ogromny lint do sprawdzania zasad zapory, było to trudne. Teraz integralność kontroluje BEFW. Intensywnie pilnuje, aby zasady, które ustala, nie były zmieniane. Jeśli ktoś zmieni zasady zapory, przywróci wszystko z powrotem. „Szybko uruchomiłem proxy, aby pracować z domu” — takich opcji już nie ma.
BEFW kontroluje ipset z usług i listy w befw.conf, zasady usług w łańcuchu BEFW. Jednak nie monitoruje innych łańcuchów i zasad oraz innych ipset.
Ochrona przed awariami
BEFW zawsze zapisuje ostatni udany stan bezpośrednio w binarnej strukturze state.bin. Jeśli coś poszło nie tak, zawsze wraca do tego state.bin.
To rodzaj ubezpieczenia przed niestabilną pracą Consul, kiedy nie wysłał danych lub ktoś pomylił się i użył zasad, które nie mogą być zastosowane. Abyśmy nie zostali bez zapory, BEFW cofnął się do ostatniego stanu, jeśli na którymś etapie wystąpi błąd.
W krytycznych sytuacjach to gwarancja, że pozostaniemy z działającą zaporą. Otwieramy wszystkie szare sieci w nadziei, że administrator przyjdzie i naprawi. Kiedyś to umieszczę w konfiguracjach, ale teraz mamy tylko trzy szare sieci: 10/8, 172/12 i 192.168/16. W ramach naszego Consul to ważna cecha, która pomaga się rozwijać.
Demo: podczas wykładu Ivan demonstruje tryb demo pracy BEFW. Wygodniej oglądać demonstrację na . Kod źródłowy demo jest dostępny .
Pułapki
Opowiem o błędach, z którymi się spotkaliśmy.
ipset add set 0.0.0.0/0. Co się stanie, jeśli dodasz do ipset 0.0.0.0/0? Dodane zostaną wszystkie IP? Otworzy się dostęp do internetu?
Nie, otrzymamy błąd, który kosztował nas dwie godziny przestoju. Ten błąd nie działał od 2016 roku, leży w RedHat Bugzilla pod numerem #1297092, a odkryliśmy go przypadkowo — z raportu programisty.
Teraz w BEFW obowiązuje ścisła zasada, że 0.0.0.0/0 zmienia się w dwa adresy: 0.0.0.0/1 i 128.0.0.0/1.
ipset restore set < file. Co robi ipset, gdy mówisz mu restore? Вы думаете, он работает также, как iptables? Восстановит данные?
Nic podobnego — robi merge, a stare adresy nie znikają, dostępu nie zamykasz.
Błąd odkryliśmy, gdy testowaliśmy izolację. Teraz tam jest dość skomplikowany system — zamiast restore prowadzi się create temp, potem restore flush temp i restore temp. Na końcu swap: dla atomowości, bo jeśli najpierw przeprowadza flush I w tym momencie przyjdzie jakiś pakiet, który zostanie odrzucony i coś pójdzie nie tak. Dlatego czeka nas trochę czarnej magii.
consul kv get -datacenter=other. Jak już mówiłem, myślimy, że żądamy jakichś danych, ale otrzymamy albo dane, albo błąd. Możemy to robić lokalnie przez Consul, ale w takim przypadku oba procesy zawieszą się.
Lokalny klient Consul to powłoka nad HTTP API. Jednak po prostu zawiesza się i nie odpowiada na Ctrl+C, Ctrl+Z ani nic, tylko na kill -9 w sąsiedniej konsoli. Napotkaliśmy to, gdy budowaliśmy duży klaster. Ale na razie nie mamy rozwiązania, przygotowujemy się do naprawy tego błędu w Consul.
Lider Consul nie odpowiada. Nasz master w centrum danych nie odpowiada, myślimy: "Chyba teraz zadziała algorytm ponownego wyboru?"
Nie, nie zadziała, a monitoring nic nie pokaże: Consul powie, że commitment index jest, lider znaleziony, wszystko w porządku.
Jak z tym walczymy? service consul restart w cron co godzinę. Jeśli masz 50 serwerów – to nie problem. Gdy będzie ich 16 000, zrozumiesz, jak to działa.
Podsumowanie
Ostatecznie uzyskaliśmy następujące korzyści:
- 100% pokrycie wszystkich maszyn z systemem Linux.
- Szybkość.
- Automatyzacja.
- Uw freeing hardware and network engineers from servitude.
- Pojawiły się możliwości integracji, które są praktycznie nieograniczone: z Kubernetes, z Ansible, z Pythonem.
Minusy: Consul, z którym teraz musimy żyć, oraz bardzo wysoka cena błędu. Dla przykładu, raz o 18:00 (czas szczytowy w Rosji) coś zmieniałem na listach sieci. Właśnie wtedy budowaliśmy izolację na BEFW. Gdzieś się pomyliłem, wydaje mi się, że podałem niewłaściwą maskę, a wszystko padło w ciągu dwóch sekund. Uruchomił się monitoring, przybiegł dyżurny wsparcia: "Wszystko u nas leży!" Szef działu siwieje, gdy tłumaczy biznesowi, dlaczego tak się stało.
Cena błędu jest tak wysoka, że wymyśliliśmy własną skomplikowaną procedurę zapobiegawczą. Jeśli zamierzasz wdrażać to w dużej produkcji, nie dawaj master-tokenu nad Consul wszystkim bez wyjątku. To źle się skończy.
Koszt. Spędziłem 400 godzin na pisaniu kodu samodzielnie. Na wsparcie moja czteroosobowa drużyna poświęca 10 godzin miesięcznie na wszystkich. W porównaniu z kosztami jakiejkolwiek zapory nowej generacji, to za darmo.
Plany. Długoterminowym planem jest poszukiwanie alternatywnego transportu w zamian lub dodatkowo do Consul. Może to być Kafka lub coś w tym stylu. Ale przez najbliższe lata będziemy żyć na Consul.
Najbliższe plany: integracja z Fail2ban, monitorowanie, nftables, być może z innymi dystrybucjami, metryki, rozszerzone monitorowanie, optymalizacja. Wsparcie dla Kubernetes również jest w planach, ponieważ obecnie mamy kilka klastrów i chęci.
Jeszcze z planów:
- wykrywanie anomalii w ruchu;
- zarządzanie mapą sieci;
- wsparcie dla Kubernetes;
- kompilacja pakietów dla wszystkich systemów;
- Web-UI.
Nieprzerwanie pracujemy nad rozszerzeniem konfiguracji, zwiększeniem metryk i optymalizacją.
Dołącz do projektu. Projekt stał się świetny, ale niestety to wciąż projekt jednej osoby. Przyjdź na i spróbuj coś zrobić: zakomitować, przetestować, coś zaproponować, ocenić.
W międzyczasie przygotowujemy się do , które odbędzie się 6 i 7 kwietnia w Sankt Petersburgu, i zapraszamy twórców systemów wysokoobciążeniowych . Doświadczeni prelegenci i tak wiedzą, co robić, a nowicjuszom w wystąpieniach polecamy chociażby . Udział w konferencji jako prelegent ma szereg zalet. Jakich, można przeczytać na przykład na końcu .
Źródło: habr.com
