Nel 2010 l'azienda c'erano 50 server e un modello di rete semplice: backend, frontend e firewall. Il numero di server è cresciuto, il modello è diventato più complesso: staging, VLAN isolate con ACL, poi VPN con VRF, VLAN con ACL su L2, VRF con ACL su L3. Ti gira la testa? Sarà più divertente dopo.
Quando i server erano 16, era impossibile lavorare senza strappi con così tanti segmenti eterogenei. Quindi abbiamo trovato un'altra soluzione. Abbiamo preso lo stack Netfilter, aggiunto Consul come origine dati e abbiamo ottenuto un firewall distribuito velocemente. Hanno sostituito gli ACL sui router e li hanno utilizzati come firewall esterno e interno. Per gestire dinamicamente lo strumento, abbiamo sviluppato il sistema BEFW, che è stato utilizzato ovunque: dalla gestione dell'accesso degli utenti alla rete di prodotti all'isolamento dei segmenti di rete gli uni dagli altri.
Ti dirà come funziona il tutto e perché dovresti dare un'occhiata più da vicino a questo sistema. Ivan Agarkov () è a capo del gruppo di sicurezza delle infrastrutture della divisione Manutenzione presso il centro di sviluppo dell'azienda a Minsk. Ivan è un fan di SELinux, ama Perl e scrive codice. In qualità di capo del gruppo di sicurezza delle informazioni, lavora regolarmente con registri, backup e ricerca e sviluppo per proteggere Wargaming dagli hacker e garantire il funzionamento di tutti i server di gioco dell'azienda.
storia
Prima di dirti come abbiamo fatto, ti dirò come siamo arrivati a questo e perché era necessario. Per fare questo, torniamo indietro di 9 anni: 2010, è appena apparso World of Tanks. Wargaming aveva circa 50 server.
Grafico di crescita dei server aziendali.
Avevamo un modello di rete. Per quel tempo era ottimale.
Modello di rete nel 2010.
Ci sono dei cattivi sul front-end che vogliono distruggerci, ma c'è un firewall. Non c'è firewall sul backend, ma ci sono 50 server lì, li conosciamo tutti. Tutto funziona bene.
In 4 anni, la flotta di server è cresciuta di 100 volte, fino a 5000. Sono apparse le prime reti isolate: staging: non potevano andare in produzione e spesso c'erano cose in esecuzione che potevano essere pericolose.
Modello di rete nel 2014.
Per inerzia, abbiamo utilizzato gli stessi componenti hardware e tutto il lavoro è stato svolto su VLAN isolate: gli ACL vengono scritti sulle VLAN, che consentono o negano qualche tipo di connessione.
Nel 2016, il numero di server ha raggiunto gli 8000. Wargaming ha assorbito altri studi e sono apparse ulteriori reti di affiliazione. Sembrano nostri, ma non del tutto: spesso la VLAN non funziona per i partner, devi usare la VPN con VRF, l'isolamento diventa più complicato. La miscela di isolamento ACL è cresciuta.
Modello di rete nel 2016.
All'inizio del 2018, il parco macchine era cresciuto fino a 16: c'erano 000 segmenti e non abbiamo contato il resto, compresi quelli chiusi in cui erano archiviati i dati finanziari. Sono apparse reti container (Kubernetes), DevOps, reti cloud collegate tramite VPN, ad esempio da un IVS. C'erano molte regole: era doloroso.
Modello di rete e metodi di isolamento nel 2018.
Per l'isolamento abbiamo utilizzato: VLAN con ACL su L2, VRF con ACL su L3, VPN e molto altro. Troppo.
Problematica
Tutti vivono con ACL e VLAN. Cosa c'è che non va? A questa domanda risponderà Harold, nascondendo il dolore.
C'erano molti problemi, ma ce n'erano cinque enormi.
- Aumento geometrico dei prezzi per nuove regole. Ogni nuova regola richiedeva più tempo per essere aggiunta rispetto alla precedente, perché era necessario prima vedere se esisteva già una regola del genere.
- Nessun firewall all'interno dei segmenti. I segmenti erano in qualche modo separati l'uno dall'altro e all'interno non c'erano già abbastanza risorse.
- Le regole sono state applicate per molto tempo. Gli operatori potrebbero scrivere a mano una regola locale in un'ora. Quello globale ha richiesto diversi giorni.
- Difficoltà con le regole di audit. Più precisamente, non è stato possibile. Le prime regole sono state scritte nel 2010 e la maggior parte dei loro autori non lavorava più per l’azienda.
- Basso livello di controllo delle infrastrutture. Questo è il problema principale: non sapevamo molto bene cosa stesse succedendo nel nostro Paese.
Ecco come appariva un ingegnere di rete nel 2018 quando sentì: “Ho bisogno di più ACL”.
Soluzioni
All’inizio del 2018 si è deciso di fare qualcosa al riguardo.
Il prezzo delle integrazioni è in costante crescita. Il punto di partenza era che i data center di grandi dimensioni hanno smesso di supportare VLAN e ACL isolate perché i dispositivi avevano esaurito la memoria.
Soluzione: abbiamo eliminato il fattore umano e automatizzato al massimo la fornitura dell'accesso.
Le nuove regole richiedono molto tempo per essere applicate. Soluzione: accelerare l'applicazione delle regole, renderla distribuita e parallela. Ciò richiede un sistema distribuito in modo che le regole vengano consegnate da sole, senza rsync o SFTP a migliaia di sistemi.
Nessun firewall all'interno dei segmenti. Un firewall all'interno dei segmenti ha iniziato a presentarsi quando sono comparsi servizi diversi all'interno della stessa rete. Soluzione: utilizzare un firewall a livello di host: firewall basati su host. Quasi ovunque abbiamo Linux, e ovunque abbiamo iptables, questo non è un problema.
Difficoltà con le regole di audit. Soluzione: conservare tutte le regole in un unico posto per la revisione e la gestione, in modo da poter controllare tutto.
Basso livello di controllo sulle infrastrutture. Soluzione: fare un inventario di tutti i servizi e degli accessi tra di loro.
Si tratta più di un processo amministrativo che tecnico. A volte abbiamo 200-300 nuove uscite a settimana, soprattutto durante promozioni e festività. Inoltre, questo vale solo per un team dei nostri DevOps. Con così tante versioni, è impossibile vedere quali porte, IP e integrazioni siano necessarie. Pertanto, avevamo bisogno di responsabili del servizio appositamente formati che chiedessero ai team: "Cosa c'è comunque e perché ne avete parlato?"
Dopo tutto ciò che abbiamo lanciato, un ingegnere di rete nel 2019 ha iniziato ad assomigliare a questo.
Console
Abbiamo deciso di inserire tutto ciò che avremmo trovato con l'aiuto dei gestori del servizio in Consul e da lì scriveremo le regole di iptables.
Come abbiamo deciso di farlo?
- Raccoglieremo tutti i servizi, le reti e gli utenti.
- Creiamo regole iptables basate su di esse.
- Automatizziamo il controllo.
- ....
- UTILE.
Consul non è un'API remota, può essere eseguita su ogni nodo e scrivere su iptables. Non resta che inventare controlli automatici che elimineranno le cose inutili e la maggior parte dei problemi sarà risolta! Il resto lo risolveremo man mano che procediamo.
Perchè Console?
Si è dimostrato valido. Nel 2014-15 lo abbiamo utilizzato come backend per Vault, in cui archiviamo le password.
Non perde dati. Durante il periodo di utilizzo, Consul non ha perso dati durante un singolo incidente. Questo è un enorme vantaggio per un sistema di gestione del firewall.
Le connessioni P2P accelerano la diffusione del cambiamento. Con P2P, tutti i cambiamenti avvengono rapidamente, senza bisogno di aspettare ore.
Comoda API REST. Abbiamo preso in considerazione anche Apache ZooKeeper, ma non ha un'API REST, quindi dovrai installare le stampelle.
Funziona sia come Key Vault (KV) che come directory (Service Discovery). Puoi archiviare servizi, cataloghi e data center contemporaneamente. Questo è conveniente non solo per noi, ma anche per i team vicini, perché quando costruiamo un servizio globale, pensiamo in grande.
Scritto in Go, che fa parte dello stack Wargaming. Adoriamo questo linguaggio, abbiamo molti sviluppatori Go.
Potente sistema ACL. In Console, puoi utilizzare gli ACL per controllare chi scrive cosa. Garantiamo che le regole del firewall non si sovrapporranno a nient'altro e non avremo problemi con questo.
Ma Console ha anche i suoi svantaggi.
- Non è scalabile all'interno di un data center a meno che non si disponga di una versione aziendale. È scalabile solo tramite federazione.
- Dipende molto dalla qualità della rete e dal carico del server. Consul non funzionerà correttamente come server su un server occupato se sono presenti ritardi nella rete, ad esempio velocità irregolare. Ciò è dovuto alle connessioni P2P e ai modelli di distribuzione degli aggiornamenti.
- Difficoltà nel monitorare la disponibilità. Nello stato di Console può dire che va tutto bene, ma è morto molto tempo fa.
Abbiamo risolto la maggior parte di questi problemi utilizzando Consul, motivo per cui l'abbiamo scelto. L'azienda ha in programma un backend alternativo, ma abbiamo imparato ad affrontare i problemi e attualmente conviviamo con Consul.
Come funziona Console
Installeremo da tre a cinque server in un data center condizionale. Uno o due server non funzioneranno: non saranno in grado di organizzare un quorum e decidere chi ha ragione e chi ha torto quando i dati non corrispondono. Più di cinque non ha senso, la produttività calerà.
I client si connettono ai server in qualsiasi ordine: gli stessi agenti, solo con il flag server = false.
Successivamente, i client ricevono un elenco di connessioni P2P e creano connessioni tra loro.
A livello globale, colleghiamo diversi data center. Connettono anche P2P e comunicano.
Quando vogliamo recuperare i dati da un altro data center, la richiesta passa da un server all'altro. Questo schema si chiama Protocollo servo. Il protocollo Serf, come Consul, è sviluppato da HashiCorp.
Alcuni fatti importanti su Console
Il Console ha la documentazione che descrive come funziona. Fornirò solo fatti selezionati che vale la pena conoscere.
I server del console selezionano un maestro tra gli elettori. Consul seleziona un master dall'elenco dei server per ciascun data center e tutte le richieste vanno solo ad esso, indipendentemente dal numero di server. Il congelamento totale non porta alla rielezione. Se il master non viene selezionato, le richieste non vengono servite da nessuno.
Volevi il ridimensionamento orizzontale? Mi dispiace, no.
Una richiesta a un altro data center passa da master a master, indipendentemente dal server a cui è arrivata. Il master selezionato riceve il 100% del carico, ad eccezione del carico sulle richieste inoltrate. Tutti i server del data center hanno una copia aggiornata dei dati, ma solo uno risponde.
L'unico modo per scalare è abilitare la modalità obsoleta sul client.
In modalità obsoleta è possibile rispondere senza quorum. Questa è una modalità in cui rinunciamo alla coerenza dei dati, ma leggiamo un po' più velocemente del solito e qualsiasi server risponde. Naturalmente, registrando solo tramite il master.
Consul non copia i dati tra data center. Quando viene assemblata una federazione, ciascun server avrà solo i propri dati. Per gli altri, si rivolge sempre a qualcun altro.
L'atomicità delle operazioni non è garantita al di fuori di una transazione. Ricorda che non sei l’unico che può cambiare le cose. Se lo desideri diversamente, esegui una transazione con un lucchetto.
Le operazioni di blocco non garantiscono il blocco. La richiesta passa da master a master e non direttamente, quindi non vi è alcuna garanzia che il blocco funzioni quando si blocca, ad esempio, in un altro data center.
Inoltre, ACL non garantisce l'accesso (in molti casi). L'ACL potrebbe non funzionare perché è archiviato in un data center federativo, nel data center ACL (DC primario). Se il DC non ti risponde, l'ACL non funzionerà.
Un master congelato causerà il congelamento dell'intera federazione. Ad esempio, in una federazione sono presenti 10 data center, uno ha una rete difettosa e un master si guasta. Tutti coloro che comunicano con lui rimarranno bloccati in un cerchio: c'è una richiesta, non c'è risposta, il filo si blocca. Non c’è modo di sapere quando ciò accadrà, solo tra un’ora o due l’intera federazione cadrà. Non c'è niente che tu possa fare al riguardo.
Lo status, il quorum e le elezioni sono gestiti da un thread separato. La rielezione non avverrà, lo status non mostrerà nulla. Pensi di avere un Console vivo, chiedi e non succede nulla: non c'è risposta. Allo stesso tempo, lo stato mostra che va tutto bene.
Abbiamo riscontrato questo problema e per evitarlo abbiamo dovuto ricostruire parti specifiche dei data center.
La versione business di Consul Enterprise non presenta alcuni degli svantaggi sopra menzionati. Ha molte funzioni utili: selezione degli elettori, distribuzione, ridimensionamento. C'è solo un "ma": il sistema di licenza per un sistema distribuito è molto costoso.
Life hacking: rm -rf /var/lib/consul - una cura per tutte le malattie dell'agente. Se qualcosa non funziona per te, elimina semplicemente i tuoi dati e scarica i dati da una copia. Molto probabilmente, il Console funzionerà.
PRIMA
Ora parliamo di cosa abbiamo aggiunto a Consul.
è l'acronimo di BackEndFiraWTutto. Ho dovuto dare un nome al prodotto in qualche modo quando ho creato il repository per inserirvi i primi commit di test. Questo nome rimane.
Modelli di regole
Le regole sono scritte nella sintassi iptables.
- -N PRIMA
- -P CADUTA INGRESSO
- -A INPUT -m stato—stato CORRELATO,STABILITO -j ACCETTA
- -A INGRESSO -i lo -j ACCETTO
- -A INPUT -j BEFW
Tutto rientra nella catena BEFW, tranne ESTABLISHED, RELATED e localhost. Il modello può essere qualsiasi cosa, questo è solo un esempio.
In che modo BEFW è utile?
Servizi
Abbiamo un servizio, ha sempre una porta, un nodo su cui gira. Dal nostro nodo possiamo chiedere localmente all'agente e scoprire che abbiamo qualche tipo di servizio. Puoi anche inserire dei tag.
Qualsiasi servizio in esecuzione e registrato con Consul si trasforma in una regola iptables. Abbiamo SSH: porta aperta 22. Lo script Bash è semplice: curl e iptables, non è necessario nient'altro.
Clienti
Come aprire l'accesso non a tutti, ma in modo selettivo? Aggiungi elenchi IP allo storage KV in base al nome del servizio.
Ad esempio, vogliamo che tutti gli utenti della decima rete possano accedere al servizio SSH_TCP_22. Aggiungere un piccolo campo TTL? e ora abbiamo permessi temporanei, ad esempio, per un giorno.
Accesso
Colleghiamo servizi e clienti: abbiamo un servizio, lo stoccaggio KV è pronto per ciascuno. Adesso diamo l'accesso non a tutti, ma in modo selettivo.
Gruppo
Se scriviamo ogni volta migliaia di IP per l’accesso, ci stancheremo. Troviamo i raggruppamenti: un sottoinsieme separato in KV. Chiamiamolo Alias (o gruppi) e memorizziamo lì i gruppi secondo lo stesso principio.
Connettiamoci: ora possiamo aprire SSH non specificamente per P2P, ma per un intero gruppo o più gruppi. Allo stesso modo, c'è TTL: puoi aggiungere a un gruppo e rimuovere temporaneamente dal gruppo.
integrazione
Il nostro problema è il fattore umano e l’automazione. Finora abbiamo risolto in questo modo.
Lavoriamo con Puppet e trasferiamo loro tutto ciò che riguarda il sistema (codice dell'applicazione). Puppetdb (PostgreSQL normale) memorizza un elenco di servizi in esecuzione lì, che possono essere trovati per tipo di risorsa. Lì puoi scoprire chi si candida e dove. Abbiamo anche un sistema di richiesta pull e richiesta di fusione per questo.
Abbiamo scritto befw-sync, una soluzione semplice che aiuta a trasferire i dati. Innanzitutto, i cookie di sincronizzazione sono accessibili da pupazzodb. Lì è configurata un'API HTTP: chiediamo quali servizi abbiamo, cosa deve essere fatto. Poi fanno una richiesta al Console.
C'è integrazione? Sì: hanno scritto le regole e permesso che le Pull Request venissero accettate. Hai bisogno di una determinata porta o aggiungi un host a qualche gruppo? Pull Request, revisione: niente più "Trova altri 200 ACL e prova a fare qualcosa al riguardo".
Ottimizzazione
Il ping di localhost con una catena di regole vuota richiede 0,075 ms.
Aggiungiamo 10 indirizzi iptables a questa catena. Di conseguenza, il ping aumenterà di 000 volte: iptables è completamente lineare, l'elaborazione di ogni indirizzo richiede del tempo.
Per un firewall in cui migriamo migliaia di ACL, abbiamo molte regole e questo introduce latenza. Questo è dannoso per i protocolli di gioco.
Ma se mettiamo 10 indirizzi in ipset Il ping diminuirà addirittura.
Il punto è che “O” (complessità dell’algoritmo) per ipset è sempre uguale a 1, non importa quante regole ci siano. È vero, c'è una limitazione: non possono esserci più di 65535 regole. Per ora conviviamo con questo: puoi combinarli, espanderli, creare due ipset in uno.
Conservazione
Una continuazione logica del processo di iterazione è la memorizzazione delle informazioni sui client per il servizio in ipset.
Ora abbiamo lo stesso SSH e non scriviamo 100 IP contemporaneamente, ma impostiamo il nome dell'ipset con cui dobbiamo comunicare e la seguente regola DROP. Può essere convertito in un'unica regola “Chi non c'è, DROP”, ma è più chiara.
Ora abbiamo regole e set. Il compito principale è creare un insieme prima di scrivere la regola, perché altrimenti iptables non scriverà la regola.
Schema generale
Sotto forma di diagramma, tutto ciò che ho detto appare così.
Ci impegniamo con Puppet, tutto viene inviato all'host, i servizi qui, ipset lì e chiunque non sia registrato lì non è ammesso.
Consentono di negare
Per salvare rapidamente il mondo o disabilitare rapidamente qualcuno, all'inizio di tutte le catene abbiamo creato due ipset: rules_allow и rules_deny. Come funziona?
Ad esempio, qualcuno sta creando un carico sul nostro Web con i bot. In precedenza, dovevi trovare il suo IP dai registri, portarlo agli ingegneri di rete, in modo che potessero trovare la fonte del traffico e bannarlo. Sembra diverso ora.
Lo inviamo al Console, aspettiamo 2,5 secondi ed è fatto. Poiché Consul distribuisce velocemente tramite P2P, funziona ovunque, in qualsiasi parte del mondo.
Una volta in qualche modo ho interrotto completamente WOT a causa di un errore con il firewall. rules_allow - questa è la nostra assicurazione contro questi casi. Se abbiamo commesso un errore da qualche parte con il firewall, qualcosa è bloccato da qualche parte, possiamo sempre inviare un condizionale 0.0/0per raccogliere tutto velocemente. Successivamente sistemeremo tutto a mano.
Altri set
Puoi aggiungere qualsiasi altro set nello spazio $IPSETS$.
Per quello? A volte qualcuno ha bisogno di ipset, ad esempio, per emulare l'arresto di alcune parti del cluster. Chiunque può portare qualsiasi set, nominarlo e verrà ritirato dal Console. Allo stesso tempo, i set possono partecipare alle regole di iptables o agire come una squadra NOOP: La coerenza verrà mantenuta dal demone.
Membri
In precedenza era così: l'utente si connetteva alla rete e riceveva i parametri tramite il dominio. Prima dell’avvento dei firewall di nuova generazione, Cisco non sapeva come capire dove si trovava l’utente e dove si trovava l’IP. Pertanto, l'accesso è stato concesso solo tramite il nome host della macchina.
Cosa abbiamo fatto? Siamo rimasti bloccati nel momento in cui abbiamo ricevuto l'indirizzo. Di solito si tratta di dot1x, Wi-Fi o VPN: tutto passa attraverso RADIUS. Per ogni utente creiamo un gruppo per nome utente e inseriamo al suo interno un IP con un TTL uguale al suo dhcp.lease: non appena scade, la regola scomparirà.
Ora possiamo aprire l'accesso ai servizi, come ad altri gruppi, tramite nome utente. Abbiamo eliminato il problema dei nomi host quando cambiano e abbiamo alleggerito il peso degli ingegneri di rete perché non hanno più bisogno di Cisco. Ora gli stessi ingegneri registrano l'accesso ai propri server.
Isolamento
Allo stesso tempo, abbiamo iniziato a smantellare l'isolamento. I responsabili del servizio hanno fatto un inventario e abbiamo analizzato tutte le nostre reti. Dividiamoli negli stessi gruppi e sui server necessari sono stati aggiunti i gruppi, ad esempio, per negare. Ora lo stesso isolamento scenico finisce nelle regole_negazione della produzione, ma non nella produzione stessa.
Lo schema funziona in modo rapido e semplice: rimuoviamo tutti gli ACL dai server, scarichiamo l'hardware e riduciamo il numero di VLAN isolate.
Controllo dell'integrità
In precedenza, disponevamo di un trigger speciale che segnalava quando qualcuno modificava manualmente una regola del firewall. Stavo scrivendo un enorme linter per controllare le regole del firewall, è stato difficile. L'integrità è ora controllata da BEFW. Si assicura con zelo che le regole da lui stabilite non cambino. Se qualcuno cambia le regole del firewall, tutto cambierà di nuovo. “Ho configurato rapidamente un proxy per poter lavorare da casa”: opzioni del genere non esistono più.
BEFW controlla l'ipset dai servizi ed elenca in befw.conf, le regole dei servizi nella catena BEFW. Ma non monitora altre catene, regole e altri ipset.
Protezione dagli urti
BEFW memorizza sempre l'ultimo stato valido conosciuto direttamente nella struttura binaria state.bin. Se qualcosa va storto, torna sempre a questo stato.bin.
Questa è un'assicurazione contro il funzionamento instabile di Console, quando non ha inviato dati o qualcuno ha commesso un errore e ha utilizzato regole che non possono essere applicate. Per garantire che non rimaniamo senza firewall, BEFW tornerà allo stato più recente se si verifica un errore in qualsiasi momento.
In situazioni critiche, questa è una garanzia che rimarremo con un firewall funzionante. Apriamo tutte le reti grigie nella speranza che l'amministratore venga e risolva il problema. Un giorno lo inserirò nelle configurazioni, ma ora abbiamo solo tre reti grigie: 10/8, 172/12 e 192.168/16. All'interno del nostro Console, questa è una caratteristica importante che ci aiuta a svilupparci ulteriormente.
Demo: durante il rapporto, Ivan mostra la modalità demo di BEFW. È più facile guardare la dimostrazione . Codice sorgente demo disponibile .
Insidie
Ti parlerò dei bug che abbiamo riscontrato.
ipset aggiunge il set 0.0.0.0/0. Cosa succede se aggiungi 0.0.0.0/0 a ipset? Verranno aggiunti tutti gli IP? Sarà disponibile l'accesso a Internet?
No, riceveremo un bug che ci costerà due ore di inattività. Inoltre, il bug non funziona dal 2016, si trova in RedHat Bugzilla con il numero #1297092 e lo abbiamo trovato per caso, dal rapporto di uno sviluppatore.
Ormai è una regola rigida in BEFW 0.0.0.0/0 si trasforma in due indirizzi: 0.0.0.0/1 и 128.0.0.0/1.
set di ripristino ipset <file. Cosa fa ipset quando glielo dici restore? Pensi che funzioni come iptables? Recupererà i dati?
Niente del genere: fa un'unione e i vecchi indirizzi non vanno da nessuna parte, non blocchi l'accesso.
Abbiamo riscontrato un bug durante il test dell'isolamento. Ora esiste un sistema piuttosto complesso - invece di restore condotto create temp, quindi restore flush temp и restore temp. Alla fine dello scambio: per atomicità, perché se lo fai prima flush e in questo momento arriva qualche pacchetto, verrà scartato e qualcosa andrà storto. Quindi c'è un po' di magia nera lì.
console kv get -datacenter=altro. Come ho detto, pensiamo di chiedere alcuni dati, ma otterremo dati o un errore. Possiamo farlo tramite il Console locale, ma in questo caso entrambi si bloccheranno.
Il client Consul locale è un wrapper sull'API HTTP. Ma si blocca e non risponde solo a Ctrl+C, o Ctrl+Z, o altro kill -9 nella console successiva. L'abbiamo riscontrato durante la creazione di un cluster di grandi dimensioni. Ma non abbiamo ancora una soluzione; ci stiamo preparando a correggere questo errore in Consul.
Il leader del Console non risponde. Il nostro padrone nel data center non risponde, pensiamo: "Forse l'algoritmo di riselezione funzionerà adesso?"
No, non funzionerà e il monitoraggio non mostrerà nulla: il Console dirà che c’è un indice di impegno, è stato trovato un leader, va tutto bene.
Come affrontiamo questo problema? service consul restart in cron ogni ora. Se hai 50 server, non è un grosso problema. Quando saranno 16 capirai come funziona.
conclusione
Di conseguenza, abbiamo ottenuto i seguenti vantaggi:
- Copertura del 100% di tutte le macchine Linux.
- Velocità.
- Automazione.
- Abbiamo liberato gli ingegneri hardware e di rete dalla schiavitù.
- Sono apparse possibilità di integrazione quasi illimitate: anche con Kubernetes, anche con Ansible, anche con Python.
Contro: Console, con il quale ora dobbiamo convivere, e l'altissimo costo dell'errore. Ad esempio, una volta alle 6 (ora di punta in Russia) stavo modificando qualcosa negli elenchi delle reti. All'epoca stavamo solo costruendo isolamenti alla BEFW. Ho sbagliato da qualche parte, sembra che abbia indicato la maschera sbagliata, ma in due secondi è caduto tutto. Il monitoraggio si accende, l'addetto all'assistenza di turno arriva di corsa: “Abbiamo tutto!” Il capo del dipartimento è diventato grigio quando ha spiegato all'azienda perché ciò è accaduto.
Il costo dell’errore è così alto che abbiamo messo a punto una nostra complessa procedura di prevenzione. Se lo implementi su un grande sito di produzione, non è necessario dare a tutti un token principale su Console. Questa cosa finirà male.
Costo. Ho scritto codice per 400 ore da solo. Il mio team di 4 persone dedica 10 ore al mese al supporto per tutti. Rispetto al prezzo di qualsiasi firewall di nuova generazione, è gratis.
Piani. Il piano a lungo termine è trovare mezzi di trasporto alternativi per sostituire o integrare Consul. Forse sarà Kafka o qualcosa di simile. Ma nei prossimi anni vivremo a Console.
Piani immediati: integrazione con Fail2ban, con monitoraggio, con nftables, eventualmente con altre distribuzioni, metriche, monitoraggio avanzato, ottimizzazione. Anche il supporto di Kubernetes è da qualche parte nei piani, perché ora abbiamo diversi cluster e lo desideriamo.
Altro dai piani:
- ricerca di anomalie nel traffico;
- gestione della mappa di rete;
- Supporto Kubernetes;
- assemblare pacchetti per tutti i sistemi;
- Interfaccia utente Web.
Lavoriamo costantemente per espandere la configurazione, aumentare le metriche e l'ottimizzazione.
Partecipa al progetto. Il progetto si è rivelato interessante, ma sfortunatamente è ancora un progetto individuale. Vieni a e provare a fare qualcosa: impegnarsi, testare, suggerire qualcosa, dare la propria valutazione.
Nel frattempo ci stiamo preparando , che si svolgerà il 6 e 7 aprile a San Pietroburgo, e invitiamo gli sviluppatori di sistemi ad alto carico . Gli oratori esperti sanno già cosa fare, ma per chi è nuovo a parlare lo consigliamo almeno . Partecipare al convegno in qualità di relatore presenta numerosi vantaggi. Puoi leggere quali, ad esempio, alla fine .
Fonte: habr.com