Árið 2010 var fyrirtækið það voru 50 netþjónar og einfalt netkerfi: bakendi, framenda og eldveggur. Fjöldi netþjóna jókst, líkanið varð flóknara: sviðsetning, einangruð VLAN með ACL, síðan VPN með VRF, VLAN með ACL á L2, VRF með ACL á L3. Snýst höfuðið? Það verður skemmtilegra seinna.
Þegar það voru 16 netþjónar varð ómögulegt að vinna án tára með svo mörgum ólíkum hlutum. Svo við komum með aðra lausn. Við tókum Netfilter stafla, bættum Consul við hann sem gagnagjafa og við fengum fljótan dreifðan eldvegg. Þeir skiptu út ACL á beinum og notuðu þá sem ytri og innri eldvegg. Til að stjórna tólinu á kraftmikinn hátt þróuðum við BEFW kerfið, sem var notað alls staðar: allt frá því að stjórna notendaaðgangi að vörunetinu til að einangra nethluta hver frá öðrum.
Hann mun segja þér hvernig þetta virkar allt saman og hvers vegna þú ættir að skoða þetta kerfi nánar. Ivan Agarkov () er yfirmaður innviðaöryggishóps viðhaldssviðs í þróunarmiðstöð fyrirtækisins í Minsk. Ivan er SELinux aðdáandi, elskar Perl og skrifar kóða. Sem yfirmaður upplýsingaöryggishópsins vinnur hann reglulega með logs, öryggisafrit og R&D til að vernda Wargaming fyrir tölvuþrjótum og tryggja rekstur allra leikjaþjóna fyrirtækisins.
Saga
Áður en ég segi þér hvernig við gerðum það, skal ég segja þér hvernig við komum að þessu í upphafi og hvers vegna það var þörf. Til að gera þetta skulum við fara 9 ár aftur í tímann: 2010, World of Tanks birtist bara. Wargaming var með um það bil 50 netþjóna.
Vaxtarrit fyrir netþjóna fyrirtækis.
Við vorum með netmódel. Fyrir þann tíma var það ákjósanlegt.
Netmódel árið 2010.
Það eru vondir krakkar í framendanum sem vilja brjóta okkur niður, en það er með eldvegg. Það er enginn eldveggur á bakendanum, en það eru 50 netþjónar þar, við þekkjum þá alla. Allt virkar vel.
Á 4 árum stækkaði netþjónaflotinn 100 sinnum, í 5000. Fyrstu einangruðu netkerfin komu fram - sviðsetning: þau gátu ekki farið í framleiðslu og það voru oft hlutir í gangi þar sem gætu verið hættulegir.
Netmódel árið 2014.
Með tregðu notuðum við sömu vélbúnaðinn og öll vinnan fór fram á einangruðum VLAN: ACL eru skrifuð á VLAN, sem leyfa eða neita einhvers konar tengingu.
Árið 2016 náði fjöldi netþjóna 8000. Wargaming gleypti önnur stúdíó og fleiri tengd net komu fram. Þeir virðast vera okkar, en ekki alveg: VLAN virkar oft ekki fyrir samstarfsaðila, þú verður að nota VPN með VRF, einangrun verður flóknari. ACL einangrunarblandan óx.
Netmódel árið 2016.
Í ársbyrjun 2018 var vélaflotinn kominn upp í 16. Það voru 000 hlutar og við töldum ekki afganginn, þar á meðal lokaðar þar sem fjárhagsgögn voru geymd. Gámakerfi (Kubernetes), DevOps, skýjanet tengd í gegnum VPN, til dæmis frá IVS, hafa birst. Það voru margar reglur - það var sársaukafullt.
Netlíkan og einangrunaraðferðir árið 2018.
Til einangrunar notuðum við: VLAN með ACL á L2, VRF með ACL á L3, VPN og margt fleira. Of mikið.
Vandamál
Allir búa við ACL og VLAN. Hvað er að? Þessari spurningu mun Harold svara og fela sársaukann.
Vandamálin voru mörg, en þau voru fimm stór.
- Geometrísk verðhækkun fyrir nýjar reglur. Það tók lengri tíma að bæta við hverri nýrri reglu en þeirri fyrri, því fyrst þurfti að athuga hvort slík regla væri fyrir hendi.
- Enginn eldveggur inni í hlutum. Hlutarnir voru einhvern veginn aðskildir hver frá öðrum og það voru nú þegar ekki nóg fjármagn inni.
- Reglunum var beitt í langan tíma. Rekstraraðilar gætu skrifað eina staðbundna reglu í höndunum á klukkutíma. Hinn alþjóðlegi tók nokkra daga.
- Erfiðleikar við endurskoðunarreglur. Nánar tiltekið var það ekki hægt. Fyrstu reglurnar voru skrifaðar aftur árið 2010 og flestir höfundar þeirra störfuðu ekki lengur hjá fyrirtækinu.
- Lítið eftirlit með innviðum. Þetta er aðalvandamálið - við vissum ekki vel hvað var að gerast í landinu okkar.
Svona leit netverkfræðingur út árið 2018 þegar hann heyrði: „Þarftu meira ACL.
Lausnir
Í byrjun árs 2018 var ákveðið að gera eitthvað í málinu.
Verð á samþættingum fer stöðugt vaxandi. Útgangspunkturinn var að stór gagnaver hættu að styðja einangruð VLAN og ACL vegna þess að tækin urðu uppiskroppa með minni.
Lausn: við fjarlægðum mannlega þáttinn og gerðum sjálfvirkan aðgang að hámarkinu.
Það tekur langan tíma að gilda um nýju reglurnar. Lausn: flýttu fyrir beitingu reglna, gerðu þær dreifðar og samhliða. Þetta krefst dreifðs kerfis þannig að reglurnar berist sjálfar, án rsync eða SFTP í þúsund kerfi.
Enginn eldveggur inni í hlutum. Eldveggur innan hluta fór að koma til okkar þegar mismunandi þjónusta birtist innan sama nets. Lausn: notaðu eldvegg á hýsingarstigi - hýsiltengda eldveggi. Næstum alls staðar sem við erum með Linux, og alls staðar sem við höfum iptables, er þetta ekki vandamál.
Erfiðleikar við endurskoðunarreglur. Lausn: Hafðu allar reglur á einum stað til að skoða og stjórna, svo við getum endurskoðað allt.
Lítið eftirlit með innviðum. Lausn: Taktu skrá yfir alla þjónustu og aðgang á milli þeirra.
Þetta er meira stjórnunarferli en tæknilegt ferli. Stundum erum við með 200-300 nýjar útgáfur á viku, sérstaklega á kynningum og frídögum. Þar að auki er þetta aðeins fyrir eitt teymi af DevOps okkar. Með svo mörgum útgáfum er ómögulegt að sjá hvaða tengi, IP og samþættingar eru nauðsynlegar. Þess vegna vantaði okkur sérþjálfaða þjónustustjóra sem spurðu teymin: „Hvað er til staðar og hvers vegna komstu með það?
Eftir allt sem við settum af stað byrjaði netverkfræðingur árið 2019 að líta svona út.
Ræðismaður
Við ákváðum að setja allt sem við fundum með aðstoð þjónustustjóra inn í Consul og þaðan myndum við skrifa iptables reglur.
Hvernig ákváðum við að gera þetta?
- Við munum safna öllum þjónustum, netkerfum og notendum.
- Við skulum búa til iptables reglur byggðar á þeim.
- Við gerum sjálfvirkan stjórn.
- ....
- HAGNAÐUR.
Consul er ekki fjarstýrt API, það getur keyrt á hverjum hnút og skrifað í iptables. Það eina sem er eftir er að koma með sjálfvirkar stýringar sem hreinsa út óþarfa hluti, og flest vandamálin verða leyst! Við munum vinna úr restinni þegar við förum.
Hvers vegna ræðismaður?
Hefur sannað sig vel. Árin 2014-15 notuðum við það sem bakendi fyrir Vault, þar sem við geymum lykilorð.
Tapar ekki gögnum. Á notkunartímanum tapaði Consul ekki gögnum í einu slysi. Þetta er mikill plús fyrir eldveggsstjórnunarkerfi.
P2P tengingar flýta fyrir útbreiðslu breytinga. Með P2P koma allar breytingar fljótt, engin þörf á að bíða í klukkutíma.
Þægilegt REST API. Við skoðuðum einnig Apache ZooKeeper, en hann er ekki með REST API, svo þú verður að setja upp hækjur.
Virkar bæði sem Key Vault (KV) og Directory (Service Discovery). Þú getur geymt þjónustu, vörulista og gagnaver í einu. Þetta er ekki aðeins þægilegt fyrir okkur, heldur líka fyrir nágrannahópa, því þegar við byggjum upp alþjóðlega þjónustu hugsum við stórt.
Skrifað í Go, sem er hluti af Wargaming staflanum. Við elskum þetta tungumál, við höfum marga Go forritara.
Öflugt ACL kerfi. Í Consul er hægt að nota ACL til að stjórna hver skrifar hvað. Við tryggjum að eldveggsreglurnar skarast ekki við neitt annað og við munum ekki lenda í vandræðum með þetta.
En ræðismaður hefur líka sína galla.
- Skalast ekki innan gagnavera nema þú sért með viðskiptaútgáfu. Það er aðeins stigstærð af samtökunum.
- Mjög háð gæðum netsins og álagi netþjónsins. Consul mun ekki virka rétt sem þjónn á uppteknum netþjóni ef það eru einhverjar tafir á netinu, til dæmis ójafn hraði. Þetta er vegna P2P tenginga og uppfærslu dreifingarlíkana.
- Erfiðleikar við að fylgjast með framboði. Í Consul status getur hann sagt að allt sé í lagi, en hann dó fyrir löngu síðan.
Við leystum flest þessi vandamál á meðan við notuðum Consul, þess vegna völdum við það. Fyrirtækið er með áætlanir um annan stuðning en við höfum lært að takast á við vandamál og búum nú hjá Consul.
Hvernig Consul virkar
Við munum setja upp þrjá til fimm netþjóna í skilyrtu gagnaveri. Einn eða tveir netþjónar munu ekki virka: þeir munu ekki geta skipulagt ályktun og ákveðið hver hefur rétt fyrir sér og hver hefur rangt fyrir sér þegar gögnin passa ekki saman. Meira en fimm meika ekkert vit, framleiðni mun minnka.
Viðskiptavinir tengjast netþjónunum í hvaða röð sem er: sömu umboðsmenn, aðeins með fánanum server = false.
Eftir þetta fá viðskiptavinir lista yfir P2P tengingar og byggja upp tengingar sín á milli.
Á heimsvísu tengjum við saman nokkur gagnaver. Þeir tengja einnig P2P og hafa samskipti.
Þegar við viljum sækja gögn úr öðru gagnaveri fer beiðnin frá netþjóni til netþjóns. Þetta kerfi er kallað Serf siðareglur. Serf siðareglur, eins og Consul, er þróuð af HashiCorp.
Nokkrar mikilvægar staðreyndir um ræðismann
Consul hefur skjöl sem lýsa því hvernig það virkar. Ég mun aðeins gefa valdar staðreyndir sem vert er að vita.
Ráðgjafaþjónar velja meistara úr hópi kjósenda. Consul velur meistara af listanum yfir netþjóna fyrir hverja gagnaver og allar beiðnir fara eingöngu til hans, óháð fjölda netþjóna. Meistarafrysting leiðir ekki til endurkjörs. Ef skipstjóri er ekki valinn eru beiðnir ekki afgreiddar af neinum.
Viltu lárétta skala? Því miður, nei.
Beiðni til annars gagnavers fer frá meistara til meistara, óháð því á hvaða netþjóni hún kom. Valinn skipstjóri fær 100% af álaginu, nema álaginu á framsendingarbeiðnum. Allir netþjónar í gagnaverinu eru með uppfært afrit af gögnunum, en aðeins einn svarar.
Eina leiðin til að skala er að virkja gamaldags ham á viðskiptavininum.
Í gamalt ham geturðu svarað án ályktunar. Þetta er háttur þar sem við gefum upp gagnasamkvæmni en lesum aðeins hraðar en venjulega og hvaða netþjónn sem er bregst við. Að sjálfsögðu tekur aðeins upp í gegnum meistarann.
Consul afritar ekki gögn á milli gagnavera. Þegar samband er sett saman mun hver netþjónn aðeins hafa sín eigin gögn. Fyrir aðra snýr hann sér alltaf að einhverjum öðrum.
Atómvirkni starfsemi er ekki tryggð utan viðskipta. Mundu að þú ert ekki sá eini sem getur breytt hlutunum. Ef þú vilt hafa það öðruvísi, gerðu viðskipti með læsingu.
Lokunaraðgerðir tryggja ekki læsingu. Beiðnin fer frá master til master, og ekki beint, svo það er engin trygging fyrir því að lokunin virki þegar þú lokar td í öðru gagnaveri.
ACL ábyrgist heldur ekki aðgang (í mörgum tilfellum). ACL virkar kannski ekki vegna þess að það er geymt í einu sambandsgagnaveri - í ACL gagnaveri (Primary DC). Ef DC svarar þér ekki mun ACL ekki virka.
Einn frosinn meistari mun valda því að allt sambandið frystir. Til dæmis eru 10 gagnaver í sambandsríki og eitt er með lélegt net og einn húsbóndi bilar. Allir sem eiga samskipti við hann verða fastir í hring: það er beiðni, það er ekkert svar við henni, þráðurinn frýs. Það er engin leið að vita hvenær þetta gerist, bara eftir einn eða tvo klukkutíma mun allt sambandið falla. Það er ekkert sem þú getur gert í því.
Staða, ályktun og kosningar eru meðhöndlaðar með sérstökum þræði. Endurkjör verður ekki, staðan mun ekki sýna neitt. Þú heldur að þú sért með lifandi ræðismann, þú spyrð og ekkert gerist - það er ekkert svar. Á sama tíma sýnir staðan að allt er í lagi.
Við höfum lent í þessu vandamáli og þurftum að endurbyggja tiltekna hluta gagnavera til að forðast það.
Viðskiptaútgáfan af Consul Enterprise hefur ekki nokkra af ókostunum hér að ofan. Það hefur margar gagnlegar aðgerðir: að velja kjósendur, dreifingu, skala. Það er aðeins eitt „en“ - leyfiskerfið fyrir dreift kerfi er mjög dýrt.
Líf reiðhestur: rm -rf /var/lib/consul - lækning við öllum sjúkdómum lyfsins. Ef eitthvað virkar ekki fyrir þig skaltu bara eyða gögnunum þínum og hlaða niður gögnunum af afriti. Líklegast mun ræðismaður vinna.
BEFW
Nú skulum við tala um það sem við höfum bætt við Consul.
er skammstöfun fyrir BACKEndFég mun faraWallt. Ég varð að nefna vöruna einhvern veginn þegar ég bjó til geymsluna til að setja fyrstu prófunarskuldbindingarnar inn í hana. Þetta nafn er eftir.
Reglusniðmát
Reglurnar eru skrifaðar í iptables setningafræði.
- -N BEFW
- -P INNTAK DROP
- -A INNPUT -m ástand—ástand tengt, STOFNAÐ -j SAMÞYKKT
- -A INNSLAG -i lo -j SAMÞYKKJA
- -A INNTAK -j BEFW
Allt fer í BEFW keðjuna, nema ESTABLISHED, RELATED og staðbundinn gestgjafi. Sniðmátið getur verið hvað sem er, þetta er bara dæmi.
Hvernig er BEFW gagnlegt?
Þjónusta
Við erum með þjónustu, hún hefur alltaf höfn, hnút sem hún keyrir á. Frá hnútnum okkar getum við spurt umboðsmanninn á staðnum og komist að því að við höfum einhvers konar þjónustu. Þú getur líka sett merki.
Sérhver þjónusta sem er í gangi og skráð hjá Consul breytist í iptables reglu. Við erum með SSH - opið port 22. Bash forskriftin er einföld: curl og iptables, ekkert annað þarf.
Viðskiptavinir
Hvernig á að opna aðgang ekki öllum, heldur vali? Bættu IP listum við KV geymslu eftir þjónustuheiti.
Til dæmis viljum við að allir á tíunda netinu geti fengið aðgang að SSH_TCP_22 þjónustunni. Bæta við einum litlum TTL reiti? og nú erum við með bráðabirgðaleyfi, til dæmis fyrir einn dag.
Aðgangur
Við tengjum þjónustu og viðskiptavini: við erum með þjónustu, KV geymsla er tilbúin fyrir hvern. Nú gefum við aðgang ekki öllum, heldur vali.
Hópar
Ef við skrifum þúsundir IP-tölva fyrir aðgang í hvert skipti, verðum við þreytt. Komum með hópa - sérstakt hlutmengi í KV. Köllum það Alias (eða hópa) og geymum hópa þar samkvæmt sömu reglu.
Tengjumst: nú getum við opnað SSH ekki sérstaklega fyrir P2P, heldur fyrir heilan hóp eða nokkra hópa. Á sama hátt er TTL - þú getur bætt við hóp og fjarlægt úr hópnum tímabundið.
Sameining
Vandamál okkar er mannlegi þátturinn og sjálfvirkni. Hingað til höfum við leyst þetta með þessum hætti.
Við vinnum með Puppet og flytjum allt sem tengist kerfinu (umsóknarkóða) til þeirra. Puppetdb (venjulegur PostgreSQL) geymir lista yfir þjónustur sem eru í gangi þar, þær má finna eftir tegund auðlinda. Þar getur þú fundið út hver sækir um hvar. Við erum líka með dráttarbeiðni og samrunabeiðnakerfi fyrir þetta.
Við skrifuðum befw-sync, einfalda lausn sem hjálpar til við að flytja gögn. Í fyrsta lagi eru samstillingarkökur opnaðar af puppetdb. HTTP API er stillt þar: við biðjum um hvaða þjónustu við höfum, hvað þarf að gera. Síðan gera þeir beiðni til ræðismanns.
Er samþætting til staðar? Já: þeir skrifuðu reglurnar og leyfðu Pull Requests að vera samþykktar. Þarftu ákveðna höfn eða bæta gestgjafa við einhvern hóp? Dragðu beiðni, skoðaðu - ekki meira "Finndu 200 önnur ACL og reyndu að gera eitthvað í því."
Hagræðingu
Að hringja staðbundinn gestgjafa með tómri reglukeðju tekur 0,075 ms.
Bætum 10 iptables heimilisföngum við þessa keðju. Fyrir vikið mun pingið aukast 000 sinnum: iptables er algjörlega línulegt, vinnsla hvers heimilisfangs tekur nokkurn tíma.
Fyrir eldvegg þar sem við flytjum þúsundir ACL, höfum við fullt af reglum og þetta kynnir leynd. Þetta er slæmt fyrir leikjasamskiptareglur.
En ef við setjum 10 heimilisföng í ipset Pingið mun jafnvel minnka.
Málið er að „O“ (flækjustig reiknirit) fyrir ipset er alltaf jafnt og 1, sama hversu margar reglur það eru. Það er satt, það er takmörkun - það geta ekki verið fleiri en 65535 reglur. Í augnablikinu búum við við þetta: þú getur sameinað þær, stækkað þær, búið til tvö ípsets í einu.
Geymsla
Rökrétt framhald af endurtekningarferlinu er að geyma upplýsingar um viðskiptavini fyrir þjónustuna í ipset.
Nú erum við með sama SSH og við skrifum ekki 100 IP í einu, heldur setjum nafnið á ipsetinu sem við þurfum að eiga samskipti við og eftirfarandi reglu DROP. Það er hægt að breyta því í eina reglu „Hver er ekki hér, DROP“ en það er skýrara.
Nú höfum við reglur og sett. Aðalverkefnið er að búa til sett áður en regluna er skrifað, því annars skrifa iptables ekki regluna.
Almenn áætlun
Í formi skýringarmyndar lítur allt sem ég sagði svona út.
Við skuldbindum okkur til Puppet, allt er sent til gestgjafans, þjónusta hér, ipset þar, og allir sem ekki eru skráðir þar mega ekki.
Leyfa & neita
Til að bjarga heiminum á fljótlegan hátt eða slökkva fljótt á einhverjum, í upphafi allra keðja gerðum við tvö ípsets: rules_allow и rules_deny. Hvernig það virkar?
Til dæmis er einhver að búa til álag á vefnum okkar með vélmennum. Áður þurfti að finna IP-töluna hans úr loggunum, fara með hana til netverkfræðinga, svo þeir gætu fundið uppsprettu umferðarinnar og bannað hann. Það lítur öðruvísi út núna.
Við sendum það til ræðismanns, bíddu í 2,5 sekúndur og það er búið. Þar sem Consul dreifir hratt í gegnum P2P virkar það alls staðar, hvar sem er í heiminum.
Einu sinni hætti ég einhvern veginn algjörlega WOT vegna mistaka í eldveggnum. rules_allow - þetta er trygging okkar gegn slíkum málum. Ef við gerðum mistök einhvers staðar með eldveggnum er eitthvað lokað einhvers staðar, við getum alltaf sent skilyrt 0.0/0að taka allt upp fljótt. Seinna munum við laga allt með höndunum.
Önnur sett
Þú getur bætt við hvaða öðrum settum sem er í geimnum $IPSETS$.
Til hvers? Stundum þarf einhver ipset, til dæmis, til að líkja eftir lokun einhvers hluta klasans. Hver sem er getur komið með hvaða sett sem er, nefnt þau og þau verða sótt hjá ræðismanni. Á sama tíma geta sett annað hvort tekið þátt í iptables reglum eða virkað sem lið NOOP: Samræmi verður viðhaldið af púknum.
Notendur
Áður var þetta svona: notandinn tengdur við netið og fékk breytur í gegnum lénið. Fyrir tilkomu nýrrar kynslóðar eldveggja vissi Cisco ekki hvernig á að skilja hvar notandinn var og hvar IP-talan var. Þess vegna var aðgangur aðeins veittur í gegnum hýsingarheiti vélarinnar.
Hvað gerðum við? Við lentum í því þegar við fengum heimilisfangið. Venjulega er þetta dot1x, Wi-Fi eða VPN - allt fer í gegnum RADIUS. Fyrir hvern notanda búum við til hóp eftir notendanafni og setjum IP í hann með TTL sem er jafn dhcp.lease hans - um leið og það rennur út hverfur reglan.
Nú getum við opnað aðgang að þjónustu, eins og öðrum hópum, eftir notendanafni. Við höfum tekið sársaukann af hýsingarnöfnum þegar þau breytast og við höfum tekið byrðina af netverkfræðingum vegna þess að þeir þurfa ekki lengur Cisco. Nú skrá verkfræðingar sjálfir aðgang á netþjóna sína.
Einangrun
Á sama tíma fórum við að taka einangrunina í sundur. Þjónustustjórar tóku úttekt og við greindum öll tengslanet okkar. Skiptum þeim í sömu hópa og á nauðsynlegum netþjónum var hópunum bætt við, til dæmis til að neita. Nú endar sama sviðsetningareinangrun í reglum_neitun framleiðslunnar, en ekki í framleiðslunni sjálfri.
Kerfið virkar hratt og einfaldlega: við fjarlægjum öll ACL af netþjónum, affermum vélbúnaðinn og fækkum einangruðum VLAN.
Heildareftirlit
Áður höfðum við sérstakan kveikju sem tilkynnti þegar einhver breytti eldveggsreglu handvirkt. Ég var að skrifa risastórt linter til að athuga eldveggreglur, það var erfitt. Heiðarleiki er nú stjórnað af BEFW. Hann tryggir ákaft að reglurnar sem hann setur breytist ekki. Ef einhver breytir eldveggsreglunum mun það breyta öllu til baka. „Ég setti fljótt upp proxy svo ég gæti unnið að heiman“ - það eru engir fleiri slíkir valkostir.
BEFW stjórnar ipsetinu frá þjónustunum og listanum í befw.conf, þjónustureglunum í BEFW keðjunni. En það fylgist ekki með öðrum keðjum og reglum og öðrum ísets.
Árekstursvörn
BEFW geymir alltaf síðasta þekkta góða ástandið beint í state.bin tvöfalda uppbyggingunni. Ef eitthvað fer úrskeiðis fer það alltaf aftur í þetta ástand.bin.
Þetta er trygging gegn óstöðugum Consul rekstri, þegar það sendi ekki gögn eða einhver gerði mistök og notaði reglur sem ekki er hægt að beita. Til að tryggja að við séum ekki eftir án eldveggs mun BEFW fara aftur í nýjasta ástandið ef villa kemur upp á einhverju stigi.
Í mikilvægum aðstæðum er þetta trygging fyrir því að við sitjum eftir með virkan eldvegg. Við opnum öll grá net í von um að admin komi og reddi því. Einhvern tíma mun ég setja þetta í stillingarnar, en nú erum við bara með þrjú grá net: 10/8, 172/12 og 192.168/16. Innan ræðismanns okkar er þetta mikilvægur eiginleiki sem hjálpar okkur að þróast frekar.
Demo: meðan á skýrslunni stendur sýnir Ivan kynningarham BEFW. Það er auðveldara að horfa á sýninguna . Demo frumkóði í boði .
Gildra
Ég skal segja þér frá villunum sem við lentum í.
ipset add set 0.0.0.0/0. Hvað gerist ef þú bætir 0.0.0.0/0 við ipset? Verður öllum IP-tölum bætt við? Verður netaðgangur í boði?
Nei, við fáum villu sem kostaði okkur tvær klukkustundir af niður í miðbæ. Þar að auki hefur villan ekki virkað síðan 2016, hún er staðsett í RedHat Bugzilla undir númeri #1297092 og við fundum hana fyrir tilviljun - úr skýrslu þróunaraðila.
Það er nú ströng regla hjá BEFW að 0.0.0.0/0 breytist í tvö heimilisföng: 0.0.0.0/1 и 128.0.0.0/1.
ipset endurheimta sett < skrá. Hvað gerir ipset þegar þú segir það restore? Heldurðu að það virki eins og iptables? Mun það endurheimta gögn?
Ekkert svoleiðis - það sameinar og gömlu heimilisföngin fara ekki neitt, þú lokar ekki fyrir aðgang.
Við fundum villu þegar einangrun var prófuð. Núna er frekar flókið kerfi - í staðinn fyrir restore haldin create temp, þá restore flush temp и restore temp. Í lok skipta: fyrir atomicity, því ef þú gerir það fyrst flush og á þessu augnabliki kemur einhver pakki, honum verður hent og eitthvað fer úrskeiðis. Svo það er smá svartagaldur þarna.
ræðismaður kv fá -datacenter=annað. Eins og ég sagði þá höldum við að við séum að biðja um einhver gögn, en annað hvort fáum við gögn eða villu. Við getum gert þetta í gegnum Consul á staðnum, en í þessu tilfelli munu báðir frjósa.
Staðbundinn Consul viðskiptavinur er umbúðir yfir HTTP API. En það hangir bara og svarar ekki Ctrl+C, eða Ctrl+Z, eða neitt, bara kill -9 í næstu stjórnborði. Við lentum í þessu þegar við vorum að byggja stóran klasa. En við höfum enga lausn ennþá; við erum að undirbúa að laga þessa villu í Consul.
Leiðtogi ræðismanns svarar ekki. Húsbóndi okkar í gagnaverinu svarar ekki, við hugsum: "Kannski mun endurvalsreikniritið virka núna?"
Nei, það mun ekki virka og eftirlit mun ekki sýna neitt: ræðismaður mun segja að það sé skuldbindingarvísitala, leiðtogi hefur fundist, allt sé í lagi.
Hvernig tökum við á þessu? service consul restart í cron á klukkutíma fresti. Ef þú ert með 50 netþjóna, ekkert mál. Þegar það eru 16 af þeim muntu skilja hvernig það virkar.
Ályktun
Fyrir vikið fengum við eftirfarandi kosti:
- 100% umfang allra Linux véla.
- Hraði.
- Sjálfvirkni.
- Við frelsuðum vélbúnaðar- og netverkfræðinga úr þrælahaldi.
- Samþættingarmöguleikar hafa birst sem eru næstum endalausir: jafnvel með Kubernetes, jafnvel með Ansible, jafnvel með Python.
Gallar: Ræðismaður, sem við verðum nú að búa við, og mjög mikill villukostnaður. Sem dæmi má nefna að einu sinni klukkan 6:XNUMX (á besta tíma í Rússlandi) var ég að breyta einhverju í netlistunum. Við vorum bara að byggja einangrun hjá BEFW á sínum tíma. Ég gerði mistök einhvers staðar, það virðist sem ég hafi gefið til kynna ranga grímu, en allt féll á tveimur sekúndum. Eftirlitið kviknar, aðstoðarmaðurinn á vakt kemur hlaupandi: „Við höfum allt!“ Deildarstjórinn varð gráhærður þegar hann útskýrði fyrir fyrirtækinu hvers vegna þetta gerðist.
Kostnaður við villu er svo mikill að við höfum komið upp okkar eigin flóknu forvarnarferli. Ef þú innleiðir þetta á stórum framleiðslustað þarftu ekki að gefa öllum meistaratákn yfir Consul. Þetta mun enda illa.
Kostnaðurinn. Ég skrifaði kóða fyrir 400 klukkustundir einn. Fjögurra manna lið mitt eyðir 4 klukkustundum á mánuði í stuðning fyrir alla. Miðað við verð hvers kyns eldveggs af nýrri kynslóð er það ókeypis.
Áætlanir. Langtímaáætlunin er að finna aðrar samgöngur til að koma í stað eða bæta við ræðismanninn. Kannski verður það Kafka eða eitthvað álíka. En á næstu árum munum við búa á Consul.
Strax áætlanir: samþætting við Fail2ban, með vöktun, með nftables, hugsanlega með öðrum dreifingum, mæligildi, háþróað eftirlit, hagræðingu. Kubernetes stuðningur er líka einhvers staðar í áætlunum, því nú höfum við nokkra klasa og löngun.
Meira úr áætlunum:
- leita að frávikum í umferðinni;
- netkortastjórnun;
- Kubernetes stuðningur;
- setja saman pakka fyrir öll kerfi;
- Web-UI.
Við erum stöðugt að vinna að því að auka stillingar, auka mæligildi og hagræðingu.
Taktu þátt í verkefninu. Verkefnið reyndist flott, en því miður er þetta samt eins manns verkefni. Koma til og reyndu að gera eitthvað: skuldbinda þig, prófa, leggja til eitthvað, gefa þitt mat.
Á meðan erum við að undirbúa , sem fer fram dagana 6. og 7. apríl í Sankti Pétursborg og bjóðum við hönnuðum á háhleðslukerfum . Reyndir fyrirlesarar vita nú þegar hvað þeir eiga að gera, en fyrir þá sem eru nýir að tala mælum við með a.m.k . Að taka þátt í ráðstefnunni sem fyrirlesari hefur ýmsa kosti. Þú getur lesið hverjar, til dæmis, í lokin .
Heimild: www.habr.com