Tvrtka je 2010 bilo je 50 poslužitelja i jednostavan mrežni model: backend, frontend i firewall. Broj poslužitelja je rastao, model je postao složeniji: staging, izolirani VLAN-ovi s ACL-ovima, zatim VPN-ovi s VRF-ovima, VLAN-ovi s ACL-ovima na L2, VRF-ovi s ACL-ovima na L3. Vrti li se u glavi? Kasnije će biti zabavnije.
Kada je bilo 16 servera, postalo je nemoguće raditi bez suza s toliko heterogenih segmenata. Pa smo došli do drugog rješenja. Uzeli smo Netfilter stog, dodali mu Consul kao izvor podataka i dobili smo brzi distribuirani vatrozid. Zamijenili su ACL-ove na usmjerivačima i koristili ih kao vanjski i unutarnji vatrozid. Za dinamičko upravljanje alatom razvili smo BEFW sustav koji se koristio posvuda: od upravljanja pristupom korisnika mreži proizvoda do međusobnog izoliranja mrežnih segmenata.
On će vam reći kako to sve funkcionira i zašto biste trebali bolje pogledati ovaj sustav. Ivan Agarkov () voditelj je grupe za sigurnost infrastrukture odjela za održavanje u razvojnom centru tvrtke u Minsku. Ivan je obožavatelj SELinuxa, voli Perl i piše kod. Kao voditelj grupe za informacijsku sigurnost, redovito radi s zapisnicima, sigurnosnim kopijama i istraživanjem i razvojem kako bi zaštitio Wargaming od hakera i osigurao rad svih poslužitelja igara u tvrtki.
Povijest
Prije nego što vam kažem kako smo to uspjeli, reći ću vam kako smo uopće došli do ovoga i zašto je to bilo potrebno. Da bismo to učinili, vratimo se 9 godina unatrag: 2010., World of Tanks se upravo pojavio. Wargaming je imao otprilike 50 servera.
Grafikon rasta poslužitelja tvrtke.
Imali smo mrežni model. Za ono vrijeme to je bilo optimalno.
Model mreže 2010.
Postoje negativci na prednjoj strani koji nas žele slomiti, ali ima vatrozid. Nema vatrozida na pozadini, ali tamo ima 50 servera, sve ih poznajemo. Sve radi dobro.
U 4 godine flota servera narasla je 100 puta, na 5000. Pojavile su se prve izolirane mreže – staging: nisu mogle ići u produkciju, a tamo su često bile pokrenute stvari koje su mogle biti opasne.
Model mreže 2014.
Inercijom smo koristili iste dijelove hardvera, a sav posao je obavljen na izoliranim VLAN-ovima: ACL-ovi se upisuju u VLAN-ove koji dopuštaju ili odbijaju neku vrstu veze.
U 2016. broj poslužitelja dosegao je 8000. Wargaming je apsorbirao druge studije, a pojavile su se i dodatne pridružene mreže. Čini se da su naši, ali ne baš: VLAN često ne radi za partnere, morate koristiti VPN s VRF-om, izolacija postaje kompliciranija. ACL izolacijska smjesa je rasla.
Model mreže 2016.
Do početka 2018. flota strojeva narasla je na 16 000. Bilo je 6 segmenata, a ostale nismo računali, uključujući zatvorene u kojima su pohranjeni financijski 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 s ACL-om na L2, VRF s ACL-om na L3, VPN i još mnogo toga. Previše.
Problemi
Svi žive s ACL-om i VLAN-om. Što nije u redu? Na ovo pitanje će odgovoriti Harold, skrivajući bol.
Problema je bilo mnogo, ali bilo je pet velikih.
- Geometrijsko povećanje cijene za nova pravila. Dodavanje svakog novog pravila trajalo je dulje od prethodnog, jer je prvo bilo potrebno vidjeti postoji li takvo pravilo.
- Nema vatrozida unutar segmenata. Segmenti su bili nekako odvojeni jedan od drugog, a unutra već nije bilo dovoljno resursa.
- Pravila su se dugo primjenjivala. Operateri mogu napisati jedno lokalno pravilo rukom u sat vremena. Globalna je trajala nekoliko dana.
- Poteškoće s pravilima revizije. Točnije, nije bilo moguće. Prva pravila napisana su još 2010. godine, a većina njihovih autora više nije radila u tvrtki.
- Niska razina kontrole infrastrukture. To je glavni problem - nismo dobro znali što se događa u našoj zemlji.
Ovako je izgledao mrežni inženjer 2018. kada je čuo: "Trebam još ACL-a."
rješenja
Početkom 2018. godine odlučeno je nešto poduzeti po tom pitanju.
Cijena integracija stalno raste. Polazna toč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.
Za primjenu novih pravila potrebno je dosta vremena. Rješenje: ubrzati primjenu pravila, učiniti je distribuiranom i paralelnom. To zahtijeva distribuirani sustav tako da se pravila isporučuju sama, bez rsync ili SFTP na tisuću sustava.
Nema vatrozida unutar segmenata. Vatrozid unutar segmenata počeo nam je dolaziti kada su se unutar iste mreže pojavili različiti servisi. Rješenje: koristite vatrozid na razini glavnog računala - vatrozid baziran na glavnom računalu. Gotovo svugdje gdje imamo Linux, i svugdje gdje imamo iptables, to nije problem.
Poteškoće s pravilima revizije. Rješenje: Držite sva pravila na jednom mjestu za pregled i upravljanje, tako da možemo sve revidirati.
Niska razina 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 tjedno, posebno tijekom promocija i praznika. Štoviše, ovo je samo za jedan tim našeg DevOps-a. Uz toliko izdanja, nemoguće je vidjeti koji su priključci, IP-ovi i integracije potrebni. Stoga su nam bili potrebni posebno obučeni voditelji servisa koji su pitali timove: “Što je tu uopće i zašto ste to spomenuli?”
Nakon svega što smo pokrenuli, mrežni inženjer 2019. počeo je izgledati ovako.
Konzul
Odlučili smo da ćemo sve što nađemo uz pomoć servis menadžera staviti u Consul i odatle pisati iptables pravila.
Kako smo se odlučili na ovo?
- Prikupit ćemo sve usluge, mreže i korisnike.
- Kreirajmo iptables pravila na temelju njih.
- Automatiziramo kontrolu.
- ....
- DOBIT.
Consul nije udaljeni API, može raditi na svakom čvoru i pisati u iptables. Ostaje samo smisliti automatske kontrole koje će očistiti nepotrebne stvari i većina problema će biti riješena! Ostalo ćemo riješiti u hodu.
Zašto konzul?
Dobro se dokazao. U 2014.-15. koristili smo ga kao pozadinu za Vault, u kojem pohranjujemo lozinke.
Ne gubi podatke. Tijekom vremena korištenja, Consul nije izgubio podatke niti u jednoj nezgodi. Ovo je veliki plus za sustav upravljanja vatrozidom.
P2P veze ubrzavaju širenje promjena. Uz P2P, sve promjene dolaze brzo, nema potrebe čekati satima.
Zgodan REST API. Razmotrili smo i Apache ZooKeeper, ali on nema REST API, pa ćete morati instalirati štake.
Radi i kao trezor ključeva (KV) i kao imenik (otkrivanje usluga). Možete pohraniti usluge, kataloge i podatkovne centre odjednom. To je zgodno ne samo za nas, već i za susjedne timove, jer kada gradimo globalnu uslugu, razmišljamo na veliko.
Napisano u Gou, koji je dio Wargaming paketa. Volimo ovaj jezik, imamo mnogo Go programera.
Snažan ACL sustav. U Consulu možete koristiti ACL-ove za kontrolu tko što piše. Jamčimo da se pravila vatrozida neće preklapati ni sa čim drugim i da s tim nećemo imati problema.
Ali Consul ima i svojih nedostataka.
- Ne skalira se unutar podatkovnog centra osim ako nemate poslovnu verziju. Skalabilan je samo prema federaciji.
- Vrlo ovisi o kvaliteti mreže i opterećenju poslužitelja. Consul neće ispravno raditi kao poslužitelj na zauzetom poslužitelju ako postoje bilo kakvi zastoji u mreži, na primjer, nejednaka brzina. To je zbog P2P veza i modela distribucije ažuriranja.
- Poteškoće s praćenjem dostupnosti. U statusu konzula može reći da je sve u redu, ali on je davno umro.
Većinu ovih problema riješili smo koristeći Consul, zato smo ga i odabrali. Tvrtka ima planove za alternativnu pozadinu, ali naučili smo se nositi s problemima i trenutno živimo s Consulom.
Kako Consul radi
Instalirat ćemo tri do pet servera u uvjetnom podatkovnom centru. Jedan ili dva poslužitelja neće raditi: neće moći organizirati kvorum i odlučiti tko je u pravu, a tko u krivu kada se podaci ne podudaraju. Više od pet nema smisla, produktivnost će pasti.
Klijenti se povezuju na poslužitelje bilo kojim redoslijedom: isti agenti, samo s oznakom server = false.
Nakon toga klijenti dobivaju popis P2P veza i međusobno grade veze.
Na globalnoj razini povezujemo nekoliko podatkovnih centara. Oni također povezuju P2P i komuniciraju.
Kada želimo dohvatiti podatke iz drugog podatkovnog centra, zahtjev ide od poslužitelja do poslužitelja. Ova shema se zove Kmetovski protokol. Serf protokol, kao i Consul, razvija HashiCorp.
Nekoliko važnih činjenica o konzulu
Consul ima dokumentaciju koja opisuje kako to radi. Navest ću samo odabrane činjenice koje vrijedi znati.
Poslužitelji konzula biraju gospodara među glasačima. Consul s popisa poslužitelja za svaki podatkovni centar odabire mastera i svi zahtjevi idu samo njemu, bez obzira na broj poslužitelja. Master zamrzavanje ne dovodi do reizbora. Ako master nije odabran, zahtjeve nitko ne servisira.
Jeste li htjeli horizontalno skaliranje? Žao mi je, ne.
Zahtjev 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 prosljeđivanje zahtjeva. Svi poslužitelji u podatkovnom centru imaju ažurnu kopiju podataka, ali samo jedan odgovara.
Jedini način skaliranja je omogućiti ustajali način rada na klijentu.
U zastarjelom načinu možete odgovoriti bez kvoruma. Ovo je način rada u kojem se odričemo konzistentnosti podataka, ali čitamo malo brže nego inače, a svaki poslužitelj odgovara. Naravno, snimanje samo preko mastera.
Consul ne kopira podatke između podatkovnih centara. Kada se federacija sastavi, svaki poslužitelj će imati samo svoje podatke. Za druge se uvijek okrene nekom drugom.
Atomičnost operacija nije zajamčena izvan transakcije. Zapamtite da niste jedini koji mogu promijeniti stvari. Ako želite drugačije, izvršite transakciju s zaključavanjem.
Operacije blokiranja ne jamče zaključavanje. Zahtjev ide od mastera do mastera, a ne izravno, tako da nema jamstva da će blokiranje funkcionirati kada blokirate, na primjer, u drugom podatkovnom centru.
ACL također ne jamči pristup (u mnogim slučajevima). ACL možda neće raditi jer je pohranjen u jednom federalnom podatkovnom centru - u ACL podatkovnom centru (Primarni DC). Ako vam DC ne odgovori, ACL neće raditi.
Jedan zamrznuti majstor će uzrokovati zamrzavanje cijele federacije. Na primjer, postoji 10 podatkovnih centara u federaciji, jedan ima lošu mrežu, a jedan glavni kvari. Svi koji komuniciraju s njim zaglavit će u krugu: postoji zahtjev, nema odgovora na njega, nit se smrzava. Nema šanse da se zna kada će se to dogoditi, za sat-dva će pasti cijela federacija. Ne možete ništa učiniti u vezi s tim.
Status, kvorum i izbori obrađuju se u zasebnoj niti. Reizbor se neće dogoditi, status neće pokazati ništa. Misliš da imaš živog Konzula, pitaš, ništa se ne događa - nema odgovora. Istovremeno, status pokazuje da je sve u redu.
Susreli smo se s ovim problemom i morali smo ponovno 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, distribucija, skaliranje. Postoji samo jedan "ali" - sustav licenciranja za distribuirani sustav je vrlo skup.
Život sjeckanje: rm -rf /var/lib/consul - lijek za sve bolesti uzročnika. Ako vam nešto ne ide, samo izbrišite svoje podatke i preuzmite podatke iz kopije. Najvjerojatnije će Consul raditi.
BEFW
Sada razgovarajmo o tome što smo dodali Consulu.
je akronim za BackEndFgnjevWsvi. Morao sam nekako imenovati proizvod kada sam kreirao repozitorij kako bih u njega stavio prve probne obveze. Ovo ime ostaje.
Predlošci pravila
Pravila su napisana u iptables sintaksi.
- -N BEFW
- -P ULAZNI PAD
- -A INPUT -m stanje—stanje POVEZANO,UTVRĐENO -j PRIHVATLJIV
- -A INPUT -i lo -j ACCEPT
- -A INPUT -j BEFW
Sve ide u lanac BEFW, osim ESTABLISHED, RELATED i lokalni host. Predložak može biti bilo koji, ovo je samo primjer.
Kako je BEFW koristan?
Usluge
Imamo uslugu, ona uvijek ima port, čvor na kojem radi. Iz našeg čvora možemo lokalno pitati agenta i saznati da imamo neku vrstu usluge. Također možete staviti oznake.
Svaka usluga koja je pokrenuta i registrirana kod Consula pretvara se u pravilo iptables. 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 pohranu prema nazivu usluge.
Na primjer, želimo da svi na desetoj mreži mogu pristupiti usluzi SSH_TCP_22. Dodati jedno malo TTL polje? a sada imamo privremene dozvole npr. na jedan dan.
Pristupi
Povezujemo usluge i klijente: imamo servis, KV skladište je spremno za svakog. Sada ne dajemo pristup svima, već selektivno.
Skupina
Ako svaki put napišemo tisuće IP adresa za pristup, umorit ćemo se. Smislimo grupiranje - zaseban podskup u KV. Nazovimo to alias (ili grupe) i tamo pohranimo grupe prema 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 TTL - možete dodati u grupu i privremeno ukloniti iz grupe.
integracija
Naš problem je ljudski faktor i automatika. Do sada smo to rješavali na ovaj način.
Surađujemo s Puppetom, te im prenosimo sve što se odnosi na sustav (kod aplikacije). Puppetdb (obični PostgreSQL) pohranjuje popis servisa koji se tamo izvode, mogu se pronaći prema vrsti resursa. Tamo možete saznati tko se gdje prijavljuje. Za to također imamo sustav zahtjeva za povlačenjem i zahtjevom za spajanje.
Napisali smo befw-sync, jednostavno rješenje koje pomaže u prijenosu podataka. Prvo, kolačićima za sinkronizaciju pristupa puppetdb. Tamo je konfiguriran HTTP API: tražimo koje usluge imamo, što treba učiniti. Zatim upućuju zahtjev konzulu.
Postoji li integracija? Da: napisali su pravila i dopustili prihvaćanje zahtjeva za povlačenjem. Trebate li određeni port ili želite dodati host u neku grupu? Zahtjev za povlačenjem, pregled - nema više "Pronađi 200 drugih ACL-ova i pokušaj učiniti nešto u vezi s tim."
Optimizacija
Pingiranje lokalnog hosta s praznim lancem pravila traje 0,075 ms.
Dodajmo 10 000 iptables adresa ovom lancu. Kao rezultat toga, ping će se povećati 5 puta: iptables je potpuno linearan, obrada svake adrese traje neko vrijeme.
Za vatrozid na koji migriramo tisuće ACL-ova, imamo puno pravila, a to uvodi kašnjenje. To je loše za protokole igranja.
Ali ako stavimo 10 000 adresa u ipsetu Ping će se čak smanjiti.
Poanta je da je "O" (složenost algoritma) za ipset uvijek jednako 1, bez obzira koliko pravila postoji. Istina, postoji ograničenje - pravila ne može biti više od 65535. Za sada živimo s ovim: možete ih kombinirati, proširivati, napraviti dva ipseta u jednom.
Skladištenje
Logičan nastavak procesa ponavljanja je pohranjivanje informacija o klijentima usluge u ipset.
Sada imamo isti SSH, i ne pišemo 100 IP odjednom, već postavljamo ime ipseta s kojim trebamo komunicirati i sljedeće pravilo DROP. Može se pretvoriti u jedno pravilo "Tko nije ovdje, ISPUSTI", ali je jasnije.
Sada imamo pravila i skupove. Glavni zadatak je napraviti set prije pisanja pravila, jer inače iptables neće napisati pravilo.
Opća shema
U obliku dijagrama sve što sam rekao izgleda ovako.
Obavezujemo se na Puppet, sve se šalje hostu, usluge ovdje, ipset tamo, a tko nije registriran tamo ne ulazi.
Dopusti & zabrani
Kako bismo brzo spasili svijet ili brzo onesposobili nekoga, na početku svih lanaca napravili smo dva ipseta: rules_allow и rules_deny. Kako radi?
Na primjer, netko botovima stvara opterećenje na našem webu. Prije ste morali pronaći njegov IP iz logova, odnijeti ga mrežnim inženjerima, kako bi oni pronašli izvor prometa i banirali ga. Sada izgleda drugačije.
Šaljemo ga konzulu, čekamo 2,5 sekunde i gotovo. Budući da Consul brzo distribuira putem P2P-a, radi svugdje, u bilo kojem dijelu svijeta.
Jednom sam nekako potpuno zaustavio WOT zbog greške s vatrozidom. rules_allow - ovo je naše osiguranje od takvih slučajeva. Ako smo negdje pogriješili s vatrozidom, negdje je nešto blokirano, uvijek možemo poslati uvjet 0.0/0da brzo sve pokupi. Kasnije ćemo sve popraviti ručno.
Ostali setovi
U prostoru možete dodati bilo koje druge setove $IPSETS$.
Za što? Ponekad nekome treba ipset, na primjer, da emulira gašenje nekog dijela klastera. Svatko može donijeti bilo koji set, imenovati ga i preuzet će ga kod konzula. U isto vrijeme, skupovi mogu sudjelovati u pravilima iptables ili djelovati kao tim NOOP: Dosljednost će održavati demon.
Članovi
Prije je to bilo ovako: korisnik se spajao na mrežu i primao parametre preko domene. Prije pojave vatrozida nove generacije, Cisco nije znao kako razumjeti gdje je korisnik, a gdje IP. Stoga je pristup dopušten samo preko imena računala.
Što smo učinili? Zapeli smo u trenutku kada smo primili adresu. Obično je to dot1x, Wi-Fi ili VPN - sve ide preko RADIUS-a. Za svakog korisnika kreiramo grupu prema korisničkom imenu i u nju postavimo IP s TTL-om koji je jednak njegovom dhcp.lease - čim istekne, pravilo će nestati.
Sada možemo otvoriti pristup uslugama, poput drugih grupa, pomoću korisničkog imena. Uklonili smo probleme s imenima računala kada se mijenjaju i skinuli smo teret s mrežnih inženjera jer im Cisco više nije potreban. Sada sami inženjeri registriraju pristup na svojim poslužiteljima.
izolacija
Istovremeno smo počeli demontirati izolaciju. Voditelji servisa napravili su popis, a mi smo analizirali sve naše mreže. Podijelimo ih u iste grupe, a na potrebnim poslužiteljima dodane su grupe, na primjer, za odbijanje. Sada ista inscenacijska izolacija završava u rules_deny produkcije, ali ne i u samoj produkciji.
Shema radi brzo i jednostavno: uklanjamo sve ACL-ove s poslužitelja, rasterećujemo hardver i smanjujemo broj izoliranih VLAN-ova.
Kontrola integriteta
Ranije smo imali poseban okidač koji je javljao kada je netko ručno promijenio pravilo vatrozida. Pisao sam veliki linter za provjeru pravila vatrozida, bilo je teško. Integritet sada kontrolira BEFW. On revno osigurava da se pravila koja donosi ne mijenjaju. Ako netko promijeni pravila vatrozida, vratit će sve. "Brzo sam postavio proxy kako bih mogao raditi od kuće"—nema više takvih opcija.
BEFW kontrolira ipset iz usluga i liste u befw.conf, pravila usluga u BEFW lancu. Ali ne prati druge lance i pravila i druge ipsete.
Zaštita od sudara
BEFW uvijek sprema zadnje poznato dobro stanje izravno u binarnu strukturu state.bin. Ako nešto pođe po zlu, uvijek se vraća na ovo stanje.bin.
Ovo je osiguranje od nestabilnog rada Consula, kada nije poslao podatke ili je netko pogriješio i koristio pravila koja se ne mogu primijeniti. Kako bismo osigurali da ne ostanemo bez vatrozida, BEFW će se vratiti na najnovije stanje ako se u bilo kojoj fazi pojavi pogreška.
U kritičnim situacijama to je jamstvo da ćemo ostati s vatrozidom koji radi. 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 Consula, ovo je važna značajka koja nam pomaže u daljnjem razvoju.
Demo: tijekom izvještaja, Ivan demonstrira demo mod 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 add set 0.0.0.0/0. Što se događa ako dodate 0.0.0.0/0 u ipset? Hoće li sve IP adrese biti dodane? Hoće li pristup internetu biti dostupan?
Ne, dobit ćemo grešku koja nas je koštala dva sata prekida rada. Štoviše, bug ne radi od 2016., nalazi se u RedHat Bugzilli pod brojem #1297092, a pronašli smo ga slučajno - iz izvješća programera.
Sada je na BEFW-u strogo pravilo da 0.0.0.0/0 pretvara u dvije adrese: 0.0.0.0/1 и 128.0.0.0/1.
ipset set za vraćanje < datoteka. Što ipset radi kada mu kažete restore? Mislite li da radi isto kao iptables? Hoće li oporaviti podatke?
Ništa slično - vrši spajanje, a stare adrese ne idu nikamo, ne blokirate pristup.
Pronašli smo grešku prilikom testiranja izolacije. Sada postoji prilično složen sustav - umjesto restore održava create temp, a zatim restore flush temp и restore temp. Na kraju zamjene: za atomičnost, jer ako to učinite prvi flush i u ovom trenutku stigne neki paket, bit će odbačen i nešto će poći po zlu. Dakle, tu ima 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 putem konzulata lokalno, ali u ovom slučaju oboje će se zamrznuti.
Lokalni Consul klijent je omot preko HTTP API-ja. Ali samo visi i ne reagira samo na Ctrl+C, ili Ctrl+Z, ili bilo što drugo kill -9 u sljedećoj konzoli. S tim smo se susreli kada smo gradili veliki klaster. Ali još nemamo rješenje; pripremamo se popraviti ovu grešku u Consulu.
Vođa konzula ne odgovara. Naš gospodar u podatkovnom centru ne reagira, 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 predanosti, vođa je pronađen, sve je u redu.
Kako se nosimo s ovim? service consul restart u cron svaki sat. Ako imate 50 poslužitelja, ništa strašno. Kad ih bude 16, shvatit ćete kako to funkcionira.
Zaključak
Kao rezultat toga, dobili smo sljedeće prednosti:
- 100% pokrivenost svih Linux strojeva.
- Brzina.
- Automatizacija.
- Oslobodili smo inženjere hardvera i mreže iz ropstva.
- Pojavile su se mogućnosti integracije koje su gotovo neograničene: čak i s Kubernetesom, čak i s Ansibleom, čak i s Pythonom.
Cons: Konzul, s kojim sada moramo živjeti, i vrlo visoka cijena pogreške. Na primjer, jednom sam u 6 sati (prime time u Rusiji) uređivao nešto na listama mreža. U to smo vrijeme samo gradili izolaciju u BEFW-u. Negdje sam pogriješio, izgleda da sam označio krivu masku, ali sve je palo u dvije sekunde. Pali se monitor, dotrčava dežurna podrška: “Imamo sve!” Šef odjela je posijedio kada je objasnio poslu zašto se to dogodilo.
Cijena pogreške toliko je visoka da smo osmislili vlastiti složeni postupak prevencije. Ako ovo implementirate na velikoj proizvodnoj lokaciji, ne morate svima dati glavni token preko Consula. Ovo će loše završiti.
Trošak. Pisao sam kod 400 sati sam. Moj tim od 4 osobe troši 10 sati mjesečno na podršku svima. U usporedbi s cijenom bilo kojeg vatrozida nove generacije, besplatan je.
Planovi. Dugoročni plan je pronaći alternativni prijevoz koji će zamijeniti ili nadopuniti konzula. Možda će to biti Kafka ili nešto slično. Ali u nadolazećim godinama živjet ćemo na Consulu.
Trenutni planovi: integracija s Fail2ban, s praćenjem, s nftables, eventualno s drugim distribucijama, metrika, napredni nadzor, optimizacija. Podrška za Kubernetes je također negdje u planu, jer sada imamo nekoliko klastera i želju.
Više od planova:
- traženje anomalija u prometu;
- upravljanje mrežnom kartom;
- podrška za Kubernetes;
- sastavljanje paketa za sve sustave;
- Web-UI.
Konstantno radimo na proširenju konfiguracije, povećanju metrike i optimizaciji.
Pridružite se projektu. Projekt se pokazao cool, ali je, nažalost, još uvijek projekt jedne osobe. Dođite i pokušati nešto učiniti: obvezati se, testirati, predložiti nešto, dati svoju procjenu.
U međuvremenu se pripremamo za , koji će se održati 6. i 7. travnja u Sankt Peterburgu, te pozivamo programere visokoopterećenih sustava . Iskusni govornici već znaju što im je činiti, ali za one koji tek govore barem preporučujemo . Sudjelovanje na konferenciji kao govornik ima niz prednosti. Koje, možete pročitati npr. na kraju .
Izvor: www.habr.com