I 2010 selskapet det var 50 servere og en enkel nettverksmodell: backend, frontend og brannmur. Antall servere vokste, modellen ble mer kompleks: iscenesettelse, isolerte VLAN-er med ACL-er, deretter VPN-er med VRF-er, VLAN-er med ACL-er på L2, VRF-er med ACL-er på L3. Snurrer hodet? Det blir mer moro senere.
Da det var 16 000 servere, ble det umulig å jobbe uten tårer med så mange heterogene segmenter. Så vi kom på en annen løsning. Vi tok Netfilter-stakken, la Consul til den som en datakilde, og vi fikk en raskt distribuert brannmur. De erstattet ACL-er på rutere og brukte dem som en ekstern og intern brannmur. For å administrere verktøyet dynamisk utviklet vi BEFW-systemet, som ble brukt overalt: fra å administrere brukertilgang til produktnettverket til å isolere nettverkssegmenter fra hverandre.
Han vil fortelle deg hvordan det hele fungerer og hvorfor du bør se nærmere på dette systemet. Ivan Agarkov () er leder for infrastruktursikkerhetsgruppen til vedlikeholdsdivisjonen ved selskapets utviklingssenter i Minsk. Ivan er en SELinux-fan, elsker Perl og skriver kode. Som leder av informasjonssikkerhetsgruppen jobber han jevnlig med logger, backup og FoU for å beskytte Wargaming mot hackere og sikre driften av alle spillservere i selskapet.
Historisk informasjon
Før jeg forteller deg hvordan vi gjorde det, skal jeg fortelle deg hvordan vi kom til dette i utgangspunktet og hvorfor det var nødvendig. For å gjøre dette, la oss gå 9 år tilbake: 2010, World of Tanks dukket nettopp opp. Wargaming hadde omtrent 50 servere.
Vekstdiagram for bedriftens server.
Vi hadde en nettverksmodell. For den tiden var det optimalt.
Nettverksmodell i 2010.
Det er skurker på fronten som vil knekke oss, men den har en brannmur. Det er ingen brannmur på backend, men det er 50 servere der, vi kjenner dem alle. Alt fungerer bra.
På 4 år vokste serverflåten 100 ganger, til 5000. De første isolerte nettverkene dukket opp - iscenesettelse: de kunne ikke gå til produksjon, og det var ofte ting som kjørte der som kunne være farlige.
Nettverksmodell i 2014.
Ved treghet brukte vi de samme maskinvarene, og alt arbeidet ble utført på isolerte VLAN-er: ACL-er skrives til VLAN-ene, som tillater eller nekter en form for tilkobling.
I 2016 nådde antallet servere 8000. Wargaming absorberte andre studioer, og flere tilknyttede nettverk dukket opp. De ser ut til å være våre, men ikke helt: VLAN fungerer ofte ikke for partnere, du må bruke VPN med VRF, isolasjon blir mer komplisert. ACL-isolasjonsblandingen vokste.
Nettverksmodell i 2016.
Ved inngangen til 2018 hadde maskinparken vokst til 16 000. Det var 6 segmenter, og vi talte ikke med resten, inkludert lukkede hvor finansdata var lagret. Containernettverk (Kubernetes), DevOps, skynettverk koblet til via VPN, for eksempel fra en IVS, har dukket opp. Det var mange regler - det var vondt.
Nettverksmodell og isolasjonsmetoder i 2018.
For isolasjon brukte vi: VLAN med ACL på L2, VRF med ACL på L3, VPN og mye mer. For mye.
Problemer
Alle lever med ACL og VLAN. Hva er galt? Dette spørsmålet vil bli besvart av Harold, og skjuler smerten.
Det var mange problemer, men det var fem store.
- Geometrisk prisøkning for nye regler. Hver ny regel tok lengre tid å legge til enn den forrige, fordi det først var nødvendig å se om det allerede fantes en slik regel.
- Ingen brannmur inne i segmenter. Segmentene var på en eller annen måte skilt fra hverandre, og det var allerede ikke nok ressurser inne.
- Reglene ble brukt i lang tid. Operatører kunne skrive én lokal regel for hånd på en time. Den globale tok flere dager.
- Vansker med revisjonsregler. Mer presist var det ikke mulig. De første reglene ble skrevet tilbake i 2010, og de fleste av forfatterne deres jobbet ikke lenger for selskapet.
- Lavt nivå av infrastrukturkontroll. Dette er hovedproblemet - vi visste ikke så godt hva som foregikk i landet vårt.
Slik så en nettverksingeniør ut i 2018 da han hørte: "Trenger litt mer ACL."
Løsninger
I begynnelsen av 2018 ble det besluttet å gjøre noe med det.
Prisen på integrasjoner vokser stadig. Utgangspunktet var at store datasentre sluttet å støtte isolerte VLAN og ACL fordi enhetene gikk tom for minne.
Løsning: vi fjernet den menneskelige faktoren og automatiserte tilgangen til maksimalt.
De nye reglene tar lang tid å gjelde. Løsning: få fart på anvendelsen av regler, gjør den distribuert og parallell. Dette krever et distribuert system slik at reglene leveres selv, uten rsync eller SFTP til tusen systemer.
Ingen brannmur inne i segmenter. En brannmur innenfor segmenter begynte å komme til oss da forskjellige tjenester dukket opp innenfor samme nettverk. Løsning: bruk en brannmur på vertsnivå - vertsbaserte brannmurer. Nesten overalt hvor vi har Linux, og overalt hvor vi har iptables, er ikke dette et problem.
Vansker med revisjonsregler. Løsning: Oppbevar alle reglene på ett sted for gjennomgang og administrasjon, slik at vi kan revidere alt.
Lav grad av kontroll over infrastruktur. Løsning: ta en oversikt over alle tjenester og tilganger mellom dem.
Dette er mer en administrativ prosess enn en teknisk. Noen ganger har vi 200-300 nye utgivelser i uken, spesielt under kampanjer og høytider. Dessuten er dette bare for ett team av våre DevOps. Med så mange utgivelser er det umulig å se hvilke porter, IP-er og integrasjoner som trengs. Derfor trengte vi spesialtrente serviceledere som spurte teamene: «Hva er det egentlig og hvorfor tok dere det opp?»
Etter alt vi lanserte, begynte en nettverksingeniør i 2019 å se slik ut.
Konsul
Vi bestemte oss for at vi skulle legge alt vi fant ved hjelp av serviceledere inn i Consul og derfra skulle vi skrive iptables-regler.
Hvordan bestemte vi oss for å gjøre dette?
- Vi vil samle alle tjenester, nettverk og brukere.
- La oss lage iptables-regler basert på dem.
- Vi automatiserer kontroll.
- ....
- PROFITT.
Consul er ikke et eksternt API, det kan kjøres på hver node og skrive til iptables. Det gjenstår bare å komme opp med automatiske kontroller som vil rense ut unødvendige ting, og de fleste problemene vil bli løst! Vi ordner resten mens vi går.
Hvorfor konsul?
Har bevist seg godt. I 2014-15 brukte vi det som en backend for Vault, der vi lagrer passord.
Mister ikke data. I løpet av brukstiden mistet ikke Consul data under en eneste ulykke. Dette er et stort pluss for et brannmurstyringssystem.
P2P-forbindelser akselererer spredningen av endring. Med P2P kommer alle endringer raskt, du trenger ikke å vente i timevis.
Praktisk REST API. Vi vurderte også Apache ZooKeeper, men den har ikke et REST API, så du må installere krykker.
Fungerer både som nøkkelhvelv (KV) og katalog (tjenesteoppdagelse). Du kan lagre tjenester, kataloger og datasentre samtidig. Dette er praktisk ikke bare for oss, men også for naboteam, fordi når vi bygger en global tjeneste, tenker vi stort.
Skrevet i Go, som er en del av Wargaming-stabelen. Vi elsker dette språket, vi har mange Go-utviklere.
Kraftig ACL-system. I Consul kan du bruke ACLer til å kontrollere hvem som skriver hva. Vi garanterer at brannmurreglene ikke vil overlappe med noe annet og vi vil ikke ha problemer med dette.
Men Consul har også sine ulemper.
- Skaleres ikke i et datasenter med mindre du har en bedriftsversjon. Det er bare skalerbart av føderasjon.
- Veldig avhengig av kvaliteten på nettverket og serverbelastningen. Consul vil ikke fungere som en server på en opptatt server hvis det er forsinkelser i nettverket, for eksempel ujevn hastighet. Dette skyldes P2P-tilkoblinger og oppdateringsdistribusjonsmodeller.
- Vanskeligheter med å overvåke tilgjengelighet. I konsulstatus kan han si at alt er bra, men han døde for lenge siden.
Vi løste de fleste av disse problemene mens vi brukte Consul, og det er derfor vi valgte det. Selskapet har planer om en alternativ backend, men vi har lært å håndtere problemer og bor for tiden hos Consul.
Hvordan Consul fungerer
Vi skal installere tre til fem servere i et betinget datasenter. En eller to servere vil ikke fungere: de vil ikke være i stand til å organisere et quorum og bestemme hvem som har rett og hvem som har feil når dataene ikke stemmer overens. Mer enn fem gir ingen mening, produktiviteten vil synke.
Klienter kobler til serverne i hvilken som helst rekkefølge: de samme agentene, bare med flagget server = false.
Etter dette mottar klienter en liste over P2P-tilkoblinger og bygger tilkoblinger seg imellom.
På globalt nivå kobler vi sammen flere datasentre. De kobler også til P2P og kommuniserer.
Når vi ønsker å hente data fra et annet datasenter, går forespørselen fra server til server. Denne ordningen kalles Serf-protokoll. Serf-protokollen, i likhet med Consul, er utviklet av HashiCorp.
Noen viktige fakta om konsul
Consul har dokumentasjon som beskriver hvordan det fungerer. Jeg vil kun gi utvalgte fakta som er verdt å vite.
Konsul-servere velger en master blant velgerne. Consul velger en master fra listen over servere for hvert datasenter, og alle forespørsler går kun til den, uavhengig av antall servere. Mesterfrysing fører ikke til gjenvalg. Hvis masteren ikke er valgt, betjenes ikke forespørsler av noen.
Ønsket du horisontal skalering? Beklager, nei.
En forespørsel til et annet datasenter går fra master til master, uavhengig av hvilken server den kom til. Den valgte masteren mottar 100 % av lasten, bortsett fra lasten på videresendingsforespørsler. Alle servere i datasenteret har en oppdatert kopi av dataene, men kun én svarer.
Den eneste måten å skalere på er å aktivere foreldet modus på klienten.
I foreldet modus kan du svare uten beslutningsdyktighet. Dette er en modus der vi gir opp datakonsistens, men leser litt raskere enn vanlig, og enhver server svarer. Naturligvis kun opptak gjennom masteren.
Consul kopierer ikke data mellom datasentre. Når en føderasjon er satt sammen, vil hver server bare ha sine egne data. For andre henvender han seg alltid til noen andre.
Atomitet av operasjoner er ikke garantert utenfor en transaksjon. Husk at du ikke er den eneste som kan endre ting. Hvis du ønsker det annerledes, gjør en transaksjon med en lås.
Blokkering garanterer ikke låsing. Forespørselen går fra master til master, og ikke direkte, så det er ingen garanti for at blokkeringen vil fungere når du blokkerer for eksempel i et annet datasenter.
ACL garanterer heller ikke tilgang (i mange tilfeller). ACL fungerer kanskje ikke fordi den er lagret i ett føderasjonsdatasenter - i ACL-datasenteret (Primær DC). Hvis DC ikke svarer deg, vil ikke ACL fungere.
Én frossen mester vil få hele forbundet til å fryse. For eksempel er det 10 datasentre i en føderasjon, og ett har et dårlig nettverk, og en master svikter. Alle som kommuniserer med ham vil sitte fast i en sirkel: det er en forespørsel, det er ikke noe svar på den, tråden fryser. Det er ingen måte å vite når dette vil skje, bare om en time eller to vil hele forbundet falle. Det er ingenting du kan gjøre med det.
Status, beslutningsdyktighet og valg håndteres av en egen tråd. Gjenvalg vil ikke skje, status vil ikke vise noe. Du tror at du har en levende konsul, spør du, og ingenting skjer - det er ikke noe svar. Samtidig viser status at alt er bra.
Vi har støtt på dette problemet og måtte bygge om bestemte deler av datasentre for å unngå det.
Bedriftsversjonen av Consul Enterprise har ikke noen av ulempene ovenfor. Den har mange nyttige funksjoner: velge velgere, distribusjon, skalering. Det er bare ett "men" - lisensieringssystemet for et distribuert system er veldig dyrt.
Livet hacking: rm -rf /var/lib/consul - en kur for alle sykdommer i agenten. Hvis noe ikke fungerer for deg, slett bare dataene dine og last ned dataene fra en kopi. Mest sannsynlig vil Consul jobbe.
BEFW
La oss nå snakke om hva vi har lagt til Consul.
er et akronym for BackEndFireWalle. Jeg måtte navngi produktet på en eller annen måte da jeg opprettet depotet for å sette inn de første testforpliktelsene i det. Dette navnet består.
Regelmaler
Reglene er skrevet i iptables-syntaks.
- -N BEFW
- -P INPUT DROP
- -A INPUT -m tilstand—tilstand RELATED,ETABLISHED -j ACCEPT
- -A INNGANG -i lo -j GODTAR
- -A INNGANG -j BEFW
Alt går inn i BEFW-kjeden, bortsett fra ESTABLISHED, RELATED og lokalvert. Malen kan være hva som helst, dette er bare et eksempel.
Hvordan er BEFW nyttig?
tjenester
Vi har en tjeneste, den har alltid en port, en node den kjører på. Fra noden vår kan vi lokalt spørre agenten og finne ut at vi har en form for tjeneste. Du kan også sette merkelapper.
Enhver tjeneste som kjører og er registrert hos Consul blir til en iptables-regel. Vi har SSH - åpen port 22. Bash-skriptet er enkelt: curl og iptables, ingenting annet er nødvendig.
Klienter
Hvordan åpne tilgang ikke for alle, men selektivt? Legg til IP-lister til KV-lagring etter tjenestenavn.
For eksempel ønsker vi at alle på det tiende nettverket skal kunne få tilgang til SSH_TCP_22-tjenesten. Legg til ett lite TTL-felt? og nå har vi midlertidige tillatelser for eksempel for en dag.
Tilganger
Vi kobler sammen tjenester og kunder: vi har en tjeneste, KV-lagring er klar for hver. Nå gir vi tilgang ikke til alle, men selektivt.
Gruppe
Hvis vi skriver tusenvis av IP-er for tilgang hver gang, blir vi slitne. La oss finne på grupperinger - en egen delmengde i KV. La oss kalle det Alias (eller grupper) og lagre grupper der etter samme prinsipp.
La oss koble til: nå kan vi åpne SSH ikke spesifikt for P2P, men for en hel gruppe eller flere grupper. På samme måte er det TTL - du kan legge til en gruppe og fjerne fra gruppen midlertidig.
integrering
Problemet vårt er den menneskelige faktoren og automatisering. Så langt har vi løst det på denne måten.
Vi samarbeider med Puppet, og overfører alt som gjelder systemet (applikasjonskode) til dem. Puppetdb (vanlig PostgreSQL) lagrer en liste over tjenester som kjører der, de kan finnes etter ressurstype. Der kan du finne ut hvem som søker hvor. Vi har også et pull request og merge request system for dette.
Vi skrev befw-sync, en enkel løsning som hjelper til med å overføre data. Først får du tilgang til synkroniseringskapsler av puppetdb. En HTTP API er konfigurert der: vi ber om hvilke tjenester vi har, hva som må gjøres. Så sender de en forespørsel til konsul.
Er det integrering? Ja: de skrev reglene og tillot at Pull-forespørsler ble akseptert. Trenger du en bestemt port eller legger du til en vert i en gruppe? Trekk forespørsel, gjennomgå - ikke mer "Finn 200 andre tilgangskontrollister og prøv å gjøre noe med det."
Optimalisering
Å pinge lokalvert med en tom regelkjede tar 0,075 ms.
La oss legge til 10 000 iptables-adresser til denne kjeden. Som et resultat vil ping øke 5 ganger: iptables er helt lineært, behandling av hver adresse tar litt tid.
For en brannmur der vi migrerer tusenvis av tilgangskontrollister, har vi mange regler, og dette introduserer latens. Dette er dårlig for spillprotokoller.
Men hvis vi setter 10 000 adresser i ipset Pingen vil til og med avta.
Poenget er at "O" (algoritmekompleksitet) for ipset alltid er lik 1, uansett hvor mange regler det er. Riktignok er det en begrensning - det kan ikke være mer enn 65535 regler. For nå lever vi med dette: du kan kombinere dem, utvide dem, lage to ipsets i ett.
lagring
En logisk fortsettelse av iterasjonsprosessen er å lagre informasjon om klienter for tjenesten i ipset.
Nå har vi samme SSH, og vi skriver ikke 100 IP-er på en gang, men setter navnet på ipset som vi må kommunisere med, og følgende regel DROP. Den kan konverteres til én regel "Hvem er ikke her, DROP", men den er mer tydelig.
Nå har vi regler og sett. Hovedoppgaven er å lage et sett før du skriver regelen, fordi ellers vil ikke iptables skrive regelen.
Generell ordning
I form av et diagram ser alt jeg sa slik ut.
Vi forplikter oss til Puppet, alt sendes til verten, tjenester her, ipset der, og alle som ikke er registrert der har ikke lov.
Tillat og avslå
For raskt å redde verden eller raskt deaktivere noen, laget vi to ipsets i begynnelsen av alle kjeder: rules_allow и rules_deny. Hvordan det fungerer?
For eksempel oppretter noen en belastning på nettet vårt med roboter. Tidligere måtte du finne IP-en hans fra loggene, ta den med til nettverksingeniører, slik at de kunne finne kilden til trafikken og utestenge ham. Det ser annerledes ut nå.
Vi sender det til Consul, vent 2,5 sekunder, og det er gjort. Siden Consul distribuerer raskt gjennom P2P, fungerer det overalt, i alle deler av verden.
En gang stoppet jeg på en eller annen måte helt WOT på grunn av en feil med brannmuren. rules_allow – dette er vår forsikring mot slike saker. Hvis vi har gjort en feil et sted med brannmuren, er noe blokkert et sted, vi kan alltid sende en betinget 0.0/0for raskt å plukke opp alt. Senere skal vi fikse alt for hånd.
Andre sett
Du kan legge til andre sett i rommet $IPSETS$.
For hva? Noen ganger trenger noen ipset, for eksempel for å etterligne nedleggelsen av en del av klyngen. Hvem som helst kan ta med hvilke som helst sett, navngi dem, og de blir hentet hos Consul. Samtidig kan sett enten delta i iptables-reglene eller fungere som et lag NOOP: Konsistens vil opprettholdes av daemonen.
Medlemmer
Tidligere var det slik: brukeren koblet til nettverket og mottok parametere gjennom domenet. Før den nye generasjonen brannmurer kom, visste ikke Cisco hvordan han skulle forstå hvor brukeren var og hvor IP-en var. Derfor ble tilgang kun gitt gjennom vertsnavnet til maskinen.
Hva gjorde vi? Vi ble sittende fast i det øyeblikket vi fikk adressen. Vanligvis er dette dot1x, Wi-Fi eller VPN – alt går gjennom RADIUS. For hver bruker oppretter vi en gruppe etter brukernavn og plasserer en IP i den med en TTL som er lik dens dhcp.lease - så snart den utløper, vil regelen forsvinne.
Nå kan vi åpne tilgang til tjenester, som andre grupper, etter brukernavn. Vi har tatt smerten ut av vertsnavn når de endres, og vi har tatt byrden fra nettverksingeniører fordi de ikke lenger trenger Cisco. Nå registrerer ingeniører selv tilgang på serverne sine.
Isolasjon
Samtidig begynte vi å demontere isolasjonen. Tjenesteledere tok en inventar, og vi analyserte alle nettverkene våre. La oss dele dem inn i de samme gruppene, og på de nødvendige serverne ble gruppene lagt til for eksempel for å nekte. Nå havner den samme iscenesettelsesisolasjonen i reglene_fornektelse av produksjonen, men ikke i selve produksjonen.
Opplegget fungerer raskt og enkelt: vi fjerner alle ACL-er fra serverne, laster av maskinvaren og reduserer antallet isolerte VLAN-er.
Integritetskontroll
Tidligere hadde vi en spesiell trigger som rapporterte når noen endret en brannmurregel manuelt. Jeg skrev en stor linter for å sjekke brannmurreglene, det var vanskelig. Integritet er nå kontrollert av BEFW. Han sørger nidkjært for at reglene han lager ikke endres. Hvis noen endrer brannmurreglene, vil det endre alt tilbake. "Jeg satte raskt opp en proxy slik at jeg kunne jobbe hjemmefra" - det er ikke flere slike alternativer.
BEFW kontrollerer ipset fra tjenestene og listen i befw.conf, reglene for tjenester i BEFW-kjeden. Men den overvåker ikke andre kjeder og regler og andre ipsets.
Kollisjonsbeskyttelse
BEFW lagrer alltid den siste kjente gode tilstanden direkte i den binære strukturen state.bin. Hvis noe går galt, ruller den alltid tilbake til denne tilstanden.bin.
Dette er forsikring mot ustabil Consul-drift, når den ikke sendte data eller noen gjorde en feil og brukte regler som ikke kan brukes. For å sikre at vi ikke blir stående uten brannmur, vil BEFW rulle tilbake til siste tilstand hvis det oppstår en feil på noe tidspunkt.
I kritiske situasjoner er dette en garanti for at vi sitter igjen med en fungerende brannmur. Vi åpner alle grå nettverk i håp om at admin kommer og fikser det. En dag vil jeg legge dette inn i konfigurasjonene, men nå har vi bare tre grå nettverk: 10/8, 172/12 og 192.168/16. Innenfor vår konsul er dette en viktig funksjon som hjelper oss å utvikle oss videre.
Demo: under rapporten demonstrerer Ivan demomodusen til BEFW. Det er lettere å se demonstrasjonen . Demokildekode tilgjengelig .
Fallgruver
Jeg skal fortelle deg om feilene vi møtte.
ipset add sett 0.0.0.0/0. Hva skjer hvis du legger til 0.0.0.0/0 i ipset? Vil alle IP-er bli lagt til? Vil Internett-tilgang være tilgjengelig?
Nei, vi får en feil som kostet oss to timers nedetid. Dessuten har feilen ikke fungert siden 2016, den ligger i RedHat Bugzilla under nummer #1297092, og vi fant den ved et uhell - fra en utviklerrapport.
Det er nå en streng regel hos BEFW at 0.0.0.0/0 blir til to adresser: 0.0.0.0/1 и 128.0.0.0/1.
ipset gjenopprettingssett < fil. Hva gjør ipset når du forteller det restore? Tror du det fungerer på samme måte som iptables? Vil det gjenopprette data?
Ingenting sånt - det slår sammen, og de gamle adressene går ikke noe sted, du blokkerer ikke tilgang.
Vi fant en feil under testing av isolasjon. Nå er det et ganske komplekst system – i stedet for restore gjennomført create temp, deretter restore flush temp и restore temp. På slutten av bytte: for atomitet, fordi hvis du gjør det først flush og i dette øyeblikket kommer en pakke, den vil bli kastet og noe vil gå galt. Så det er litt svart magi der.
konsul kv få -datasenter=annet. Som sagt tror vi at vi ber om noen data, men vi vil enten få data eller en feil. Vi kan gjøre dette via Consul lokalt, men i dette tilfellet vil begge fryse.
Den lokale Consul-klienten er en innpakning over HTTP API. Men det bare henger og reagerer ikke på Ctrl+C, eller Ctrl+Z, eller noe, bare kill -9 i neste konsoll. Vi møtte dette da vi skulle bygge en stor klynge. Men vi har ikke en løsning ennå; vi forbereder oss på å fikse denne feilen i Consul.
Konsulleder svarer ikke. Mesteren vår i datasenteret svarer ikke, vi tenker: "Kanskje omvalgsalgoritmen vil fungere nå?"
Nei, det vil ikke fungere, og overvåking vil ikke vise noe: Konsul vil si at det er en forpliktelsesindeks, en leder er funnet, alt er bra.
Hvordan takler vi dette? service consul restart i cron hver time. Hvis du har 50 servere, er det ingen stor sak. Når det er 16 000 av dem, vil du forstå hvordan det fungerer.
Konklusjon
Som et resultat fikk vi følgende fordeler:
- 100 % dekning av alle Linux-maskiner.
- Speed.
- Automasjon.
- Vi frigjorde maskinvare- og nettverksingeniører fra slaveri.
- Det har dukket opp integrasjonsmuligheter som er nesten ubegrensede: selv med Kubernetes, til og med med Ansible, til og med med Python.
Cons: Konsul, som vi nå må leve med, og de svært høye kostnadene ved feil. Som et eksempel, en gang kl. 6 (primetime i Russland) redigerte jeg noe i listene over nettverk. Vi holdt nettopp på å bygge isolasjon på BEFW på den tiden. Jeg gjorde en feil et sted, det ser ut til at jeg indikerte feil maske, men alt falt på to sekunder. Overvåkingen lyser, støttepersonen på vakt kommer løpende: «Vi har alt!» Avdelingslederen ble grå da han forklarte virksomheten hvorfor dette skjedde.
Kostnadene ved feil er så høye at vi har kommet opp med vår egen komplekse forebyggingsprosedyre. Hvis du implementerer dette på et stort produksjonssted, trenger du ikke gi en master-token over Consul til alle. Dette vil ende dårlig.
Kostnaden. Jeg skrev kode for 400 timer alene. Teamet mitt på 4 personer bruker 10 timer i måneden på støtte for alle. Sammenlignet med prisen på en ny generasjons brannmur, er det gratis.
Planer. Den langsiktige planen er å finne alternativ transport for å erstatte eller utfylle Consul. Kanskje det blir Kafka eller noe lignende. Men i årene som kommer skal vi leve på Consul.
Umiddelbare planer: integrasjon med Fail2ban, med overvåking, med nftables, eventuelt med andre distribusjoner, metrikk, avansert overvåking, optimalisering. Kubernetes-støtte er også et sted i planene, for nå har vi flere klynger og ønsket.
Mer fra planene:
- søk etter uregelmessigheter i trafikken;
- nettverk kart ledelse;
- Kubernetes-støtte;
- sette sammen pakker for alle systemer;
- Web-UI.
Vi jobber kontinuerlig med å utvide konfigurasjonen, øke beregningene og optimalisere.
Bli med i prosjektet. Prosjektet viste seg å være kult, men dessverre er det fortsatt et enmannsprosjekt. Kom til og prøv å gjøre noe: forplikte seg, teste, foreslå noe, gi din vurdering.
I mellomtiden forbereder vi oss på , som finner sted 6. og 7. april i St. Petersburg, og vi inviterer utviklere av høylastsystemer . Erfarne foredragsholdere vet allerede hva de skal gjøre, men for de nye som snakker anbefaler vi i det minste . Å delta på konferansen som foredragsholder har en rekke fordeler. Du kan lese hvilke for eksempel på slutten .
Kilde: www.habr.com