2010. aastal oli ettevõttel 50 serverit ja lihtne võrgu mudel: tagakülg, esikülg ja tulemüür. Serverite arv kasvas, mudel muutus keerukamaks: ststage’ide, isoleeritud VLAN-ide ACL-idega, hiljem VPN VRF-iga, VLAN ACL-iga L2-l, VRF ACL-iga L3-l. Kas pea hakkas ringi käima? Edasi läheb veel huvitavamaks.
Kui serverite arv ulatus 16 000-ni, oli võimatu sellise suurusega erinevate segmentidega nutuseta töötada. Seetõttu leidisime välja uue lahenduse. Kasutasime Netfilteri, lisasime sellele Consuli andmeallikana ja saime kiire jaotatud tulemüüri. Selle asemel asendati ACL-id ruuterites ja kasutati seda nii välistena kui ka sisetulemüüridena. Dünaamiliseks haldamiseks arendasime BEFW süsteemi, mida rakendati igal pool: alates kasutajate juurdepääsu haldamisest tootmisvõrgus kuni võrgu segmentide üksteisest isoleerimiseni.
Kuidas see kõik töötab ja miks peaksite sellele süsteemile tähelepanu pöörama, räägib Ivan Agarov () — infrastruktuuri turvalisuse grupi juht Maintenance osakonnas Minskis Wargamingu arenduskeskuses. Ivan on SELinuxi fänn, armastab Perl-i ja kirjutab koodi. Turvalisuse grupi juhina töötab ta regulaarselt logide, varukoopiate ja R&D-iga, et kaitsta Wargamingut häkkerite eest ning tagada kõigi ettevõtte mängu serverite töö.
2DOMAINS on 16 aastat teeninud professionaale, kes on valmis maksma vaid nende valikute eest, mida nad tõeliselt kasutavad.
Enne kui räägin, kuidas me seda tegime, räägin, kuidas me üldse sinna jõudsime ja miks see vajalikuks osutus. Selleks liikuge 9 aastat tagasi: 2010. aastasse, kui World of Tanks just ilmuma hakkas. 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.
Esiküljel elavad halvad poisid, kes tahavad meid purustada, kuid seal on tulemüür. Tagaküljel ei ole tulemüüri, kuid seal on 50 serverit, mille kõik me teame. Kõik töötab hästi.
Nelja aasta jooksul kasvas serverite park 100 korda, 5000-ni. Ilmusid esimesed isoleeritud võrgud — ststage’id: neid ei saa lähetada tootmisse ning seal käis sageli see, mis võis olla ohtlik.
Võrgu mudel 2014.
Me kasutasime harjumuse tõttu samu seadmeid ning kogu töö toimus isoleeritud VLAN-ides: VLAN-idele kirjutatakse ACL-id, mis lubavad või keelavad teatud ühenduse.
2016. aastal saavutas serverite arv 8000. Wargaming omandas teisi stuudioid, lisandusid uued partnerlusvõrgustikud. Need tunduvad olevat meie omad, kuid mitte päris: partnerite VLAN sageli ei tööta, tuleb kasutada VPN-i koos VRF-iga, isolatsioonid keerusid keerulisemaks. ACL-i isolatsioonide segu suurenes.
Võrgumudel 2016. aastal.
2018. aasta alguseks kasvas masinate park 16 000-ni. Segmente oli 6 ja ülejäänud me ei lugenud, sealhulgas suletud segmente, kus hoiti finantsandmeid. Ilmusid konteinerivõrgud (Kubernetes), DevOps, pilvevõrgud, mis olid ühendatud VPN-i kaudu, näiteks IVS-ist. Reegleid oli väga palju - see oli valus.
Võrgumudel ja isolatsiooni viisid 2018. aastal.
Isolatsiooni jaoks kasutasime: VLAN koos ACL-iga L2-l, VRF koos ACL-iga L3-l, VPN ja palju muud. Liialt palju.
Probleemid
Kõik elavad ACL-i ja VLAN-i kõrval. Mis on üldse valesti? Sellele küsimusele vastab Harold, kes varjab valu.
Probleeme oli palju, kuid massilisi - viis.
- Hinnatõusu geomeetriline kasv uute reeglite jaoks.. Iga uus reegel lisandus kauem kui eelmine, sest kõigepealt pidi kontrollima, kas sellist reeglit juba ei eksisteeri.
- Segmendis ei olnud tulemüüri.. Segmendid eraldati kuidagi üksteisest, sees polnud juba piisavalt ressursse.
- Reeglid rakendati kaua. Käega üksiku kohaliku reegli saaks operaator kirjutada tunni jooksul. Globaalne võttis mitu päeva.
- Raskused reeglite auditeerimisel.. Täpsemalt, see ei olnud võimalik. Esimesed reeglid kirjutati juba 2010. aastal ja enamik nende autoritest ei töötanud enam ettevõttes.
- Madala taseme kontroll infrastruktuuri üle.. See on peamine probleem - me ei teadnud, mis meile üldse toimub.
Nii nägi 2018. aastal välja võrguinsener, kui ta kuulis: "Vaja on veel natuke ACL-i."
Lahendused
2018. aasta alguses otsustati midagi selle probleemiga teha.
Integreerimise hind kasvab pidevalt. Lähtudes sellest, et suured andakeskused lõpetasid isoleeritud VLAN-ide ja ACL-ide toetamise, sest seadmetes loppus mälu.
Lahendus: eemaldati inimfaktor ja maksimaalselt automatiseeriti ligipääsu andmine.
Uute reeglite rakendamine on aeglane. Lahendus: kiirendada reeglite rakendamist, muuta see jagatud ja paralleelseks. Selle jaoks on vajalik jagatud süsteem, et reeglid jõuaksid ise kohale, ilma rsync või SFTP-ta tuhandesse süsteemi.
Segmendis ei olnud tulemüüri. Tulev viralub, kui ühe võrgu sees ilmuvad erinevad teenused. Lahendus: kasutada host-põhiseid tulemüüre. Peaaegu kõikjal on meil Linux ja iptables, seega pole probleem.
Küsimused reeglite auditeerimisega. Lahendus: hoida kõik reeglid ühes kohas ülevaatamiseks ja haldamiseks, et saaksime neid auditeerida.
Infrastruktuuri kontrolli madal tase. Lahendus: inventeerida kõik teenused ja nende vahelised juurdepääsud.
See on pigem haldusprotsess kui tehniline. Mõnikord on meil nädalas 200-300 uut versiooni, eriti reklaamide ja pühade ajal. See kehtib ainult ühe meie DevOps'i meeskonna kohta. Nii suure versioonide arvu juures on võimatu mõista, millised pordid, IP-d ja integratsioonid on vajalikud. Seetõttu vajasime spetsiaalselt koolitatud teenusehaldurite meeskonda, kes küsisid meeskondadelt: 'Mis on olemas ja miks te selle üles tõite?'
Pärast kõike, mida oleme käivitanud, hakkas võrguinsener 2019. aastal välja nägema selline.
Consul
Otsustasime, et kõik, mida leidis teenusehaldurite abiga, paigaldame Consulisse 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 eemal API, ta võib töötada igas sõlmes ja kirjutada iptables'isse. Jääb vaid välja mõelda automatiseeritud kontrollvahendid, mis eemaldavad liialdused, ning suurem osa probleemidest on lahendatud! Ülejäänu viime ellu protsessi käigus.
Miks Consul?
On hästi ennast tõestanud. Aastatel 2014-15 kasutasime seda Vaulti tagaplaanina, kus hoiame paroole.
Ei kaota andmeid.. Consul ei ole andmeid kaotanud ühegi rikke ajal. See on suurt pluss süsteemi haldamisel.
P2P-ühendused kiirendavad muudatuste levikut.. P2P puhul tulevad kõik muudatused kiiresti, ei pea tundide viisi ootama.
Mugav REST API. Oleme kaalunud ka Apache ZooKeeper'i, kuid sel pole REST API-d, tuleks asja keeruliseks muuta.
Töötab nii võtmete (KV) salvestajana kui ka kataloogina (teenuse avastamine).. Saame salvestada teenuseid, katalooge ja andmekeskusi. See on mugav mitte ainult meile, vaid ka naabermeeskondadele, kuna ehitades globaalset teenust, mõtleme suurelt.
Kirjutatud Go-s, mis on Wargamingi tehnikapis. Me armastame seda keelt, meil on palju Go-arendajaid.
Tugev ACL-süsteem. Consulis saab ACL-i abil hallata, kellele ja mida kirjutada. Garantiime, et tulemüüri reeglid ei kattu rohkem millegagi ning meil ei teki sellega probleeme.
Aga Consulil on ka puudused.
- Ei skaalata andmekeskuse ulatuses, kui teil pole äriversiooni. See skaleerub ainult föderatsiooni kaudu.
- Oled väga sõltuv võrgu kvaliteedist ja serverite koormusest. Consul ei tööta õigesti serverina koormatud serveris, kui võrgus on mingid viivitused, näiteks ebaregulaarne kiirus. See on seotud P2P-ühenduste ja värskenduste levitamise mudelitega.
- Probleemid kättesaadavuse jälgimisega. Consuli staatuse järgi võib tunduda, et kõik on korras, kuid tegelikult on see juba ammu välja kukkunud.
Suur osa neist probleemidest lahendasime Consuli kasutamise käigus, seetõttu valisime selle. Ettevõttel on alternatiivse tagaosa plaanid, kuid me oleme õppinud probleemidega toime tulema ja seni elame Consuliga.
Kuidas Consul töötab
Tinglikku andmekeskusesse paigaldame serverid - kolm kuni viis. Üks või kaks serverit ei tööta: nad ei suuda korraldada kvoorumit ja otsustada, kes on õige, kui andmed ei klapi. Üks rohkem kui viis ei anna mõtet, jõudlus langeb.
Klientide ühendamine serveritega toimub suvalises järjekorras: samad agendid, ainult lipuga server = false.
Pärast seda saavad kliendid nimekirja P2P-ühendustest ja loovad omavahel sidemed.
Globaalset tasandil ühendame mitut andmekeskust. Need on samuti ühendatud P2P ja suhtlevad omavahel.
Kui tahame andmeid teisest andmekeskusest hankida, käib päring serverilt serverile. Sellist 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ööpõhimõtteid. Tõin välja ainult valitud faktid, mida tasub teada.
Consuli serverid valivad meistri hääletavate seas. Consul valib meistri serverite loendist iga andmekeskuse jaoks, ja kõik päringud suunatakse ainult temale, arvestamata serverite arvu. Meistri ootamine ei too kaasa uuesti valimist. Kui meistrit ei valita, ei teeninda keegi päringuid.
Kas soovisite horisontaalset skaleerimist? Vabandust, ei.
Päring teisele andmekeskusele toimub meistrilt meistrile, sõltumata sellest, millisele serverile see tuli. Valitud meister saab 100% koormusest, välja arvatud päringute edastamise koormus. Kõigil andmekeskuse serveritel on aktuaalne andmekoopia, kuid vastab vaid üks.
Ainus võimalus skaleerimiseks on sisse lülitada stale-režiim kliendil.
Stale-režiimis saab vastata ilma kvoorumita. See on režiim, kus loobume andmete järjepidevusest, kuid loeme natuke kiiremini kui tavaliselt, ja vastab iga server. Loomulikult toimub kirjutamine ainult läbi meistri.
Consul ei kopeeri andmeid andmekeskuste vahel.. Föderatsiooni kogumisel on igal serveril vaid oma andmed. Ülejäänud jaoks pöördub ta alati kellegi teise poole.
Tehinguteväliseid operatsioonide aatomilisust ei garanteerita.. Pidage meeles, et midagi ei saa muuta ainult teie. Kui soovite teisiti, viige läbi tehing lukuga.
Blokeerivad operatsioonid ei garanteeri lukustamist.. Päring läheb meistrilt meistrile, mitte otse, seega ei ole garantiid, et lukustus kehtib, kui teete lukustuse näiteks muus andmekeskuses.
ACL ei garanteeri ka juurdepääsu (paljuski).. ACL võib mitte töötada, kuna see on salvestatud ühte andmekeskusesse föderatsioonis - ACL andmekeskusesse (Primary DC). Kui DC Teile ei vasta, ei tööta ACL.
Üks hangunud meister viib kogu föderatsiooni hangumise.. Näiteks kui föderatsioonis on 10 andmekeskust ja ühes on halb võrk, ning üks meister kukub. Kõik, kes temaga suhtlevad, jäävad ringi kinni: päring toimub, sellele ei vastata, teema hangub. Te ei saa teada, millal see juhtub, lihtsalt tunni või kahe pärast kukub kogu föderatsioon. Te ei saa selle vastu midagi teha.
Staatus, kvoorum ja valimised töödeldakse eraldi lõimes. Uuendavaid valimisi ei toimu, staatuse teave ei näita midagi. Te arvate, et teie Consul töötab, pärite, ja midagi ei juhtu - vastust ei tule. Samal ajal näitab staatus, et kõik on hästi.
Oleme selle probleemiga kokku puutunud, olime sunnitud ümber ehitama teatud osa andmekeskustest, et seda vältida.
Consul Enterprise'i äriversioonis pole teatud ülaltoodud puudusi.Selles on palju kasulikke funktsioone: hääletajate valimine, jaotamine, skaleerimine. On ainult üks "aga" — jaotatud süsteemi litsentsimisest on üsna kallis.
Elu näpunäide: rm -rf /var/lib/consul — ravim kõigi agentide haiguste vastu. Kui midagi ei toimi, kustutage oma andmed ja laadige koopia andmed tagasi. Tõenäoliselt töötab Consul jälle.
BEFW
Nüüd räägime sellest, mida oleme Consulile lisanud.
— see on akronüüm BackEndFireWall. Toote nimetus pidi olema kuidagi valitud, kui ma loodud repot, et panna esimesed testkommit.
Reegli mallid
Reeglid on kirjutatud iptables'i 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
Kõik läheb läbi BEFW ahela, välja arvatud ESTABLISHED, RELATED ja localhost. Mall võib olla igasugune, see on lihtsalt näide.
Mis on BEFW kasu?
Teenused
Meil on teenus, millel on alati port ja sõlm, millel see töötab. Meie sõlmest saame kohalikult küsida agentilt ja teada saada, et meil on mõni teenus. Samuti saab lisada silte.
Iga teenus, mis on käivitatud ja registreeritud Consulis, muudetakse iptables'i reegliks. Meil on SSH — avame portaali 22. Bash-skript on lihtne: curl ja iptables, rohkem pole vaja.
Kliendid
Kuidas avada juurdepääs mitte kõigile, vaid valikuliselt? Teenuse nime järgi salvestada KV-lao IP-loendid.
Näiteks tahame, et kõik kümnenda võrgu kasutajad saaksid ligi SSH_TCP_22 teenusele. Lisame ühe väikese välja TTL? ja nüüd on meil ajutised load, näiteks üheks päevaks.
Juurdepääsud
Seome teenused ja kliendid: meil on teenus, igaühe jaoks on valmis KV-ladu. Nüüd anname ligipääsu mitte kõigile, vaid valikuliselt.
Grupid
Kui igal korral kirjutame tuhandeid IP-aadresse, siis väsime ära. Leiame grupid — eraldi alamhulk KV-s. Nimeta see Alias (või grupid) ja hoia seal gruppe sama põhimõtte järgi.
Seome: nüüd saame avada SSH mitte konkreetselt P2P-l, vaid tervele grupile või mitmele grupile. Samuti on olemas TTL — grupis saab ajutiselt lisada ja kustutada.
Integreerimine
Meie probleem on inimfaktor ja automatiseerimine. Praegu oleme selle nii lahendanud.
Me töötame Puppetiga ja edastame sellele kõik, mis puutub süsteemi (rakenduste kood). Puppetdb's (tavaline PostgreSQL) hoitakse teenuste loetelu, mis seal töötavad, ja neid saab leida ressursi tüübi järgi. Samuti saab seal näha, kes kuhu pöördub. Meil on ka pull request ja merge request süsteem selle jaoks.
Me kirjutasime befw-sync — lihtsa lahenduse, mis aitab andmeid edastada. Esiteks pöörduvad sync cookies puppetdb'sse. Seal on seadistatud HTTP API: küsime, millised teenused meil on ja mida on vaja teha. Seejärel tehakse päring Consuli.
Kas integratsioon on olemas? On: me kirjutasime reeglid ja lubasime Pull Requeste vastu võtta. Kas on vajalik mõni port või tuleb host mingisse gruppi lisada? Pull Request, ülevaatus — rohkem ei ole mitte mingit „Leia 200 muud ACL-i ja püüa midagi sellega teha.”
Optimeerimine
Pingi localhost tühja reeglite ahelaga aega 0,075 ms.
Lisame sellesse ahelasse 10 000 aadressi iptables. Tulemuseks on, et ping suureneb 5 korda: iptables on täiesti lineaarsed, iga aadressi töötlemine võtab aega.
Firewalli, kuhu me migreerime tuhandeid ACL-e, jaoks on meil palju reegleid, ja see tekitab viivitusi. Mänguprotokollide jaoks on see halb.
Aga kui me paneme 10 000 aadressi ipseti siis ping isegi väheneb.
Mõte on selles, et „O” (algoritmi keerukus) ipseti puhul on alati 1, sõltumata reeglite arvust. Tõsi, seal on piirang — reegleid ei tohi olla rohkem kui 65535. Praegu elame sellega: neid saab kombineerida, laiendada, teha kaks ipsetit ühes.
Salvestamine
Loogiline jätk protsesside iteratsioonides on teabe hoidmine klientide kohta teenuse ipsetis.
Nüüd on meil sama SSH ja me ei kirjuta kohe 100 IP-d, vaid määrame ipseti nime, millega suhelda, ja järgmise reegli DROP. Saame ümber kujundada ühe reegli „Kes ei ole siin, see DROP”, aga nii on silmatorkavam.
Nüüd on meil reeglid ja setid. Peamine ülesanne on luua set enne reegli kirjutamist, sest muidu iptables ei salvesta reeglit.
Üldine skeem
Skeemina näeb kõik, mida ma rääkisin, välja selline.
Teeme Puppetisse commit'i, kõik saadetakse hosti, teenused on siin, ipset seal ja kedagi, kes seal kirjas ei ole, ei lubata.
Luba & keela
Kuna kiirelt maailma päästa või kedagi kiiresti välja lülitada, tegime kõigi ahelate alguses kaks ipsetit: rules_allow ja rules_deny. Kuidas see töötab?
Näiteks keegi loob botidega koormuse meie veebile. Varem tuli leida logidest tema IP, anda see võrgutehnilistele inseneridele, et nad leiaksid liiklusallika ja blokeeriksid selle. Nüüd näeb see välja teisiti.
Saatame Consulisse, ootame 2,5 sek, ja valmis. Kuna Consul levitab kiiresti tänu P2P-le, töötab see igal pool, igas maailma nurgas.
Kord peatusin ma täielikult WOT-i, eksides tulemüüriga. rules_allow — see on meie kindlustus selliste juhtumite vastu. Kui me kuskil tulemüüriga eksime, ja midagi on blokeeritud, saame alati saata tinglikku 0.0/0, et kiiresti kõik üles tõsta. Hiljem saame kõik käsitsi korda teha.
Teised ipset'id
Võib lisada teisi ipset'e süsteemi $IPSETS$.
Miks? Mõnikord on kellelgi vaja ipset'i, näiteks, et emuleerida osa klastri väljalülitamist. Igaüks võib tuua erinevaid ipset'e, neid nimetada ja need tuuakse Consulist. Samal ajal võivad need osaleda iptables'i reeglites või olla lihtsalt käsud NOOP: konsistentsi toetab daemon.
Kasutajad
Varem oli nii: kasutaja ühendas võrku ja sai domeeni kaudu seadistused. Enne uue põlvkonna tulemüüride ilmumist ei osanud Cisco aru saada, kus kasutaja ja kus IP on. Seetõttu anti ligipääs ainult masina hostname'i kaudu.
Mida me tegime? Me sekkusime aadressi saamise hetkel. Üldiselt on see dot1x, Wi-Fi või VPN — kõik käib läbi RADIUS'e. Iga kasutaja jaoks loome grupp kasutajanime järgi ja paneme sinna IP aadressi, mille TTL on tema dhcp.lease — nii kui see aegub, kaob reegel.
Nüüd saame avada ligipääsu teenustele, nagu ka teistesse gruppidesse, kasutajanime järgi. Oleme pääsenud hostname'i valutest, kui need muutuvad, ja vähendanud võrgutehniliste inseneride koormust, sest nad ei vaja enam Cisco't. Nüüd kirjutavad insenerid ise ligipääsad oma serveritele.
Isolatsioon
Samas alustasime isolatsiooni analüüsimist. Teenusehaldurid tegid inventuuri ja me analüüsisime kõiki meie võrke. Jaotame need samadeks gruppideks ning vajalikesse serveritesse lisasime gruppidele näiteks deny. Nüüd satub sama stängimise isolatsioon produtktsiooni reeglite keeldumisse, kuid mitte sisestatavale produtktsiooni.
Skeem töötab kiiresti ja lihtsalt: eemaldame kõik ACL-id serveritelt, vabastame rauda, vähendame isoleeritud VLANide arvu.
Terviklikkuse kontroll
Varem oli meil spetsiaalne käivitus, mis teavitas, kui keegi käsitsi tulemüürireeglit muutis. Ma kirjutasin tohutu tulemüürireeglite kontrollimise lintimise, see oli keeruline. Praegu kontrollib BEFW terviklikkust. Ta jälgib hoolikalt, et tema loodud reeglid ei muutuks. Kui keegi muudab tulemüürireegleid, taastab ta kõik tagasi. "Ma tõstsin kiiresti proksit, et kodust töötada" — selliseid võimalusi enam ei ole.
BEFW kontrollib ipset teenuste ja loendi kaudu befw.conf, teenuste reeglid BEFW ahelas. Kuid ta ei jälgi teisi ahelaid ja reegleid ning muid ipset'e.
Kaitse riketest
BEFW salvestab alati viimase eduka oleku otse binaarsesse struktuuri state.bin. Kui midagi läheb valesti, tagastab ta alati selle state.bin'ile.
See on kindlustus ebastabiilse Consuli töö vastu, kui ta ei saatnud andmeid või keegi eksis ja kasutas reegleid, mida ei saa rakendada. Et me ei jääks ilma tulemüürist, taastub BEFW viimasele olekule, kui mõnes etapis toimub viga.
Kriitilistes olukordades on see garantii, et jääme töövõimelise tulemüüriga. Me avame kõik hallid võrgud lootuses, et administraator tuleb ja parandab. Kord panen selle konfigureerimisse, aga hetkel on meil lihtsalt kolm halli võrku: 10/8, 172/12 ja 192.168/16. Meie Consuli raames on see oluline omadus, mis aitab edasi areneda.
Demo: ettekande käigus demonstreerib Ivan BEFW demo-režiimi. Demonstraati on mugavam vaadata aadressil . Demoversiooni lähtekood on saadaval .
Pahupooled
Räägin vigadest, millega me silmitsi seisime.
ipset add set 0.0.0.0/0. Mis juhtub, kui lisada ipset'i 0.0.0.0/0? Lisatakse kõik IP-d? Avaneb juurdepääs internetile?
Ei, me saame vea, mis maksis meile kaks tundi seisakut. Ja see viga ei toimi alates 2016. aastast, see on RedHat Bugzilas numbri all #1297092, ja me leidsime selle juhuslikult — arendaja raportist.
Nüüd kehtib BEFW's rangelt 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 te ütlete talle restore? Вы думаете, он работает также, как iptables? Восстановит данные?
Mitte midagi sellist — ta teeb merge, ja vanad aadressid ei kao kuhugi, juurdepääsu ei sulgu.
Leidsime vea, kui testisime isolatsiooni. Nüüd on seal üsna keeruline süsteem — selle asemel, et restore teostatakse create temp, siis restore flush temp ja restore temp. Lõpus swap: atomaarseks, sest kui esiteks teostatakse flush Ja ja hetkedel, kui mõni pakett saabub, siis lükatakse see kõrvale ja midagi läheb valesti. Seetõttu on seal natuke musta maagiat.
consul kv get -datacenter=other. Nagu ma juba mainisin, arvame, et küsime mingisuguseid andmeid, kuid saame kas andmed või vea. Saame seda teha Consuli kaudu kohapeal, kuid sel juhul hangub nii üks kui teine.
Kohalik Consul-klient on HTTP API ümbermõeldud pildiks. Kuid see hangub ja ei reageeri ei Ctrl+C, ei Ctrl+Z-le, mitte millelegi, ainult , protsessi õrn sulgemine ja serveri seiskamine ( naaberterminalis. Oleme sellega silmitsi seisnud, kui ehitasime suurt klastrit. Kuid meil pole hetkel lahendust, valmistume selle vea parandamiseks Consulis.
Consuli juht ei reageeri. Meil ei reageeri keskserver andmekeskuses, me mõtleme: "Äkki töötab nüüd ümbervalimise algoritm?"
Ei, see ei toimi, ja jälgimine ei näita midagi: Consul ütleb, et kohustuste indeks on olemas, juht leitud, kõik on korras.
Kuidas me sellega toime tuleme? service consul restart cronis iga tunni tagant. Kui teil on 50 serverit - pole hullu. Kui neid on 16 000, mõistate, kuidas see töötab.
Kokkuvõte
Lõpuks saime järgmised eelised:
- 100% katmine kõigi Linux-masinatega.
- Kiirus.
- Automatiseerimine.
- Oleme vabastanud riistvara ja võrguinsenerid orjuse alt.
- On tekkinud praktiliselt piiramatu integratsiooni võimalused: olgu see Kubernetes, Ansible või Python.
Miinused: Consul, millega me nüüd elame, ja väga kõrge vea hind. Näiteks, kord kell 6 õhtul (tipptund Venemaal) muutsin ma midagi võrguliste nimekirjade juures. Just siis ehitasime isolatsiooni BEFW-l. Ma tegin kuskil vea, tundub, et määrasin vale maski, kuid kõik kukkus kahe sekundi jooksul. Jälgimine süttib, toimetaja tõttab: "Meie süsteem peab peesitama!" Osakonna juht hallitas, kui selgitas äri sellele, miks nii läks.
Axios on nii kõrge, et me mõtlesime välja oma keeruka ennetusprotseduuri. Kui kavatsete seda rakendada suurtootmises, ärge andke meistrite tokenit Consuli juurde kõigile oma. See lõpeb halvasti.
Kulud. Ma olen üksi koodi 400 tundi kirjutanud. Toetuseks kulutab minu 4 inimesest koosnev meeskond 10 tundi kuus kõigi peale. Võrreldes iga uue põlvkonna tulemüüriga, on see tasuta.
Plaane. Pikaajaline plaan on leida alternatiivne transport Consuli asemel või lisana. Võibolla on see Kafka või midagi sarnast. Kuid järgmise paari aasta jooksul elame me Consuli peal.
Lähituleviku plaanid: integreerimine Fail2bani, jälgimisega, nftables'iga, võimalusel ka teiste distributsioonidega, mõõdikud, laiendatud jälgimine, optimeerimine. Kubernetes'e tugi on samuti plaanides, kuna meil on hetkel mitu klastri ja soov.
Veel tuleviku plaane:
- liiklustuvastuse anomaaliad;
- võrgu kaardi haldamine;
- Kubernetes'e tugi;
- pakettide kokkupanek kõigi süsteemide jaoks;
- Veebiliides.
Töötame pidevalt konfiguratsiooni laiendamise, mõõdikute suurendamise ja optimeerimise kallal.
Liituge projektiga. Projekt on suurepärane, kuid kahjuks on see praegu ühe inimese projekt. Tulge ja proovige midagi teha: commitida, testida, pakkuda midagi välja, anda oma hinnang.
Vahepeal valmistume , mis toimub 6. ja 7. aprillil Peterburgis, ja kutsume kõrge koormusega süsteemide arendajaid . Kogenud esinejad teavad juba, mida teha, kuid noortele soovitame vähemalt . Konverentsil esinejana osalemisel on mitmeid eeliseid. Millised, saab lugeda näiteks lõpust. .
Allikas: habr.com
