2010. aastal oli ettevõttel 50 serverit ja lihtne võrgumudel: tagaplaan, esiplaan ja tulemüür. Serverite arv kasvas, mudel muutus keerulisemaks: etappid, isoleeritud VLANid koos ACL-dega, siis VPNid koos VRF-idega, VLANid koos ACL-dega L2-l, VRF-id koos ACL-dega L3-l. Pea käib ringi? Edasi läheb veel huvitavamaks.
Kui servereid sai juba 16 000, oli sellise mitmekesiste segmentide hulga haldamine nutte ja vaeva täis. Seetõttu leiti teine lahendus. Võeti Netfilteri tehnoloogia, lisati sellele Consul andmeallikana ning saadi kiire jagatud tulemüür. Sellega asendati ACL-id ruuterites ning kasutati nii välist kui sisemist tulemüüri. Dünaamiliseks haldamiseks koostati BEFW süsteem, mida rakendati igal pool: alates kasutajate juurdepääsu haldamisest tootmisvõrgus kuni võrgu segmentide isolatsioonini üksteisest.
Kuidas see kõik töötab ja miks peaksite sellele süsteemile tähelepanu pöörama, räägib Ivan Agarov () — infrastruktuuri turbegrupi juht Maintenance'i osakonnas Minski arenduskeskuses. Ivan on SELinuxi fänn, armastab Perl'i ja kirjutab koodi. Infrastruktuuri turbegrupi juhina töötab ta regulaarselt logide, varukoopiate ja R&D-keskkondadega, et kaitsta Wargamingut häkkerite eest ja tagada kõigi ettevõtte mängiserverite toimimine.
Ajalooline ülevaade
Enne kui räägin, kuidas me seda tegime, räägin, kuidas me üldse sinna jõudsime ja miks see vajalik oli. Selleks liikuge 9 aastat tagasi: 2010. aasta, kui World of Tanks alles turule tuli. Wargamingul oli umbes 50 serverit.
Ettevõtte serverite kasvu graafik.
Meil oli võrgu mudel. Selle aja jaoks oli see optimaalne.
Võrgu mudel 2010.
Frondil elavad halvad poisid, kes tahavad meid murda, kuid seal on tulekaitse. Tagumise poolel tulekaitset pole, kuid seal on 50 serverit, millest me kõiki teame. Kõik toimib hästi.
4 aasta jooksul kasvas serverite arv 100 korda, 5000-ni. Ilmusid esimesed isoleeritud võrgud — stendide testimisseadmed: need ei saanud minna tootmisse, kuid seal töötati sageli asjadega, mis võiksid olla ohtlikud.
Võrgu mudel 2014.
Tavaliselt kasutasime samu seadmeid ja kogu töö toimus isoleeritud VLAN-ide peal: VLAN-idesse kirjutatakse ACL-id, mis lubavad või keelavad teatud ühendusi.
2016. aastal kasvas serverite arv 8000-ni. Wargaming omandas teisi stuudiosid ning tekkisid uued partnervõrgustikud. Need näivad olevat meie omad, aga mitte päris: partnerite VLAN-id ei tööta sageli, seetõttu tuleb kasutada VPN-i koos VRF-iga, isolatsioonid muutusid keerulisemaks. ACL-i isolatsioonide segu kasvas.
Võrgumudel 2016. aastal.
2018. aasta alguseks kasvas masinate park 16 000-ni. Segmente oli 6, kuid ülejäänud me ei arvestanud, sealhulgas suletud segmendid, kus hoiti finantsteavet. Ilmusid konteinerivõrgud (Kubernetes), DevOps, pilvevõrgud, mis olid ühendatud VPN-i kaudu, näiteks IWS-ist. Reegleid oli väga palju — see oli piinav.
Võrgumudel ja isolatsiooni meetodid 2018. aastal.
Isolatsiooni jaoks kasutasime: VLAN-e koos L2 ACL-idega, VRF-i koos L3 ACL-idega, VPN-i ja palju muud. Liiga palju.
Probleemid
Kõik elavad ACL-ide ja VLAN-ide järgi. Mis küll valesti on? Sellele küsimusele vastab Harold, peites oma valu.
Probleeme oli palju, kuid ulatuslikke — viis.
- Uute reeglite geometriline hinnatõus.. Iga uus reegel võeti vastu pikemalt kui eelmine, kuna esmalt tuli kontrollida, kas sellist reeglit pole juba olemas.
- Sektoreid ei kaitse tulemüür.. Sektorid lahutasid üksteisest kuidagi, ressursid on seal sees puuduvad.
- Reeglite kehtestamine võttis aega. Kohalikku reeglit suudavad operaatorid käsitsi kirjutada tunni jooksul. Ülemaailmne nõudis mitmeid päevi.
- Oli raskusi reeglite auditeerimisega.. Täpsemalt, see oli võimatu. Esimesed reeglid kirjutati juba 2010. aastal ning enamus autoritest ei töötanud enam firmaski.
- Madala tasemega infrastruktuuri kontroll.. See on peamine probleem — me ei teadnud, mis meil üldse toimub.
Nii nägi välja võrguinsener 2018. aastal, kui ta kuulis: «Vaja on veel veidi ACL-i».
Lahendused
2018. aasta alguses otsustati midagi sellega ette võtta.
Integreerimise hind kasvab pidevalt. Aluspunktiks oli see, et suured andmekeskused lõpetasid isoleeritud VLANide ja ACL-ide toetamise, kuna seadmetes oli mäluruum otsa saanud.
Lahendus: eemaldati inimfaktor ja suurendati juurdepääsu automaatikat maksimaalselt.
Uued reeglid kehtestatakse kaua. Lahendus: reeglite rakendamise kiirus tuleb suurendada, muutes selle jaotatavaks ja paralleelseks. Selle jaoks on vajalik jaotatud süsteem, et reeglid saaksid automaatselt kohale toimetatud, ilma et oleks vaja rsync-i või SFTP-d tuhandel süsteemil.
Tulekahjusüütaja puudub segmentide sees. Tulekahjusüütaja algas meie jaoks, kui sama võrgu sees hakkasid ilmuma erinevad teenused. Lahendus: kasutada hostitasandi tulemüüre — host-based firewalls. Peaaegu kõikjal on meil Linux ja kõigil on iptables, seega ei ole see probleem.
Reeglite auditeerimisega on keerukusi. Lahendus: salvestada kõik reeglid ühte kohta ülevaate ja haldamise jaoks, nii suudame kõike auditeerida.
Infrastruktuuri kontrollimise madal tase. Lahendus: teha inventuur kõigist teenustest ja nende vahelisest ligipääsust.
See on rohkem haldusprotsess kui tehniline. Mõnikord on meil nädalas 200–300 uut versiooni, eriti kampaaniate ja pühade ajal. See kehtib ainult meie DevOps'i meeskonna kohta. Niisuguste versioonide arvuga on võimatu näha, milliseid porte, IP-sid, integreerimisi on vaja. Seetõttu vajasime spetsiaalselt koolitatud teenusehaldureid, kes küsiksid meeskondadelt: „Mida teil üldse on ja miks te selle üles tõstsite?”
Pärast seda, kui me kõik käivitasime, nägi 2019. aastal võrguinsener välja juba selline.
Consul
Otsustasime, et kõik, mida me teenusehalduri abiga leidsime, paneme Consuli ja sealt kirjutame iptables'i reeglid.
Kuidas me otsustasime seda teha?
- Kogume kõik teenused, võrgud ja kasutajad.
- Loome nende põhjal iptables'i reeglid.
- Automatiseerime kontrolli.
- ….
- PROFIT.
Consul ei ole kaug-API, see võib töötada igas sõlmes ja kirjutada iptables'isse. Jääb vaid välja mõelda automaatse kontrolli vahendid, mis puhastavad liigse, ja suurem osa probleemidest on lahendatud! Ülejäänu viime ellu protsessi käigus.
Miks Consul?
On end hästi tõestanud. Aastatel 2014–15 kasutasime seda Vaulti tagaplaanina, kus hoiame paroole.
Ei kaota andmeid. Consul ei ole kaotanud andmeid üheski avarii ajal, mis on tohutu eelis tulemüüride haldamisse.
P2P-ühendused kiirendavad muutuste levikut. P2P kaudu tulevad kõik muudatused kiiresti, ei pea tundide kaupa ootama.
Mugav REST API. Me vaatasime ka Apache ZooKeeperit, kuid sellel puudub REST API, tuleb kasutada lisalahendusi.
Töötab nii võtmeväärsusena (KV) kui ka kataloogina (Teenuse avastamine). Saab salvestada kohe teenuseid, katalooge ja andmekeskusi. See on mugav mitte ainult meie jaoks, vaid ka naabermeeskondade jaoks, sest globaalse teenuse loomisel mõtleme ulatuslikult.
Kirjutatud Go keeles, mis kuulub Wargamingi tehnolooge. Me armastame seda keelt, meil on palju Go arendajaid.
Võimas ACL süsteem. Consuliga saab ACL abil hallata, kellel on õigus ja mida kirjutada. Garantii, et tulemüüri reeglid ei kattu enam millegagi, ja meil ei ole sellega probleeme.
Aga Consulil on ka puudusi.
- Ei skaala andmekeskuse raames, kui teil ei ole äriversiooni. See skaleerub ainult föderatsiooni kaudu.
- On väga sõltuv võrgu kvaliteedist ja serverite koormusest. Consul ei tööta korrektselt serverina ülekoormatud serveris, kui võrgus esinevad viivitused, näiteks ebaregulaarne kiirus. See on seotud P2P-ühendustega ja värskenduste levitamise mudelitega.
- Raskused kättesaadavuse jälgimisel. Consuli staatus võib näidata, et kõik on korras, kuid tegelikult on see juba ammu kuu juurde jäänud.
Enamik neist probleemidest lahendasime Consuli kasutamise ajal, mistõttu valisime selle. Ettevõttel on plaanid alternatiivse tagaküljega, kuid oleme õppinud probleemidega toime tulema ja praegu elame Consuliga.
Kuidas Consul töötab
Seame üles serverid - alates kolmest kuni viieni. Üks või kaks serverit ei sobi: nad ei suuda korraldada kvoorumi ja otsustada, kes on õige ja kes vale, kui andmed ei ühti. Ükski rohkem kui viis ei ole mõtet, jõudlus langeb.
Kliente ühendatakse serveritega igas järjekorras: samad agendid, ainult lipuga server = false.
Pärast seda saavad kliendid P2P-ühenduste loendi ja loovad omavahel sidemeid.
Globaalset taset ühendame mitmeid andmekeskusi. Need on samuti P2P-ühenduses ja suhtlevad omavahel.
Kui me soovime andmeid teiselt andmekeskuselt üle võtta, toimub päring serverist serverisse. Seda skeemi nimetatakse Serfi protokolliks. Serfi protokoll, nagu ka Consul, on HashiCorpi arendus.
Mõned olulised faktid Consuli kohta
Consulil on dokumentatsioon, mis kirjeldab selle tööd. Nimetan ainult valikaid fakte, mida tasub teada.
Consuli serverid valivad hääletajate seast juhi. Consul valib igas andmekeskuses serverite nimekirjast juhi ja kõik päringud lähevad ainult temale, sõltumata serverite arvust. Juhi seiskumine ei too kaasa uuesti valimist. Kui juhti ei ole valitud — päringud ei saa kedagi teenindada.
Kas soovisite horisontaalset skaleerimist? Kahjuks ei.
Päring teisele andmekeskusele toimub juhi ja juhi vahel, olenemata sellest, millisele serverile see tuli. Valitud juht kannab 100% koormusest, välja arvatud päringute edastamise koormus. Ajakohane andmekopeerimine on kõigil andmekeskuse serveritel, kuid vastab ainult üks.
Ainus viis skaleerimiseks on kliendil stale-režiim aktiveerida.
Stale-režiimis saab vastata ilma kvoorumita. See on režiim, kus me loobume andmete järjepidevast seisundist, kuid loeme veidi kiiremini kui tavaliselt, ning vastata võib ükskõik milline server. Loomulikult saab salvestada ainult läbi meistri.
Consul ei kopeeri andmeid andmekeskuste vahel.. Föderatsiooni kogumisel on igal serveril ainult oma andmed. Muudele pöördub ta alati kellegi teise poole.
Tehingute välisel operatsioonide aatomilisust ei garanteerita.. Pidage meeles, et midagi võib muuta mitte ainult teie. Kui soovite muudatusi teha, viige läbi lukustusega tehing.
Lukustavad operatsioonid ei garanteeri lukustamist.. Päring läheb meistrilt meistrile, mitte otse, seega ei ole garantiid, et lukustus töötab, kui teete lukustuse, näiteks teises andmekeskuses.
ACL ei garanteeri ka ligipääsu (paljuski).. ACL võib mitte töötada, kuna see talletatakse föderatsiooni ühes andmekeskuses — ACL andmekeskuses (Primary DC). Kui DC ei vasta, ei tööta ACL.
Üks kinni jäänud meister toob kaasa kogu föderatsiooni seiskumise.. Näiteks föderatsioon, kus on 10 andmekeskust, ja ühes on halb võrk ning üks server sureb. Kõik, kes temaga suhtlevad, hanguvad ringis: päring läheb, vastust ei tule, teema hangub. Pole võimalik teada, millal see juhtub, kas lihtsalt tunni või kahe pärast kukub kogu föderatsioon. Te ei saa sellega midagi teha.
Staatus, kvoorum ja valimised töödeldakse eraldi lõimes. Ümbervalimisi ei toimu, staatus ei näita midagi. Te arvate, et Teil on aktiivne Consul, küsite, ja ei juhtu midagi — vastust pole. Samal ajal näitab staatus, et kõik on hästi.
Oleme selle probleemiga kokku puutunud, pidime konkreetseid osi andmekeskustest ümber ehitama, et seda vältida.
Consul Enterprise'i äriversioonis ei ole mõningaid eelnevalt mainitud puudusi.. Seal on palju kasulikke funktsioone: häälte valimine, jaotamine, skaleerimine. Ainuke 'aga' on see, et jaotatud süsteemi litsentsimisüsteem on väga kallis.
Eluhäki: rm -rf /var/lib/consul — ravim agentide kõigi haiguste vastu. Kui midagi ei tööta, kustutage lihtsalt oma andmed ja laadige andmed varukoopiast. Tõenäoliselt töötab Consul jälle.
BEFW
Nüüd räägime sellest, mida me Consulile lisasime.
— on akronüüm sõnalt BackEndFtuliWall. Toode pidi saama mingisuguse nime, kui ma loodud repositooriumi, kuhu panin esimesed testkommitid. See nimi jäi ka alles.
Reeglite mallid
Reeglid on kirjutatud iptables süntaksis.
- -N BEFW
- -P INPUT DROP
- -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
- -A INPUT -i lo -j ACCEPT
- -A INPUT -j BEFW
Meil läheb kõik BEFW ahelasse, välja arvatud KINDLAKS, RELATED ja localhost. Mall võib olla igasugune, see on lihtsalt näidis.
Miks on BEFW kasulik?
Teenused
Meil on teenus, seal on alati port ja node, kus see töötab. Oma nodest saame kohalikult küsida agendi käest ja teada saada, et meil on mingi teenus. Samuti saab lisada silte.
Iga teenus, mis on käivitatud ja registreeritud Consulis, muutub iptables reegliks. Meil on SSH — avame port 22. Bash-skript on lihtne: curl ja iptables, rohkem pole midagi vaja.
Kliendid
Kuidas avada ligipääs mitte kõigile, vaid valikuliselt? Teenuse nime alusel koguda KV-salvestusse IP-loendeid.
Näiteks, me tahame, et kõik kümnendast võrgust saaksid ligi SSH_TCP_22 teenusele. Lisame ühe väikse TTL välja? ja nüüd on meil ajutised lubamised, näiteks üheks päevaks.
Ligipääsud
Seome ühendad teenuseid ja kliente: meil on teenus, millele on igaks juhuks valmis KV-lao hoidla. Nüüd anname juurdepääsu mitte kõigile, vaid valikuliselt.
Rühmad
Kui me iga kord kirjutame tuhandeid IP-aadresse juurdepääsuks, siis väsime. Loome rühmitusi — eraldi alamkogumi KV-s. Nimeks paneme Alias (või rühmad) ja hoiame seal rühmi sama põhimõtte kohaselt.
Ühendame: nüüd saame avada SSH mitte konkreetselt P2P-le, vaid tervele rühmale või mitmele rühmale. Samuti on olemas TTL — võime rühma lisada ja sealt ajutiselt eemaldada.
Integreerimine
Meie probleem on — inimfaktor ja automatiseerimine. Hetkel oleme selle lahendanud nii.
Kasutame Puppetit ja viime sinna kõik, mis on seotud süsteemiga (rakenduste kood). Puppetdb-s (tavaline PostgreSQL) hoitakse teenuste nimekirja, mis seal on käivitatud, neid saab leida ressursi tüübi järgi. Samuti saab sealt leida, kes kuhu pöördub. Meil on ka pull request ja merge request süsteem selle jaoks.
Oleme kirjutanud befw-sync — lihtsa lahenduse, mis aitab andmeid edastada. Esiteks pöörduvad sync küpsised puppetdb-sse. Seal on seadistatud HTTP API: küsime, millised teenused meil on ja mida on vaja teha. Seejärel tehakse päring Consulisse.
Kas integratsioon on olemas? Jah: me kirjutasime reeglid, lubasime Pull Requesti. Kas on vaja mingit porti või lisada host mingisse gruppi? Pull Request, ülevaatus — mitte mingeid „Leia 200 muud ACL-i ja proovi midagi nende teha”.
Optimeerimine
Ping localhost tühja reeglite jadaga kestab 0,075 ms.
Lisame sellesse jadasse 10 000 iptables aadressi. Selle tulemusena ping suureneb 5 korda: iptables töötlemine on täiesti lineaarne, iga aadressi töötlemine võtab natuke aega.
Tulevikus, kuhu me migreerime tuhandeid ACL-e, on meil palju reegleid ja see toob kaasa viivituse. Mänguprotokollide jaoks on see halb.
Aga kui me paigutame 10 000 aadressi ipseti siis ping isegi väheneb.
Mõte on selles, et „O” (algoritmi keerukus) ipseti jaoks on alati 1, olenemata sellest, kui palju reegleid seal on. Tõsi, seal on piirang — reegleid ei tohi olla rohkem kui 65535. Seni elame sellega: neid saab kombineerida, laiendada, teha kaks ipseti ühes.
Hoidmine
Loogiline jätk iteratsioonide protsessis on teabe hoidmine klientide kohta teenuse jaoks ipsetis.
Nüüd on meil sama SSH, ja me ei kirjuta kohe 100 IP-d, vaid määrame ipseti nime, millega tuleb suhelda, ja järgmise reegli. DROP. Võib luua reegel "Kes ei ole siin, see DROP", kuid nii on see selgem.
Nüüd on meil reeglid ja komplektid. Peamine ülesanne on komplekti luua enne reegli kirjutamist, sest muidu ei salvesta iptables reeglit.
Üldine skeem
Diagrammi kujul näeb kõik, mida ma rääkisin, välja nii.
Teeme Puppetisse commit'i, kõik saadetakse hostile, teenused on siin, ipset seal ja kes seal ei ole, seda ei lasta sisse.
Lubamine & keeldumine
Kuidas kiiresti maailma päästa või kedagi kiiresti välja lülitada, on kõikide ahelate alguses loodud kaks ipset: rules_allow ja rules_deny. Kuidas see töötab?
Näiteks, kui keegi botidega koormust tekitab meie Webile. Varem tuli leida logidest tema IP, viia see võrguinseneridele, et nad leiksid liikluse allika ja blokeeriksid ta. Nüüd näeb see välja teistmoodi.
Saadame Consulisse, ootame 2,5 s ja on valmis. Kuna Consul jaotab kiiresti P2P kaudu, töötab see igal pool maailmas.
Üks kord peatasingi WOT-i täielikult, eksides tulemüüriga. rules_allow — see on meie kindlustus selliste juhtumite vastu. Kui me oleme kuskil tulemüüriga eksinud, midagi kuskil blokeeritakse, saame alati saata tingimisi 0.0/0, et kiiresti kõik taastada. Hiljem parandame kõik käsitsi.
Teised komplektid
Võite lisada ruumi mistahes muid komplekte $IPSETS$.
Miks? Mõnikord on kellegi jaoks vajalikud ipset’id, näiteks teatud klastriosade katkestamise simuleerimiseks. Igaühel on võimalus tuua oma komplekte, neid nimetada ja need võetakse Consul’ist. Nendel komplektidel võivad olla nii iptables’i reeglitega seosed kui ka olla lihtsalt käsud. NOOP: konsistentsi toetab demon.
Kasutajad
Varem oli asi nii: kasutaja ühendas end võrku ja domeeni kaudu sai ta seadistused. Enne järgmise põlvkonna tulemüüri kasutuselevõttu ei suutnud Cisco aru saada, kus on kasutaja ja kus IP. Seetõttu anti ligipääs välja ainult masina hostname’i kaudu.
Mida me tegime? Me segunesime aadressi saamise hetkel. Tavaliselt on see dot1x, Wi-Fi või VPN — kõik läheb läbi RADIUS’e. Iga kasutaja jaoks loome grupi kasutajanime järgi ja paneme sellesse IP, mille TTL on tema dhcp.lease’i pikkuse poolest — niipea kui see aegub, kaob reegel.
Nüüd saame avada juurdepääsu teenustele nagu muudele gruppidele kasutajanime alusel. Oleme vabanenud hostname’ide vaevast, kui need muutuvad, ning vähendanud koormust võrguinseneridelt, kuna neil pole enam vaja Cisco’t. Nüüd kirjutavad insenerid ise oma serverites juurdepääsu õigusi.
Isolatsioon
Samas alustasime isolatsiooni analüüsimist. Teenusejuhid tegid inventuuri ja meie analüüsisime kõiki meie võrke. Jagame need rühmadesse ja lisasime vajalikud rühmad serveritesse, näiteks deny jaoks. Nüüd jõuab sama stendi isolatsioon produktsioonis rules_deny, kuid mitte ise produktsiooni.
Scheem töötab kiiresti ja lihtsalt: eemaldame kõik ACL-id serveritest, vabastame juhulisi seadmeid, vähendame isoleeritud VLANide arvu.
Integreerituse kontroll
Varem oli meil spetsiaalne käivitaja, mis teavitas, kui keegi käsitsi muuda tulevärgi reeglit. Kirjutasin tohutu lintimi tulevärgi reeglite kontrollimiseks, see oli keeruline. Nüüd jälgib integreeritust BEFW. Ta hoolikalt jälgib, et talle määratud reeglid ei muutuks. Kui keegi muudab tulevärgi reegleid, taastab ta kõik tagasi. 'Ma hõlpsasti tõstsin proksi, et kodust töötada' — selliseid variante enam ei ole.
BEFW kontrollib ipset teenustest ja loendist befw.conf, teenuste reeglid BEFW ahelas. Kuid ta ei jälgi teisi ahelaid ega reegleid ja teisi ipset-e.
Hädaolukordade kaitse
BEFW salvestab alati viimase eduka oleku binaarses struktuuris state.bin. Kui midagi läheb valesti, siis taastab ta selle state.bin-i.
See on kindlustus ebastabiilse Consuli töö eest, kui ta ei saatnud andmeid või keegi tegi vea ja kasutas reegleid, mida ei saa rakendada. Et me ei jääks ilma tulemüürist, taastab BEFW viimase oleku, kui mõnel hetkel juhtub viga.
Kriitilistes olukordades tagab see, et jääme töökorras tulemüüri juurde. Avame kõik hallid võrgud lootuses, et admin tuleb ja parandab asja. Millalgi viin selle konfigureerimisfailidesse, kuid praegu on meil lihtsalt kolm halli võrku: 10/8, 172/12 ja 192.168/16. Meie Consuli raames on see oluline funktsioon, mis aitab edasi areneda.
Demo: konverentsi ajal demonstreerib Ivan BEFW töötamise demorežiimi. Demot on mugavam vaadata . Demokood on saadaval .
Peidetud probleemid
Räägin vigadest, millega kokku puutusime.
ipset add set 0.0.0.0/0. Mis juhtub, kui lisada ipset-i 0.0.0.0/0? Kas lisatakse kõik IP-d? Kas pääseb internetti?
Ei, me saame vea, mis põhjustas meile kaks tundi seisakut. Ja see viga on olnud aktiivne alates 2016. aastast, selle kohta on RedHat Bugzilas number #1297092, ja me avastasime selle juhuslikult — arendaja aruandest.
Nüüd on BEFW-s rangelt seadustatud reegel, et 0.0.0.0/0 muutub kaheks aadressiks: 0.0.0.0/1 ja 128.0.0.0/1.
ipset restore set < file. Mida teeb ipset, kui ütlete talle restore? Вы думаете, он работает также, как iptables? Восстановит данные?
Pole midagi sarnast — ta teeb ühendamise (merge), ja vanad aadressid ei kao kuhugi, juurdepääs ei sulgu.
Me leidsime vea, kui testisime isolatsiooni. Nüüd on seal üsna keeruline süsteem — selle asemel, et restore tehakse create temp, seejärel restore flush temp ja restore temp. Lõpus swap: aatomaarne, sest kui kõigepealt teha flush ja sel hetkel tuleb mõni paket, siis see visatakse kõrvale ja midagi läheb valesti. Seetõttu on seal natuke musta maagiat.
consul kv get -datacenter=other. Kuidas ma juba ütlesin, me arvame, et küsime mingit teavet, kuid saame kas andmeid või veateate. Saame seda teha läbi Consul kohapeal, aga ka sel juhul hangub nii see kui ka teine.
Kohalik Consul- klient on HTTP API ümberpakitud. Kuid ta lihtsalt hangub ja ei reageeri ei Ctrl+C-le, ei Ctrl+Z-le, ega millelegi muule, ainult kill -9 na kõrval konsolis. Me kogesime seda, kui ehitasime suurt klastrit. Kuid meil pole praegu lahendust, valmistame ette selle vea parandamist Consulis.
Consul juhil ei ole vastust. Meil pole andmekeskuses meistrit, mõtleme: „Tõenäoliselt hakkab ümbervalimise algoritm praegu tööle?“
Ei, ei hakka, ja jälgimine ei näita midagi: Consul ütleb, et commitment index on olemas, juht on leitud, kõik on hästi.
Kuidas me sellega toime tuleme? service consul restart kroonis iga tunni tagant. Kui teil on 50 serverit - pole hullu. Kui neid on 16 000, saate aru, kuidas see töötab.
Kokkuvõte
Lõpuks saime järgmised eelised:
- 100% katvus kõikide Linuxi masinate puhul.
- Kiirus.
- Automatiseerimine.
- Vabastasime riistvara ja võrguinsenerid orjusest.
- Ilmnesid peaaegu piiramatu integreerimise võimalused: olgu need Kubernetes, Ansible või Python.
Miinused: Consul, millega me nüüd elama peame, ja väga kõrged vead. Näiteks, kord kell 6 õhtul (tipptund Venemaal) tegin võrgu nimekirjades midagi. Just siis ehitasime BEFW-is isolatsiooni. Ma tegin kuskil vea, tundub, et märkisin vale maski, ja kõik kukkus kahe sekundi jooksul kokku. Monitoring süttib, valvespetsialist jookseb sisse: „Meil on kõik kukkunud!” Osakonna juht hallines, kui selgitas ärile, miks see juhtus.
Veakulu on nii kõrge, et me lõime oma keerulise ennetusprotseduuri. Kui kavatsete seda suurel tootmishuumoris rakendada, ärge andke meistritokenit Consuli üle igale. See lõpeb halvasti.
Maksumus. Kirjutasin koodi 400 tundi üksi. Minu nelja inimese meeskond kulutab toetusele kuu jooksul 10 tundi kõigile. Võrreldes uue põlvkonna tulemüüride hinnaga on see tasuta.
Plaane. Pikaajaline plaan on leida alternatiivne transport Consuli asemel või lisaks. Võib-olla on selleks Kafka või midagi sarnast. Kuid järgmiste aastate jooksul elame me Consuliga.
Järgmised kavatsused: integreerimine Fail2bane'iga, jälgimine, nftables, võimalik, et teiste distributsioonidega, mõõdikud, täiendav jälgimine, optimeerimine. Kubernetes'e tugi on samuti plaanides, kuna meil on praegu mitu klastrit ja soov.
Veel plaanides:
- anomaaliate otsimine liikluses;
- võrgukaardi haldamine;
- Kubernetes'e tugi;
- pakettide koostamine kõigi süsteemide jaoks;
- Web-UI.
Töötame pidevalt konfiguratsiooni laiendamise, mõõdikute suurendamise ja optimeerimise kallal.
Liituge projektiga. Projekt on tõeliselt äge, kuid kahjuks on see praegu ühe inimese projekt. Tulge ja proovige midagi teha: panustada, testida, midagi pakkuda, anda oma hinnang.
Samas valmistume , mis toimub 6. ja 7. aprillil Peterburis, ja kutsume kõrgekoormuslike süsteemide arendajaid . Kogenud esinejad teavad juba, mida teha, ja soovitame algajatele ettekannetes vähemalt . Konverentsil osalejana rääkimine toob mitmeid eeliseid. Millised, sellest saab lugeda näiteks lõpuks. .
Allikas: habr.com
