2010ean konpainiak 50 zerbitzari eta sare eredu sinple bat zeuden: backend, frontend eta suebakia. Zerbitzari kopurua hazi zen, eredua konplexuagoa bihurtu zen: eszenaratzea, VLAN isolatuak ACLekin, gero VPNak VRFekin, VLANak ACLekin L2n, VRFak ACLekin L3an. Burua biraka ari da? Geroago dibertigarriagoa izango da.
16 zerbitzari zeudenean, ezinezkoa bihurtu zen malkorik gabe lan egitea hainbeste segmentu heterogeneoekin. Beraz, beste irtenbide bat asmatu genuen. Netfilter pila hartu genuen, Consul gehitu genuen datu-iturri gisa eta banatutako suebaki azkarra lortu genuen. Bideratzaileetan ACLak ordezkatu zituzten eta kanpoko eta barneko suebaki gisa erabili zituzten. Tresna dinamikoki kudeatzeko, BEFW sistema garatu genuen, edonon erabiltzen zena: erabiltzaileen sarbidea produktuen sarerako kudeatzetik sare-segmentuak elkarrengandik isolatzeraino.
Berak esango dizu nola funtzionatzen duen eta zergatik aztertu behar duzun sistema hau. Ivan Agarkov () Mantentze dibisioko azpiegituren segurtasun taldeko burua da konpainiaren Minsk garapen zentroan. Ivan SELinux zalea da, Perl maite du eta kodea idazten du. Informazioaren segurtasun taldeko burua den heinean, erregistroekin, babeskopiekin eta I+Grekin lan egiten du Wargaming hackerengandik babesteko eta konpainiako joko zerbitzari guztien funtzionamendua ziurtatzeko.
Informazio historiko
Nola egin genuen kontatu baino lehen, esango dizut nola heldu ginen lehenik eta zergatik behar zen. Horretarako, atzera egin dezagun 9 urte: 2010ean, World of Tanks agertu berri zen. Wargaming-ek 50 zerbitzari inguru zituen.
Enpresaren zerbitzariaren hazkunde-diagrama.
Sare eredu bat genuen. Ordurako optimoa zen.
Sare eredua 2010ean.
Aurrealdean daude mutil gaiztoak hautsi nahi gaituztenak, baina suebaki bat dauka. Backend-ean ez dago suebakirik, baina 50 zerbitzari daude bertan, denak ezagutzen ditugu. Dena ondo funtzionatzen du.
4 urtetan, zerbitzarien flota 100 aldiz hazi zen, 5000era arte. Lehen sare isolatuak agertu ziren - eszenaratzea: ezin ziren produkziora joan, eta arriskutsuak izan zitezkeen gauzak martxan zeuden askotan.
Sare eredua 2014ean.
Inertziaz, hardware pieza berdinak erabili genituen, eta lan guztia VLAN isolatuetan egin zen: ACLak VLANetan idazten dira, nolabaiteko konexioa ahalbidetzen edo ukatzen dutenak.
2016an, zerbitzarien kopurua 8000 XNUMXra iritsi zen. Wargaming-ek beste estudio batzuk xurgatu zituen eta afiliatu sare osagarriak agertu ziren. Badirudi gureak direla, baina ez guztiz: VLANak askotan ez du funtzionatzen bazkideentzat, VPN VRFarekin erabili behar duzu, isolamendua konplikatu egiten da. ACL isolamendu nahasketa hazi egin zen.
Sare eredua 2016ean.
2018. urtearen hasieran, makinen flota 16 izatera iritsi zen. 000 segmentu zeuden, eta gainerakoak ez genituen zenbatu, finantza-datuak gordetzen zituzten itxiak barne. Edukiontzi sareak (Kubernetes), DevOps, VPN bidez konektatutako hodeiko sareak, adibidez, IVS batetik, agertu dira. Arau asko zeuden - mingarria zen.
Sare eredua eta isolamendu metodoak 2018an.
Isolatzeko erabili dugu: VLAN ACLrekin L2n, VRF ACLrekin L3n, VPN eta askoz gehiago. Gehiegi.
Problems
Guztiak ACL eta VLANekin bizi dira. Zer dago oker? Galdera honi Haroldek erantzungo dio, mina ezkutatuz.
Arazo asko zeuden, baina bost masibo izan ziren.
- Arau berrietarako prezio geometrikoa igoera. Arau berri bakoitzak aurrekoa baino denbora gehiago behar izan zuen gehitzeko, lehenik eta behin halako araurik ba ote zegoen ikusi behar zelako.
- Ez dago suebakirik segmentuen barruan. Segmentuak nolabait elkarrengandik bereizita zeuden, eta jada ez zegoen baliabide nahikorik barruan.
- Arauak denbora luzez aplikatu ziren. Operadoreek tokiko arau bat idatzi dezakete eskuz ordu batean. Mundu mailakoak hainbat egun behar izan zituen.
- Ikuskapen-arauekin zailtasunak. Zehatzago esanda, ez zen posible izan. Lehen arauak 2010ean idatzi ziren, eta haien egile gehienek ez zuten enpresan lan egiten.
- Azpiegituren kontrol maila baxua. Hau da arazo nagusia - ez genekien oso ondo zer gertatzen ari zen gure herrialdean.
Hauxe izan zen sareko ingeniari batek 2018an entzun zuenean: "ACL gehiago behar da".
Π Π΅ΡΠ΅Π½ΠΈΡ
2018. urte hasieran zerbait egitea erabaki zen.
Integrazioen prezioa etengabe hazten ari da. Abiapuntua izan zen datu-zentro handiek VLAN eta ACL isolatuak onartzeari utzi ziola, gailuak memoriarik gabe geratu zirelako.
Irtenbidea: giza faktorea kendu eta sarbide-eskaintza ahalik eta gehien automatizatu dugu.
Arau berriak denbora asko behar dira aplikatzeko. Irtenbidea: arauen aplikazioa bizkortu, banatu eta paralelo egin. Honek sistema banatua behar du, arauak beraiek entregatu daitezen, rsync edo SFTPrik gabe mila sistematara.
Ez dago suebakirik segmentuen barruan. Segmentu barruko suebaki bat etortzen hasi zitzaigun sare berean zerbitzu desberdinak agertu zirenean. Irtenbidea: erabili suebaki bat ostalariaren mailan - ostalarietan oinarritutako suebakiak. Ia nonahi dugu Linux, eta edonon iptables dugu, hau ez da arazo bat.
Ikuskapen-arauekin zailtasunak. Irtenbidea: gorde arau guztiak leku bakarrean berrikusteko eta kudeatzeko, dena ikuskatu ahal izateko.
Azpiegituren gaineko kontrol maila baxua. Irtenbidea: egin haien arteko zerbitzu eta sarbide guztien inbentarioa.
Prozesu administratibo bat baino gehiago teknikoa da. Batzuetan, astean 200-300 bertsio berri izaten ditugu, batez ere promozio eta oporretan. Gainera, hau gure DevOps-eko talde bakarrarentzat da. Hainbeste bertsiorekin, ezinezkoa da ikusi zer portu, IP eta integrazio behar diren. Horregatik, bereziki prestatutako zerbitzu-kudeatzaileak behar genituen, taldeei galdetu zieten: "Zer dago, hala ere, eta zergatik ekarri duzu?"
Abian jarri genuen guztiaren ostean, 2019an sare ingeniari bat honela hasi zen.
kontsula
Zerbitzu-kudeatzaileen laguntzarekin aurkitutako guztia Consul-en sartuko genuela erabaki genuen eta hortik iptables arauak idatziko genituela.
Nola erabaki genuen hori egitea?
- Zerbitzu, sare eta erabiltzaile guztiak bilduko ditugu.
- Sor ditzagun iptables arauak horietan oinarrituta.
- Kontrola automatizatzen dugu.
- ....
- IRABAZI.
Consul ez da urruneko API bat, nodo guztietan exekutatu daiteke eta iptables-en idatz dezake. Alferrikako gauzak garbituko dituzten kontrol automatikoko tresnak sortzea besterik ez da geratzen, eta arazo gehienak konponduko dira! Gainontzekoa goazen heinean landuko dugu.
Zergatik kontsul?
Ondo frogatu du. 2014-15ean, Vault-en backend gisa erabili genuen, eta bertan pasahitzak gordetzen ditugu.
Ez du daturik galtzen. Erabilera denboran, Consul ez zen daturik galdu istripu bakar batean. Hau abantaila handia da suebakia kudeatzeko sistema batentzat.
P2P konexioek aldaketaren hedapena bizkortzen dute. P2P-rekin, aldaketa guztiak azkar etortzen dira, ez da ordu asko itxaron beharrik.
REST API erosoa. Apache ZooKeeper ere kontuan hartu dugu, baina ez du REST APIrik, beraz makuluak instalatu beharko dituzu.
Key Vault (KV) eta Directory (Zerbitzuaren aurkikuntza) gisa funtzionatzen du. Zerbitzuak, katalogoak eta datu-zentroak aldi berean gorde ditzakezu. Hau komenigarria da guretzat ez ezik, inguruko taldeentzat ere, zerbitzu global bat eraikitzerakoan handi pentsatzen dugulako.
Go-n idatzia, Wargaming pilaren parte dena. Hizkuntza hau maite dugu, Go garatzaile asko ditugu.
ACL sistema indartsua. Consul-en, ACLak erabil ditzakezu nork zer idazten duen kontrolatzeko. Suebakiaren arauak beste ezerekin gainjarri ez direla bermatzen dugu eta honekin ez dugu arazorik izango.
Baina Kontsulak ere baditu bere eragozpenak.
- Ez da eskalatzen datu-zentro batean, negozio-bertsiorik ez baduzu. Federazioak bakarrik eskalagarria da.
- Oso sarearen eta zerbitzariaren kargaren kalitatearen menpekoa. Consulek ez du behar bezala funtzionatuko zerbitzari gisa lanpetuta dagoen zerbitzari batean, sarean atzerapenik badago, adibidez, abiadura irregularra. P2P konexioen eta banaketa ereduen eguneratzearen ondorioz gertatzen da.
- Erabilgarritasuna kontrolatzeko zailtasunak. Kontsul egoeran dena ondo dagoela esan dezake, baina aspaldi hil zen.
Arazo hauetako gehienak Konsula erabiltzean konpondu genituen, horregatik aukeratu genuen. Konpainiak backend alternatibo baterako planak ditu, baina arazoei aurre egiten ikasi dugu eta gaur egun Consulrekin bizi gara.
Nola funtzionatzen duen Consul
Hiru edo bost zerbitzari instalatuko ditugu baldintzapeko datu-zentro batean. Zerbitzari batek edo bik ez dute funtzionatuko: ezin izango dute quorum bat antolatu eta erabaki zein den zuzen eta nor den gaizki datuak bat ez datozenean. Bostek baino gehiagok ez dute zentzurik, produktibitatea jaitsi egingo da.
Bezeroak zerbitzarietara edozein ordenatan konektatzen dira: agente berdinak, banderarekin bakarrik server = false.
Horren ondoren, bezeroek P2P konexioen zerrenda jasotzen dute eta beraien artean konexioak eraikitzen dituzte.
Mundu mailan, hainbat datu-zentro konektatzen ditugu. P2P ere konektatzen dute eta komunikatzen dira.
Beste datu-zentro batetik datuak berreskuratu nahi ditugunean, eskaera zerbitzaritik zerbitzarira doa. Eskema honi deitzen zaio Zerbitzarien protokoloa. Serf protokoloa, Consul bezala, HashiCorp-ek garatzen du.
Kontsulari buruzko datu garrantzitsu batzuk
Kontsulak nola funtzionatzen duen azaltzen duen dokumentazioa du. Jakitea merezi duten datu hautatuak soilik emango ditut.
Kontsul zerbitzariek maisu bat hautatzen dute hautesleen artean. Kontsulak datu-zentro bakoitzeko zerbitzarien zerrendatik maisu bat hautatzen du, eta eskaera guztiak bertara joaten dira, zerbitzari kopurua edozein dela ere. Maisu izozteak ez dakar berriro hauteskundeetara. Masterra hautatzen ez bada, eskaerak ez ditu inork artatzen.
Eskala horizontala nahi zenuen? Barkatu, ez.
Beste datu-zentro bati egindako eskaera maisu batetik bestera doa, zein zerbitzaritara iritsi den kontuan hartu gabe. Hautatutako maisuak kargaren % 100 jasotzen du, birbidaltzeko eskaeren karga izan ezik. Datu-zentroko zerbitzari guztiek dute datuen kopia eguneratua, baina bakarrak erantzuten du.
Eskalatzeko modu bakarra bezeroan modu zaharkitua gaitzea da.
Modu zaharkituan, quorumik gabe erantzun dezakezu. Datuen koherentziari uko egiten diogun modua da, baina ohi baino apur bat azkarrago irakurri eta edozein zerbitzariak erantzuten du. Noski, master bidez bakarrik grabatzea.
Consul ez da datu-zentroen artean kopiatzen. Federazio bat muntatzen denean, zerbitzari bakoitzak bere datuak baino ez ditu izango. Beste batzuentzat, beti beste norbaitengana jotzen du.
Eragiketen atomotasuna ez dago bermatzen transakzio batetik kanpo. Gogoratu ez zarela gauzak alda ditzakeen bakarra. Bestela nahi baduzu, egin transakzio bat blokeo batekin.
Blokeo eragiketek ez dute blokeoa bermatzen. Eskaera maisu batetik bestera doa, eta ez zuzenean, beraz, ez dago bermatzen blokeoak funtzionatuko duenik, adibidez, beste datu-zentro batean blokeatzen duzunean.
ACL-k ere ez du sarbidea bermatzen (kasu askotan). Baliteke ACL-ak ez funtzionatzea, federazioko datu-zentro batean gordeta dagoelako, ACL datu-zentroan (DC nagusia). DC-k ez badizu erantzuten, ACL-k ez du funtzionatuko.
Izoztutako maisu batek federazio osoa izoztuko du. Adibidez, federazio batean 10 datu-zentro daude, eta batek sare txarra dauka eta maisu batek huts egiten du. Berarekin komunikatzen den oro zirkulu batean geratuko da: eskaera bat dago, ez dago erantzunik, haria izoztu egiten da. Ez dago hori noiz gertatuko den jakiterik, ordubete edo bi barru federazio osoa eroriko da. Ez dago ezer egiterik.
Egoera, quoruma eta hauteskundeak beste hari baten bidez kudeatzen dira. Ez da berriro hauteskunderik gertatuko, egoerak ez du ezer erakutsiko. Bizirik dagoen Kontsul bat duzula uste duzu, galdetzen duzu, eta ez da ezer gertatzen - ez dago erantzunik. Aldi berean, egoerak erakusten du dena ondo dagoela.
Arazo hau aurkitu dugu eta datu-zentroen zati zehatzak berreraiki behar izan ditugu ekiditeko.
Consul Enterprise-ren negozio-bertsioak ez ditu goiko desabantaila batzuk. Funtzio erabilgarriak ditu: hautesleak hautatzea, banaketa, eskalatzea. "Baina" bakarra dago: sistema banatu baten lizentzia sistema oso garestia da.
Bizitza hacking: rm -rf /var/lib/consul - Agentearen gaixotasun guztien sendabidea. Zerbaitek ez badu funtzionatzen, ezabatu zure datuak eta deskargatu datuak kopia batetik. Seguruenik, Kontsulak lan egingo du.
BEFW
Orain kontsulari gehitu diogunari buruz hitz egin dezagun.
akronimoa da BACKEndFireWguztiak. Biltegia sortu nuenean produktuari nolabait izendatu behar izan nion lehen proba-konpromisoak bertan jartzeko. Izen hau geratzen da.
Arau txantiloiak
Arauak iptables sintaxian idatzita daude.
- -N BEFW
- -P SARRERA JAITSI
- -A INPUT -m egoeraβegoera ERLAZIONATUA,EZARRITUA -j ONARTU
- -A SARRERA -i lo -j ONARTU
- -A SARRERA -j BEFW
Dena BEFW katean sartzen da, izan ezik ESTABLISHED, RELATED eta localhost. Txantiloia edozein izan daiteke, hau adibide bat besterik ez da.
Nola da erabilgarria BEFW?
Zerbitzuak
Zerbitzu bat dugu, beti dauka portu bat, exekutatzen den nodo bat. Gure nodotik, lokalean agenteari galdetu diezaiokegu eta jakin dezakegu nolabaiteko zerbitzu bat dugula. Etiketak ere jar ditzakezu.
Exekutatzen ari den eta Consul-en erregistratuta dagoen edozein zerbitzu iptables arau bihurtzen da. SSH dugu - 22. ataka irekia. Bash script-a sinplea da: curl eta iptables, ez da beste ezer behar.
Bezeroak
Nola ireki sarbidea ez guztiontzat, baizik eta modu selektiboan? Gehitu IP zerrendak KV biltegian zerbitzuaren izenaren arabera.
Esaterako, hamargarren sareko guztiek SSH_TCP_22 zerbitzua atzitu ahal izatea nahi dugu. TTL eremu txiki bat gehitu? eta orain aldi baterako baimenak ditugu, adibidez, egun baterako.
Sarbideak
Zerbitzuak eta bezeroak konektatzen ditugu: zerbitzu bat dugu, KV biltegiratzea prest dago bakoitzarentzat. Orain ez denei sarbidea ematen diegu, modu selektiboan baizik.
Taldeak
Aldi bakoitzean sartzeko milaka IP idazten baditugu, nekatu egingo gara. Goazen taldekatzeak - KV-n azpimultzo bereizia. Dei diezaiogun Alias ββ(edo taldeak) eta gorde ditzagun taldeak printzipio beraren arabera.
Konektatu gaitezen: orain SSH ireki dezakegu ez bereziki P2Prako, talde oso baterako edo hainbat talderentzat baizik. Modu berean, TTL dago - talde batean gehitu eta taldetik aldi baterako kendu dezakezu.
Integrazioa
Gure arazoa giza faktorea eta automatizazioa da. Orain arte horrela konpondu dugu.
Puppet-ekin lan egiten dugu, eta sistemarekin zerikusia duen guztia (aplikazio-kodea) haiei transferitzen diegu. Puppetdb-ek (PostgreSQL arrunta) bertan exekutatzen ari diren zerbitzuen zerrenda gordetzen du, baliabide motaren arabera aurki daitezke. Bertan jakin dezakezu nor ari den aplikatzen non. Horrez gain, tira eskaera eta bateratze eskaera sistema bat dugu horretarako.
befw-sync idatzi dugu, datuak transferitzen laguntzen duen irtenbide sinplea. Lehenik eta behin, sinkronizazio cookieak puppetdb-ek sartzen ditu. HTTP API bat konfiguratuta dago bertan: zer zerbitzu ditugun, zer egin behar den eskatzen dugu. Ondoren, Kontsulari eskaera egiten diote.
Integraziorik ba al dago? Bai: arauak idatzi zituzten eta Pull Requests onartzea onartu zuten. Ataka jakin bat behar al duzu edo ostalari bat gehitu talde batean? Pull Request, berrikusi - ez gehiago "Bilatu beste 200 ACL eta saiatu zerbait egiten".
optimizazioa
Arau kate hutsarekin lokal host ping egiteak 0,075 ms behar ditu.
Gehi ditzagun 10 iptables helbide kate honi. Ondorioz, ping-a 000 aldiz handituko da: iptables guztiz lineala da, helbide bakoitza prozesatzeko denbora pixka bat behar da.
Milaka ACL migratzen ditugun suebaki baterako, arau asko ditugu, eta honek latentzia sartzen du. Hau txarra da joko-protokoloentzat.
Baina jartzen badugu 10 helbide ipset-en Ping-a ere gutxituko da.
Kontua da ipset-erako "O" (algoritmoaren konplexutasuna) beti 1-en berdina dela, zenbat arau dauden. Egia da, muga bat dago - ezin dira 65535 arau baino gehiago egon. Oraingoz honekin bizi gara: konbinatu, zabaldu, bi ipset batean egin ditzakezu.
biltegiratze
Iterazio-prozesuaren jarraipen logikoa ipset-en zerbitzurako bezeroei buruzko informazioa gordetzen da.
Orain SSH berdina dugu, eta ez dugu 100 IP idazten aldi berean, baizik eta komunikatu behar dugun ipset-aren izena ezarri eta hurrengo araua DROP. "Nor ez dago hemen, DROP" arau bakar batean bihur daiteke, baina argiagoa da.
Orain arauak eta multzoak ditugu. Araua idatzi aurretik multzo bat egitea da zeregin nagusia, bestela iptablesek ez baitu araua idatziko.
Eskema orokorra
Diagrama moduan, esan dudan guztia honelakoa da.
Puppet-ekin konprometitzen gara, dena ostalarira bidaltzen da, zerbitzuak hemen, ipset han, eta bertan erregistratuta ez dagoen edonor ez dago onartzen.
Baimendu eta ukatu
Mundua azkar salbatzeko edo norbait azkar desgaitzeko, kate guztien hasieran bi ipset egin genituen: rules_allow ΠΈ rules_deny. Nola dabil?
Adibidez, norbait karga bat sortzen ari da gure Webean botekin. Aurretik, bere IP erregistroetan aurkitu behar zenuten, sareko ingeniariei eraman, trafikoaren iturria aurkitu eta debekatu zezaten. Orain ezberdina dirudi.
Kontsulari bidaltzen diogu, 2,5 segundo itxaron eta listo. Consul P2P bidez azkar banatzen denez, nonahi funtzionatzen du, munduko edozein lekutan.
Behin, nolabait, WOT erabat gelditu nuen suebakiarekin akats batengatik. rules_allow - hau da gure asegurua horrelako kasuetarako. Suebakiarekin akatsen bat egin badugu nonbait, zerbait blokeatuta dago nonbait, beti bidal dezakegu baldintza bat 0.0/0dena azkar jasotzeko. Geroago dena eskuz konponduko dugu.
Beste multzo batzuk
Beste edozein multzo gehi ditzakezu espazioan $IPSETS$.
Zertarako? Batzuetan, norbaitek ipset behar du, adibidez, klusterraren zatiren baten itzaltzea emulatzeko. Edonork eraman dezake edozein sorta, izendatu, eta Kontsuletik jasoko dituzte. Aldi berean, multzoek iptables arauetan parte hartu dezakete edo talde gisa jardun dezakete NOOP: koherentzia mantenduko du deabruak.
Kide
Aurretik, honela zegoen: erabiltzailea sarera konektatu eta parametroak jasotzen zituen domeinuaren bidez. Belaunaldi berriko suebakiak agertu aurretik, Ciscok ez zekien nola ulertzen non zegoen erabiltzailea eta non zegoen IPa. Hori dela eta, sarbidea makinaren ostalari-izenaren bidez bakarrik eman zen.
Zer egin genuen? Helbidea jaso genuen momentuan trabatu egin ginen. Normalean hau dot1x, Wi-Fi edo VPN da - dena RADIUS bidez doa. Erabiltzaile bakoitzarentzat, erabiltzaile-izenaren arabera talde bat sortzen dugu eta IP bat jartzen dugu bere dhcp.lease-ren berdina den TTL batekin - iraungi bezain pronto, araua desagertuko da.
Orain zerbitzuetarako sarbidea ireki dezakegu, beste talde batzuek bezala, erabiltzaile-izenaren arabera. Ostalari-izenei mina kendu diegu aldatzen direnean, eta sareko ingeniariei zama kendu diegu, jada Cisco behar ez dutelako. Orain ingeniariek eurek erregistratzen dute sarbidea beren zerbitzarietan.
Isolamendua
Aldi berean, isolamendua desmuntatzen hasi ginen. Zerbitzu-kudeatzaileek inbentario bat egin zuten, eta gure sare guztiak aztertu genituen. Bana ditzagun talde berdinetan, eta beharrezko zerbitzarietan taldeak gehitu ziren, adibidez, ukatzeko. Orain eszenaratze-isolamendu bera produkzioaren arau_ukatzean amaitzen da, baina ez ekoizpenean bertan.
Eskemak azkar eta erraz funtzionatzen du: zerbitzarietatik ACL guztiak kentzen ditugu, hardwarea deskargatzen dugu eta VLAN isolatuen kopurua murrizten dugu.
Osotasunaren kontrola
Aurretik, norbaitek suebakiaren arau bat eskuz aldatzen zuenean jakinarazi zuen abiarazle berezi bat genuen. Suebakiaren arauak egiaztatzeko linter izugarria idazten ari nintzen, zaila zen. Osotasuna BEFWk kontrolatzen du orain. Berak egiten dituen arauak aldatzen ez direla ziurtatzen du gogotsu. Norbaitek suebakiaren arauak aldatzen baditu, dena aldatuko du. "Proxy bat azkar konfiguratu dut etxetik lan egin ahal izateko"; ez dago horrelako aukera gehiago.
BEFW-k ipset-a kontrolatzen du befw.conf-eko zerbitzuetatik eta zerrendan, BEFW kateko zerbitzuen arauak. Baina ez ditu beste kate eta arauak eta bestelako ipsetak kontrolatzen.
Istripuen babesa
BEFW-k beti gordetzen du ezagutzen den azken egoera ona zuzenean egoera.bin egitura bitarrean. Zerbait gaizki ateratzen bada, egoera honetara itzultzen da beti.
Kontsularen funtzionamendu ezegonkorren aurkako asegurua da, datuak bidali ez dituenean edo norbaitek akatsen bat egin eta aplikatu ezin diren arauak erabiltzen dituenean. Suebakirik gabe geratzen ez garela ziurtatzeko, BEFW-k azken egoerara itzuliko du edozein unetan erroreren bat gertatzen bada.
Egoera kritikoetan, funtzionatzen duen suebaki batekin geratuko garen bermea da. Sare gris guztiak irekitzen ditugu administratzailea etorriko den eta konponduko den itxaropenarekin. Noizbait hau konfigurazioetan jarriko dut, baina orain hiru sare gris besterik ez ditugu: 10/8, 172/12 eta 192.168/16. Gure Kontsularen barruan, gehiago garatzen laguntzen gaituen ezaugarri garrantzitsu bat da.
Demo: txostenean zehar, Ivanek BEFWren demo modua erakusten du. Errazagoa da manifestazioa ikustea . Demo iturburu-kodea eskuragarri .
Pitfalls
Aurkitu ditugun akatsen berri emango dizut.
ipset gehitu multzoa 0.0.0.0/0. Zer gertatzen da ipset-i 0.0.0.0/0 gehitzen badiozu? IP guztiak gehituko al dira? Interneterako sarbidea egongo al da?
Ez, bi orduko geldialdia kostatu zaigun akats bat jasoko dugu. Gainera, akatsak ez du funtzionatu 2016az geroztik, RedHat Bugzillan dago # 1297092 zenbakiarekin, eta ustekabean aurkitu dugu garatzaile baten txostenetik.
Orain BEFWn arau zorrotza da hori 0.0.0.0/0 bi helbide bihurtzen dira: 0.0.0.0/1 ΠΈ 128.0.0.0/1.
ipset berrezarri multzoa < fitxategia. Zer egiten du ipset-ek esaten diozunean restore? iptablesek bezala funtzionatzen duela uste duzu? Datuak berreskuratuko al ditu?
Ez da horrelakorik: bateratzea egiten du eta helbide zaharrak ez dira inora joaten, ez duzu sarbidea blokeatzen.
Isolamendua probatzerakoan akats bat aurkitu dugu. Orain sistema konplexu samarra dago - ordez restore atxilotuta create temp, gero restore flush temp ΠΈ restore temp. Trukearen amaieran: atomotasunagatik, lehenengo egiten baduzu flush eta momentu honetan paketeren bat iristen da, baztertu egingo da eta zerbait gaizki aterako da. Beraz, magia beltz pixka bat dago.
kontsul kv get -datacenter=beste. Esan bezala, datu batzuk eskatzen ari garela uste dugu, baina datuak edo erroreren bat jasoko dugu. Kontsularen bidez egin dezakegu lokalean, baina kasu honetan biak izoztuko dira.
Bertako Consul bezeroa HTTP APIaren bilgarri bat da. Baina zintzilikatzen da eta ez dio erantzuten Ctrl+C, edo Ctrl+Z edo ezeri, soilik kill -9 hurrengo kontsolan. Hau kluster handi bat eraikitzen ari ginenean topatu genuen. Baina oraindik ez dugu irtenbiderik; akats hau Kontsulan konpontzeko prestatzen ari gara.
Kontsulburuak ez du erantzuten ari. Datu-zentroko gure maisuak ez du erantzuten ari, pentsatzen dugu: "Agian berriro hautaketa algoritmoak funtzionatuko du orain?"
Ez, ez du funtzionatuko, eta monitorizazioak ez du ezer erakutsiko: kontsulak esango du konpromiso indize bat dagoela, lider bat aurkitu dela, dena ondo dagoela.
Nola aurre egiten diogu honi? service consul restart in cron orduro. 50 zerbitzari badituzu, ez da gauza handirik. 16 daudenean, ulertuko duzu nola funtzionatzen duen.
Ondorioa
Ondorioz, abantaila hauek jaso genituen:
- Linux makina guztien % 100eko estaldura.
- Abiadura.
- Automatizazioa.
- Hardware eta sareko ingeniariak esklabotasunetik askatu genituen.
- Ia mugagabeak diren integrazio aukerak agertu dira: Kubernetesekin ere, Ansiblerekin ere, Pythonekin ere.
Cons: Kontsula, orain bizi behar dugun horrekin, eta errorearen kostu oso altua. Adibide gisa, behin 6:XNUMXetan (Errusiako lehen ordua) sareen zerrendetan zerbait editatzen ari nintzen. BEFWn isolamendua eraikitzen ari ginen orduan. Akats bat egin nuen nonbait, maskara okerra adierazi nuela dirudi, baina dena bi segundotan erori zen. Jarraipena pizten da, guardiako laguntzailea korrika etortzen da: βDena dugu!β. Saileko burua gris bihurtu zen negozioari zergatik gertatu zen hori azaldu zionean.
Errorearen kostua hain da altua, non gure prebentzio prozedura konplexua sortu dugula. Hau ekoizpen gune handi batean ezartzen baduzu, ez duzu kontsularen gaineko token maisurik eman behar guztiei. Hau gaizki amaituko da.
Kostua. 400 orduz bakarrik idatzi nuen kodea. Nire 4 pertsonako taldeak hilean 10 ordu ematen ditu guztientzako laguntzan. Belaunaldi berriko edozein suebakiren prezioarekin alderatuta, doakoa da.
Planoak. Epe luzerako plana kontsul ordezkatzeko edo osatzeko garraio alternatiboak bilatzea da. Agian Kafka edo antzeko zerbait izango da. Baina datozen urteetan Kontsulaz biziko gara.
Berehalako planak: Fail2ban-ekin integratzea, monitorizazioarekin, nftableekin, agian beste banaketa batzuekin, metrika, monitorizazio aurreratua, optimizazioa. Kubernetesen laguntza ere planetan dago nonbait, orain hainbat kluster eta gogoa ditugulako.
Planetatik gehiago:
- trafikoan anomaliak bilatzea;
- sareko mapa kudeatzea;
- Kubernetes laguntza;
- sistema guztietarako paketeak muntatzea;
- Web-UI.
Etengabe ari gara lanean konfigurazioa zabaltzen, metrikak handitzen eta optimizazioan.
Bat egin proiektuan. Proiektua polita izan zen, baina, tamalez, pertsona bakarreko proiektua da oraindik. Etorri eta saiatu zerbait egiten: konpromisoa hartu, probatu, zerbait iradoki, zure balorazioa eman.
Bitartean prestatzen ari gara , apirilaren 6an eta 7an San Petersburgon ospatuko dena, eta karga handiko sistemen garatzaileak gonbidatzen ditugu. . Esperientziadun hiztunek badakite zer egin behar duten, baina hitz egiten berri dutenei gomendatzen diegu behintzat . Jardunaldian hizlari gisa parte hartzeak abantaila ugari ditu. Zeintzuk irakur ditzakezu, adibidez, amaieran .
Iturria: www.habr.com