Kompanija 2010. godine postojalo je 50 servera i jednostavan mrežni model: backend, frontend i firewall. Broj servera je rastao, model je postao složeniji: staging, izolovani VLAN sa ACL-ovima, zatim VPN-ovi sa VRF-ovima, VLAN-ovi sa ACL-ovima na L2, VRF-ovi sa ACL-ovima na L3. Vrti se u glavi? Kasnije će biti zabavnije.
Kada je bilo 16 servera, postalo je nemoguće raditi bez suza sa toliko heterogenih segmenata. Tako smo došli do drugog rješenja. Uzeli smo Netfilter stek, dodali mu Consul kao izvor podataka i dobili smo brzi distribuirani zaštitni zid. Zamijenili su ACL-ove na ruterima i koristili ih kao vanjski i interni zaštitni zid. Da bismo dinamički upravljali alatom, razvili smo BEFW sistem, koji se koristio svuda: od upravljanja pristupom korisnika mreži proizvoda do izolacije mrežnih segmenata jedan od drugog.
On će vam reći kako sve to funkcionira i zašto biste trebali detaljnije pogledati ovaj sistem. Ivan Agarkov () je šef grupe za infrastrukturnu sigurnost odjela za održavanje u razvojnom centru kompanije Minsk. Ivan je obožavatelj SELinuxa, voli Perl i piše kod. Kao šef grupe za informatičku sigurnost, redovno radi sa logovima, rezervnim kopijama i istraživanjem i razvojem kako bi zaštitio Wargaming od hakera i osigurao rad svih servera za igre u kompaniji.
Istorijski podaci
Prije nego što vam kažem kako smo to uradili, reći ću vam kako smo uopće došli do ovoga i zašto je to bilo potrebno. Da bismo to uradili, vratimo se 9 godina unazad: 2010, World of Tanks se upravo pojavio. Wargaming je imao otprilike 50 servera.
Grafikon rasta servera kompanije.
Imali smo mrežni model. Za to vrijeme je bilo optimalno.
Mrežni model iz 2010.
Postoje loši momci na front endu koji žele da nas razbiju, ali ima zaštitni zid. Nema firewall-a na backendu, ali postoji 50 servera, znamo ih sve. Sve radi dobro.
Za 4 godine, flota servera je porasla 100 puta, na 5000. Pojavile su se prve izolovane mreže - stacioniranje: nisu mogle ići u proizvodnju, a tamo su se često pokretale stvari koje su mogle biti opasne.
Mrežni model iz 2014.
Po inerciji smo koristili iste komade hardvera, a sav posao je obavljen na izolovanim VLAN-ovima: ACL-ovi se upisuju na VLAN-ove, koji dozvoljavaju ili odbijaju neku vrstu veze.
U 2016. broj servera je dostigao 8000. Wargaming je apsorbirao druge studije, a pojavile su se i dodatne partnerske mreže. Čini se da su naši, ali ne baš: VLAN često ne radi za partnere, morate koristiti VPN sa VRF-om, izolacija postaje složenija. ACL izolacijska mješavina je rasla.
Mrežni model iz 2016.
Do početka 2018. flota mašina je narasla na 16 000. Bilo je 6 segmenata, a ostale nismo računali, uključujući zatvorene u kojima su pohranjeni finansijski podaci. Pojavile su se kontejnerske mreže (Kubernetes), DevOps, mreže u oblaku povezane preko VPN-a, na primjer, iz IVS-a. Bilo je puno pravila - bilo je bolno.
Mrežni model i metode izolacije u 2018.
Za izolaciju smo koristili: VLAN sa ACL na L2, VRF sa ACL na L3, VPN i još mnogo toga. Previse.
Problemi
Svi žive sa ACL-om i VLAN-om. Sta nije u redu? Na ovo pitanje će odgovoriti Harold, skrivajući bol.
Bilo je mnogo problema, ali je bilo pet velikih.
- Geometrijsko povećanje cijena za nova pravila. Svako novo pravilo se dodavalo duže od prethodnog, jer je prvo trebalo vidjeti postoji li takvo pravilo.
- Nema zaštitnog zida unutar segmenata. Segmenti su bili nekako odvojeni jedan od drugog, a unutra već nije bilo dovoljno resursa.
- Pravila su se primjenjivala dugo vremena. Operateri su mogli ručno napisati jedno lokalno pravilo za sat vremena. Globalni je trajao nekoliko dana.
- Poteškoće s pravilima revizije. Tačnije, nije bilo moguće. Prva pravila napisana su još 2010. godine, a većina njihovih autora više nije radila za kompaniju.
- Nizak nivo kontrole infrastrukture. To je glavni problem - nismo dobro znali šta se dešava u našoj zemlji.
Ovako je izgledao mrežni inženjer 2018. kada je čuo: “Treba mi još ACL-a.”
Rešenja
Početkom 2018. odlučeno je da se nešto učini po tom pitanju.
Cijena integracija stalno raste. Polazna tačka je bila da su veliki podatkovni centri prestali podržavati izolirane VLAN-ove i ACL-ove jer je uređajima ponestalo memorije.
Rješenje: uklonili smo ljudski faktor i maksimalno automatizirali pružanje pristupa.
Primjena novih pravila traje dugo. Rješenje: ubrzati primjenu pravila, učiniti je distribuiranom i paralelnom. Ovo zahtijeva distribuirani sistem tako da se pravila isporučuju sama, bez rsync ili SFTP-a na hiljadu sistema.
Nema zaštitnog zida unutar segmenata. Firewall unutar segmenata počeo nam je dolaziti kada su se pojavili različiti servisi unutar iste mreže. Rješenje: koristite zaštitni zid na nivou hosta - zaštitne zidove zasnovane na hostu. Gotovo svugdje gdje imamo Linux, i svugdje imamo iptables, to nije problem.
Poteškoće s pravilima revizije. Rješenje: Sačuvajte sva pravila na jednom mjestu za pregled i upravljanje, tako da možemo revidirati sve.
Nizak nivo kontrole nad infrastrukturom. Rješenje: napravite popis svih usluga i pristupa između njih.
Ovo je više administrativni nego tehnički proces. Ponekad imamo 200-300 novih izdanja sedmično, posebno tokom promocija i praznika. Štaviše, ovo je samo za jedan tim našeg DevOps-a. Sa toliko izdanja, nemoguće je vidjeti koji su portovi, IP-ovi i integracije potrebni. Stoga su nam bili potrebni posebno obučeni servis menadžeri koji su pitali timove: „Šta uopće ima i zašto ste to spomenuli?“
Nakon svega što smo pokrenuli, mrežni inženjer je 2019. godine počeo izgledati ovako.
Konzul
Odlučili smo da ćemo sve što smo pronašli uz pomoć servis menadžera staviti u Consul i odatle pisati iptables pravila.
Kako smo se odlučili na ovo?
- Mi ćemo prikupiti sve usluge, mreže i korisnike.
- Kreirajmo iptables pravila na osnovu njih.
- Mi automatizujemo kontrolu.
- ....
- PROFIT.
Consul nije udaljeni API, može se pokrenuti na svakom čvoru i pisati u iptables. Ostaje samo smisliti automatske kontrole koje će očistiti nepotrebne stvari, a većina problema će biti riješena! Ostalo ćemo srediti kako idemo.
Zašto konzul?
Dobro se dokazao. U 2014-15, koristili smo ga kao backend za Vault, u koji pohranjujemo lozinke.
Ne gubi podatke. Za vrijeme korištenja, Consul nije izgubio podatke ni u jednoj nesreći. Ovo je veliki plus za sistem upravljanja zaštitnim zidom.
P2P veze ubrzavaju širenje promjena. Uz P2P, sve promjene dolaze brzo, nema potrebe čekati satima.
Pogodan REST API. Razmatrali smo i Apache ZooKeeper, ali on nema REST API, tako da ćete morati da instalirate štake.
Radi i kao Key Vault (KV) i kao direktorij (Service Discovery). Možete pohraniti usluge, kataloge i podatkovne centre odjednom. Ovo je zgodno ne samo za nas, već i za susjedne timove, jer kada gradimo globalni servis, mislimo na veliko.
Napisano u Go, koji je dio Wargaming grupe. Volimo ovaj jezik, imamo mnogo Go programera.
Moćan ACL sistem. U Consul-u možete koristiti ACL-ove za kontrolu ko piše šta. Garantujemo da se pravila firewall-a neće preklapati ni sa čim drugim i nećemo imati problema s tim.
Ali Consul ima i svojih nedostataka.
- Ne povećava se unutar data centra osim ako nemate poslovnu verziju. Skalabilan je samo od strane federacije.
- Vrlo ovisi o kvaliteti mreže i opterećenju servera. Consul neće raditi ispravno kao server na zauzetom serveru ako postoje zastoji u mreži, na primjer, neujednačena brzina. To je zbog P2P veza i modela distribucije ažuriranja.
- Poteškoće u praćenju dostupnosti. U statusu konzula može reći da je sve u redu, ali je davno umro.
Većinu ovih problema smo riješili koristeći Consul, zbog čega smo ga i odabrali. Kompanija ima planove za alternativni backend, ali mi smo naučili da se nosimo sa problemima i trenutno živimo sa Consulom.
Kako Consul radi
U uslovni data centar ćemo instalirati tri do pet servera. Jedan ili dva servera neće raditi: neće moći da organizuju kvorum i odluče ko je u pravu, a ko nije kada se podaci ne poklapaju. Više od pet nema smisla, produktivnost će pasti.
Klijenti se povezuju na servere bilo kojim redoslijedom: isti agenti, samo sa zastavicom server = false.
Nakon toga, klijenti dobijaju listu P2P veza i grade veze među sobom.
Na globalnom nivou povezujemo nekoliko data centara. Oni također povezuju P2P i komuniciraju.
Kada želimo da preuzmemo podatke iz drugog data centra, zahtev ide od servera do servera. Ova šema se zove Serf protokol. Protokol Serf, kao i Consul, razvija HashiCorp.
Nekoliko važnih činjenica o Konzulu
Konzul ima dokumentaciju koja opisuje kako to funkcionira. Navest ću samo odabrane činjenice koje vrijedi znati.
Konzulski serveri biraju gospodara među glasačima. Konzul bira master sa liste servera za svaki data centar i svi zahtevi idu samo njemu, bez obzira na broj servera. Glavno zamrzavanje ne dovodi do ponovnog izbora. Ako master nije odabran, zahtjeve niko ne servisira.
Da li ste želeli horizontalno skaliranje? Izvini, ne.
Zahtjev prema drugom podatkovnom centru ide od mastera do mastera, bez obzira na koji server je došao. Odabrani master prima 100% opterećenja, osim opterećenja na zahtjeve za prosljeđivanje. Svi serveri u data centru imaju ažurnu kopiju podataka, ali samo jedan odgovara.
Jedini način za skaliranje je da omogućite zastarjeli način na klijentu.
U zastarjelom načinu možete odgovoriti bez kvoruma. Ovo je način u kojem odustajemo od konzistentnosti podataka, ali čitamo malo brže nego inače, a svaki server odgovara. Naravno, snimanje samo preko mastera.
Konzul ne kopira podatke između data centara. Kada se sastavi federacija, svaki server će imati samo svoje podatke. Za druge se uvijek okreće nekom drugom.
Atomičnost operacija nije zagarantovana izvan transakcije. Zapamtite da niste jedini koji može promijeniti stvari. Ako želite drugačije, izvršite transakciju sa zaključavanjem.
Operacije blokiranja ne garantuju zaključavanje. Zahtjev ide od mastera do mastera, a ne direktno, tako da nema garancije da će blokiranje funkcionirati kada blokirate, na primjer, u drugom podatkovnom centru.
ACL takođe ne garantuje pristup (u mnogim slučajevima). ACL možda neće raditi jer je pohranjen u jednom centru podataka federacije - u ACL centru podataka (primarni DC). Ako vam DC ne odgovori, ACL neće raditi.
Jedan zamrznuti gospodar će uzrokovati zamrzavanje cijele federacije. Na primjer, postoji 10 centara podataka u federaciji, i jedan ima lošu mrežu, a jedan master ne radi. Svi koji komuniciraju s njim će se ukočiti u krug: postoji zahtjev, nema odgovora na njega, nit se zamrzava. Ne postoji način da se zna kada će se to dogoditi, samo za sat-dva cela federacija će pasti. Ne možete ništa učiniti povodom toga.
Status, kvorum i izbori obrađuju se u posebnoj niti. Reizbor se neće desiti, status neće ništa pokazati. Misliš da imaš živog Konzula, pitaš, a ništa se ne dešava - nema odgovora. Istovremeno, status pokazuje da je sve u redu.
Naišli smo na ovaj problem i morali smo ponovo izgraditi određene dijelove podatkovnih centara kako bismo ga izbjegli.
Poslovna verzija Consul Enterprisea nema neke od gore navedenih nedostataka. Ima mnogo korisnih funkcija: odabir birača, raspodjela, skaliranje. Postoji samo jedno „ali“ - sistem licenciranja za distribuirani sistem je veoma skup.
Hakovanje života: rm -rf /var/lib/consul - lijek za sve bolesti uzročnika. Ako vam nešto ne radi, samo izbrišite svoje podatke i preuzmite podatke iz kopije. Najvjerovatnije će Konzul raditi.
BEFW
Hajde sada da razgovaramo o tome šta smo dodali Konzulu.
je akronim za BackEndFljutnjaWsve. Morao sam nekako imenovati proizvod kada sam kreirao spremište kako bih u njega stavio prve testne urezivanja. Ovo ime ostaje.
Predlošci pravila
Pravila su napisana u iptables sintaksi.
- -N BEFW
- -P INPUT DROP
- -A ULAZ -m stanje—stanje POVEZANO, UTVRĐENO -j PRIHVATI
- -A ULAZ -i lo -j PRIHVATI
- -A INPUT -j BEFW
Sve ide u lanac BEFW, osim ESTABLISHED, RELATED i localhost. Šablon može biti bilo koji, ovo je samo primjer.
Kako je BEFW koristan?
usluge
Imamo servis, on uvijek ima port, čvor na kojem radi. Iz našeg čvora možemo lokalno pitati agenta i saznati da imamo neku vrstu usluge. Takođe možete staviti oznake.
Svaki servis koji je pokrenut i registrovan kod Consul-a pretvara se u iptables pravilo. Imamo SSH - otvoreni port 22. Bash skripta je jednostavna: curl i iptables, ništa drugo nije potrebno.
Klijenti
Kako otvoriti pristup ne svima, već selektivno? Dodajte IP liste u KV memoriju prema nazivu usluge.
Na primjer, želimo da svi u desetoj mreži mogu pristupiti usluzi SSH_TCP_22. Dodati jedno malo TTL polje? a sada imamo privremene dozvole, na primjer, na jedan dan.
Pristupi
Povezujemo usluge i klijente: imamo servis, KV skladište je spremno za svaki. Sada dajemo pristup ne svima, već selektivno.
grupe
Ako svaki put napišemo hiljade IP adresa za pristup, umorićemo se. Hajde da smislimo grupisanje - poseban podskup u KV. Nazovimo to Alias (ili grupe) i pohranimo grupe tamo po istom principu.
Povežimo se: sada možemo otvoriti SSH ne posebno za P2P, već za cijelu grupu ili nekoliko grupa. Na isti način postoji i TTL - možete dodati u grupu i privremeno ukloniti iz grupe.
Integracija
Naš problem je ljudski faktor i automatizacija. Do sada smo to rješavali na ovaj način.
Radimo sa Puppet-om, i prenosimo sve što se odnosi na sistem (aplikacijski kod) na njih. Puppetdb (obični PostgreSQL) pohranjuje listu servisa koji se tamo izvode, mogu se pronaći po tipu resursa. Tamo možete saznati ko se gdje prijavljuje. Za ovo imamo i sistem zahtjeva za povlačenjem i spajanjem.
Napisali smo befw-sync, jednostavno rješenje koje pomaže u prijenosu podataka. Prvo, kolačićima za sinhronizaciju pristupa puppetdb. Tamo je konfigurisan HTTP API: tražimo koje usluge imamo, šta treba uraditi. Zatim upućuju zahtjev konzulu.
Postoji li integracija? Da: napisali su pravila i dozvolili prihvatanje zahtjeva za povlačenjem. Treba li vam određeni port ili dodati host u neku grupu? Zahtjev za povlačenjem, pregled - nema više “Pronađite 200 drugih ACL-ova i pokušajte nešto učiniti u vezi s tim.”
Optimizacija
Pingiranje lokalnog hosta s praznim lancem pravila traje 0,075 ms.
Dodajmo 10 iptables adresa u ovaj lanac. Kao rezultat toga, ping će se povećati 000 puta: iptables je potpuno linearan, obrada svake adrese traje neko vrijeme.
Za zaštitni zid u koji migriramo hiljade ACL-ova, imamo mnogo pravila, a to dovodi do kašnjenja. Ovo je loše za protokole za igre.
Ali ako stavimo 10 adresa u ipsetu Ping će se čak i smanjiti.
Poenta je da je “O” (složenost algoritma) za ipset uvijek jednak 1, bez obzira koliko pravila postoji. Istina, postoji ograničenje - ne može biti više od 65535 pravila. Za sada živimo s ovim: možete ih kombinirati, proširiti, napraviti dva ipseta u jednom.
Skladištenje
Logičan nastavak procesa iteracije je pohranjivanje informacija o klijentima za uslugu u ipset.
Sada imamo isti SSH i ne pišemo 100 IP adresa odjednom, već postavljamo ime ipseta sa kojim treba da komuniciramo i sledeće pravilo DROP. Može se pretvoriti u jedno pravilo „Ko nije tu, PUSTI“, ali je jasnije.
Sada imamo pravila i setove. Glavni zadatak je napraviti skup prije pisanja pravila, jer inače iptables neće napisati pravilo.
Opšta šema
U obliku dijagrama, sve što sam rekao izgleda ovako.
Obvezujemo se na Puppet, sve se šalje hostu, servisi ovdje, ipset tamo, a ko nije registriran tamo nije dozvoljen.
Dozvoli i zabrani
Da bismo brzo spasili svijet ili brzo onemogućili nekoga, na početku svih lanaca napravili smo dva ipseta: rules_allow и rules_deny. Kako radi?
Na primjer, neko stvara opterećenje na našem webu botovima. Ranije ste morali pronaći njegovu IP adresu iz logova, odnijeti je mrežnim inženjerima, kako bi pronašli izvor prometa i zabranili ga. Sada izgleda drugačije.
Šaljemo Konzulu, čekamo 2,5 sekunde i gotovo. Budući da Consul brzo distribuira putem P2P-a, radi svuda, u bilo kojem dijelu svijeta.
Jednom sam nekako potpuno zaustavio WOT zbog greške sa firewall-om. rules_allow - ovo je naše osiguranje od takvih slučajeva. Ako smo negde pogrešili sa firewall-om, negde je nešto blokirano, uvek možemo poslati uslov 0.0/0da brzo sve pokupim. Kasnije ćemo sve popraviti ručno.
Ostali setovi
Možete dodati bilo koje druge setove u prostor $IPSETS$.
Za što? Ponekad je nekome potreban ipset, na primjer, da emulira gašenje nekog dijela klastera. Svako može donijeti bilo koje setove, imenovati ih, a oni će se preuzeti od Konzula. Istovremeno, skupovi mogu ili učestvovati u iptables pravilima ili djelovati kao tim NOOP: Dosljednost će održavati demon.
korisnici
Ranije je to bilo ovako: korisnik se povezivao na mrežu i primao parametre preko domene. Pre pojave zaštitnih zidova nove generacije, Cisco nije znao kako da razume gde je korisnik i gde je IP. Stoga je pristup odobren samo preko imena hosta mašine.
sta smo uradili? Zapeli smo u trenutku kada smo dobili adresu. Obično je to dot1x, Wi-Fi ili VPN - sve ide kroz RADIUS. Za svakog korisnika kreiramo grupu po korisničkom imenu i u nju postavljamo IP sa TTL-om koji je jednak njegovom dhcp.lease - čim istekne, pravilo će nestati.
Sada možemo otvoriti pristup uslugama, kao i drugim grupama, po korisničkom imenu. Otklonili smo bol od imena hostova kada se mijenjaju i skinuli smo teret sa mrežnih inženjera jer im više nije potreban Cisco. Sada sami inženjeri registruju pristup na svojim serverima.
Izolacija
Istovremeno smo počeli da demontiramo izolaciju. Servisni menadžeri su izvršili inventuru, a mi smo analizirali sve naše mreže. Podijelimo ih u iste grupe, a na potrebnim serverima grupe su dodane, na primjer, za odbijanje. Sada ista scenska izolacija završava u rules_deny produkcije, ali ne i u samoj produkciji.
Shema radi brzo i jednostavno: uklanjamo sve ACL-ove sa servera, rasterećujemo hardver i smanjujemo broj izolovanih VLAN-ova.
Kontrola integriteta
Ranije smo imali poseban okidač koji je prijavljivao kada je neko ručno promijenio pravilo zaštitnog zida. Pisao sam ogroman linter za provjeru pravila zaštitnog zida, bilo je teško. Integritet sada kontroliše BEFW. On revnosno pazi da se pravila koja donosi ne mijenjaju. Ako neko promijeni pravila zaštitnog zida, promijenit će sve natrag. „Brzo sam postavio proxy da bih mogao da radim od kuće“—nema više takvih opcija.
BEFW kontroliše ipset iz usluga i navodi u befw.conf, pravila usluga u BEFW lancu. Ali ne prati druge lance i pravila i druge ipsete.
Zaštita od sudara
BEFW uvijek pohranjuje posljednje poznato dobro stanje direktno u binarnu strukturu state.bin. Ako nešto krene po zlu, uvijek se vraća na ovo stanje.bin.
Ovo je osiguranje od nestabilnog rada Konzula, kada nije poslao podatke ili je neko napravio grešku i koristio pravila koja se ne mogu primijeniti. Kako bismo osigurali da ne ostanemo bez zaštitnog zida, BEFW će se vratiti na najnovije stanje ako dođe do greške u bilo kojoj fazi.
U kritičnim situacijama, ovo je garancija da ćemo ostati sa ispravnim firewall-om. Otvaramo sve sive mreže u nadi da će admin doći i popraviti. Jednog dana ću ovo staviti u konfiguracije, ali sada imamo samo tri sive mreže: 10/8, 172/12 i 192.168/16. Unutar našeg konzula, ovo je važna karakteristika koja nam pomaže da se dalje razvijamo.
Demo: tokom izvještaja, Ivan demonstrira demo način rada BEFW-a. Lakše je gledati demonstraciju . Demo izvorni kod dostupan .
zamke
Reći ću vam o greškama na koje smo naišli.
ipset dodati set 0.0.0.0/0. Šta se dešava ako dodate 0.0.0.0/0 u ipset? Hoće li svi IP biti dodati? Hoće li biti dostupan pristup internetu?
Ne, dobićemo grešku koja nas košta dva sata zastoja. Štaviše, greška ne radi od 2016. godine, nalazi se u RedHat Bugzilla pod brojem #1297092, a pronašli smo je slučajno - iz izvještaja programera.
Sada je to strogo pravilo u BEFW-u 0.0.0.0/0 pretvara se u dvije adrese: 0.0.0.0/1 и 128.0.0.0/1.
ipset restart set < fajl. Šta ipset radi kada mu vi kažete restore? Mislite li da radi isto kao iptables? Hoće li oporaviti podatke?
Ništa slično - spaja se, a stare adrese ne idu nikuda, ne blokirate pristup.
Pronašli smo grešku prilikom testiranja izolacije. Sada postoji prilično složen sistem - umjesto restore se sprovodi create temponda restore flush temp и restore temp. Na kraju zamjene: za atomičnost, jer ako to prvo uradite flush i u ovom trenutku stigne neki paket, bit će odbačen i nešto će poći naopako. Dakle, tu je malo crne magije.
konzul kv get -datacenter=ostalo. Kao što sam rekao, mislimo da tražimo neke podatke, ali ćemo ili dobiti podatke ili grešku. To možemo učiniti preko konzulata lokalno, ali u ovom slučaju će se oboje zamrznuti.
Lokalni Consul klijent je omotač preko HTTP API-ja. Ali samo visi i ne reaguje samo na Ctrl+C, ili Ctrl+Z, ili bilo šta drugo kill -9 u sledećoj konzoli. Na ovo smo se susreli kada smo pravili veliki klaster. Ali još nemamo rješenje, spremamo se da ispravimo ovu grešku u Consulu.
Lider konzula ne odgovara. Naš gospodar u data centru ne odgovara, mislimo: "Možda će algoritam ponovnog odabira sada raditi?"
Ne, neće raditi, a praćenje neće pokazati ništa: Konzul će reći da postoji indeks posvećenosti, lider je pronađen, sve je u redu.
Kako da se nosimo sa ovim? service consul restart u cron svaki sat. Ako imate 50 servera, ništa strašno. Kada ih bude 16, shvatićete kako to funkcioniše.
zaključak
Kao rezultat, dobili smo sljedeće prednosti:
- 100% pokrivenost svih Linux mašina.
- Brzina
- Automatizacija.
- Oslobodili smo hardverske i mrežne inženjere iz ropstva.
- Pojavile su se mogućnosti integracije koje su gotovo neograničene: čak i sa Kubernetesom, čak i sa Ansibleom, čak i sa Pythonom.
Minusy: Konzul, s kojim sada moramo živjeti, i vrlo visoka cijena greške. Na primjer, jednom u 6 sati (prime time u Rusiji) uređivao sam nešto na listama mreža. U to vrijeme samo smo gradili izolaciju u BEFW-u. Negdje sam pogriješio, izgleda da sam naznačio pogrešnu masku, ali sve je palo za dvije sekunde. Monitoring svijetli, dežurna osoba za podršku trči: “Imamo sve!” Šef odjeljenja je posijedio kada je biznisu objasnio zašto se to dogodilo.
Cijena greške je toliko visoka da smo osmislili vlastitu složenu proceduru prevencije. Ako ovo implementirate na velikom proizvodnom mjestu, ne morate svima davati master token nad Consulom. Ovo će se loše završiti.
Troškovi Pisao sam kod 400 sati sam. Moj tim od 4 osobe troši 10 sati mjesečno na podršku svima. U poređenju sa cijenom bilo kojeg vatrozida nove generacije, besplatan je.
Planovi. Dugoročni plan je pronaći alternativni prijevoz koji bi zamijenio ili dopunio Consul. Možda će to biti Kafka ili nešto slično. Ali u narednim godinama živjet ćemo na Konzulu.
Neposredni planovi: integracija sa Fail2ban, sa praćenjem, sa nftables, eventualno sa drugim distribucijama, metrika, napredno praćenje, optimizacija. Kubernetes podrška je također negdje u planu, jer sada imamo nekoliko klastera i želju.
Više iz planova:
- traženje anomalija u saobraćaju;
- upravljanje mrežnom mapom;
- Kubernetes podrška;
- sastavljanje paketa za sve sisteme;
- Web-UI.
Konstantno radimo na proširenju konfiguracije, povećanju metrike i optimizaciji.
Pridružite se projektu. Ispostavilo se da je projekat kul, ali je, nažalost, još uvijek projekt jedne osobe. Doći i pokušajte nešto učiniti: posvetite se, testirajte, predložite nešto, dajte svoju procjenu.
U međuvremenu se pripremamo za , koji će se održati 6. i 7. aprila u Sankt Peterburgu, a mi pozivamo programere sistema visokog opterećenja . Iskusni govornici već znaju šta da rade, ali za one koji su novi u govoru preporučujemo barem . Učešće na konferenciji kao govornik ima niz prednosti. Koje, na primjer, možete pročitati na kraju .
izvor: www.habr.com