2010-ben a cég 50 szerver volt és egy egyszerű hálózati modell: backend, frontend és tűzfal. A szerverek száma nőtt, a modell összetettebbé vált: staging, izolált VLAN-ok ACL-ekkel, majd VPN-ek VRF-ekkel, VLAN-ok ACL-ekkel L2-n, VRF-k ACL-ekkel L3-on. Pörög a fej? Később szórakoztatóbb lesz.
Amikor 16 000 szerver volt, lehetetlenné vált szakadás nélkül dolgozni ennyi heterogén szegmens mellett. Így egy másik megoldást találtunk ki. Fogtuk a Netfilter veremét, adatforrásként hozzáadtuk a Consul-t, és kaptunk egy gyorsan elosztott tűzfalat. Lecserélték az ACL-eket az útválasztókon, és külső és belső tűzfalként használták őket. Az eszköz dinamikus kezeléséhez kifejlesztettük a BEFW rendszert, amelyet mindenhol használtak: a termékhálózat felhasználói hozzáférésének kezelésétől a hálózati szegmensek egymástól való elkülönítéséig.
Elmondja, hogyan működik mindez, és miért érdemes közelebbről megvizsgálni ezt a rendszert. Ivan Agarkov () a Karbantartási részleg infrastruktúra biztonsági csoportjának vezetője a vállalat minszki fejlesztési központjában. Ivan SELinux rajongó, szereti a Perlt, és kódokat ír. Az információbiztonsági csoport vezetőjeként rendszeresen dolgozik naplókkal, biztonsági mentésekkel és kutatás-fejlesztéssel, hogy megvédje a Wargamingot a hackerektől, és biztosítsa a cég összes játékszerverének működését.
Történelmi háttér
Mielőtt elmondanám, hogyan csináltuk, elmondom, hogyan jutottunk el idáig, és miért volt erre szükség. Ehhez ugorjunk vissza 9 évet: 2010-ben most jelent meg a World of Tanks. A Wargaming körülbelül 50 szerverrel rendelkezett.
Vállalati szerver növekedési diagram.
Volt egy hálózati modellünk. Abban az időben ez volt az optimális.
Hálózati modell 2010-ben.
Vannak rosszfiúk a fronton, akik meg akarnak törni minket, de van tűzfala. A háttérben nincs tűzfal, de van 50 szerver, mindegyiket ismerjük. Minden jól működik.
4 év alatt 100-szorosára, 5000-re nőtt a szerverpark. Megjelentek az első elszigetelt hálózatok – staging: nem tudtak termelésbe kerülni, és sokszor olyan dolgok futottak ott, amelyek veszélyesek lehetnek.
Hálózati modell 2014-ben.
Tehetetlenségből ugyanazokat a hardverdarabokat használtuk, és minden munkát izolált VLAN-okon végeztünk: ACL-eket írnak a VLAN-okba, amelyek megengednek vagy tiltanak valamilyen kapcsolatot.
2016-ban a szerverek száma elérte a 8000-et. A Wargaming más stúdiókat is felszívott, és további társult hálózatok jelentek meg. Úgy tűnik, hogy a miénk, de nem egészen: a VLAN gyakran nem működik a partnereknél, VPN-t kell használni VRF-fel, az elkülönítés bonyolultabbá válik. Az ACL szigetelő keverék nőtt.
Hálózati modell 2016-ben.
2018 elejére a géppark 16 000-re nőtt, 6 szegmens volt, a többit nem számoltuk, beleértve a zártakat is, amelyekben pénzügyi adatokat tároltak. Megjelentek a konténerhálózatok (Kubernetes), a DevOps-ok, a VPN-en keresztül, például IVS-ről csatlakoztatott felhőhálózatok. Sok szabály volt – fájdalmas volt.
Hálózati modell és izolációs módszerek 2018-ban.
Az elkülönítéshez a következőket használtuk: VLAN ACL-lel L2-n, VRF ACL-lel L3-on, VPN és még sok más. Túl sok.
Problémák
Mindenki ACL-lel és VLAN-nal él. Mi a baj? Erre a kérdésre a fájdalmat elrejtő Harold fogja megválaszolni.
Sok probléma volt, de volt öt hatalmas.
- Geometriai áremelés az új szabályokhoz. Minden új szabály hozzáadása hosszabb ideig tartott, mint az előző, mert először meg kellett nézni, van-e már ilyen szabály.
- Nincs tűzfal a szegmenseken belül. A szegmensek valahogy elkülönültek egymástól, és már nem volt bent elég erőforrás.
- A szabályokat sokáig alkalmazták. Az üzemeltetők egy óra alatt megírhattak egy helyi szabályt kézzel. A globális több napig tartott.
- Az auditálási szabályokkal kapcsolatos nehézségek. Pontosabban nem lehetett. Az első szabályokat még 2010-ben írták meg, és szerzőik többsége már nem dolgozott a cégnél.
- Alacsony szintű infrastruktúra-ellenőrzés. Ez a fő probléma – nem nagyon tudtuk, mi folyik hazánkban.
Így nézett ki egy hálózati mérnök 2018-ban, amikor ezt hallotta: „Kell még néhány ACL”.
Решения
2018 elején úgy döntöttek, hogy teszünk valamit ez ellen.
Az integrációk ára folyamatosan nő. A kiindulópont az volt, hogy a nagy adatközpontok nem támogatták az elszigetelt VLAN-okat és ACL-eket, mivel az eszközök memóriája elfogyott.
Megoldás: eltávolítottuk az emberi tényezőt, és maximálisan automatizáltuk a hozzáférés biztosítását.
Az új szabályok alkalmazása sokáig tart. Megoldás: gyorsítsa fel a szabályok alkalmazását, tegye elosztottá és párhuzamossá. Ehhez elosztott rendszerre van szükség, hogy a szabályok maguk, rsync vagy SFTP nélkül, ezer rendszerbe kerüljenek.
Nincs tűzfal a szegmenseken belül. A szegmenseken belüli tűzfal akkor kezdett bejönni hozzánk, amikor különböző szolgáltatások jelentek meg ugyanazon a hálózaton belül. Megoldás: használjon tűzfalat a gazdagép szintjén - gazdagép alapú tűzfalak. Szinte mindenhol van Linux, és mindenhol van iptable, ez nem probléma.
Az auditálási szabályokkal kapcsolatos nehézségek. Megoldás: Tartsa az összes szabályt egy helyen felülvizsgálat és kezelés céljából, hogy mindent auditálhassunk.
Az infrastruktúra feletti ellenőrzés alacsony szintje. Megoldás: készítsen leltárt az összes szolgáltatásról és a köztük lévő hozzáférésről.
Ez inkább adminisztratív, mint technikai folyamat. Néha heti 200-300 új megjelenésünk van, különösen promóciók és ünnepek idején. Ráadásul ez csak a DevOps egyik csapatára vonatkozik. Ennyi kiadás mellett lehetetlen belátni, hogy milyen portokra, IP-címekre és integrációkra van szükség. Ezért szükségünk volt speciálisan képzett szervizmenedzserekre, akik megkérdezték a csapatokat: „Mégis mi van, és miért hozták fel?”
Mindazok után, amit elindítottunk, 2019-ben egy hálózati mérnök kezdett így kinézni.
Konzul
Elhatároztuk, hogy mindent, amit a szervizmenedzserek segítségével találunk, a Consulba teszünk, és onnan írunk iptables szabályokat.
Hogyan döntöttünk így?
- Összegyűjtjük az összes szolgáltatást, hálózatot és felhasználót.
- Ezek alapján hozzunk létre iptables szabályokat.
- Az irányítást automatizáljuk.
- ....
- NYERESÉG.
A Consul nem távoli API, minden csomóponton futhat és írhat az iptables-ba. Nem marad más hátra, mint előállni olyan automata vezérlésekkel, amelyek kitisztítják a felesleges dolgokat, és a legtöbb probléma megoldódik! A többit menet közben megoldjuk.
Miért konzul?
Jól bevált. 2014-15-ben a Vault háttérprogramjaként használtuk, amelyben a jelszavakat tároljuk.
Nem veszít adatot. A használat ideje alatt a Consul egyetlen baleset során sem veszített el adatot. Ez egy hatalmas plusz egy tűzfalkezelő rendszer számára.
A P2P kapcsolatok felgyorsítják a változások terjedését. A P2P segítségével minden változás gyorsan megtörténik, nem kell órákat várni.
Kényelmes REST API. Megfontoltuk az Apache ZooKeeper-t is, de nem rendelkezik REST API-val, ezért mankókat kell telepítenie.
Kulcstárolóként (KV) és címtárként (Service Discovery) is működik. Egyszerre tárolhat szolgáltatásokat, katalógusokat és adatközpontokat. Ez nemcsak nekünk, hanem a szomszédos csapatoknak is kényelmes, hiszen egy globális szolgáltatás kiépítésénél nagyban gondolkodunk.
Go-ban íródott, ami a Wargaming stack része. Szeretjük ezt a nyelvet, sok Go fejlesztőnk van.
Erőteljes ACL rendszer. A Consulban az ACL-ek segítségével szabályozhatja, hogy ki mit írjon. Garantáljuk, hogy a tűzfalszabályok semmi mással nem fedik át egymást, és ezzel nem lesz gondunk.
De a Consulnak vannak hátrányai is.
- Nem méretezhető adatközponton belül, hacsak nincs üzleti verziója. Csak szövetség által méretezhető.
- Nagyon függ a hálózat minőségétől és a szerverterheléstől. A Consul nem fog megfelelően működni kiszolgálóként egy foglalt szerveren, ha a hálózatban késések vannak, például egyenetlen sebesség. Ez a P2P kapcsolatoknak és a frissítési terjesztési modelleknek köszönhető.
- Nehézségek a rendelkezésre állás megfigyelésében. Konzul státuszban elmondhatja, hogy minden rendben, de régen meghalt.
A legtöbb problémát a Consul használata során megoldottuk, ezért választottuk. A cégnek tervei vannak egy alternatív háttérrel, de megtanultuk kezelni a problémákat, és jelenleg a Consul-lal élünk.
Hogyan működik a Consul
Három-öt szervert telepítünk egy feltételes adatközpontba. Egy-két szerver nem fog működni: nem tudják megszervezni a határozatképességet és eldönteni, hogy kinek van igaza és kinek nincs igaza, ha az adatok nem egyeznek. Ötnél többnek semmi értelme, a termelékenység csökkenni fog.
A kliensek tetszőleges sorrendben csatlakoznak a szerverekhez: ugyanazok az ügynökök, csak a jelzővel server = false.
Ezt követően az ügyfelek megkapják a P2P kapcsolatok listáját, és kapcsolatokat építenek ki egymás között.
Globális szinten több adatközpontot kapcsolunk össze. P2P-t is kapcsolnak és kommunikálnak.
Amikor adatokat szeretnénk lekérni egy másik adatközpontból, a kérés szerverről szerverre megy. Ezt a sémát az ún Jobbágyprotokoll. A Serf protokollt a Consulhoz hasonlóan a HashiCorp fejlesztette ki.
Néhány fontos tény a konzulról
A konzul rendelkezik dokumentációval, amely leírja, hogyan működik. Csak kiválasztott tényeket közölök, amelyeket érdemes tudni.
A konzuli szerverek választanak ki egy mestert a szavazók közül. A Consul minden adatközponthoz kiválaszt egy mestert a szerverek listájából, és minden kérés csak erre érkezik, függetlenül a szerverek számától. A mesterfagyás nem vezet újraválasztáshoz. Ha nincs kiválasztva a mester, akkor a kéréseket senki nem szolgálja ki.
Vízszintes méretezést akart? Elnézést, nem.
Egy másik adatközponthoz intézett kérés mesterről mesterre megy, függetlenül attól, hogy melyik szerverre érkezett. A kiválasztott mester a terhelés 100%-át megkapja, kivéve a továbbítási kérések terhelését. Az adatközpontban található összes szerver rendelkezik az adatok naprakész másolatával, de csak egy válaszol.
A méretezés egyetlen módja az elavult mód engedélyezése az ügyfélen.
Elavult módban határozatképesség nélkül is válaszolhat. Ez egy olyan mód, amelyben feladjuk az adatok konzisztenciáját, de a szokásosnál kicsit gyorsabban olvasunk, és bármelyik szerver válaszol. Természetesen a felvétel csak a mesteren keresztül történik.
A Consul nem másol adatokat az adatközpontok között. Az összevonás összeállításakor minden kiszolgálónak csak saját adatai lesznek. Másokért mindig máshoz fordul.
A műveletek atomitása nem garantált tranzakción kívül. Ne feledje, hogy nem te vagy az egyetlen, aki megváltoztathatja a dolgokat. Ha másképp szeretné, zárral bonyolítson tranzakciót.
A blokkolási műveletek nem garantálják a reteszelést. A kérés mestertől mesterig halad, és nem közvetlenül, így nincs garancia arra, hogy a blokkolás működni fog, ha például egy másik adatközpontban blokkol.
Az ACL sem garantálja a hozzáférést (sok esetben). Előfordulhat, hogy az ACL nem működik, mert egyetlen összevonási adatközpontban van tárolva – az ACL adatközpontban (elsődleges DC). Ha a DC nem válaszol, az ACL nem fog működni.
Egy lefagyott mester az egész szövetséget lefagyja. Például egy szövetségben 10 adatközpont van, és az egyiknek rossz a hálózata, és egy master meghibásodik. Mindenki, aki kommunikál vele, beragad egy körbe: van egy kérés, nincs rá válasz, lefagy a cérna. Nem lehet tudni, hogy ez mikor fog megtörténni, csak egy-két óra múlva az egész szövetség bukik. Nem tehetsz ellene semmit.
A státuszt, a határozatképességet és a választásokat külön szál kezeli. Újraválasztás nem lesz, a státusz nem mutat semmit. Azt hiszi, hogy van egy élő konzulja, megkérdezi, és nem történik semmi – nincs válasz. Ugyanakkor az állapot azt mutatja, hogy minden rendben van.
Találkoztunk ezzel a problémával, és az adatközpontok egyes részeit újjá kellett építeni, hogy elkerüljük.
A Consul Enterprise üzleti verziója nem rendelkezik a fenti hátrányokkal. Számos hasznos funkciója van: szavazók kiválasztása, elosztás, méretezés. Csak egy „de” van - az elosztott rendszer engedélyezési rendszere nagyon drága.
Az élet hackelés: rm -rf /var/lib/consul - gyógymód az ágens összes betegségére. Ha valami nem működik az Ön számára, egyszerűen törölje az adatait, és töltse le az adatokat egy másolatból. Valószínűleg a Consul dolgozni fog.
BEFW
Most beszéljünk arról, hogy mit adtunk hozzá a Consulhoz.
egy mozaikszó BackEndFharagWminden. Valahogy el kellett neveznem a terméket a tároló létrehozásakor, hogy az első teszt commitokat beletehessem. Ez a név megmarad.
Szabálysablonok
A szabályok iptables szintaxisban vannak megírva.
- -N BEFW
- -P BEMENET CSÖKKENÉSE
- -A BEMENET -m állapot - Kapcsolódó, LÉTESÍTETT állapot -j ELFOGADÁS
- -A BEMENET -i lo -j ELFOGADÁS
- -A BEMENET -j BEFW
Minden a BEFW láncba kerül, kivéve ESTABLISHED, RELATED és localhost. A sablon bármi lehet, ez csak egy példa.
Hogyan hasznos a BEFW?
Szolgáltatások
Van egy szolgáltatásunk, mindig van portja, csomópontja, amin fut. A csomópontunkból helyben megkérdezhetjük az ügynököt, és megtudhatjuk, hogy van valamilyen szolgáltatásunk. Címkéket is rakhatsz.
Minden futó és a Consulnál regisztrált szolgáltatás iptables szabállyá válik. SSH-nk van - nyitott 22-es port. A Bash szkript egyszerű: curl és iptables, semmi másra nincs szükség.
Ügyfelek
Hogyan lehet megnyitni a hozzáférést nem mindenkinek, hanem szelektíven? Adjon hozzá IP-listákat a KV tárolóhoz szolgáltatásnév alapján.
Például azt szeretnénk, hogy a tizedik hálózaton mindenki hozzáférhessen az SSH_TCP_22 szolgáltatáshoz. Hozzáad egy kis TTL mezőt? és most ideiglenes engedélyeink vannak például egy napra.
Hozzáférések
Összekapcsoljuk a szolgáltatásokat és az ügyfeleket: van szolgáltatásunk, mindegyikhez készen áll a KV tárhely. Most nem mindenkinek adunk hozzáférést, hanem szelektíven.
Csoport
Ha minden alkalommal több ezer IP-t írunk a hozzáféréshez, elfáradunk. Jöjjön a csoportosítás – külön részhalmaz a KV-ban. Nevezzük Aliasnak (vagy csoportoknak), és tároljunk ott csoportokat ugyanazon elv szerint.
Csatlakozzunk: most már nem kifejezetten P2P-re nyithatjuk meg az SSH-t, hanem egy egész csoportra vagy több csoportra. Ugyanígy létezik a TTL is – hozzáadhat egy csoportot, és ideiglenesen eltávolíthatja a csoportból.
integráció
A mi problémánk az emberi tényező és az automatizálás. Eddig így oldottuk meg.
A Puppettel dolgozunk, és mindent, ami a rendszerrel kapcsolatos (alkalmazáskódot) átadunk nekik. A Puppetdb (normál PostgreSQL) az ott futó szolgáltatások listáját tárolja, erőforrástípusonként megtalálhatóak. Ott megtudhatod, ki hova jelentkezik. Ehhez egy lehívási kérelmet és egyesítést kérő rendszerünk is van.
Megírtuk a befw-sync-et, egy egyszerű megoldást, amely segít az adatátvitelben. Először is, a szinkronizálási cookie-kat a puppetdb éri el. Ott van beállítva egy HTTP API: lekérdezzük, hogy milyen szolgáltatásaink vannak, mit kell tenni. Aztán kérést intéznek a konzulhoz.
Van integráció? Igen: megírták a szabályokat, és engedélyezték a Pull Requests elfogadását. Szüksége van egy bizonyos portra, vagy hozzáadnia kell egy gazdagépet valamilyen csoporthoz? Húzza le a kérést, tekintse át – nincs több „Keressen 200 másik ACL-t, és próbáljon meg tenni ellene”.
Optimalizálás
A localhost pingelése üres szabálylánccal 0,075 ms.
Adjunk hozzá 10 000 iptables címet ehhez a lánchoz. Ennek eredményeként a ping 5-szörösére nő: az iptables teljesen lineáris, az egyes címek feldolgozása némi időt vesz igénybe.
Egy tűzfalnál, ahol több ezer ACL-t migrálunk, sok szabályunk van, és ez késleltetést vezet be. Ez rossz a játékprotokollokhoz.
De ha feltesszük 10 000 cím az ipsetben A ping még csökkenni is fog.
A lényeg az, hogy az ipset „O” (algoritmus bonyolultsága) mindig egyenlő 1-gyel, függetlenül attól, hogy hány szabály van. Igaz, van egy korlátozás - nem lehet több 65535-nél.. Egyelőre ezzel élünk: kombinálhatod, bővítheted, két ipset-et készíthetsz egyben.
tárolás
Az iterációs folyamat logikus folytatása a szolgáltatás klienseiről szóló információk tárolása az ipsetben.
Most ugyanaz az SSH van, és nem írunk 100 IP-t egyszerre, hanem beállítjuk az ipset nevét, amellyel kommunikálnunk kell, és a következő szabályt DROP. Át lehet alakítani egyetlen szabállyá: „Aki nincs itt, DROP”, de ez egyértelműbb.
Most már vannak szabályok és halmazok. A fő feladat egy halmaz készítése a szabály megírása előtt, mert különben az iptables nem írja meg a szabályt.
Általános rendszer
Diagram formájában minden, amit mondtam, így néz ki.
Elkötelezzük magunkat a Puppetre, mindent elküldenek a hostnak, szolgáltatások ide, ipset oda, és aki nincs oda regisztrálva, azt nem engedik be.
Engedélyezés és elutasítás
A világ gyors megmentése vagy valaki gyors letiltása érdekében az összes lánc elején két ipset-et készítettünk: rules_allow и rules_deny. Hogyan működik?
Például valaki botokkal hoz létre terhelést a weben. Korábban meg kellett találni az IP-címét a naplókból, el kellett vinni a hálózati mérnökökhöz, hogy megtalálják a forgalom forrását és kitiltsák. Most máshogy néz ki.
Elküldjük a Consulnak, várunk 2,5 másodpercet, és kész. Mivel a Consul gyorsan terjeszt P2P-n keresztül, mindenhol, a világ bármely részén működik.
Egyszer valahogy teljesen leállítottam a WOT-t a tűzfal hibája miatt. rules_allow - ez a mi biztosításunk az ilyen esetekre. Ha valahol hibáztunk a tűzfallal, valahol le van tiltva valami, mindig tudunk feltételes üzenetet küldeni 0.0/0hogy gyorsan felszedjen mindent. Később mindent kézzel fogunk javítani.
Egyéb készletek
Bármilyen más készletet hozzáadhat az űrben $IPSETS$.
Miért? Néha valakinek szüksége van az ipsetre, például a fürt valamely részének leállásának emulálásához. Bárki hozhat bármilyen készletet, nevezze el, és a Consultól átveszik. Ugyanakkor a készletek részt vehetnek az iptables szabályokban, vagy csapatként működhetnek NOOP: A konzisztenciát a démon fogja fenntartani.
Tagok
Korábban ez így volt: a felhasználó csatlakozott a hálózathoz, és a tartományon keresztül kapott paramétereket. Az új generációs tűzfalak megjelenése előtt a Cisco nem tudta, hogyan lehet megérteni, hol van a felhasználó és hol van az IP. Ezért a hozzáférést csak a gép gazdagépnevén keresztül biztosították.
Mit csináltunk? Abban a pillanatban, amikor megkaptuk a címet, elakadtunk. Általában ez a dot1x, Wi-Fi vagy VPN - minden a RADIUS-on keresztül megy. Minden felhasználó számára létrehozunk egy csoportot felhasználónév alapján, és elhelyezünk benne egy IP-t, amelynek TTL-je megegyezik a dhcp.lease-ével - amint lejár, a szabály eltűnik.
Mostantól – más csoportokhoz hasonlóan – felhasználói név alapján nyithatunk hozzáférést a szolgáltatásokhoz. Csökkentettük a hosztnevek változásának fájdalmát, és levettük a terhet a hálózati mérnökökről, mert már nincs szükségük a Ciscóra. Most a mérnökök maguk regisztrálják a hozzáférést szervereiken.
Szigetelés
Ezzel egy időben elkezdtük a szigetelés bontását. A szervizmenedzserek leltárt készítettek, és minden hálózatunkat elemeztük. Osszuk őket ugyanabba a csoportba, és a szükséges szervereken a csoportok hozzáadásra kerültek, pl. Most ugyanez a staging izoláció a produkció szabályok_tagadásában végződik, de magában a produkcióban nem.
A séma gyorsan és egyszerűen működik: eltávolítjuk az összes ACL-t a szerverekről, eltávolítjuk a hardvert, és csökkentjük az elszigetelt VLAN-ok számát.
Integritás ellenőrzése
Korábban volt egy speciális triggerünk, amely jelezte, ha valaki manuálisan módosított egy tűzfalszabályt. Hatalmas szöveget írtam a tűzfalszabályok ellenőrzéséhez, nehéz volt. Az integritást most a BEFW ellenőrzi. Buzgón gondoskodik arról, hogy az általa hozott szabályok ne változzanak. Ha valaki megváltoztatja a tűzfalszabályokat, az mindent vissza fog változtatni. „Gyorsan beállítottam egy proxyt, hogy otthonról dolgozhassak” – nincs több ilyen lehetőség.
A BEFW vezérli az ipset-et a szolgáltatásokból és a befw.conf-ban található listából, a BEFW-lánc szolgáltatási szabályaiból. De nem figyel más láncokat és szabályokat és egyéb ipseteket.
Ütközésvédelem
A BEFW mindig az utolsó ismert jó állapotot közvetlenül a state.bin bináris struktúrában tárolja. Ha valami elromlik, mindig visszagurul ebbe az állapotba.bin.
Ez egy biztosítás a Consul instabil működésére, amikor nem küldött adatot, vagy valaki hibázott és nem alkalmazható szabályokat használt. Annak érdekében, hogy ne maradjunk tűzfal nélkül, a BEFW visszaállítja a legfrissebb állapotot, ha valamelyik szakaszban hiba történik.
Kritikus helyzetekben ez garancia arra, hogy működő tűzfalunk marad. Megnyitjuk az összes szürke hálózatot abban a reményben, hogy jön az adminisztrátor és megjavítja. Egyszer majd beírom ezt a konfigurációkba, de most már csak három szürke hálózatunk van: 10/8, 172/12 és 192.168/16. Konzulunkon belül ez egy fontos jellemző, amely segít bennünket a további fejlődésben.
Demo: a riport alatt Ivan bemutatja a BEFW demó módját. Könnyebb nézni a bemutatót . Demo forráskód elérhető .
Buktatók
Mesélek azokról a hibákról, amelyekkel találkoztunk.
ipset add set 0.0.0.0/0. Mi történik, ha hozzáadja a 0.0.0.0/0 értéket az ipsethez? Minden IP-cím hozzáadásra kerül? Elérhető lesz az internet?
Nem, kapunk egy hibát, ami két óra állásidőbe kerül. Ráadásul a hiba 2016 óta nem működik, a RedHat Bugzillában található #1297092 szám alatt, és véletlenül találtuk meg - egy fejlesztői jelentésből.
A BEFW-nél ez most szigorú szabály 0.0.0.0/0 két címre változik: 0.0.0.0/1 и 128.0.0.0/1.
ipset visszaállítási készlet < fájl. Mit csinál az ipset, ha azt mondod neki restore? Szerinted ugyanúgy működik, mint az iptables? Visszaállítja az adatokat?
Semmi ilyesmi – egyesíti, és a régi címek nem mennek sehova, nem blokkolja a hozzáférést.
Hibát találtunk az izoláció tesztelésekor. Most van egy meglehetősen összetett rendszer - ahelyett restore tartják create temp, akkor restore flush temp и restore temp. Csere végén: atomitásért, mert ha először csinálod flush és ebben a pillanatban érkezik valami csomag, azt eldobják, és valami elromlik. Szóval van benne egy kis fekete mágia.
consul kv get -adatközpont=egyéb. Mint mondtam, azt gondoljuk, hogy kérünk néhány adatot, de vagy adatokat kapunk, vagy hibát. Ezt helyben Consulon keresztül megtehetjük, de ebben az esetben mindkettő lefagy.
A helyi Consul kliens a HTTP API-n keresztüli wrapper. De csak lefagy és nem reagál a Ctrl+C, vagy a Ctrl+Z, vagy bármi másra, csak kill -9 a következő konzolon. Ezzel akkor találkoztunk, amikor egy nagy klasztert építettünk. De még nincs megoldásunk, készülünk a hiba javítására a Consulban.
A konzul vezetője nem válaszol. Mesterünk az adatközpontban nem válaszol, azt gondoljuk: "Talán most működni fog az újrakiválasztási algoritmus?"
Nem, nem fog működni, és a monitorozás sem mutat semmit: a konzul azt fogja mondani, hogy van elkötelezettségi index, vezetőt találtak, minden rendben.
Hogyan kezeljük ezt? service consul restart cron minden órában. Ha 50 szervered van, nem nagy baj. Ha 16 000 lesz belőlük, akkor megérti, hogyan működik.
Következtetés
Ennek eredményeként a következő előnyökhöz jutottunk:
- Az összes Linux-gép 100%-os lefedettsége.
- Speed.
- Automatizálás.
- Megszabadítottuk a hardver- és hálózati mérnököket a rabszolgaságtól.
- Olyan integrációs lehetőségek jelentek meg, amelyek szinte korlátlanok: még Kubernetesnél, még Ansible-nél, sőt Pythonnál is.
Hátrányok: Konzul, amellyel most együtt kell élnünk, és a hiba nagyon magas költsége. Például egyszer este 6 órakor (Oroszországban a főműsoridőben) szerkesztettem valamit a hálózatok listáján. A BEFW-nél akkor még csak szigetelést építettünk. Valahol hibáztam, úgy tűnik rossz maszkot jeleztem, de két másodperc alatt minden leesett. Kigyullad a figyelő, fut az ügyeletes kisegítő: „Mindenünk megvan!” Az osztályvezető elszürkült, amikor elmagyarázta az üzletnek, hogy ez miért történt.
A hiba költsége olyan magas, hogy saját komplex megelőzési eljárást dolgoztunk ki. Ha ezt egy nagy gyártótelepen valósítja meg, akkor nem kell mindenkinek a Consul feletti mester tokent adnia. Ennek rossz vége lesz.
Költség. Egyedül 400 órán keresztül írtam kódot. A 4 fős csapatom havi 10 órát fordít mindenki támogatására. Minden új generációs tűzfal árához képest ingyenes.
Tervek. A hosszú távú terv az, hogy alternatív szállítási módot találjanak a Consul helyettesítésére vagy kiegészítésére. Talán Kafka vagy valami hasonló lesz. De a következő években a Consulon fogunk élni.
Azonnali tervek: integráció Fail2ban-nal, monitorozással, nftables-szal, esetleg más disztribúciókkal, metrikák, haladó monitorozás, optimalizálás. Valahol a tervek között szerepel a Kubernetes támogatás is, mert most már több klaszterünk és vágyunk van.
Továbbiak a tervekből:
- a forgalom anomáliáinak keresése;
- hálózati térképkezelés;
- Kubernetes támogatás;
- csomagok összeállítása minden rendszerhez;
- Web-UI.
Folyamatosan dolgozunk a konfiguráció bővítésén, a mutatók növelésén és az optimalizáláson.
Csatlakozz a projekthez. A projekt menőnek bizonyult, de sajnos még mindig egyszemélyes projekt. Gyere el és próbáljon meg valamit tenni: elkötelezni magát, tesztelni, javasolni valamit, értékelni.
Közben készülünk , amelyre április 6-án és 7-én kerül sor Szentpéterváron, és meghívjuk a nagy terhelésű rendszerek fejlesztőit . A tapasztalt előadók már tudják, mit kell tenniük, de azoknak, akik nem tudnak beszélni, legalább ajánljuk . A konferencián előadóként való részvétel számos előnnyel jár. Hogy melyeket, azt például a végén olvashatod .
Forrás: will.com