En 2010 la firmao estis 50 serviloj kaj simpla retomodelo: backend, fasado kaj fajroŝirmilo. La nombro da serviloj kreskis, la modelo iĝis pli kompleksa: enscenigado, izolitaj VLANoj kun ACLoj, tiam VPNoj kun VRFoj, VLANoj kun ACLoj sur L2, VRFoj kun ACLoj sur L3. Kapo turniĝas? Pli amuze estos poste.
Kiam estis 16 serviloj, fariĝis neeble labori sen larmoj kun tiom da heterogenaj segmentoj. Do ni elpensis alian solvon. Ni prenis la Netfilter-stakon, aldonis Konsulo al ĝi kiel datumfonton, kaj ni ricevis rapidan distribuitan fajroŝirmilon. Ili anstataŭigis ACL-ojn sur enkursigiloj kaj uzis ilin kiel eksteran kaj internan fajroŝirmilon. Por dinamike administri la ilon, ni evoluigis la BEFW-sistemon, kiu estis uzata ĉie: de administrado de uzantaliro al la produktoreto ĝis izolado de retsegmentoj unu de la alia.
Li diros al vi kiel ĉio funkcias kaj kial vi devus rigardi pli detale ĉi tiun sistemon. Ivan Agarkov () estas la estro de la infrastruktura sekureca grupo de la prizorgado-dividado ĉe la Minska evolucentro de la kompanio. Ivan estas ŝatanto de SELinux, amas Perl kaj skribas kodon. Kiel la estro de la informa sekureca grupo, li regule laboras kun protokoloj, sekurkopioj kaj R&D por protekti Wargaming kontraŭ retpiratoj kaj certigi la funkciadon de ĉiuj ludserviloj en la kompanio.
Historia Fono
Antaŭ ol mi rakontos al vi kiel ni faris ĝin, mi rakontos al vi kiel ni venis al ĉi tio unue kaj kial ĝi estis bezonata. Por fari tion, ni reiru 9 jarojn: 2010, ĵus aperis Mondo de Tankoj. Wargaming havis ĉirkaŭ 50 servilojn.
Firmaa servila kreskodiagramo.
Ni havis retan modelon. Por tiu tempo ĝi estis optimuma.
Retmodelo en 2010.
Estas malbonuloj ĉe la antaŭa parto, kiuj volas rompi nin, sed ĝi havas fajroŝirmilon. Ne estas fajroŝirmilo sur la backend, sed estas 50 serviloj tie, ni konas ilin ĉiujn. Ĉio funkcias bone.
En 4 jaroj, la servila floto kreskis 100 fojojn, ĝis 5000. La unuaj izolitaj retoj aperis - enscenigado: ili ne povis iri al produktado, kaj estis ofte aferoj kurantaj tie, kiuj povus esti danĝeraj.
Retmodelo en 2014.
Per inercio, ni uzis la samajn pecojn de aparataro, kaj la tuta laboro estis farita sur izolitaj VLAN-oj: ACL-oj estas skribitaj al la VLAN-oj, kiuj permesas aŭ neas ian konekton.
En 2016, la nombro da serviloj atingis 8000 XNUMX. Wargaming absorbis aliajn studiojn, kaj aperis pliaj filiaj retoj. Ili ŝajnas esti niaj, sed ne tute: VLAN ofte ne funkcias por partneroj, vi devas uzi VPN kun VRF, izolado fariĝas pli komplika. La ACL-izolaj miksaĵo kreskis.
Retmodelo en 2016.
Komence de 2018, la aro de maŝinoj kreskis al 16 000. Estis 6 segmentoj, kaj ni ne kalkulis la ceterajn, inkluzive de fermitaj, en kiuj financaj datumoj estis konservitaj. Aperis ujretoj (Kubernetes), DevOps, nubaj retoj konektitaj per VPN, ekzemple, de IVS. Estis multaj reguloj - estis dolora.
Reta modelo kaj izolaj metodoj en 2018.
Por izolado ni uzis: VLAN kun ACL sur L2, VRF kun ACL sur L3, VPN kaj multe pli. Tro multe.
Problemoj
Ĉiuj vivas kun ACL kaj VLAN. Kio estas malbona? Ĉi tiu demando estos respondita de Harold, kaŝante la doloron.
Estis multaj problemoj, sed estis kvin amasaj.
- Geometria prezo pliiĝo por novaj reguloj. Ĉiu nova regulo daŭris pli longe por aldoni ol la antaŭa, ĉar necesis unue vidi ĉu jam ekzistas tia regulo.
- Neniu fajroŝirmilo ene de segmentoj. La segmentoj estis iel apartigitaj unu de la alia, kaj jam ne estis sufiĉe da rimedoj interne.
- La reguloj estis aplikataj dum longa tempo. Operaciistoj povus skribi unu lokan regulon mane en horo. La tutmonda daŭris plurajn tagojn.
- Malfacilaĵoj kun reviziaj reguloj. Pli precize, ne eblis. La unuaj reguloj estis skribitaj reen en 2010, kaj la plej multaj el iliaj aŭtoroj ne plu laboris por la firmao.
- Malalta nivelo de infrastruktura kontrolo. Ĉi tiu estas la ĉefa problemo - ni ne sciis tre bone, kio okazas en nia lando.
Jen kiel reta inĝeniero aspektis en 2018 kiam li aŭdis: "Bezonas pli da ACL."
Solvoj
Komence de 2018, estis decidite fari ion pri ĝi.
La prezo de integriĝoj konstante kreskas. La deirpunkto estis, ke grandaj datumcentroj ĉesis subteni izolitajn VLAN-ojn kaj ACL-ojn ĉar la aparatoj elĉerpigis memoron.
Solvo: ni forigis la homan faktoron kaj aŭtomatigis la provizon de aliro al la maksimumo.
La novaj reguloj bezonas longan tempon por apliki. Solvo: plirapidigi la aplikadon de reguloj, fari ĝin distribuita kaj paralela. Ĉi tio postulas distribuitan sistemon, por ke la reguloj estu liveritaj mem, sen rsync aŭ SFTP al mil sistemoj.
Neniu fajroŝirmilo ene de segmentoj. Fajroŝirmilo ene de segmentoj komencis veni al ni kiam malsamaj servoj aperis ene de la sama reto. Solvo: uzu fajroŝirmilon ĉe la gastiga nivelo - gastig-bazitaj fajroŝirmiloj. Preskaŭ ĉie ni havas Linukso, kaj ĉie ni havas iptables, ĉi tio ne estas problemo.
Malfacilaĵoj kun reviziaj reguloj. Solvo: Konservu ĉiujn regulojn en unu loko por revizio kaj administrado, por ke ni povu ĉion revizii.
Malalta nivelo de kontrolo de infrastrukturo. Solvo: faru inventaron de ĉiuj servoj kaj aliroj inter ili.
Ĉi tio estas pli administra procezo ol teknika. Foje ni havas 200-300 novajn eldonojn semajne, precipe dum promocioj kaj ferioj. Krome, ĉi tio estas nur por unu teamo de nia DevOps. Kun tiom da eldonoj, estas neeble vidi kiajn havenojn, IP-ojn kaj integriĝojn necesas. Tial ni bezonis speciale trejnitajn servantojn, kiuj demandis al la teamoj: "Kio estas ĉiuokaze kaj kial vi priparolis ĝin?"
Post ĉio, kion ni lanĉis, reta inĝeniero en 2019 komencis aspekti tiel.
konsulo
Ni decidis, ke ni metos ĉion, kion ni trovis helpe de servaj administrantoj, en Konsulon kaj de tie ni skribus iptables-regulojn.
Kiel ni decidis fari ĉi tion?
- Ni kolektos ĉiujn servojn, retojn kaj uzantojn.
- Ni kreu iptables-regulojn bazitajn sur ili.
- Ni aŭtomatigas kontrolon.
- ....
- PROFITO.
Konsulo ne estas fora API, ĝi povas funkcii sur ĉiu nodo kaj skribi al iptables. Restas nur elpensi aŭtomatajn kontrolojn, kiuj purigos nenecesajn aferojn, kaj la plej multaj problemoj estos solvitaj! Ni ellaboros la reston dum ni iros.
Kial Konsulo?
Pruvis sin bone. En 2014-15, ni uzis ĝin kiel backend por Vault, en kiu ni stokas pasvortojn.
Ne perdas datumojn. Dum la tempo de uzo, Konsulo ne perdis datumojn dum ununura akcidento. Ĉi tio estas grandega pluso por sistemo de administrado de fajroŝirmilo.
P2P-konektoj akcelas la disvastiĝon de ŝanĝo. Kun P2P, ĉiuj ŝanĝoj venas rapide, ne necesas atendi horojn.
Konvena REST API. Ni ankaŭ konsideris Apache ZooKeeper, sed ĝi ne havas REST-API, do vi devos instali lambastonojn.
Funkcias kaj kiel Ŝlosilo-Trezorejo (KV) kaj Adresaro (Serva Malkovro). Vi povas stoki servojn, katalogojn kaj datumcentrojn samtempe. Ĉi tio estas oportuna ne nur por ni, sed ankaŭ por najbaraj teamoj, ĉar kiam ni konstruas tutmondan servon, ni pensas grandan.
Skribita en Go, kiu estas parto de la Wargaming-stako. Ni amas ĉi tiun lingvon, ni havas multajn Go-programistojn.
Potenca ACL-sistemo. En Konsulo, vi povas uzi ACL-ojn por kontroli kiu skribas kion. Ni garantias, ke la reguloj pri fajroŝirmilo ne koincidos kun io alia kaj ni ne havos problemojn pri tio.
Sed Konsulo ankaŭ havas siajn malavantaĝojn.
- Ne skalas en datumcentro krom se vi havas komercan version. Ĝi estas nur skalebla de federacio.
- Tre dependa de la kvalito de la reto kaj servila ŝarĝo. Konsulo ne funkcios ĝuste kiel servilo sur okupata servilo se estas iuj malfruoj en la reto, ekzemple neegala rapideco. Ĉi tio estas pro P2P-konektoj kaj ĝisdatigaj distribuaj modeloj.
- Malfacileco monitori haveblecon. En Konsulo statuso li povas diri ke ĉio estas bona, sed li mortis antaŭ longa tempo.
Ni solvis la plej multajn el ĉi tiuj problemoj dum uzado de Consul, tial ni elektis ĝin. La firmao havas planojn por alternativa backend, sed ni lernis trakti problemojn kaj nuntempe vivas kun Consul.
Kiel Konsulo funkcias
Ni instalos tri ĝis kvin servilojn en kondiĉa datumcentro. Unu aŭ du serviloj ne funkcios: ili ne povos organizi kvorumon kaj decidi kiu pravas kaj kiu eraras kiam la datumoj ne kongruas. Pli ol kvin havas neniun sencon, produktiveco falos.
Klientoj konektas al la serviloj en ajna ordo: la samaj agentoj, nur kun la flago server = false.
Post tio, klientoj ricevas liston de P2P-konektoj kaj konstruas ligojn inter si.
Je la tutmonda nivelo, ni konektas plurajn datumcentrojn. Ili ankaŭ konektas P2P kaj komunikas.
Kiam ni volas preni datumojn de alia datumcentro, la peto iras de servilo al servilo. Ĉi tiu skemo nomiĝas Protokolo pri servuto. La Serf-protokolo, kiel Konsulo, estas evoluigita fare de HashiCorp.
Kelkaj gravaj faktoj pri Konsulo
Konsulo havas dokumentaron priskribantan kiel ĝi funkcias. Mi donos nur elektitajn faktojn, kiujn indas scii.
Konsulserviloj elektas majstron el inter la balotantoj. Konsulo elektas majstron el la listo de serviloj por ĉiu datumcentro, kaj ĉiuj petoj iras nur al ĝi, sendepende de la nombro da serviloj. Majstra frosto ne kondukas al reelekto. Se la majstro ne estas elektita, petoj ne estas servitaj de neniu.
Ĉu vi volis horizontalan skalon? Pardonu, ne.
Peto al alia datumcentro iras de majstro al majstro, sendepende de kiu servilo ĝi venis. La elektita majstro ricevas 100% de la ŝarĝo, krom la ŝarĝo sur antaŭaj petoj. Ĉiuj serviloj en la datumcentro havas ĝisdatigitan kopion de la datumoj, sed nur unu respondas.
La nura maniero grimpi estas ebligi malnoviĝintan reĝimon sur la kliento.
En malfreŝa reĝimo, vi povas respondi sen kvorumo. Ĉi tio estas reĝimo en kiu ni rezignas datuman konsistencon, sed legas iom pli rapide ol kutime, kaj ajna servilo respondas. Nature, registrado nur per la majstro.
Konsulo ne kopias datumojn inter datencentroj. Kiam federacio estas kunvenita, ĉiu servilo havos nur siajn proprajn datumojn. Por aliaj, li ĉiam turnas sin al iu alia.
Atomiko de operacioj ne estas garantiita ekster transakcio. Memoru, ke vi ne estas la sola, kiu povas ŝanĝi aferojn. Se vi volas ĝin malsame, faru transakcion per seruro.
Blokaj operacioj ne garantias ŝlosadon. La peto iras de majstro al majstro, kaj ne rekte, do ne estas garantio, ke la blokado funkcios kiam vi blokas, ekzemple, en alia datuma centro.
ACL ankaŭ ne garantias aliron (en multaj kazoj). La ACL eble ne funkcias ĉar ĝi estas konservita en unu federacia datumcentro - en la ACL-datumcentro (Primara DC). Se la DC ne respondas al vi, la ACL ne funkcios.
Unu frosta majstro igos la tutan federacion frostigi. Ekzemple, estas 10 datumcentroj en federacio, kaj unu havas malbonan reton, kaj unu majstro malsukcesas. Ĉiu, kiu komunikas kun li, estos blokita en rondo: estas peto, ne estas respondo al ĝi, la fadeno frostiĝas. Ne estas maniero scii kiam tio okazos, nur post unu aŭ du horoj la tuta federacio falos. Estas nenio, kion vi povas fari pri ĝi.
Statuso, kvorumo kaj elektoj estas pritraktitaj per aparta fadeno. Reelekto ne okazos, la stato montros nenion. Vi pensas, ke vi havas vivantan Konsulon, vi demandas, kaj nenio okazas - ne estas respondo. Samtempe, la statuso montras, ke ĉio estas en ordo.
Ni renkontis ĉi tiun problemon kaj devis rekonstrui specifajn partojn de datumcentroj por eviti ĝin.
La komerca versio de Consul Enterprise ne havas iujn el la supraj malavantaĝoj. Ĝi havas multajn utilajn funkciojn: elektado de balotantoj, distribuado, skalo. Estas nur unu "sed" - la licenca sistemo por distribuita sistemo estas tre multekosta.
Viva hackeado: rm -rf /var/lib/consul - kuraco por ĉiuj malsanoj de la agento. Se io ne funkcias por vi, simple forigu viajn datumojn kaj elŝutu la datumojn el kopio. Plej verŝajne, Konsulo funkcios.
BEFW
Nun ni parolu pri tio, kion ni aldonis al Konsulo.
estas akronimo por BACKEndFkoleroWĉiuj. Mi devis nomi la produkton iel kiam mi kreis la deponejon por meti la unuajn testajn kommitaĵojn en ĝin. Ĉi tiu nomo restas.
Regulŝablonoj
La reguloj estas skribitaj en iptables-sintakso.
- -N BEFW
- -P ENIGA GUTO
- -A INPUT -m stato—stato RELATED,ESTABLISHED -j Akcepti
- -A ENIGO -i lo -j Akcepti
- -A ENIGO -j BEFW
Ĉio iras en la BEFW-ĉenon, krom ESTABLISHED, RELATED kaj lokagastiganto. La ŝablono povas esti io ajn, ĉi tio estas nur ekzemplo.
Kiel utilas BEFW?
Servoj
Ni havas servon, ĝi ĉiam havas havenon, nodon sur kiu ĝi funkcias. De nia nodo, ni povas loke demandi la agenton kaj ekscii, ke ni havas ian servon. Vi ankaŭ povas meti etikedojn.
Ajna servo, kiu funkcias kaj registrita ĉe Consul, fariĝas regulo de iptables. Ni havas SSH - malferman havenon 22. La Bash-skripto estas simpla: curl kaj iptables, nenio alia necesas.
Klientoj
Kiel malfermi aliron ne al ĉiuj, sed selekteme? Aldonu IP-listojn al KV-stokado laŭ servonomo.
Ekzemple, ni volas, ke ĉiuj en la deka reto povu aliri la servon SSH_TCP_22. Ĉu aldoni unu malgrandan TTL-kampon? kaj nun ni havas provizorajn permesojn, ekzemple, por tago.
Aliroj
Ni konektas servojn kaj klientojn: ni havas servon, KV-stokado estas preta por ĉiu. Nun ni donas aliron ne al ĉiuj, sed selekteme.
Grupoj
Se ni skribas milojn da IP-oj por aliro ĉiufoje, ni laciĝos. Ni elpensu grupiĝojn - apartan subaron en KV. Ni nomu ĝin Kaŝnomo (aŭ grupoj) kaj stoku tie grupojn laŭ la sama principo.
Ni konektu: nun ni povas malfermi SSH ne specife por P2P, sed por tuta grupo aŭ pluraj grupoj. En la sama maniero, ekzistas TTL - vi povas aldoni al grupo kaj forigi el la grupo provizore.
Integriĝo
Nia problemo estas la homa faktoro kaj aŭtomatigo. Ĝis nun ni solvis ĝin tiel.
Ni laboras kun Puppet, kaj transdonas ĉion, kio rilatas al la sistemo (aplikkodo) al ili. Puppetdb (kutima PostgreSQL) konservas liston de servoj, kiuj funkcias tie, ili troveblas laŭ rimeda tipo. Tie vi povas ekscii, kiu petas kie. Ni ankaŭ havas tirpeton kaj kunfandan peton por ĉi tio.
Ni skribis befw-sync, simplan solvon, kiu helpas translokigi datumojn. Unue, sinkronigaj kuketoj estas alireblaj de puppetdb. HTTP API estas agordita tie: ni petas kiajn servojn ni havas, kion oni devas fari. Tiam ili faras peton al Konsulo.
Ĉu estas integriĝo? Jes: ili skribis la regulojn kaj permesis ke Pull Requests estu akceptitaj. Ĉu vi bezonas certan havenon aŭ aldonas gastiganton al iu grupo? Tiru Peton, reviziu - ne plu "Trovu 200 aliajn ACL-ojn kaj provu fari ion pri ĝi."
Optimumigo
Pingi lokagastiganton kun malplena regulĉeno daŭras 0,075 ms.
Ni aldonu 10 iptables-adresojn al ĉi tiu ĉeno. Kiel rezulto, la ping pliiĝos 000 fojojn: iptables estas tute linia, prilaborado de ĉiu adreso daŭras iom da tempo.
Por fajroŝirmilo, kie ni migras milojn da ACL-oj, ni havas multajn regulojn, kaj ĉi tio enkondukas latentecon. Ĉi tio estas malbona por videoludaj protokoloj.
Sed se ni metas 10 adresoj en ipset La ping eĉ malpliiĝos.
La punkto estas, ke "O" (algoritma komplekseco) por ipset estas ĉiam egala al 1, negrave kiom da reguloj ekzistas. Vere, ekzistas limigo - ne povas esti pli ol 65535 reguloj. Nuntempe ni vivas kun ĉi tio: vi povas kombini ilin, pligrandigi ilin, fari du ipsetojn en unu.
Stokado
Logika daŭrigo de la ripeta procezo konservas informojn pri klientoj por la servo en ipset.
Nun ni havas la saman SSH, kaj ni ne skribas 100 IP-ojn samtempe, sed fiksas la nomon de la ipseto kun kiu ni devas komuniki, kaj la sekvan regulon DROP. Ĝi povas esti konvertita en unu regulon "Kiu ne estas ĉi tie, FALO", sed ĝi estas pli klara.
Nun ni havas regulojn kaj arojn. La ĉefa tasko estas fari aron antaŭ skribi la regulon, ĉar alie iptables ne skribos la regulon.
Ĝenerala skemo
En formo de diagramo, ĉio, kion mi diris, aspektas tiel.
Ni kompromitas al Puppet, ĉio estas sendita al la gastiganto, servoj ĉi tie, ipset tie, kaj iu ajn, kiu ne estas registrita tie, ne rajtas.
Permesi & nei
Por rapide savi la mondon aŭ rapide malŝalti iun, komence de ĉiuj ĉenoj ni faris du ipsetojn: rules_allow и rules_deny. Kiel ĝi funkcias?
Ekzemple, iu kreas ŝarĝon en nia Retejo per robotoj. Antaŭe, vi devis trovi lian IP el la protokoloj, porti ĝin al retaj inĝenieroj, por ke ili trovu la fonton de la trafiko kaj malpermesi lin. Ĝi aspektas alie nun.
Ni sendas ĝin al Konsulo, atendu 2,5 sekundojn, kaj ĝi estas farita. Ĉar Konsulo distribuas rapide per P2P, ĝi funkcias ĉie, en ajna parto de la mondo.
Iam mi iel tute haltigis WOT pro eraro kun la fajroŝirmilo. rules_allow - jen nia asekuro kontraŭ tiaj kazoj. Se ni eraris ie kun la fajroŝirmilo, io estas blokita ie, ni ĉiam povas sendi kondiĉon. 0.0/0por rapide repreni ĉion. Poste ni riparos ĉion mane.
Aliaj aroj
Vi povas aldoni ajnajn aliajn arojn en la spaco $IPSETS$.
Por kio? Foje iu bezonas ipset, ekzemple, por emuli la malŝalton de iu parto de la areto. Iu ajn povas alporti ajnajn arojn, nomi ilin, kaj ili estos prenitaj de Konsulo. Samtempe, aroj povas aŭ partopreni en la reguloj de iptables aŭ agi kiel teamo NOOP: Konsistenco estos konservita de la demono.
Uzantoj
Antaŭe, ĝi estis tiel: la uzanto konektita al la reto kaj ricevis parametrojn tra la domajno. Antaŭ la apero de nova generaciaj fajroŝirmiloj, Cisco ne sciis kompreni kie estas la uzanto kaj kie estas la IP. Tial, aliro estis donita nur per la gastiga nomo de la maŝino.
Kion ni faris? Ni blokiĝis en la momento, kiam ni ricevis la adreson. Kutime ĉi tio estas dot1x, Wi-Fi aŭ VPN - ĉio pasas tra RADIUS. Por ĉiu uzanto, ni kreas grupon laŭ uzantnomo kaj metas IP en ĝi kun TTL kiu estas egala al ĝia dhcp.lease - tuj kiam ĝi eksvalidiĝas, la regulo malaperos.
Nun ni povas malfermi aliron al servoj, kiel aliaj grupoj, per uzantnomo. Ni forigis la doloron de gastigantnomoj kiam ili ŝanĝiĝas, kaj ni forigis la ŝarĝon de retaj inĝenieroj ĉar ili ne plu bezonas Cisco. Nun inĝenieroj mem registras aliron sur siaj serviloj.
Izolado
Samtempe, ni komencis malmunti la izolajzon. Servaj administrantoj faris inventaron, kaj ni analizis ĉiujn niajn retojn. Ni dividu ilin en la samajn grupojn, kaj sur la necesaj serviloj la grupoj estis aldonitaj, ekzemple, por nei. Nun la sama sursceniga izolado finiĝas en la reguloj_neo de la produktado, sed ne en la produktado mem.
La skemo funkcias rapide kaj simple: ni forigas ĉiujn ACL-ojn de la serviloj, malŝarĝas la aparataron kaj reduktas la nombron da izolitaj VLANoj.
Kontrolo de integreco
Antaŭe, ni havis specialan ellasilon, kiu raportis kiam iu ŝanĝis firewall regulon permane. Mi estis skribanta grandegan linter por kontroli fajroŝirmigajn regulojn, estis malfacile. Integreco nun estas kontrolita de BEFW. Li fervore certigas, ke la reguloj, kiujn li faras, ne ŝanĝiĝu. Se iu ŝanĝas la regulojn de fajroŝirmilo, ĝi ŝanĝos ĉion reen. "Mi rapide starigis prokurilon, por ke mi povu labori de hejme" - ne plu ekzistas tiaj opcioj.
BEFW kontrolas la ipseton de la servoj kaj listo en befw.conf, la reguloj de servoj en la BEFW-ĉeno. Sed ĝi ne kontrolas aliajn ĉenojn kaj regulojn kaj aliajn ipsetojn.
Protekto kontraŭ kraŝo
BEFW ĉiam stokas la lastan konatan bonan staton rekte en la stato.bin duuma strukturo. Se io misfunkcias, ĝi ĉiam revenas al ĉi tiu stato.bin.
Ĉi tio estas asekuro kontraŭ malstabila Konsula operacio, kiam ĝi ne sendis datumojn aŭ iu faris eraron kaj uzis regulojn, kiuj ne povas esti aplikataj. Por certigi, ke ni ne restas sen fajroŝirmilo, BEFW revenos al la plej nova stato se eraro okazas en iu stadio.
En kritikaj situacioj, ĉi tio estas garantio, ke ni restos kun funkcia fajroŝirmilo. Ni malfermas ĉiujn grizajn retojn kun la espero, ke la administranto venos kaj riparos ĝin. Iam mi metos ĉi tion en la agordojn, sed nun ni nur havas tri grizajn retojn: 10/8, 172/12 kaj 192.168/16. Ene de nia Konsulo, ĉi tio estas grava trajto, kiu helpas nin disvolvi plu.
Demo: dum la raporto, Ivan pruvas la demo-reĝimon de BEFW. Estas pli facile spekti la manifestacion . Demonstra fontkodo havebla .
enfaliloj
Mi rakontos al vi pri la cimoj, kiujn ni renkontis.
ipset aldoni aron 0.0.0.0/0. Kio okazas se vi aldonas 0.0.0.0/0 al ipset? Ĉu ĉiuj IP-oj estos aldonitaj? Ĉu interreta aliro estos disponebla?
Ne, ni ricevos cimon, kiu kostis al ni du horojn da malfunkcio. Krome, la cimo ne funkciis ekde 2016, ĝi situas en RedHat Bugzilla sub numero #1297092, kaj ni trovis ĝin hazarde - el raporto de programisto.
Ĝi nun estas strikta regulo ĉe BEFW tio 0.0.0.0/0 iĝas du adresoj: 0.0.0.0/1 и 128.0.0.0/1.
ipset restore set < dosiero. Kion faras ipset kiam vi diras al ĝi restore? Ĉu vi pensas, ke ĝi funkcias same kiel iptables? Ĉu ĝi reakiros datumojn?
Nenio tia - ĝi faras kunfandiĝon, kaj la malnovaj adresoj ne iras ien, vi ne blokas aliron.
Ni trovis cimon dum testado de izolado. Nun ekzistas sufiĉe kompleksa sistemo - anstataŭ restore tenis create temptiam restore flush temp и restore temp. Ĉe la fino de interŝanĝo: por atomeco, ĉar se vi faras ĝin unue flush kaj en ĉi tiu momento iu pakaĵeto alvenas, ĝi estos forĵetita kaj io misfunkcios. Do estas iom da nigra magio tie.
konsulo kv get -datacenter=other. Kiel mi diris, ni pensas, ke ni petas iujn datumojn, sed ni ricevos datumojn aŭ eraron. Ni povas fari tion per Konsulo loke, sed ĉi-kaze ambaŭ frostos.
La loka Consul-kliento estas envolvaĵo super la HTTP-API. Sed ĝi simple pendas kaj ne respondas al Ctrl+C, aŭ Ctrl+Z, aŭ io ajn, nur kill -9 en la sekva konzolo. Ni renkontis ĉi tion kiam ni konstruis grandan areton. Sed ni ankoraŭ ne havas solvon; ni prepariĝas ripari ĉi tiun eraron en Konsulo.
Konsulgvidanto ne respondas. Nia majstro en la datumcentro ne respondas, ni pensas: "Eble la reelekta algoritmo funkcios nun?"
Ne, ĝi ne funkcios, kaj monitorado montros nenion: Konsulo diros, ke ekzistas devontiga indekso, gvidanto estas trovita, ĉio estas en ordo.
Kiel ni traktas ĉi tion? service consul restart en cron ĉiuhore. Se vi havas 50 servilojn, ne gravas. Kiam estas 16 el ili, vi komprenos kiel ĝi funkcias.
konkludo
Kiel rezulto, ni ricevis la jenajn avantaĝojn:
- 100% priraportado de ĉiuj Linuksaj maŝinoj.
- Rapido.
- Aŭtomatigo.
- Ni liberigis aparataron kaj retajn inĝenierojn de sklaveco.
- Aperis ebloj de integriĝo preskaŭ senlimaj: eĉ kun Kubernetes, eĉ kun Ansible, eĉ kun Python.
Miksoj: Konsulo, kun kiu ni nun devas vivi, kaj la tre alta kosto de eraro. Ekzemple, unufoje je la 6-a horo (prime time en Rusio) mi estis redaktanta ion en la listoj de retoj. Ni tiam konstruis nur izolajzon ĉe BEFW. Mi eraris ie, ŝajnas, ke mi indikis la malĝustan maskon, sed ĉio falis en du sekundoj. La monitorado lumiĝas, la deĵoranta helpanto venas kurante: "Ni havas ĉion!" La estro de la fako griziĝis, kiam li klarigis al la komerco, kial tio okazis.
La kosto de eraro estas tiel alta, ke ni elpensis nian propran kompleksan preventan proceduron. Se vi efektivigas ĉi tion sur granda produktejo, vi ne bezonas doni majstran ĵetonon super Konsulo al ĉiuj. Ĉi tio finiĝos malbone.
Kosto Mi skribis kodon nur dum 400 horoj. Mia teamo de 4 homoj pasigas 10 horojn monate por subteno por ĉiuj. Kompare kun la prezo de iu nova generacia fajroŝirmilo, ĝi estas senpaga.
Planoj. La longdaŭra plano estas trovi alternativan transportadon por anstataŭigi aŭ kompletigi Konsulon. Eble estos Kafka aŭ io simila. Sed en la venontaj jaroj ni vivos sur Konsulo.
Tujaj planoj: integriĝo kun Fail2ban, kun monitorado, kun nftables, eventuale kun aliaj distribuoj, metrikoj, altnivela monitorado, optimumigo. Kubernetes-subteno ankaŭ estas ie en la planoj, ĉar nun ni havas plurajn aretojn kaj la deziron.
Pli el la planoj:
- serĉi anomaliojn en trafiko;
- administrado de retmapoj;
- Kubernetes subteno;
- kunmeti pakaĵojn por ĉiuj sistemoj;
- Retejo-UI.
Ni konstante laboras pri vastigado de la agordo, pliigo de metrikoj kaj optimumigo.
Aliĝu al la projekto. La projekto montriĝis bonega, sed, bedaŭrinde, ĝi ankoraŭ estas unupersona projekto. Venu al kaj provu fari ion: fari, provi, sugesti ion, doni vian takson.
Dume ni prepariĝas por , kiu okazos la 6-an kaj 7-an de aprilo en Sankt-Peterburgo, kaj ni invitas programistojn de altŝarĝaj sistemoj . Spertaj parolantoj jam scias kion fari, sed por tiuj novaj parolantoj ni rekomendas almenaŭ . Partopreni en la konferenco kiel preleganto havas kelkajn avantaĝojn. Vi povas legi kiuj, ekzemple, ĉe la fino .
fonto: www.habr.com