In 2010 het bedrijf er waren 50 servers en een eenvoudig netwerkmodel: backend, frontend en firewall. Het aantal servers groeide, het model werd complexer: staging, geïsoleerde VLAN's met ACL's, vervolgens VPN's met VRF's, VLAN's met ACL's op L2, VRF's met ACL's op L3. Hoofd draait? Het zal later leuker zijn.
Toen er nog 16 servers waren, werd het onmogelijk om zonder tranen met zoveel heterogene segmenten te werken. Daarom hebben wij een andere oplossing bedacht. We namen de Netfilter-stack, voegden Consul eraan toe als gegevensbron, en we kregen een snel gedistribueerde firewall. Ze vervingen ACL's op routers en gebruikten ze als externe en interne firewall. Om de tool dynamisch te beheren, ontwikkelden we het BEFW-systeem, dat overal werd gebruikt: van het beheren van gebruikerstoegang tot het productnetwerk tot het van elkaar isoleren van netwerksegmenten.
Hij vertelt je hoe het allemaal werkt en waarom je dit systeem eens nader moet bekijken. Ivan Agarkov () is het hoofd van de infrastructuurbeveiligingsgroep van de onderhoudsdivisie in het ontwikkelingscentrum van het bedrijf in Minsk. Ivan is een SELinux-fan, houdt van Perl en schrijft code. Als hoofd van de informatiebeveiligingsgroep werkt hij regelmatig met logs, back-ups en R&D om Wargaming te beschermen tegen hackers en de werking van alle gameservers in het bedrijf te garanderen.
geschiedenis
Voordat ik je vertel hoe we het hebben gedaan, zal ik eerst vertellen hoe we hiertoe zijn gekomen en waarom het nodig was. Laten we hiervoor 9 jaar teruggaan: 2010, World of Tanks verscheen zojuist. Wargaming had ongeveer 50 servers.
Groeigrafiek voor bedrijfsservers.
We hadden een netwerkmodel. Voor die tijd was het optimaal.
Netwerkmodel in 2010.
Er zijn slechteriken aan de voorkant die ons willen breken, maar er is een firewall. Er is geen firewall op de backend, maar er zijn wel 50 servers, we kennen ze allemaal. Alles werkt goed.
In vier jaar tijd groeide de servervloot honderd keer, tot 4. De eerste geïsoleerde netwerken verschenen - staging: ze konden niet in productie gaan, en er draaiden daar vaak dingen die gevaarlijk konden zijn.
Netwerkmodel in 2014.
Door traagheid gebruikten we dezelfde stukken hardware, en al het werk werd uitgevoerd op geïsoleerde VLAN's: ACL's worden naar de VLAN's geschreven, die een soort verbinding toestaan of weigeren.
In 2016 bereikte het aantal servers 8000. Wargaming absorbeerde andere studio's en er verschenen extra aangesloten netwerken. Ze lijken van ons te zijn, maar niet helemaal: VLAN werkt vaak niet voor partners, je moet VPN met VRF gebruiken, isolatie wordt ingewikkelder. Het ACL-isolatiemengsel groeide.
Netwerkmodel in 2016.
Begin 2018 was het machinepark gegroeid tot 16. Er waren 000 segmenten en de rest hebben we niet meegeteld, inclusief gesloten segmenten waarin financiële gegevens werden opgeslagen. Er zijn containernetwerken (Kubernetes), DevOps, cloudnetwerken verschenen die via VPN zijn verbonden, bijvoorbeeld vanuit een IVS. Er waren veel regels - het was pijnlijk.
Netwerkmodel en isolatiemethoden in 2018.
Voor isolatie gebruikten we: VLAN met ACL op L2, VRF met ACL op L3, VPN en nog veel meer. Te veel.
Problemen
Iedereen leeft met ACL en VLAN. Wat is er mis? Deze vraag zal worden beantwoord door Harold, die de pijn verbergt.
Er waren veel problemen, maar er waren vijf enorme problemen.
- Geometrische prijsverhoging voor nieuwe regels. Het toevoegen van elke nieuwe regel duurde langer dan de vorige, omdat eerst moest worden gekeken of er al zo'n regel bestond.
- Geen firewall binnen segmenten. De segmenten waren op de een of andere manier van elkaar gescheiden en er waren al niet genoeg middelen binnenin.
- De regels werden lange tijd toegepast. Operators zouden binnen een uur één lokale regel met de hand kunnen schrijven. De mondiale duurde enkele dagen.
- Problemen met auditregels. Om precies te zijn: het was niet mogelijk. De eerste regels werden in 2010 geschreven en de meeste auteurs werkten niet langer voor het bedrijf.
- Laag niveau van infrastructuurcontrole. Dit is het grootste probleem: we wisten niet zo goed wat er in ons land aan de hand was.
Zo zag een netwerkingenieur er in 2018 uit toen hij hoorde: “Ik heb wat meer ACL nodig.”
Ð ÐμÑÐμниÑ
Begin 2018 werd besloten daar iets aan te doen.
De prijs van integraties stijgt voortdurend. Het uitgangspunt was dat grote datacenters stopten met het ondersteunen van geïsoleerde VLAN's en ACL's omdat de apparaten geen geheugen meer hadden.
Oplossing: we hebben de menselijke factor geëlimineerd en de toegang maximaal geautomatiseerd.
Het duurt lang voordat de nieuwe regels van toepassing zijn. Oplossing: versnel de toepassing van regels, maak deze gedistribueerd en parallel. Hiervoor is een gedistribueerd systeem nodig, zodat de regels zelf, zonder rsync of SFTP, aan duizend systemen worden geleverd.
Geen firewall binnen segmenten. Een firewall binnen segmenten begon naar ons toe te komen toen verschillende diensten binnen hetzelfde netwerk verschenen. Oplossing: gebruik een firewall op hostniveau - hostgebaseerde firewalls. Bijna overal waar we Linux hebben, en overal waar we iptables hebben, is dit geen probleem.
Problemen met auditregels. Oplossing: Bewaar alle regels op één plek voor beoordeling en beheer, zodat we alles kunnen controleren.
Laag niveau van controle over de infrastructuur. Oplossing: inventariseer alle diensten en toegangen daartussen.
Dit is meer een administratief proces dan een technisch proces. Soms hebben we 200-300 nieuwe releases per week, vooral tijdens promoties en feestdagen. Bovendien is dit slechts voor één team van onze DevOps. Met zoveel releases is het onmogelijk om te zien welke poorten, IP's en integraties nodig zijn. Daarom hadden we speciaal opgeleide servicemanagers nodig die aan de teams vroegen: “Wat is er eigenlijk en waarom hebben jullie het ter sprake gebracht?”
Na alles wat we lanceerden, begon een netwerkingenieur er in 2019 zo uit te zien.
Consul
We besloten dat we alles wat we vonden met de hulp van servicemanagers in Consul zouden stoppen en van daaruit iptables-regels zouden schrijven.
Hoe hebben we besloten dit te doen?
- Wij verzamelen alle diensten, netwerken en gebruikers.
- Laten we iptables-regels op basis daarvan maken.
- Wij automatiseren de controle.
- ....
- WINST.
Consul is geen externe API, hij kan op elk knooppunt draaien en naar iptables schrijven. Het enige dat overblijft is het bedenken van automatische controles die onnodige dingen opruimen, en de meeste problemen zullen worden opgelost! De rest zullen we gaandeweg uitzoeken.
Waarom consul?
Heeft zich goed bewezen. In 2014-15 gebruikten we het als backend voor Vault, waarin we wachtwoorden opslaan.
Verliest geen gegevens. Tijdens het gebruik verloor Consul geen gegevens tijdens een enkel ongeval. Dit is een groot pluspunt voor een firewallbeheersysteem.
P2P-verbindingen versnellen de verspreiding van verandering. Met P2P komen alle veranderingen snel, u hoeft niet uren te wachten.
Handige REST-API. We hebben ook Apache ZooKeeper overwogen, maar deze heeft geen REST API, dus je zult krukken moeten installeren.
Werkt zowel als Key Vault (KV) als als Directory (Service Discovery). U kunt services, catalogi en datacenters tegelijk opslaan. Dit is niet alleen handig voor ons, maar ook voor aangrenzende teams, omdat we bij het bouwen van een wereldwijde service groot denken.
Geschreven in Go, onderdeel van de Wargaming-stack. We houden van deze taal, we hebben veel Go-ontwikkelaars.
Krachtig ACL-systeem. In Consul kunt u ACL's gebruiken om te bepalen wie wat schrijft. Wij garanderen dat de firewallregels met niets anders zullen overlappen en dat wij hier geen problemen mee zullen krijgen.
Maar Consul heeft ook zijn nadelen.
- Schaalt niet binnen een datacenter tenzij u een zakelijke versie heeft. Het is alleen schaalbaar via federatie.
- Zeer afhankelijk van de kwaliteit van het netwerk en de serverbelasting. Consul zal niet goed werken als server op een drukke server als er sprake is van vertragingen in het netwerk, bijvoorbeeld een ongelijkmatige snelheid. Dit komt door P2P-verbindingen en update-distributiemodellen.
- Moeilijkheden bij het monitoren van de beschikbaarheid. In de status van consul kan hij zeggen dat alles in orde is, maar hij is al lang geleden overleden.
We hebben de meeste van deze problemen opgelost tijdens het gebruik van Consul, daarom hebben we ervoor gekozen. Het bedrijf heeft plannen voor een alternatieve backend, maar wij hebben geleerd om met problemen om te gaan en wonen momenteel bij Consul.
Hoe Consul werkt
We plaatsen drie tot vijf servers in een voorwaardelijk datacenter. Een of twee servers zullen niet werken: ze zullen niet in staat zijn een quorum te organiseren en te beslissen wie gelijk heeft en wie ongelijk als de gegevens niet overeenkomen. Meer dan vijf heeft geen zin, de productiviteit zal dalen.
Clients maken in willekeurige volgorde verbinding met de servers: dezelfde agenten, alleen met de vlag server = false.
Hierna ontvangen klanten een lijst met P2P-verbindingen en bouwen ze onderling verbindingen op.
Op mondiaal niveau verbinden we verschillende datacenters. Ze verbinden ook P2P en communiceren.
Wanneer we gegevens uit een ander datacenter willen ophalen, gaat het verzoek van server naar server. Dit schema heet Serf-protocol. Het Serf-protocol is, net als Consul, ontwikkeld door HashiCorp.
Enkele belangrijke feiten over Consul
Consul heeft documentatie waarin wordt beschreven hoe het werkt. Ik zal alleen geselecteerde feiten geven die de moeite waard zijn om te weten.
Consulservers selecteren een meester uit de kiezers. Consul selecteert voor elk datacenter een master uit de lijst met servers en alle verzoeken gaan alleen daarheen, ongeacht het aantal servers. Bevriezing van de master leidt niet tot herverkiezing. Als de master niet is geselecteerd, worden aanvragen door niemand afgehandeld.
Wilt u horizontaal schalen? Sorry, nee.
Een verzoek aan een ander datacenter gaat van master naar master, ongeacht op welke server het terechtkomt. De geselecteerde master ontvangt 100% van de belasting, behalve de belasting op voorwaartse verzoeken. Alle servers in het datacenter beschikken over een actuele kopie van de gegevens, maar slechts één reageert.
De enige manier om te schalen is door de verouderde modus op de client in te schakelen.
In de verouderde modus kunt u reageren zonder quorum. Dit is een modus waarin we de gegevensconsistentie opgeven, maar iets sneller lezen dan normaal, en elke server reageert. Uiteraard alleen opnemen via de master.
Consul kopieert geen gegevens tussen datacenters. Wanneer een federatie wordt samengesteld, beschikt elke server alleen over zijn eigen gegevens. Voor anderen wendt hij zich altijd tot iemand anders.
De atomiciteit van de activiteiten kan buiten een transactie niet worden gegarandeerd. Bedenk dat jij niet de enige bent die dingen kan veranderen. Wilt u het anders, voer dan een transactie uit met een slotje.
Blokkeeroperaties garanderen geen vergrendeling. Het verzoek gaat van master naar master, en niet rechtstreeks. Er is dus geen garantie dat de blokkering werkt wanneer je bijvoorbeeld in een ander datacenter blokkeert.
ACL garandeert ook (in veel gevallen) geen toegang. De ACL werkt mogelijk niet omdat deze is opgeslagen in één federatief datacenter: in het ACL-datacenter (primaire DC). Als de DC u niet antwoordt, werkt de ACL niet.
Eén bevroren meester zal ervoor zorgen dat de hele federatie bevriest. Er zijn bijvoorbeeld tien datacenters in een federatie, één heeft een slecht netwerk en één master faalt. Iedereen die met hem communiceert, komt in een cirkel terecht: er is een verzoek, er is geen antwoord op, de draad loopt vast. Er is geen manier om te weten wanneer dit zal gebeuren, binnen een uur of twee zal de hele federatie vallen. Je kunt er niets aan doen.
Status, quorum en verkiezingen worden afgehandeld in een aparte thread. Herverkiezing zal niet plaatsvinden, de status zal niets laten zien. Je denkt dat je een echte consul hebt, je vraagt het, en er gebeurt niets - er komt geen antwoord. Tegelijkertijd laat de status zien dat alles in orde is.
We zijn dit probleem tegengekomen en moesten specifieke delen van datacenters opnieuw opbouwen om dit te voorkomen.
De zakelijke versie van Consul Enterprise heeft enkele van de bovenstaande nadelen niet. Het heeft veel handige functies: kiezers selecteren, verdelen, opschalen. Er is maar één ‘maar’: het licentiesysteem voor een gedistribueerd systeem is erg duur.
Life hacking: rm -rf /var/lib/consul - een remedie voor alle ziekten van de agent. Als iets voor u niet werkt, verwijdert u gewoon uw gegevens en downloadt u de gegevens van een kopie. Hoogstwaarschijnlijk zal Consul werken.
BEFW
Laten we het nu hebben over wat we aan Consul hebben toegevoegd.
is een afkorting voor BackEndFtoornWalle. Ik moest het product op de een of andere manier een naam geven toen ik de repository maakte om de eerste testcommits erin te plaatsen. Deze naam blijft.
Regelsjablonen
De regels zijn geschreven in de syntaxis van iptables.
- -N BEFW
- -P INGANGSDALING
- -A INPUT -m status - status GERELATEERD, VESTIGD -j ACCEPT
- -A INGANG -i lo -j ACCEPTEREN
- -A INPUT -j BEFW
Alles gaat in de BEFW-keten, behalve ESTABLISHED, RELATED en localhost. Het sjabloon kan van alles zijn, dit is slechts een voorbeeld.
Hoe is BEFW nuttig?
Services
We hebben een dienst, die heeft altijd een poort, een knooppunt waarop hij draait. Vanaf ons knooppunt kunnen we lokaal de agent vragen en ontdekken dat we een soort service hebben. Je kunt ook tags plaatsen.
Elke service die actief is en geregistreerd is bij Consul, verandert in een iptables-regel. We hebben SSH - open poort 22. Het Bash-script is eenvoudig: curl en iptables, verder is er niets nodig.
Cliënten
Hoe kan de toegang niet voor iedereen worden geopend, maar selectief? Voeg IP-lijsten toe aan KV-opslag op servicenaam.
We willen bijvoorbeeld dat iedereen op het tiende netwerk toegang heeft tot de SSH_TCP_22-service. Eén klein TTL-veld toevoegen? en nu hebben we tijdelijke vergunningen, bijvoorbeeld voor een dag.
Toegangen
Wij verbinden diensten en klanten: wij hebben een dienst, KV storage staat voor iedereen klaar. Nu geven we niet iedereen toegang, maar selectief.
Groepen
Als we elke keer duizenden IP-adressen schrijven voor toegang, worden we moe. Laten we groeperingen bedenken - een aparte subset in KV. Laten we het Alias (of groepen) noemen en daar volgens hetzelfde principe groepen opslaan.
Laten we verbinding maken: nu kunnen we SSH niet specifiek voor P2P openen, maar voor een hele groep of meerdere groepen. Op dezelfde manier is er TTL: u kunt aan een groep toevoegen en tijdelijk uit de groep verwijderen.
integratie
Ons probleem is de menselijke factor en automatisering. Tot nu toe hebben wij het op deze manier opgelost.
Wij werken met Puppet en dragen alles wat met het systeem te maken heeft (applicatiecode) aan hen over. Puppetdb (reguliere PostgreSQL) slaat een lijst met services op die daar worden uitgevoerd. Deze kunnen worden gevonden op brontype. Daar kunt u zien wie waar solliciteert. Ook hiervoor hebben wij een pull request en merge request systeem.
We schreven befw-sync, een eenvoudige oplossing die helpt bij het overbrengen van gegevens. Ten eerste worden synchronisatiecookies benaderd door puppetdb. Daar wordt een HTTP API geconfigureerd: we vragen welke diensten we hebben, wat er moet gebeuren. Vervolgens doen ze een verzoek aan de consul.
Is er sprake van integratie? Ja: zij schreven de regels en lieten toe dat Pull Requests geaccepteerd werden. Heeft u een bepaalde poort nodig of voegt u een host toe aan een bepaalde groep? Pull Request, review - niet meer “Vind 200 andere ACL’s en probeer er iets aan te doen.”
Optimalisatie
Het pingen van localhost met een lege regelketen duurt 0,075 ms.
Laten we 10 iptables-adressen aan deze keten toevoegen. Als gevolg hiervan zal de ping 000 keer toenemen: iptables is volledig lineair, het verwerken van elk adres kost enige tijd.
Voor een firewall waar we duizenden ACL's migreren, hebben we veel regels, en dit introduceert latentie. Dit is slecht voor gamingprotocollen.
Maar als we zetten 10 adressen in ipset De ping zal zelfs afnemen.
Het punt is dat “O” (algoritmecomplexiteit) voor ipset altijd gelijk is aan 1, ongeacht hoeveel regels er zijn. Toegegeven, er is een beperking: er kunnen niet meer dan 65535 regels zijn. Voorlopig leven we hiermee: je kunt ze combineren, uitbreiden, twee ipsets in één maken.
opslagruimte
Een logisch vervolg op het iteratieproces is het opslaan van informatie over clients voor de service in ipset.
Nu hebben we dezelfde SSH en schrijven we niet 100 IP's tegelijk, maar stellen we de naam in van de ipset waarmee we moeten communiceren, en de volgende regel DROP. Het kan worden omgezet in één regel “Wie is er niet, DROP”, maar het is duidelijker.
Nu hebben we regels en sets. De belangrijkste taak is om een set te maken voordat de regel wordt geschreven, omdat iptables de regel anders niet zal schrijven.
Algemeen schema
In diagramvorm ziet alles wat ik zei er zo uit.
We verbinden ons aan Puppet, alles wordt naar de host gestuurd, diensten hier, ipset daar, en iedereen die daar niet geregistreerd is, is niet toegestaan.
Toestaan & weigeren
Om snel de wereld te redden of iemand snel uit te schakelen, hebben we aan het begin van alle ketens twee ipsets gemaakt: rules_allow и rules_deny. Hoe het werkt?
Iemand creëert bijvoorbeeld een belasting op ons web met bots. Voorheen moest je zijn IP-adres uit de logboeken halen en het naar netwerkingenieurs brengen, zodat zij de bron van het verkeer konden vinden en hem konden verbannen. Het ziet er nu anders uit.
We sturen het naar Consul, wachten 2,5 seconden en het is klaar. Omdat Consul snel distribueert via P2P, werkt het overal en in elk deel van de wereld.
Ooit heb ik WOT op de een of andere manier volledig gestopt vanwege een fout met de firewall. rules_allow - dit is onze verzekering tegen dergelijke gevallen. Als we ergens een fout hebben gemaakt met de firewall, ergens iets geblokkeerd is, kunnen we altijd een conditional sturen 0.0/0om snel alles op te halen. Later zullen we alles met de hand repareren.
Andere sets
Je kunt andere sets in de ruimte toevoegen $IPSETS$.
Waarvoor? Soms heeft iemand bijvoorbeeld ipset nodig om het afsluiten van een deel van het cluster te emuleren. Iedereen kan sets meenemen, ze een naam geven en ze worden opgehaald bij Consul. Tegelijkertijd kunnen sets deelnemen aan de iptables-regels of als team optreden NOOP: Consistentie wordt gehandhaafd door de daemon.
Leden
Voorheen was het zo: de gebruiker maakte verbinding met het netwerk en ontving parameters via het domein. Vóór de komst van de nieuwe generatie firewalls wist Cisco niet hoe hij moest begrijpen waar de gebruiker zich bevond en waar het IP-adres was. Daarom werd alleen toegang verleend via de hostnaam van de machine.
Wat hebben we gedaan? We liepen vast op het moment dat we het adres ontvingen. Meestal is dit dot1x, Wi-Fi of VPN – alles gaat via RADIUS. Voor elke gebruiker maken we een groep aan op gebruikersnaam en plaatsen er een IP in met een TTL die gelijk is aan zijn dhcp.lease - zodra deze verloopt, verdwijnt de regel.
Nu kunnen we, net als andere groepen, toegang tot services openen via gebruikersnaam. We hebben de pijn weggenomen van hostnamen wanneer deze veranderen, en we hebben de last weggenomen van netwerkingenieurs omdat ze Cisco niet langer nodig hebben. Nu registreren ingenieurs zelf de toegang op hun servers.
Isolatie
Tegelijkertijd begonnen we de isolatie te demonteren. Servicemanagers hebben een inventarisatie gemaakt en we hebben al onze netwerken geanalyseerd. Laten we ze in dezelfde groepen verdelen, en op de benodigde servers zijn de groepen bijvoorbeeld toegevoegd om te ontkennen. Nu komt dezelfde ensceneringsisolatie terecht in de 'rules_deny' van de productie, maar niet in de productie zelf.
Het schema werkt snel en eenvoudig: we verwijderen alle ACL's van de servers, ontladen de hardware en verminderen het aantal geïsoleerde VLAN's.
Integriteitscontrole
Voorheen hadden we een speciale trigger die rapporteerde wanneer iemand een firewallregel handmatig veranderde. Ik was een enorme linter aan het schrijven voor het controleren van de firewallregels, het was moeilijk. Integriteit wordt nu gecontroleerd door BEFW. Hij zorgt er ijverig voor dat de regels die hij maakt niet veranderen. Als iemand de firewallregels wijzigt, verandert alles terug. “Ik heb snel een proxy ingesteld zodat ik vanuit huis kon werken” – dergelijke opties zijn er niet meer.
BEFW bestuurt de ipset van de services en lijst in befw.conf, de regels van services in de BEFW-keten. Maar het houdt geen toezicht op andere ketens, regels en andere ipsets.
Bescherming tegen botsingen
BEFW slaat altijd de laatst bekende goede staat direct op in de binaire structuur state.bin. Als er iets misgaat, keert het altijd terug naar deze state.bin.
Dit is een verzekering tegen een onstabiele Consul-operatie, waarbij er geen gegevens zijn verzonden of iemand een fout heeft gemaakt en regels heeft gebruikt die niet kunnen worden toegepast. Om ervoor te zorgen dat we niet zonder firewall komen te zitten, zal BEFW teruggaan naar de nieuwste status als er op enig moment een fout optreedt.
In kritieke situaties is dit een garantie dat we een werkende firewall overhouden. We openen alle grijze netwerken in de hoop dat de beheerder het komt repareren. Op een dag zal ik dit in de configuraties zetten, maar nu hebben we slechts drie grijze netwerken: 10/8, 172/12 en 192.168/16. Binnen onze Consul is dit een belangrijke functie waarmee wij ons verder kunnen ontwikkelen.
Demo: tijdens de reportage demonstreert Ivan de demomodus van BEFW. Het is gemakkelijker om de demonstratie te bekijken . Demobroncode beschikbaar .
Valkuilen
Ik zal je vertellen over de bugs die we tegenkwamen.
ipset voeg set 0.0.0.0/0 toe. Wat gebeurt er als je 0.0.0.0/0 aan ipset toevoegt? Worden alle IP's toegevoegd? Zal internettoegang beschikbaar zijn?
Nee, we krijgen een bug die ons twee uur downtime kost. Bovendien werkt de bug niet meer sinds 2016, hij bevindt zich in RedHat Bugzilla onder nummer #1297092, en we hebben hem per ongeluk gevonden - uit een rapport van een ontwikkelaar.
Bij BEFW is dat nu een strikte regel 0.0.0.0/0 verandert in twee adressen: 0.0.0.0/1 и 128.0.0.0/1.
ipset herstelset < bestand. Wat doet ipset als u dit zegt? restore? Denk je dat het hetzelfde werkt als iptables? Zal het gegevens herstellen?
Niets van dat alles - het voegt een samenvoeging uit, en de oude adressen gaan nergens heen, je blokkeert de toegang niet.
We hebben een bug gevonden bij het testen van de isolatie. Nu is er een nogal complex systeem - in plaats van restore vastgehouden worden create tempdan restore flush temp и restore temp. Aan het einde van de ruil: voor atomiciteit, want als je het eerst doet flush en op dat moment komt er een pakketje binnen, het wordt weggegooid en er gaat iets mis. Er zit dus een beetje zwarte magie in.
consul kv get -datacenter=andere. Zoals ik al zei, denken we dat we om bepaalde gegevens vragen, maar we krijgen óf gegevens óf een foutmelding. We kunnen dit lokaal via Consul doen, maar in dit geval lopen beide vast.
De lokale Consul-client is een wrapper over de HTTP API. Maar het blijft gewoon hangen en reageert niet alleen op Ctrl+C, of Ctrl+Z, of wat dan ook kill -9 in de volgende console. Wij kwamen dit tegen toen we een groot cluster aan het bouwen waren. Maar we hebben nog geen oplossing; we bereiden ons voor om deze fout in Consul te herstellen.
De consulleider reageert niet. Onze meester in het datacenter reageert niet, wij denken: “Misschien werkt het herselectie-algoritme nu wel?”
Nee, het zal niet werken, en monitoring zal niets opleveren: de consul zal zeggen dat er een commitment-index is, dat er een leider is gevonden, dat alles in orde is.
Hoe gaan wij hiermee om? service consul restart elk uur in cron. Als je 50 servers hebt, is dat geen probleem. Als het er 16 zijn, begrijp je hoe het werkt.
Conclusie
Als gevolg hiervan hebben we de volgende voordelen ontvangen:
- 100% dekking van alle Linux-machines.
- Snelheid.
- Automatisering.
- We hebben hardware- en netwerkingenieurs bevrijd van de slavernij.
- Er zijn integratiemogelijkheden verschenen die vrijwel onbeperkt zijn: zelfs met Kubernetes, zelfs met Ansible, zelfs met Python.
Tegens: Consul, waarmee we nu moeten leven, en de zeer hoge kosten van fouten. Ik was bijvoorbeeld een keer om 6 uur (prime time in Rusland) iets aan het bewerken in de lijsten met netwerken. Bij BEFW waren we destijds net bezig met het bouwen van isolatie. Ik heb ergens een fout gemaakt, het lijkt erop dat ik het verkeerde masker heb aangegeven, maar alles viel binnen twee seconden. De bewaking licht op, de dienstdoende ondersteuner komt aanrennen: “We hebben alles!” Het hoofd van de afdeling werd grijs toen hij aan het bedrijf uitlegde waarom dit gebeurde.
De kosten van fouten zijn zo hoog dat we onze eigen complexe preventieprocedure hebben bedacht. Als je dit op een grote productielocatie implementeert, hoef je niet aan iedereen een mastertoken over Consul te geven. Dit zal slecht aflopen.
Kosten. Ik heb alleen al 400 uur code geschreven. Mijn team van 4 personen besteedt 10 uur per maand aan ondersteuning voor iedereen. Vergeleken met de prijs van elke nieuwe generatie firewall is het gratis.
Plannen. Het langetermijnplan is om alternatief vervoer te vinden ter vervanging of aanvulling van Consul. Misschien wordt het Kafka of iets dergelijks. Maar de komende jaren gaan we op Consul wonen.
Onmiddellijke plannen: integratie met Fail2ban, met monitoring, met nftables, eventueel met andere distributies, metrics, geavanceerde monitoring, optimalisatie. Kubernetes-ondersteuning zit ook ergens in de plannen, want nu hebben we meerdere clusters en de wens.
Meer uit de plannen:
- zoeken naar afwijkingen in het verkeer;
- netwerkkaartbeheer;
- Kubernetes-ondersteuning;
- het samenstellen van pakketten voor alle systemen;
- Web-UI.
We werken voortdurend aan het uitbreiden van de configuratie, het verhogen van de statistieken en optimalisatie.
Sluit je aan bij het project. Het project bleek cool, maar helaas is het nog steeds een eenmansproject. Kom naar en probeer iets te doen: plegen, testen, iets voorstellen, uw oordeel geven.
Ondertussen zijn wij ons aan het voorbereiden , dat zal plaatsvinden op 6 en 7 april in St. Petersburg, en we nodigen ontwikkelaars van systemen met hoge belasting uit . Ervaren sprekers weten al wat ze moeten doen, maar voor degenen die nieuw zijn in het spreken raden we het in ieder geval aan . Als spreker deelnemen aan de conferentie heeft een aantal voordelen. Welke lees je bijvoorbeeld aan het einde .
Bron: www.habr.com