Leta 2010 je podjetje bilo je 50 strežnikov in preprost omrežni model: backend, frontend in požarni zid. Število strežnikov je raslo, model je postal kompleksnejši: uprizoritveni, izolirani VLAN-ji z ACL-ji, nato VPN-ji z VRF-ji, VLAN-ji z ACL-ji na L2, VRF-ji z ACL-ji na L3. Se vrti v glavi? Kasneje bo bolj zabavno.
Ko je bilo strežnikov 16, je postalo nemogoče delati brez solz s toliko heterogenimi segmenti. Zato smo našli drugo rešitev. Vzeli smo sklad Netfilter, mu dodali Consul kot vir podatkov in dobili smo hiter porazdeljen požarni zid. Zamenjali so ACL-je na usmerjevalnikih in jih uporabljali kot zunanji in notranji požarni zid. Za dinamično upravljanje orodja smo razvili sistem BEFW, ki je bil uporabljen povsod: od upravljanja dostopa uporabnikov do omrežja izdelkov do izolacije omrežnih segmentov drug od drugega.
Povedal vam bo, kako vse skupaj deluje in zakaj bi si morali podrobneje ogledati ta sistem. Ivan Agarkov () je vodja skupine za varnost infrastrukture oddelka za vzdrževanje v razvojnem centru podjetja v Minsku. Ivan je oboževalec SELinuxa, obožuje Perl in piše kodo. Kot vodja skupine za informacijsko varnost redno dela z dnevniki, varnostnimi kopijami in raziskavami in razvojem, da zaščiti Wargaming pred hekerji in zagotovi delovanje vseh igralnih strežnikov v podjetju.
Zgodovinski podatki
Preden vam povem, kako nam je to uspelo, vam bom povedal, kako smo do tega sploh prišli in zakaj je bilo to potrebno. Če želite to narediti, se vrnimo 9 let nazaj: 2010, World of Tanks se je pravkar pojavil. Wargaming je imel približno 50 strežnikov.
Graf rasti strežnika podjetja.
Imeli smo mrežni model. Za tisti čas je bilo optimalno.
Model omrežja leta 2010.
Na sprednji strani so slabi fantje, ki nas želijo zlomiti, vendar ima požarni zid. Na zaledju ni požarnega zidu, je pa tam 50 strežnikov, vse poznamo. Vse dobro deluje.
V 4 letih se je flota strežnikov povečala za 100-krat, na 5000. Pojavila so se prva izolirana omrežja – staging: niso mogla iti v produkcijo, tam pa so pogosto tekle stvari, ki so lahko bile nevarne.
Model omrežja leta 2014.
Po vztrajnosti smo uporabljali iste dele strojne opreme, vse delo pa je potekalo na izoliranih VLAN-ih: v VLAN-e se zapišejo ACL-ji, ki dovoljujejo ali zavračajo neko vrsto povezave.
Leta 2016 je število strežnikov doseglo 8000. Wargaming je prevzel druge studie in pojavila so se dodatna partnerska omrežja. Zdi se, da so naši, vendar ne povsem: VLAN pogosto ne deluje za partnerje, morate uporabiti VPN z VRF, izolacija postane bolj zapletena. Izolacijska mešanica ACL je rasla.
Model omrežja leta 2016.
Do začetka leta 2018 je flota strojev narasla na 16 000. Segmentov je bilo 6, ostalih nismo šteli, vključno z zaprtimi, v katerih so bili shranjeni finančni podatki. Pojavila so se vsebniška omrežja (Kubernetes), DevOps, omrežja v oblaku, povezana prek VPN, na primer iz IVS. Bilo je veliko pravil – bilo je boleče.
Omrežni model in metode izolacije v letu 2018.
Za izolacijo smo uporabili: VLAN z ACL na L2, VRF z ACL na L3, VPN in še veliko več. Preveč.
Težave
Vsi živijo z ACL in VLAN. Kaj je narobe? Na to vprašanje bo odgovoril Harold, ki skriva bolečino.
Težav je bilo veliko, a pet velikih je bilo.
- Geometrijska podražitev za nova pravila. Vsako novo pravilo se je dodajalo dlje kot prejšnje, saj je bilo treba najprej videti, ali takšno pravilo že obstaja.
- Brez požarnega zidu znotraj segmentov. Segmenti so bili nekako ločeni drug od drugega in že tako znotraj ni bilo dovolj virov.
- Pravila so veljala dolgo časa. Operaterji bi lahko v eni uri ročno napisali eno lokalno pravilo. Globalni je trajal nekaj dni.
- Težave z revizijskimi pravili. Natančneje, ni bilo mogoče. Prva pravila so bila napisana že leta 2010, večina njihovih avtorjev pa ni bila več zaposlena v podjetju.
- Nizka stopnja nadzora infrastrukture. To je glavni problem - nismo dobro vedeli, kaj se dogaja v naši državi.
Takole je izgledal omrežni inženir leta 2018, ko je slišal: "Potrebujem še nekaj ACL."
Rešitve
V začetku leta 2018 je bilo odločeno, da se glede tega nekaj naredi.
Cena integracij nenehno raste. Izhodišče je bilo, da so veliki podatkovni centri prenehali podpirati izolirane VLAN in ACL, ker je napravam zmanjkalo pomnilnika.
Rešitev: odstranili smo človeški faktor in maksimalno avtomatizirali zagotavljanje dostopa.
Uveljavitev novih pravil traja dolgo časa. Rešitev: pospešite uporabo pravil, naredite jo porazdeljeno in vzporedno. To zahteva porazdeljen sistem, tako da se pravila dostavijo sama, brez rsync ali SFTP v tisoč sistemov.
Brez požarnega zidu znotraj segmentov. Požarni zid znotraj segmentov nam je začel prihajati, ko so se znotraj istega omrežja pojavile različne storitve. Rešitev: uporabite požarni zid na ravni gostitelja - požarni zidovi na osnovi gostitelja. Skoraj povsod, kjer imamo Linux in povsod, kjer imamo iptables, to ni problem.
Težave z revizijskimi pravili. Rešitev: Hranite vsa pravila na enem mestu za pregled in upravljanje, da lahko revidiramo vse.
Nizka stopnja nadzora nad infrastrukturo. Rešitev: naredite popis vseh storitev in dostopov med njimi.
To je bolj upravni kot tehnični postopek. Včasih imamo 200-300 novih izdaj na teden, zlasti med promocijami in prazniki. Poleg tega je to samo za eno ekipo naših DevOps. Pri toliko izdajah je nemogoče videti, katera vrata, IP-ji in integracije so potrebni. Zato smo potrebovali posebej usposobljene serviserje, ki so ekipe spraševali: "Kaj sploh je in zakaj ste to izpostavili?"
Po vsem, kar smo lansirali, je omrežni inženir leta 2019 začel izgledati takole.
Konzul
Odločili smo se, da bomo vse, kar bomo našli s pomočjo skrbnikov storitev, dali v Consul in od tam pisali pravila iptables.
Kako to, da smo se za to odločili?
- Zbrali bomo vse storitve, omrežja in uporabnike.
- Na njihovi podlagi ustvarimo pravila iptables.
- Avtomatiziramo nadzor.
- ....
- DOBIČEK.
Consul ni oddaljeni API, lahko deluje na vsakem vozlišču in piše v iptables. Vse kar ostane je, da si izmislite samodejne kontrole, ki bodo očistile nepotrebne stvari, in večina težav bo rešenih! Ostalo bomo uredili sproti.
Zakaj konzul?
Se je dobro izkazal. V letih 2014-15 smo ga uporabljali kot zaledje za Vault, v katerem shranjujemo gesla.
Ne izgublja podatkov. V času uporabe Consul ni izgubil podatkov niti ob eni nesreči. To je velik plus za sistem upravljanja požarnega zidu.
Povezave P2P pospešujejo širjenje sprememb. S P2P vse spremembe pridejo hitro, ni vam treba čakati več ur.
Priročen REST API. Upoštevali smo tudi Apache ZooKeeper, vendar nima REST API-ja, zato boste morali namestiti bergle.
Deluje tako kot trezor ključev (KV) kot imenik (odkrivanje storitev). Storitve, kataloge in podatkovne centre lahko shranite hkrati. To ni priročno le za nas, ampak tudi za sosednje ekipe, saj pri gradnji globalne storitve razmišljamo na veliko.
Napisano v Go, ki je del sklada Wargaming. Obožujemo ta jezik, imamo veliko razvijalcev Go.
Zmogljiv sistem ACL. V Consulu lahko uporabite ACL za nadzor, kdo kaj piše. Zagotavljamo, da se pravila požarnega zidu ne bodo prekrivala z ničemer drugim in s tem ne bomo imeli težav.
Toda Consul ima tudi svoje pomanjkljivosti.
- Ne prilagaja se v podatkovnem centru, razen če imate poslovno različico. Razširljiv je le z zvezo.
- Zelo odvisno od kakovosti omrežja in obremenitve strežnika. Consul ne bo pravilno deloval kot strežnik na zasedenem strežniku, če so v omrežju zaostanki, na primer neenakomerna hitrost. To je posledica povezav P2P in modelov distribucije posodobitev.
- Težave pri spremljanju razpoložljivosti. V statusu konzula lahko reče, da je vse v redu, umrl pa je že zdavnaj.
Večino teh težav smo rešili z uporabo Consula, zato smo ga izbrali. Podjetje ima načrte za alternativno zaledje, vendar smo se naučili reševati težave in trenutno živimo pri Consulu.
Kako Consul deluje
V pogojnem podatkovnem centru bomo namestili tri do pet strežnikov. En ali dva strežnika ne bosta delovala: ne bosta mogla organizirati kvoruma in odločati, kdo ima prav in kdo ne, ko se podatki ne ujemajo. Več kot pet nima smisla, produktivnost bo padla.
Odjemalci se na strežnike povezujejo v poljubnem vrstnem redu: isti agenti, le z zastavico server = false.
Po tem odjemalci prejmejo seznam povezav P2P in vzpostavijo povezave med seboj.
Na globalni ravni povezujemo več podatkovnih centrov. Povezujejo tudi P2P in komunicirajo.
Ko želimo pridobiti podatke iz drugega podatkovnega centra, gre zahteva od strežnika do strežnika. Ta shema se imenuje Serf protokol. Protokol Serf, tako kot Consul, razvija HashiCorp.
Nekaj pomembnih dejstev o konzulu
Consul ima dokumentacijo, ki opisuje, kako deluje. Podal bom le izbrana dejstva, ki jih je vredno poznati.
Konzulski strežniki izberejo mojstra izmed volivcev. Consul izbere glavnega s seznama strežnikov za vsak podatkovni center in vse zahteve gredo samo njemu, ne glede na število strežnikov. Glavna zamrznitev ne vodi do ponovne izvolitve. Če glavni ni izbran, zahtevkov ne servisira nihče.
Ste želeli horizontalno skaliranje? Žal ne.
Zahteva drugemu podatkovnemu centru gre od glavnega do glavnega, ne glede na to, na kateri strežnik je prišla. Izbrani master prejme 100 % obremenitve, razen obremenitve pri zahtevah za posredovanje. Vsi strežniki v podatkovnem centru imajo posodobljeno kopijo podatkov, a se odziva le eden.
Edini način za prilagajanje je, da omogočite zastareli način na odjemalcu.
V zastarelem načinu lahko odgovorite brez sklepčnosti. To je način, v katerem se odrečemo konsistentnosti podatkov, vendar beremo nekoliko hitreje kot običajno in katerikoli strežnik se odzove. Seveda snemanje samo prek masterja.
Consul ne kopira podatkov med podatkovnimi centri. Ko je zveza sestavljena, bo vsak strežnik imel samo svoje podatke. Za druge se vedno obrne na nekoga drugega.
Atomičnost operacij ni zagotovljena zunaj transakcije. Ne pozabite, da niste edini, ki lahko spremenite stvari. Če želite drugače, opravite transakcijo s ključavnico.
Operacije blokiranja ne zagotavljajo zaklepanja. Zahteva gre od glavnega do glavnega in ne neposredno, zato ni nobenega zagotovila, da bo blokada delovala, ko blokirate na primer v drugem podatkovnem centru.
ACL tudi ne zagotavlja dostopa (v mnogih primerih). ACL morda ne bo deloval, ker je shranjen v enem zveznem podatkovnem centru – v podatkovnem centru ACL (primarni DC). Če vam DC ne odgovori, ACL ne bo deloval.
En zamrznjen mojster bo povzročil zamrznitev celotne zveze. Na primer, v federaciji je 10 podatkovnih centrov in eden ima slabo omrežje, en glavni pa odpove. Vsi, ki komunicirajo z njim, bodo obtičali v krogu: obstaja zahteva, nanjo ni odgovora, nit zamrzne. Ni mogoče vedeti, kdaj se bo to zgodilo, samo v uri ali dveh bo padla cela zveza. Nič ne moreš storiti glede tega.
Status, sklepčnost in volitve obravnava ločena nit. Ponovna izvolitev ne bo, status ne bo pokazal ničesar. Misliš, da imaš živega Konzula, vprašaš, pa se nič ne zgodi - ni odgovora. Hkrati status kaže, da je vse v redu.
Naleteli smo na to težavo in morali smo obnoviti določene dele podatkovnih centrov, da bi se ji izognili.
Poslovna različica Consul Enterprise nima nekaterih zgoraj navedenih pomanjkljivosti. Ima veliko uporabnih funkcij: izbiranje volivcev, distribucija, skaliranje. Obstaja samo en "ampak" - sistem licenciranja za porazdeljeni sistem je zelo drag.
Življenjski hekerji: rm -rf /var/lib/consul - zdravilo za vse bolezni povzročitelja. Če vam kaj ne ustreza, preprosto izbrišite svoje podatke in prenesite podatke iz kopije. Najverjetneje bo Consul deloval.
BEFW
Zdaj pa se pogovorimo o tem, kaj smo dodali Consulu.
je akronim za BackEndFIreWvse. Izdelek sem moral nekako poimenovati, ko sem ustvaril repozitorij, da sem lahko vanj postavil prve testne potrditve. To ime ostaja.
Predloge pravil
Pravila so zapisana v sintaksi iptables.
- -N BEFW
- -P VHODNI PAD
- -A INPUT -m stanje—stanje POVEZAN,VZPOSTAVLJEN -j SPREJEM
- -A VNOS -i lo -j SPREJEM
- -A VNOS -j BEFW
Vse gre v verigo BEFW, razen ESTABLISHED, RELATED in lokalni gostitelj. Predloga je lahko karkoli, to je samo primer.
Kako je BEFW uporaben?
Storitve
Imamo storitev, vedno ima vrata, vozlišče, na katerem teče. Iz našega vozlišča lahko lokalno vprašamo agenta in ugotovimo, da imamo neko storitev. Lahko tudi postavite oznake.
Vsaka storitev, ki se izvaja in je registrirana pri Consulu, se spremeni v pravilo iptables. Imamo SSH - odprta vrata 22. Skript Bash je preprost: curl in iptables, nič drugega ni potrebno.
Odjemalci
Kako odpreti dostop ne vsem, ampak selektivno? Dodajte sezname IP v shrambo KV po imenu storitve.
Na primer, želimo, da imajo vsi v desetem omrežju dostop do storitve SSH_TCP_22. Želite dodati eno majhno polje TTL? in zdaj imamo začasna dovoljenja, na primer za en dan.
Dostopi
Povezujemo storitve in odjemalce: servis imamo, KV shramba je pripravljena za vsakega. Zdaj ne dajemo dostopa vsem, ampak selektivno.
Skupina
Če vsakič napišemo na tisoče IP-jev za dostop, se bomo naveličali. Izmislimo skupine - ločeno podmnožico v KV. Poimenujmo ga vzdevek (ali skupine) in tam shranimo skupine po istem principu.
Povežimo se: zdaj lahko odpremo SSH ne posebej za P2P, ampak za celotno skupino ali več skupin. Na enak način obstaja TTL - lahko dodate v skupino in začasno odstranite iz skupine.
Integracija
Naš problem je človeški faktor in avtomatizacija. Do sedaj smo to reševali tako.
Sodelujemo s Puppetom in jim prenesemo vse, kar je povezano s sistemom (aplikacijsko kodo). Puppetdb (običajni PostgreSQL) shrani seznam storitev, ki se tam izvajajo, najdete jih po vrsti vira. Tam izveš, kdo se kam prijavlja. Za to imamo tudi sistem zahtev za vlečenje in zahtevo za združitev.
Napisali smo befw-sync, preprosto rešitev, ki pomaga prenašati podatke. Prvič, do sinhronizacijskih piškotkov dostopa puppetdb. Tam je konfiguriran HTTP API: zahtevamo, katere storitve imamo, kaj je treba narediti. Nato se obrnejo na konzula.
Ali obstaja integracija? Da: napisali so pravila in dovolili sprejemanje zahtev za vleko. Ali potrebujete določena vrata ali dodate gostitelja v neko skupino? Zahteva po vleki, pregled - nič več "Poiščite 200 drugih ACL-jev in poskusite nekaj narediti glede tega."
Optimizacija
Pinganje lokalnega gostitelja s prazno verigo pravil traja 0,075 ms.
V to verigo dodajmo 10 naslovov iptables. Posledično se bo ping povečal za 000-krat: iptables je popolnoma linearen, obdelava vsakega naslova traja nekaj časa.
Za požarni zid, kjer migriramo na tisoče ACL-jev, imamo veliko pravil, kar uvaja zakasnitev. To je slabo za igralne protokole.
Če pa postavimo 10 naslovov v ipsetu Ping se bo celo zmanjšal.
Bistvo je, da je "O" (kompleksnost algoritma) za ipset vedno enako 1, ne glede na to, koliko pravil obstaja. Res je, obstaja omejitev - pravil ne sme biti več kot 65535. Za zdaj živimo s tem: lahko jih kombinirate, razširite, naredite dva ipseta v enem.
Skladiščenje
Logično nadaljevanje iteracijskega procesa je shranjevanje informacij o odjemalcih storitve v ipset.
Zdaj imamo isti SSH in ne pišemo 100 IP-jev naenkrat, ampak nastavimo ime ipseta s katerim moramo komunicirati in naslednje pravilo DROP. Lahko se pretvori v eno pravilo "Kdo ni tukaj, DROP", vendar je bolj jasno.
Zdaj imamo pravila in sklope. Glavna naloga je narediti nabor pred pisanjem pravila, ker sicer iptables ne bo napisal pravila.
Splošna shema
V obliki diagrama je vse, kar sem rekel, videti takole.
Zavezali smo se Puppetu, vse se pošilja na host, storitve tukaj, ipset tam, kdor ni registriran tam pa ne sme.
Dovoli & zavrni
Da bi hitro rešili svet ali hitro nekoga onesposobili, smo na začetku vseh verig naredili dva ipseta: rules_allow и rules_deny. Kako deluje?
Na primer, nekdo ustvarja obremenitev našega spleta z boti. Prej si moral poiskati njegov IP iz dnevnikov, ga odnesti omrežnim inženirjem, da so lahko našli vir prometa in ga prepovedali. Zdaj je videti drugače.
Pošljemo ga konzulu, počakamo 2,5 sekunde in je končano. Ker Consul hitro distribuira prek P2P, deluje povsod, kjer koli na svetu.
Enkrat sem zaradi napake s požarnim zidom nekako povsem ustavil WOT. rules_allow - to je naše zavarovanje pred takimi primeri. Če smo se kje zmotili s požarnim zidom, je kje kaj blokirano, lahko vedno pošljemo pogojnik 0.0/0da hitro vse poberem. Kasneje bomo vse popravili ročno.
Drugi kompleti
V prostoru lahko dodate še poljubne komplete $IPSETS$.
Za kaj? Včasih nekdo potrebuje ipset, na primer, da posnema zaustavitev nekega dela gruče. Vsak lahko prinese poljubne komplete, jih poimenuje in prevzeli jih bodo pri konzulu. Hkrati lahko kompleti sodelujejo v pravilih iptables ali delujejo kot ekipa NOOP: Doslednost bo vzdrževal demon.
Člani
Prej je bilo tako: uporabnik se je povezal v omrežje in preko domene prejemal parametre. Pred pojavom požarnih zidov nove generacije Cisco ni znal razumeti, kje je uporabnik in kje je IP. Zato je bil dostop odobren samo prek imena gostitelja stroja.
Kaj smo storili? Zataknilo se nam je v trenutku, ko smo prejeli naslov. Običajno je to dot1x, Wi-Fi ali VPN - vse gre prek RADIUS-a. Za vsakega uporabnika ustvarimo skupino po uporabniškem imenu in vanjo postavimo IP s TTL, ki je enak njegovemu dhcp.lease - takoj ko poteče, bo pravilo izginilo.
Zdaj lahko odpremo dostop do storitev, tako kot druge skupine, z uporabniškim imenom. Odpravili smo težave z imeni gostiteljev, ko se spremenijo, in smo prevzeli breme z omrežnih inženirjev, ker ne potrebujejo več Cisca. Zdaj inženirji sami registrirajo dostop na svojih strežnikih.
Izolacija
Hkrati smo začeli z demontažo izolacije. Vodje storitev so naredili popis in analizirali smo vsa naša omrežja. Razdelimo jih v iste skupine in na potrebnih strežnikih so bile dodane skupine, na primer za zavrnitev. Zdaj se ista uprizoritvena izolacija konča v rules_deny produkcije, ne pa tudi v sami produkciji.
Shema deluje hitro in preprosto: s strežnikov odstranimo vse ACL-je, razbremenimo strojno opremo in zmanjšamo število izoliranih VLAN-ov.
Nadzor integritete
Prej smo imeli poseben sprožilec, ki je poročal, ko je nekdo ročno spremenil pravilo požarnega zidu. Pisal sem ogromen linter za preverjanje pravil požarnega zidu, bilo je težko. Celovitost zdaj nadzoruje BEFW. Vneto skrbi, da se pravila, ki jih postavlja, ne spreminjajo. Če nekdo spremeni pravila požarnega zidu, bo spremenil vse nazaj. "Hitro sem nastavil proxy, da sem lahko delal od doma" - ni več takih možnosti.
BEFW nadzoruje ipset iz storitev in seznama v befw.conf, pravila storitev v verigi BEFW. Vendar ne spremlja drugih verig in pravil ter drugih ipsetov.
Zaščita pred trkom
BEFW vedno shrani zadnje znano dobro stanje neposredno v binarno strukturo state.bin. Če gre kaj narobe, se vedno vrne na to stanje.bin.
To je zavarovanje pred nestabilnim delovanjem Consula, ko ni poslal podatkov ali se je nekdo zmotil in uporabil pravila, ki jih ni mogoče uporabiti. Za zagotovitev, da ne ostanemo brez požarnega zidu, se bo BEFW povrnil na zadnje stanje, če se na kateri koli stopnji pojavi napaka.
V kritičnih situacijah je to zagotovilo, da nam bo ostal delujoč požarni zid. Odpiramo vsa siva omrežja v upanju, da pride admin in to popravi. Nekoč bom to dal v konfiguracije, zdaj pa imamo samo tri siva omrežja: 10/8, 172/12 in 192.168/16. Znotraj našega Consula je to pomembna funkcija, ki nam pomaga pri nadaljnjem razvoju.
Demo: med poročilom Ivan demonstrira demo način BEFW. Lažje je gledati predstavitev . Na voljo je demo izvorna koda .
Pasti
Povedal vam bom o napakah, na katere smo naleteli.
ipset add set 0.0.0.0/0. Kaj se zgodi, če v ipset dodate 0.0.0.0/0? Ali bodo dodani vsi IP-ji? Ali bo dostop do interneta na voljo?
Ne, dobili bomo napako, ki nas je stala dve uri nedelovanja. Poleg tega hrošč ne deluje že od leta 2016, nahaja se v RedHat Bugzilla pod številko #1297092 in našli smo ga po naključju - iz poročila razvijalca.
Zdaj je na BEFW strogo pravilo, da 0.0.0.0/0 spremeni v dva naslova: 0.0.0.0/1 и 128.0.0.0/1.
ipset obnovitveni niz < datoteka. Kaj naredi ipset, ko mu ukažete restore? Mislite, da deluje enako kot iptables? Ali bo obnovil podatke?
Nič takega - izvede spajanje in stari naslovi ne gredo nikamor, ne blokirate dostopa.
Pri testiranju izolacije smo našli napako. Zdaj obstaja precej zapleten sistem – namesto restore potekala create temptorej restore flush temp и restore temp. Na koncu zamenjave: za atomičnost, ker če to storite prvi flush in v tem trenutku pride nek paket, bo zavržen in nekaj bo šlo narobe. Torej je tu malo črne magije.
konzul kv get -datacenter=other. Kot sem rekel, mislimo, da zahtevamo nekaj podatkov, vendar bomo dobili podatke ali napako. To lahko storimo preko Consula lokalno, vendar bosta v tem primeru oba zamrznila.
Lokalni odjemalec Consul je ovoj nad HTTP API. Vendar samo visi in se ne odziva samo na Ctrl+C ali Ctrl+Z ali karkoli drugega kill -9 v naslednji konzoli. Na to smo naleteli, ko smo gradili velik grozd. Vendar še nimamo rešitve; pripravljamo se na odpravo te napake v Consulu.
Vodja konzula se ne odziva. Naš gospodar v podatkovnem centru se ne odziva, pomislimo: "Mogoče bo algoritem za ponovno izbiro zdaj deloval?"
Ne, ne bo delovalo in spremljanje ne bo pokazalo ničesar: konzul bo rekel, da obstaja indeks zavezanosti, vodja je bil najden, vse je v redu.
Kako se spopadamo s tem? service consul restart v cron vsako uro. Če imate 50 strežnikov, ni nič hudega. Ko jih bo 16, boste razumeli, kako to deluje.
Zaključek
Posledično smo prejeli naslednje prednosti:
- 100 % pokritost vseh strojev Linux.
- Hitrost.
- Avtomatizacija.
- Strojne in omrežne inženirje smo osvobodili suženjstva.
- Pojavile so se možnosti integracije, ki so skoraj neomejene: tudi s Kubernetesom, tudi z Ansibleom, tudi s Pythonom.
Proti: Consul, s katerim moramo zdaj živeti, in zelo visoka cena napake. Na primer, enkrat ob 6. uri (največji čas v Rusiji) sem nekaj urejal na seznamih omrežij. V BEFW smo takrat ravno gradili izolacijo. Nekje sem se zmotil, zgleda sem navedel napačno masko, pa je vse padlo v dveh sekundah. Monitor se prižge, priteče dežurni spremljevalec: "Vse imamo!" Vodja oddelka je osivel, ko je podjetju pojasnil, zakaj je do tega prišlo.
Cena napake je tako visoka, da smo se domislili lastnega kompleksnega postopka preprečevanja. Če to izvedete na velikem proizvodnem mestu, vam ni treba dati glavnega žetona prek Consula vsem. To se bo slabo končalo.
Cena Sam sem pisal kodo 400 ur. Moja ekipa 4 ljudi porabi 10 ur na mesec za podporo vsem. V primerjavi s ceno katerega koli požarnega zidu nove generacije je brezplačen.
Načrti. Dolgoročni načrt je najti alternativni prevoz, ki bi nadomestil ali dopolnil Consul. Morda bo Kafka ali kaj podobnega. Toda v prihodnjih letih bomo živeli na Konzulu.
Takojšnji načrti: integracija s Fail2ban, z monitoringom, z nftables, po možnosti z drugimi distribucijami, metrika, napredno spremljanje, optimizacija. Tudi podpora za Kubernetes je nekje v načrtih, saj sedaj imamo več grozdov in željo.
Več iz načrtov:
- iskanje nepravilnosti v prometu;
- upravljanje omrežnih zemljevidov;
- Podpora za Kubernetes;
- sestavljanje paketov za vse sisteme;
- Spletni uporabniški vmesnik.
Nenehno delamo na širitvi konfiguracije, povečevanju metrik in optimizaciji.
Pridružite se projektu. Projekt se je izkazal za kul, vendar je na žalost še vedno projekt ene osebe. Pridi in poskusite nekaj narediti: zavezati se, testirati, nekaj predlagati, podati svojo oceno.
Medtem se pripravljamo na , ki bo 6. in 7. aprila v Sankt Peterburgu, na katerega vabimo razvijalce visokoobremenjenih sistemov. . Izkušeni govorci že vedo, kaj storiti, toda tistim, ki so šele začeli govoriti, priporočamo vsaj . Sodelovanje na konferenci kot predavatelj ima številne prednosti. Katere, lahko preberete na koncu npr .
Vir: www.habr.com