2010-ben a cégnek 50 szervere és egy egyszerű hálózati modellje volt: backend, frontend és tűzfal. A szerverek száma növekedett, a modell bonyolultabbá vált: stagingek, elkülönített VLAN-ok ACL-el, majd VPN VRF-fel, L2 ACL-lel rendelkező VLAN-ok, VRF ACL-lel az L3-on. Elkezdtél szédülni? Itt még izgalmasabb lesz.
Amikor a szerverek száma 16 000-re nőtt, lehetetlenné vált a különböző szegmensek kezelésének könnyed módon. Ezért egy másik megoldást találtak ki. A Netfilter stack-et vették, hozzáadták a Consul-t adatforrásként, így kaptak egy gyors, elosztott tűzfalat. Ezzel helyettesítették az ACL-eket az útválasztókon, és használták mint külső és belső tűzfalat. A dinamikus irányítás érdekében a BEFW rendszert fejlesztették ki, amelyet mindenhol alkalmaztak: a felhasználók hozzáférésének kezelésétől kezdve a hálózati szegmensek elszigeteléséig.
Hogyan működik mindez, és miért érdemes közelebbről megnézni ezt a rendszert, elmondja Ivan Agarov () — a Karbantartó Osztályinfrastruktúra Biztonsági Csoportjának vezetője a Minszki Fejlesztési Központban. Ivan nagy rajongója a SELinux-nak, szereti a Perl-t és kódot ír. Mint a kibervédelem csoportvezetője, rendszeresen dolgozik naplókkal, biztonsági másolatokkal és K+F ügyekkel, hogy megvédje a Wargaminget 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 mesélnék arról, hogyan csináltuk ezt, elmondom, hogy jutottunk el ide, és miért volt erre szükség. Ehhez utazzunk vissza 9 évet a múltba: 2010-be, amikor csak most jelentek meg a World of Tanks. A Wargamingnek körülbelül 50 szervere volt.
A cég szerverek növekedési ütemterve.
Volt egy hálózati modellünk. Az akkori időszakra optimális volt.
A hálózati modell 2010-ben.
A frontenden rosszfiúk laknak, akik össze akarnak törni minket, de van benne tűzfal. A backendben nincs tűzfal, de ott 50 szerver van, az összeset ismerjük. Minden jól működik.
4 év alatt a szerverpark 100-szorosára nőtt, 5000-re. Megjelentek az első elkülönített hálózatok — stagingek: ezek nem léphetnek be a produkcióba, és gyakran olyan dolgok forogtak itt, amelyek veszélyesek lehettek.
A hálózati modell 2014-ben.
Inerciából ugyanazokat a hardvereket használtuk, és minden munka elkülönített VLAN-okon zajlott: a VLAN-okra ACL-eket írtak, amelyek megengedik vagy megakadályozzák a kapcsolódást.
2016-ra 8000 szerverre nőtt a számuk. A Wargaming más stúdiókat vásárolt fel, további partneri hálózatok megjelentek. Úgy tűnik, hogy a miénk, de nem teljesen: a partnereknek a VLAN gyakran nem működik, VPN-t kell használnunk VRF-fel, a szigetelések bonyolultabbá váltak. Az ACL szigetelések keveréke nőtt.
Hálózati modell 2016-ban.
2018 elejére a géppark 16 000-re nőtt. 6 szegmens volt, a többit nem számoltuk, beleértve a zártabbakat, amelyek pénzügyi adatokat tároltak. Megjelentek a konténerhálózatok (Kubernetes), a DevOps, a felhőhálózatok, amelyek VPN-en keresztül csatlakoztak, például az IWS-ből. Nagyon sok szabály volt — fájt.
Hálózati modell és szigetelési módok 2018-ban.
A szigeteléshez a következőket használtuk: VLAN ACL-lel L2-n, VRF ACL-lel L3-on, VPN, és sok más dolgot. Túl sokat.
Problems
Mindenki ACL-lel és VLAN-nal él. Mi is a baj? E kérdésre Garold válaszol, aki elrejti a fájdalmát.
Sok probléma volt, de tömeges — öt.
- Geometrikus árnövekedés az új szabályokhoz. Minden új szabály hozzáadása tovább tartott, mint az előző, mert először meg kellett nézni, hogy nincs-e már olyan szabály.
- Nincs tűzfal a szegmensek belsejében. A szegmensek némileg elválasztották egymást, de belül már nem volt elegendő erőforrás.
- A szabályokat hosszú ideig alkalmazták. Egy helyi szabályt a műveletet végzők egy óra alatt meg tudtak írni. A globális szabályhoz több napra volt szükség.
- Nehezen auditálható szabályok. Pontosabban, nem volt lehetséges. Az első szabályokat 2010-ben írták, és szerzőik többsége már nem dolgozott a cégnél.
- Alacsony szintű ellenőrzés az infrastruktúra felett. Ez a fő probléma — rosszul tudtuk, mi történik velünk.
Így nézett ki a hálózati mérnök 2018-ban, amikor hallotta: „Még kicsit több ACL-ra van szükség.”
Megoldások
2018 elején úgy döntöttek, hogy valamit kezdenek vele.
Az integrációk ára folyamatosan növekszik. A kiindulópont az volt, hogy a nagy adatközpontok abbahagyták az izolált VLAN-ok és ACL-ek támogatását, mert elfogyott a memória az eszközökön.
Megoldás: eltávolították az emberi tényezőt és maximálisan automatizálták a hozzáférés biztosítását.
Az új szabályok hosszú ideig érvényesülnek. Megoldás: a szabályok alkalmazásának felgyorsítása, a folyamat decentralizálása és párhuzamosítása. Ehhez elosztott rendszer szükséges, hogy a szabályokat maguk hozzák el, anélkül, hogy rsync-re vagy SFTP-re lenne szükség ezer rendszerhez.
Nincs tűzfal a szegmensek belsejében. A tűzfal a szegmensekben kezdett el hozzánk érkezni, amikor egy hálózaton belül különböző szolgáltatások jelentek meg. Megoldás: host-alapú tűzfalak alkalmazása. Gyakorlatilag mindenhol Linuxot használunk, és mindenhol ott van az iptables, ez nem probléma.
Nehezen auditálható szabályok. Megoldás: tároljuk az összes szabályt egy helyen a felülvizsgálathoz és kezeléshez, így mindent auditálni tudunk.
Alacsony szintű kontroll az infrastruktúra felett. Megoldás: végezzük el az összes szolgáltatás és hozzáférés leltározását.
Ez inkább adminisztratív folyamat, mint technikai. Néha heti 200-300 új kiadásunk van, különösen akciók és ünnepek alatt. Ez csak egy DevOps csapatunkra vonatkozik. Ennyi kiadás mellett lehetetlen látni, hogy milyen portokra, IP-címekre, integrációkra van szükség. Ezért szükségünk volt kifejezetten kiképzett szolgáltatásmenedzserekre, akik megkérdezték a csapatokat: "Mi van egyáltalán és miért állítottátok be ezt?"
Mindezek után a hálózati mérnök 2019-ben már így nézett ki.
Consul
Úgy döntöttünk, hogy mindent, amit a szolgáltatásmenedzserekkel találtunk, a Consulba helyezzük, és onnan írjuk az iptables szabályokat.
Hogyan döntöttünk erről?
- Összegyűjtjük az összes szolgáltatást, hálózatot és felhasználót.
- Ezek alapján készítünk iptables szabályokat.
- Automatizáljuk a kontrollt.
- ….
- HASZON.
A Consul nem egy távoli API, képes minden csomóponton működni és írni az iptables-be. Csak ki kell találni egy automatikus ellenőrző eszközt, amely eltávolítja a felesleges dolgokat, és a legtöbb probléma megoldódik! A többit a folyamat során finomítjuk.
Miért a Consul?
Jól bevált. 2014-15 között backend-ként használtuk a Vault számára, ahol a jelszavakat tároljuk.
Nem veszít adatokat.. A Consul használata alatt egyetlen balesetnél sem veszített adatokat. Ez hatalmas előny a tűzfalkezelő rendszer számára.
A P2P kapcsolat felgyorsítja a változtatások elterjedését.. A P2P-vel az összes változtatás gyorsan megérkezik, nem kell órákig várni.
Kényelmes REST API. Az Apache ZooKeeper-t is fontolóra vettük, de annak nincs REST API-ja, így kényszerű megoldásokat kell alkalmazni.
Kulcs-érték tárolóként (KV) és mint szolgáltatásnyilvántartó (Service Discovery) is működik.. Azonnal tárolhatunk szolgáltatásokat, katalógusokat és adatközpontokat. Ez nemcsak nekünk, hanem a szomszédos csapatoknak is kényelmes, mivel globális szolgáltatás tervezésekor nagyban gondolkodunk.
Go nyelven íródott, amely a Wargaming technológiai stackjébe tartozik. Szeretjük ezt a nyelvet, sok Go-fejlesztőnk van.
Erőteljes ACL rendszer. A Consul lehetővé teszi az ACL segítségével a hozzáférés kezelését arra, hogy ki mit írhat. Garantáljuk, hogy a tűzfal szabályai soha nem ütköznek más szabályokkal, így ezzel nem lesznek problémáink.
De a Consulnak vannak hátrányai is.
- Nem skálázható a data center keretein belül, ha nincs üzleti verziója. Csak federációval skálázható.
- Nagyon függ a hálózat minőségétől és a szerverek terhelésétől. A Consul nem fog megfelelően működni szerverként egy leterhelt szerveren, ha a hálózatban akadozások vannak, például egyenetlen sebesség esetén. Ez a P2P kapcsolatokkal és a frissítések terjesztési modelljeivel kapcsolatos.
- Nehezen monitorozható az elérhetőség. A Consul státusza szerint minden rendben lehet, de már régóta nem működik.
Ezeknek a problémáknak a nagy részét sikerült megoldanunk a Consul üzemeltetése során, ezért választottuk ezt. A cégnél vannak elképzelések alternatív háttérszolgáltatásra, de megtanultunk küzdeni a problémákkal, és egyelőre a Consulnal éljük az életünket.
Hogyan működik a Consul
Egy feltételezett data centerben telepítünk szervereket — háromtól ötig. Egy vagy két szerver nem elegendő: nem tudják megszervezni a kvorumot, és eldönteni, ki a hibás, amikor az adatok nem egyeznek. Öt fölött már nincs értelme, a teljesítmény csökkenni fog.
A kliensek bármilyen sorrendben csatlakoznak a szerverekhez: ugyanazok az ügynökök, csak a server = false.
flaggal. Ezt követően a kliensek megkapják a P2P kapcsolatok listáját, és kapcsolatokat építenek közöttük.
Globális szinten összekötünk több data centert. Ezek is P2P-n kapcsolódnak és kommunikálnak egymással.
Amikor adatokat akarunk átvenni egy másik data centertől, a kérés a szerverről a szerverre megy. Ezt a rendszert Serf protokollnaknevezzük. A Serf protokoll, akárcsak a Consul, a HashiCorp fejlesztése.
Néhány fontos tény a Consulról
A Consulnak van dokumentációja a működésének leírásával. Csak néhány kiválasztott tényt említek meg, amit érdemes tudni.
A Consul szerverek választanak mestert a szavazók közül. A Consul minden data center számára választja ki a mestert a szerverek listájából, és minden kérés csak hozzá irányul, függetlenül a szerverek számától. A mester megakadás nem eredményez újraszavazást. Ha mester nincs választva, a kérések senki által nem kerülnek kiszolgálásra.
Szerettél volna horizontális skálázást? Sajnos, nem.
A kérés egyik adatközpontból a másikba mesterhez megy, függetlenül attól, hogy melyik szerverre érkezett. A kiválasztott mester 100%-os terhelést kap, a kérések továbbításához szükséges terhelés kivételével. A dátumok aktuális másolata minden adatközpont szerveren megtalálható, de csak egy felel.
Az egyetlen mód a skálázásra, ha a kliensen bekapcsoljuk a stale módot.
Stale módban lehet válaszolni quorum nélkül. Ez a mód, ahol lemondunk az adatok konzisztenciájáról, de valamivel gyorsabban olvasunk, mint általában, és bármelyik szerver válaszol. Természetesen írás csak a mesteren keresztül lehetséges.
A Consul nem másolja az adatokat az adatközpontok között. A federáció létrehozása során minden szerver csak saját adatait tartja. A többi adatért mindig valaki máshoz fordul.
A tranzakción kívüli műveletek atomaritása nem garantált. Ne felejtsd el, hogy nem csak te változtathatsz meg valamit. Ha máshogy szeretnéd, végezz tranzakciót zárolással.
A zároló műveletek nem garantálják a zárolást. A kérés a mestertől a mesterhez megy, nem közvetlenül, ezért nincs garancia, hogy a zárolás működni fog, ha például egy másik adatközpontban zárolást végzel.
Az ACL sem garantálja a hozzáférést (sok esetben). Az ACL nem működhet, mert az egyik adatközpontban tárolják — az ACL adatközpontban (Elsődleges DC). Ha az adatközpont nem válaszol, az ACL nem fog működni.
Egy beragadt mester az egész federációt megakadályozza. Például, egy federációban 10 adatközpont van, és az egyikben gyenge a hálózat, és az egyik mester leáll. Mindenki, aki vele kommunikál, körbarátban beragad: kérés érkezik, nincs válasz, a szál megakad. Megtudni, mikor fog ez megtörténni, nem lehetséges; egyszerűen egy órán belül vagy két órán belül az egész federáció le fog állni. Ezen nem tudsz segíteni.
A státusz, quorum és választások külön szálon dolgoznak. Újra választás nem fog megtörténni, a státusz semmit nem mutat. Azt hiszed, hogy az Consul él, kérdést intézel, és semmi sem történik — nincs válasz. Közben a státusz azt mutatja, hogy minden rendben van.
Ezzel a problémával találkoztunk, kénytelenek voltunk konkrét adatközponti részeket újraépíteni, hogy elkerüljük.
A Consul Enterprise üzleti verziójában nincsenek meg néhány fenti hátrány.Sok hasznos funkciót kínál: szavazók kiválasztása, elosztás, skálázás. Csak egy "de" van - a licencelési rendszer a elosztott rendszerhez nagyon drága.
Tippek: rm -rf /var/lib/consul — gyógyszer minden ügynök betegségére. Ha valami nem működik, csak törölje az adatait, és töltse be az adatokat egy másolatból. Valószínűleg a Consul működni fog.
BEFW
Most beszéljünk arról, hogy mit adtunk a Consulhoz.
— ez a rövidítése BackEndFireWall. Valahogyan el kellett neveznem a terméket, amikor létrehoztam a tárolót, hogy eltároljam az első tesztelési elkötelezettségeket. Ez a név maradt.
Szabályminták
A szabályok az iptables szintaxisában íródtak.
- -N BEFW
- -P INPUT DROP
- -A INPUT -m state—state RELATED,ESTABLISHED -j ACCEPT
- -A INPUT -i lo -j ACCEPT
- -A INPUT -j BEFW
Minden a BEFW láncba kerül, kivéve ESTABLISHED, RELATED és localhost. A minta bármi lehet, ez csak egy példa.
Miért hasznos a BEFW?
Szolgáltatások
Van egy szolgáltatásunk, mindig van egy port, a csomópont, amelyen fut. A saját csomópontunkról helyben kérhetjük az ügynököt, és megtudhatjuk, hogy van valamilyen szolgáltatásunk. Címkéket is lehet alkalmazni.
Bármely szolgáltatás, amely elindult és regisztrált a Consentban, iptables szabállyá alakul. Van SSH — megnyitjuk a 22-es portot. A bash szkript egyszerű: curl és iptables, másra nincs szükség.
Ügyfelek
Hogyan lehet korlátozottan hozzáférést biztosítani? A szolgáltatás neve alapján IP-listát menteni a KV-tárolóba.
Például szeretnénk, ha mindazok a tizedik hálózatból hozzáférhetnének az SSH_TCP_22 szolgáltatáshoz. Hozzáadunk egy kis TTL mezőt, és most időszakos engedélyeink vannak, például egy napra.
Hozzáférések
Kötjük össze a szolgáltatásokat és az ügyfeleket: van egy szolgáltatásunk, mindegyikhez készen áll a KV-tároló. Most nem mindenkinek adunk hozzáférést, hanem válogatottnak.
Csoportok
Ha minden alkalommal ezer IP-t kellene megadnunk a hozzáférésekhez, elfáradnánk. Csoportosíthatunk - külön subset a KV-ban. Elnevezzük Aliasznak (vagy csoportoknak) és ott tároljuk a csoportokat ugyanazon elv alapján.
Összekötés: most SSH-t nyithatunk meg nem konkrétan a P2P-n, hanem egy egész csoportra vagy több csoportra. Pontosan ugyanúgy van TTL - csoportba is lehet adni és csoportból is lehet törölni átmenetileg.
Integráció
A problémánk - az emberi tényező és az automatizálás. Eddig így oldottuk meg.
A Puppet-tel dolgozunk, és minden, ami a rendszerhez (alkalmazások kódja) tartozik, átként átadunk neki. A puppetdb-ben (szokásos PostgreSQL) tároljuk a futó szolgáltatások listáját, amelyeket erőforrástípus szerint kereshetünk. Ott megtalálhatjuk azt is, hogy ki hova fordul. Van egy pull request és merge request rendszerünk is ennek kezelésére.
Megírtuk a befw-sync-et – egy egyszerű megoldást, amely segít az adatok átvitelében. Először a sync cookies hívja a puppetdb-t. Ott HTTP API van beállítva: arra kérdezünk rá, hogy milyen szolgáltatásaink vannak, mit kell tennünk. Ezután a Consul-ba küldjük a kérést.
Van integráció? Van: írtunk szabályokat, és engedélyeztük a Pull Requestek fogadását. Szükség van valamilyen portra vagy pedig egy hostot hozzá kell adni valamilyen csoportra? Pull Request, review – többé nincs "Keress 200 másik ACL-t és próbálj valamit kezdeni vele".
Optimalizálás
A localhost pingelése üres szabálylánccal 0,075 ms-ot vesz igénybe.
Hozzáadunk ehhez a lánchoz 10 000 címet az iptables-hez. Ennek eredményeként a ping 5-szörösére nő: az iptables teljesen lineáris, minden cím feldolgozása időt igényel.
A tűzfal számára, amelybe ezrek migrálnak ACL, sok szabályunk van, és ez késleltetést okoz. Ez rossz a játék protokollok számára.
De ha a 10 000 címet ipset-be helyezünk, akkor a ping akár csökkenhet is.
A lényeg, hogy az ipset esetében az "O" (algoritmus bonyolultsága) mindig 1, függetlenül attól, hány szabály van. Igaz, van egy korlátozás – nem lehet több mint 65535 szabály. Eddig ezt elviseljük: kombinálni lehet őket, bővíteni, akár két ipset létrehozni egyben.
Tárolás
A folyamat iterációinak logikus folytatása – az ügyfelek adatainak tárolása az ipset-ben.
Most ugyanaz az SSH áll rendelkezésünkre, és nem írunk be azonnal 100 IP-t, hanem megadunk egy ipset nevet, amellyel kommunikálnunk kell, és a következő szabályt DROP. Lehet, hogy átkonvertáljuk az összes "Aki nem itt van, az DROP", de így szemléletesebb.
Most már vannak szabályaink és szettjeink. A legfontosabb feladat – előbb készíteni egy szettet, mint írni egy szabályt, mert különben az iptables nem jegyzi fel a szabályt.
Átfogó séma
Sémába rendezve, amit elmondtam, így néz ki.
Commitelünk a Puppet-be, minden elmegy a hosztra, a szolgáltatások itt vannak, az ipset ott, és aki ott nincs bejegyezve, azt nem engedik be.
Engedélyezés & megtagadás
Ahhoz, hogy gyorsan megmentsük a világot vagy gyorsan bárkit ki tudjunk zárni, minden lánc elején létrehoztunk két ipset: rules_allow és rules_deny. Hogyan működik ez?
Például valaki botokkal terheli a weboldalunkat. Korábban meg kellett találni az IP-címét a naplók alapján, és elvinni a hálózati mérnököknek, hogy megtalálják a forrást, és letiltsák. Most ez másképp néz ki.
Elküldjük a Consul-ba, várunk 2,5 másodpercet, és kész is van. Mivel a Consul P2P alapon gyorsan elosztja a terhelést, ezért a világ bármely részén működik.
Egyszer én teljesen leállítottam a WOT-ot, mert hibáztam a tűzfal beállításaival. rules_allow Ez a biztosítékunk az ilyen esetek ellen. Ha valahol tévedtünk a tűzfal beállításaival, és valami letiltásra kerül, mindig tudunk küldeni egy feltételes parancsot, 0.0/0hogy gyorsan újraindítsuk mindent. Utána pedig mindent kézzel javítunk.
Más iparok
Bármilyen más ipar hozzáadható a térben $IPSETS$.
Miért? Néha valakinek szüksége van ipsetekre, például azért, hogy emulálja egy klaszter egyes részeinek letiltását. Mindenki hozhat bármilyen ipart, elnevezheti azokat, és ezek a Consulból fognak érkezni. Ezek az iparok részt vehetnek az iptables szabályaiban, vagy egyszerűen csak mint egy parancs, NOOP: a konzisztenciát a démon fogja fenntartani.
Felhasználók
Korábban ez úgy működött: a felhasználó csatlakozott a hálózathoz, és a domainen keresztül kapott beállításokat. A következő generációs tűzfalak megjelenése előtt a Cisco nem tudta megérteni, hol van a felhasználó, és hol az IP-cím. Ezért a hozzáférés csak a gép hostname-jén keresztül lett kiadva.
Mit tettünk? Beavatkoztunk a cím megszerzésekor. Ez általában dot1x, Wi-Fi vagy VPN — minden a RADIUS-on keresztül megy. Minden felhasználóhoz létrehozunk egy csoportot a felhasználónevével, és ebbe tesszük az IP-t, amelynek TTL-je megegyezik a dhcp.lease értékével — amint lejár, a szabály eltűnik.
Most már hozzáférést tudunk nyújtani a szolgáltatásokhoz, mint más csoportokban, felhasználónév alapján. Megszabadultunk a hostname problémáktól, amikor változnak, és levettük a terhet a hálózati mérnökökről, mert már nincs szükségük Cisco-ra. Most már a mérnökök saját maguk határozzák meg a hozzáféréseket a szervereiken.
Elszigetelés
Parhuzamosan elkezdtük elemezni az elszigetelést. A szolgáltatásmenedzserek felmérést végeztek, mi pedig elemeztük az összes hálózatunkat. Azokat azonos csoportokra fogjuk bontani, és a szükséges szervereken csoportokat hozzáadtunk, például a tiltó listához. Most a stagging elszigetelési szabályai bekerülnek a production tiltási listába, de nem a production-ba magába.
A séma gyorsan és egyszerűen működik: eltávolítjuk az összes ACL-t a szerverekről, tehermentesítjük a hardvert, csökkentjük az elszigetelt VLAN-ok számát.
Integritásellenőrzés
Korábban volt egy speciális triggerünk, amely értesítette, amikor valaki manuálisan megváltoztatta a tűzfalszabályt. Nagy lintert írtam a tűzfalszabályok ellenőrzésére, ami összetett volt. Most a befw ellenőrzi az integritást. Gondosan figyeli, hogy a saját maga által létrehozott szabályok ne változzanak. Ha valaki megváltoztatja a tűzfalszabályokat, visszaállít mindent az eredeti állapotba. „Gyorsan beállítottam egy proxy-t, hogy otthonról dolgozhassak” — ilyen lehetőségek már nincsenek.
A befw ellenőrzi az ipsetet a szolgáltatások és a befw.conf listája alapján, a szolgáltatások szabályait a BEFW láncban. De nem figyeli a többi láncot és szabályt, illetve más ipseteket.
Balesetek elleni védelem
A befw mindig megőrzi az utolsó sikeres állapotot közvetlenül a bináris structure state.bin fájlban. Ha valami nem működik, mindig visszaáll erre a state.bin-re.
Ez egy biztosítás a Consul instabil működése ellen, amikor nem küldte el az adatokat, vagy valaki hibázott és olyan szabályokat használt, amelyek nem alkalmazhatók. Hogy ne maradjunk tűzfal nélkül, a befw visszaáll az utolsó állapotra, ha bármilyen hiba történik egy adott pillanatban.
Kritikus helyzetekben ez a garancia, hogy működő tűzfollal maradunk. Minden szürke hálózatot megnyitunk abban a reményben, hogy az adminisztrátor jön és kijavítja. Valamikor ezt beillesztem a konfigurációkba, de most csak három szürke hálózatunk van: 10/8, 172/12 és 192.168/16. A Consulunkon belül ez egy fontos jellemző, amely segíti a fejlődést.
Demos: az előadás során Ivan bemutatja a befw demo módját. A bemutató kényelmesebben nézhető itt . A demo forráskódja elérhető .
Csapdák
Beszélek a bugokról, amelyekkel szembesültünk.
ipset add set 0.0.0.0/0. Mi fog történni, ha hozzáadod az ipsethez a 0.0.0.0/0-t? Minden IP hozzáadásra kerül? Megnyílik az internet-hozzáférés?
Nem, egy bugot kapunk, ami két órás leállást okozott nekünk. A bug ráadásul 2016 óta nem működik, a RedHat Bugzilában #1297092 alatt van, és véletlenül találtuk rá - a fejlesztői jelentésből.
Most a BEFW-ben szigorú szabály van, hogy 0.0.0.0/0 kettő címmé alakul: 0.0.0.0/1 és 128.0.0.0/1.
ipset restore set < file. Mit csinál az ipset, amikor azt mondod neki, hogy restore? Вы думаете, он работает также, как iptables? Восстановит данные?
Semmi ilyesmi - egyesíti, a régi címek nem tűnnek el, a hozzáférést nem zárjátok le.
A bugot akkor találtuk meg, amikor a izolációt teszteltük. Most ott elég bonyolult rendszer működik - ahelyett, hogy restore temp létrehozása történik create temp, aztán restore flush temp és restore temp. A végén swap: a szelektivitás miatt, mert ha először csinálod flush És ebben a pillanatban, ha jön egy csomag, azt el fogják utasítani, és valami rosszul fog menni. Ezért van egy kis fekete mágia itt.
consul kv get -datacenter=other. Ahogy már mondtam, úgy gondoljuk, hogy valamilyen adatot kértünk, de vagy adatot, vagy hibát kapunk. Ezt megtehetjük helyben a Consul-on, de ebben az esetben is meg fog állni mindkettő.
A helyi Consul-kliense egy burkoló az HTTP API körül. De egyszerűen lefagy, és nem reagál sem a Ctrl+C-re, sem a Ctrl+Z-re, semmire, csak a kill -9 mellettük lévő konzolon. Ezzel szembesültünk, amikor egy nagy klasztert építettünk. De még nem találtunk megoldást, készen állunk javítani ezt a hibát a Consul-ban.
A Consul vezető nem válaszol. Nálunk nem válaszol a mester a datacenternél, azt gondoljuk: „Talán most működni fog a választási algoritmus?”
Nem, nem fog működni, és a monitoring semmit nem fog mutatni: a Consul azt mondja, hogy van elkötelezési index, vezető megtalálva, minden rendben.
Hogyan küzdünk ezzel? service consul restart a cronban óránként. Ha 50 szervered van — nem nagy probléma. Amikor 16 000 lesz, megérted, hogyan működik ez.
Zárás
Végül a következő előnyöket szereztük:
- 100% lefedettség minden Linux gépen.
- Sebesség.
- Automatizálás.
- Felszabadítottuk a hardvert és a hálózati mérnököket a rabságból.
- Megjelentek szinte korlátlan integrációs lehetőségek: akár Kubernetes-szel, akár Ansible-lel, akár Python-nal.
Hátrányok: A Consul, amivel most együtt kell élnünk, és a hiba ára nagyon magas. Például egyszer este 6-kor (csúcsidő Oroszországban) valamit módosítottam a hálózati listákban. Akkor éppen kezdtük a BEFW szigetelését. Valahol hibáztam, úgy tűnik, nem a megfelelő maszkot adtam meg, de minden két másodperc alatt leállt. A monitoring bekapcsol, a support ügyeletes rohan: „Minden leállt!” A részlegvezető megőszült, amikor elmagyarázta az üzletnek, hogy miért történt ez.
A hiba ára olyan magas, hogy saját összetett megelőző eljárást dolgoztunk ki. Ha ezt be akarod vezetni egy nagy termelésben, ne adj mester-jegyet a Consul fölé mindenkinek. Ez rosszul fog végződni.
Költségek. 400 órát írtam a kódot egyedül. A támogatásra a csapatom, ami 4 főből áll, havi 10 órát költ mindenre. Összehasonlítva bármelyik új generációs tűzfal árával, ez ingyen van.
Tervek. A hosszú távú terv egy alternatív szállítás keresése a Consul helyett vagy mellett. Lehet, hogy ez Kafka lesz, vagy valami hasonló. De a következő években a Consul-on fogunk élni.
A közeljövő tervei: integráció a Fail2bannal, megfigyeléssel, nftables-szel, lehet, hogy más disztribúciókkal, metrikák, kiterjesztett megfigyelés, optimalizálás. A Kubernetes támogatása is valahol a tervek között van, mert jelenleg van néhány klaszterünk és igényünk rá.
További tervek:
- anómáliák keresése a forgalomban;
- hálózat térképének kezelése;
- Kubernetes támogatás;
- csomagok összeállítása minden rendszerhez;
- Web-UI.
Folyamatosan dolgozunk a konfiguráció bővítésén, a metrikák növelésén és az optimalizáláson.
Csatlakozz a projekthez. A projekt szuper lett, de sajnos ez egyelőre csak egy ember projektje. Gyere a és próbálj ki valamit: commitálj, tesztelj, javasolj valamit, add meg a véleményed.
Közben készülünk a , amely április 6-án és 7-én kerül megrendezésre 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, a kezdőknek pedig legalább ajánljuk, hogy A konferencián előadóként való részvétel számos előnnyel jár. Ezekről például a végén lehet olvasni: .
Forrás: habr.com
