SDSM is voorbij, maar het oncontroleerbare verlangen om te schrijven blijft bestaan.

Jarenlang had onze broer last van het doen van routinewerk, het kruisen van zijn vingers voordat hij iets beging en slaapgebrek vanwege nachtelijke terugdraaiingen.
Maar de donkere tijden komen ten einde.

Met dit artikel begin ik een serie over hoe me automatisering wordt gezien.
Onderweg zullen we de stadia van automatisering begrijpen, variabelen opslaan, ontwerp formaliseren, RestAPI, NETCONF, YANG, YDK en we zullen veel programmeren.
Mij betekent dat a) het geen objectieve waarheid is, b) het niet onvoorwaardelijk de beste aanpak is, c) mijn mening, zelfs tijdens de overgang van het eerste naar het laatste artikel, kan veranderen – om eerlijk te zijn, van de conceptfase naar publicatie, heb ik alles twee keer volledig herschreven.

Inhoud

1. doelen
   1. Het netwerk is als één enkel organisme
   2. Configuratie testen
   3. Versiebeheer
   4. Bewaking en zelfherstel van diensten

2. fondsen
   1. inventaris systeem
   2. Beheersysteem voor IP-ruimte
   3. Netwerkservicebeschrijvingssysteem
   4. Initialisatiemechanisme van het apparaat
   5. Leverancier-onafhankelijk configuratiemodel
   6. Leverancierspecifieke driverinterface
   7. Mechanisme voor het leveren van configuratie aan het apparaat
   8. CI / CD
   9. Mechanisme voor back-up en zoeken naar afwijkingen
   10. Controlesysteem

3. Conclusie

Ik zal proberen ADSM uit te voeren in een formaat dat enigszins verschilt van SDSM. Grote, gedetailleerde, genummerde artikelen zullen blijven verschijnen, en tussendoor zal ik kleine aantekeningen uit de dagelijkse ervaring publiceren. Ik zal proberen het perfectionisme hier te bestrijden en ze niet allemaal te likken.

Hoe grappig is het dat je de tweede keer hetzelfde pad moet doorlopen.

In eerste instantie moest ik zelf artikelen over netwerken schrijven omdat ze niet op RuNet stonden.

Nu kon ik geen alomvattend document vinden dat de benaderingen van automatisering zou systematiseren en de bovengenoemde technologieën zou analyseren aan de hand van eenvoudige praktische voorbeelden.

Ik kan het mis hebben, dus geef links naar nuttige bronnen. Dit zal echter niets veranderen aan mijn vastberadenheid om te schrijven, omdat het hoofddoel is om zelf iets te leren, en het leven gemakkelijker maken voor anderen is een aangename bonus die de genen voor het delen van ervaringen streelt.

We zullen proberen een middelgroot LAN DC-datacenter te nemen en het volledige automatiseringsplan uit te werken.
Sommige dingen ga ik bijna voor het eerst met je doen.

Ik zal niet origineel zijn in de hier beschreven ideeën en hulpmiddelen. Dmitry Figol heeft een uitmuntend kanaal met streams over dit onderwerp.
De artikelen zullen in veel opzichten met hen overlappen.

De LAN DC heeft 4 DC's, ongeveer 250 switches, een half dozijn routers en een paar firewalls.
Geen Facebook, maar genoeg om je diep over automatisering te laten nadenken.
Er is echter de mening dat als je meer dan 1 apparaat hebt, automatisering al nodig is.
Sterker nog, het is moeilijk voor te stellen dat iemand nu zonder op zijn minst een pakje kniescripts kan leven.
Hoewel ik hoorde dat er kantoren zijn waar IP-adressen in Excel worden bijgehouden, en dat elk van de duizenden netwerkapparaten handmatig wordt geconfigureerd en zijn eigen unieke configuratie heeft. Dit kan natuurlijk worden afgeschilderd als moderne kunst, maar de gevoelens van de ingenieur zullen zeker beledigd zijn.

doelen

Nu zullen we de meest abstracte doelen stellen:

• Het netwerk is als één enkel organisme
• Configuratie testen
• Versiebeheer van netwerkstatus
• Bewaking en zelfherstel van diensten

Verderop in dit artikel zullen we bekijken welke middelen we zullen gebruiken, en in het volgende zullen we de doelen en middelen in detail bekijken.

Het netwerk is als één enkel organisme

De bepalende zin van de serie, hoewel deze op het eerste gezicht misschien niet zo belangrijk lijkt: we zullen het netwerk configureren, niet individuele apparaten.
De afgelopen jaren hebben we een accentverschuiving gezien in de richting van het behandelen van het netwerk als één enkele entiteit Software Defined Networking, Intentiegedreven netwerken и Autonome netwerken.
Wat hebben applicaties immers mondiaal nodig van het netwerk: connectiviteit tussen de punten A en B (nou ja, soms +B-Z) en isolatie van andere applicaties en gebruikers.

En dat is dus onze taak in deze serie bouw een systeem, waarbij de huidige configuratie behouden blijft het hele netwerk, die al is ontleed in de daadwerkelijke configuratie op elk apparaat in overeenstemming met zijn rol en locatie.
Systeem netwerkbeheer houdt in dat we contact met het netwerk opnemen om wijzigingen aan te brengen, en het berekent op zijn beurt de gewenste status voor elk apparaat en configureert het.
Op deze manier minimaliseren we de handmatige toegang tot de CLI tot vrijwel nul - eventuele wijzigingen in apparaatinstellingen of netwerkontwerp moeten worden geformaliseerd en gedocumenteerd - en pas daarna uitgerold naar de noodzakelijke netwerkelementen.

Dat wil zeggen, als we bijvoorbeeld zouden besluiten dat rackswitches in Kazan voortaan twee netwerken moeten aankondigen in plaats van één, wij

1. Eerst documenteren we wijzigingen in systemen
2. Het genereren van de doelconfiguratie van alle netwerkapparaten
3. We starten het updateprogramma voor de netwerkconfiguratie, dat berekent wat er op elk knooppunt moet worden verwijderd, wat moet worden toegevoegd en dat de knooppunten in de gewenste staat brengt.

Tegelijkertijd brengen we alleen in de eerste stap handmatig wijzigingen aan.

Configuratie testen

Bekenddat 80% van de problemen zich voordoen tijdens configuratiewijzigingen - indirect bewijs hiervan is dat tijdens de nieuwjaarsvakantie alles meestal rustig is.
Ik ben persoonlijk getuige geweest van tientallen wereldwijde downtimes als gevolg van menselijke fouten: het verkeerde commando, de configuratie werd in de verkeerde branch uitgevoerd, de gemeenschap vergat het, MPLS werd wereldwijd op de router afgebroken, er werden vijf stukken hardware geconfigureerd, maar de fout werd niet uitgevoerd. opgemerkt op de zesde, werden oude wijzigingen aangebracht die door een andere persoon waren aangebracht. Er zijn een heleboel scenario's.

Automatisering zal ons in staat stellen minder fouten te maken, maar op grotere schaal. Zo kun je niet slechts één apparaat, maar het hele netwerk in één keer bricken.

Sinds onheuglijke tijden controleerden onze grootvaders met een scherp oog de juistheid van de aangebrachte wijzigingen, stalen ballen en de functionaliteit van het netwerk nadat deze waren uitgerold.
De grootvaders wier werk tot stilstand en catastrofale verliezen leidde, lieten minder nakomelingen na en zouden na verloop van tijd moeten uitsterven, maar evolutie is een langzaam proces en daarom test niet iedereen nog steeds eerst veranderingen in het laboratorium.
Vooraan in de vooruitgang staan ​​echter degenen die het proces van het testen van de configuratie en de verdere toepassing ervan op het netwerk hebben geautomatiseerd. Met andere woorden, ik heb de CI/CD-procedure geleend (Continue integratie, continue implementatie) van de ontwikkelaars.
In een van de delen zullen we bekijken hoe we dit kunnen implementeren met behulp van een versiebeheersysteem, waarschijnlijk Github.

Als je eenmaal gewend bent aan het idee van netwerk-CI/CD, zal de methode om een ​​configuratie te controleren door deze toe te passen op een productienetwerk van de ene op de andere dag een vroegmiddeleeuwse onwetendheid lijken. Alsof je met een hamer op een kernkop slaat.

Een organische voortzetting van ideeën over systeem netwerkbeheer en CI/CD worden een volledig versiebeheer van de configuratie.

Versiebeheer

We gaan ervan uit dat bij elke verandering, zelfs de kleinste, zelfs op één onmerkbaar apparaat, het hele netwerk van de ene toestand naar de andere gaat.
En we voeren altijd geen commando uit op het apparaat, we veranderen de status van het netwerk.
Dus laten we deze statenversies noemen?

Laten we zeggen dat de huidige versie 1.0.0 is.
Is het IP-adres van de Loopback-interface op een van de ToR's gewijzigd? Dit is een secundaire versie en krijgt nummer 1.0.1.
We hebben het beleid voor het importeren van routes in BGP - iets serieuzer - al 1.1.0 herzien
We hebben besloten om van IGP af te komen en alleen naar BGP over te stappen - dit is al een radicale ontwerpwijziging - 2.0.0.

Tegelijkertijd kunnen verschillende DC's verschillende versies hebben - het netwerk ontwikkelt zich, er wordt nieuwe apparatuur geïnstalleerd, ergens worden nieuwe niveaus van stekels toegevoegd, niet in andere, enz.

Про semantisch versiebeheer we zullen in een apart artikel praten.

Ik herhaal: elke wijziging (behalve de foutopsporingsopdrachten) is een versie-update. Beheerders moeten op de hoogte worden gesteld van eventuele afwijkingen van de huidige versie.

Hetzelfde geldt voor het terugdraaien van wijzigingen - dit is niet het annuleren van de laatste opdrachten, dit is geen terugdraaien via het besturingssysteem van het apparaat - dit brengt het hele netwerk naar een nieuwe (oude) versie.

Bewaking en zelfherstel van diensten

Deze vanzelfsprekende taak heeft in moderne netwerken een nieuw niveau bereikt.
Vaak gaan grote dienstverleners ervan uit dat een defecte dienst zeer snel moet worden gerepareerd en een nieuwe moet worden opgestart, in plaats van uit te zoeken wat er is gebeurd.
'Zeer' betekent dat u aan alle kanten royaal moet worden gecoat met monitoring, die binnen enkele seconden de kleinste afwijkingen van de norm zal detecteren.
En hier zijn de gebruikelijke statistieken, zoals het laden van de interface of de beschikbaarheid van knooppunten, niet langer voldoende. Ook het handmatig monitoren ervan door de dienstdoende officier is niet voldoende.
Voor veel dingen zou dat zo moeten zijn Zelfgenezing – de controlelichten werden rood en we gingen zelf de weegbree aanbrengen waar het pijn deed.

En hier monitoren we ook niet alleen individuele apparaten, maar ook de gezondheid van het hele netwerk, zowel whitebox, wat relatief begrijpelijk is, als blackbox, wat ingewikkelder is.

Wat hebben we nodig om zulke ambitieuze plannen uit te voeren?

• Zorg voor een lijst met alle apparaten op het netwerk, hun locatie, rollen, modellen en softwareversies.
  kazan-leaf-1.lmu.net, Kazan, blad, Juniper QFX 5120, R18.3.
• Zorg voor een systeem voor het beschrijven van netwerkdiensten.
  IGP, BGP, L2/3VPN, beleid, ACL, NTP, SSH.
• Het apparaat kunnen initialiseren.
  Hostnaam, Beheerder IP, Beheerroute, Gebruikers, RSA-sleutels, LLDP, NETCONF
• Configureer het apparaat en breng de configuratie naar de gewenste (inclusief oude) versie.
• Configuratie testen
• Controleer periodiek de status van alle apparaten op afwijkingen van de huidige en meld aan wie dit moet zijn.
  Van de ene op de andere dag heeft iemand stilletjes een regel aan de ACL toegevoegd.
• Bewaak de prestaties.

fondsen

Het klinkt ingewikkeld genoeg om het project in componenten op te splitsen.

En er zullen er tien zijn:

1. inventaris systeem
2. Beheersysteem voor IP-ruimte
3. Netwerkservicebeschrijvingssysteem
4. Initialisatiemechanisme van het apparaat
5. Leverancier-onafhankelijk configuratiemodel
6. Leverancierspecifieke driverinterface
7. Mechanisme voor het leveren van configuratie aan het apparaat
8. CI / CD
9. Mechanisme voor back-up en zoeken naar afwijkingen
10. Controlesysteem

Dit is trouwens een voorbeeld van hoe de kijk op de doelstellingen van de cyclus veranderde - er waren 4 componenten in het ontwerp.

In de illustratie heb ik alle componenten en het apparaat zelf afgebeeld.
Kruisende componenten interageren met elkaar.
Hoe groter het blok, hoe meer aandacht aan dit onderdeel moet worden besteed.

Component 1: Voorraadsysteem

Uiteraard willen wij weten welke apparatuur waar staat, waar op aangesloten is.
Het voorraadsysteem is een integraal onderdeel van elke onderneming.
Meestal heeft een onderneming een apart inventarisatiesysteem voor netwerkapparaten, dat meer specifieke problemen oplost.
Als onderdeel van deze serie artikelen zullen we het DCIM noemen: Data Center Infrastructure Management. Hoewel de term DCIM zelf strikt genomen veel meer omvat.

Voor onze doeleinden slaan wij de volgende informatie over het apparaat daarin op:

• Inventaris nummer
• Titel beschrijving
• Model (Huawei CE12800, Jeneverbes QFX5120, enz.)
• Karakteristieke parameters (borden, interfaces, enz.)
• Rol (Blad-, ruggengraat-, grensrouter, enz.)
• Plaats (regio, stad, datacenter, rack, eenheid)
• Interconnecties tussen apparaten
• Netwerk topologie

Het is volkomen duidelijk dat wij dit allemaal zelf willen weten.
Maar zal dit helpen voor automatiseringsdoeleinden?
Zeker.
We weten bijvoorbeeld dat in een bepaald datacenter op Leaf-switches, als het Huawei is, ACL's om bepaald verkeer te filteren moeten worden toegepast op het VLAN, en als het Juniper is, dan op eenheid 0 van de fysieke interface.
Of u moet een nieuwe Syslog-server uitrollen naar alle grenzen in de regio.

Daarin slaan we virtuele netwerkapparaten op, bijvoorbeeld virtuele routers of rootreflectoren. We kunnen DNS-servers, NTP, Syslog en in het algemeen alles toevoegen dat op de een of andere manier met het netwerk te maken heeft.

Component 2: IP-ruimtebeheersysteem

Ja, en tegenwoordig zijn er teams van mensen die voorvoegsels en IP-adressen bijhouden in een Excel-bestand. Maar de moderne aanpak is nog steeds een database, met een front-end op nginx/apache, API en uitgebreide functies voor het vastleggen van IP-adressen en netwerken onderverdeeld in VRF’s.
IPAM - IP-adresbeheer.

Voor onze doeleinden slaan wij daarin de volgende gegevens op:

• VLAN
• VRF-extensie
• Netwerken/subnetten
• IP-adressen
• Binden van adressen aan apparaten, netwerken aan locaties en VLAN-nummers

Nogmaals, het is duidelijk dat we er zeker van willen zijn dat wanneer we een nieuw IP-adres voor de ToR-loopback toewijzen, we niet zullen struikelen over het feit dat het al aan iemand is toegewezen. Of dat we hetzelfde voorvoegsel twee keer aan verschillende uiteinden van het netwerk hebben gebruikt.
Maar hoe helpt dit bij automatisering?
Gemakkelijk.
We vragen een voorvoegsel aan in het systeem met de Loopbacks-rol, die IP-adressen bevat die beschikbaar zijn voor toewijzing. Als dit wordt gevonden, wijzen we het adres toe, zo niet, dan vragen we om de aanmaak van een nieuw voorvoegsel.
Of bij het maken van een apparaatconfiguratie kunnen we vanuit hetzelfde systeem achterhalen in welke VRF de interface zich zou moeten bevinden.
En bij het starten van een nieuwe server logt het script in op het systeem, zoekt uit in welke switch de server zich bevindt, welke poort en welk subnet aan de interface is toegewezen - en wijst daaruit het serveradres toe.

Dit suggereert een wens om DCIM en IPAM in één systeem te combineren om geen dubbele functies te hebben en geen twee vergelijkbare entiteiten te bedienen.
Dat is wat we zullen doen.

Component 3. Systeem voor het beschrijven van netwerkdiensten

Als de eerste twee systemen variabelen opslaan die op de een of andere manier nog moeten worden gebruikt, beschrijft het derde voor elke apparaatrol hoe deze moet worden geconfigureerd.
Het is de moeite waard om twee verschillende soorten netwerkdiensten te onderscheiden:

• Infrastructuur
• Cliënt.

De eerste zijn ontworpen om basisconnectiviteit en apparaatbediening te bieden. Deze omvatten VTY, SNMP, NTP, Syslog, AAA, routeringsprotocollen, CoPP, enz.
Deze laatste organiseren de service voor de klant: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, enz.
Natuurlijk zijn er ook grensgevallen: waar moeten MPLS, LDP, BGP worden opgenomen? Ja, en routeringsprotocollen kunnen voor clients worden gebruikt. Maar dit is niet belangrijk.

Beide soorten services worden opgesplitst in configuratieprimitieven:

• fysieke en logische interfaces (tag/anteg, mtu)
• IP-adressen en VRF's (IP, IPv6, VRF)
• ACL's en beleid voor verkeersverwerking
• Protocollen (IGP, BGP, MPLS)
• Routingbeleid (voorvoegsellijsten, community's, ASN-filters).
• Nutsdiensten (SSH, NTP, LLDP, Syslog...)
• Enz.

Hoe we dit precies gaan doen, heb ik nog geen idee. We zullen er in een apart artikel naar kijken.

Als we iets dichter bij het leven zouden staan, zouden we dat kunnen beschrijven
De Leaf-switch moet BGP-sessies hebben met alle verbonden Spine-switches, aangesloten netwerken in het proces importeren en alleen netwerken met een bepaald voorvoegsel van Spine-switches accepteren. Beperk CoPP IPv6 ND tot 10 pps, enz.
Op hun beurt houden stekels sessies met alle verbonden leads, fungeren als wortelreflectoren, en accepteren van hen alleen routes van een bepaalde lengte en met een bepaalde gemeenschap.

Component 4: Apparaatinitialisatiemechanisme

Onder dit kopje combineer ik veel van de acties die moeten plaatsvinden voordat een apparaat op de radar verschijnt en op afstand toegankelijk is.

1. Voer het apparaat in het inventarisatiesysteem in.
2. Selecteer een beheer-IP-adres.
3. Stel basistoegang daartoe in:
   Hostnaam, beheer-IP-adres, route naar het beheernetwerk, gebruikers, SSH-sleutels, protocollen - telnet/SSH/NETCONF

Er zijn drie benaderingen:

• Alles is volledig handmatig. Het apparaat wordt naar de stand gebracht, waar een gewoon organisch persoon het in de systemen invoert, verbinding maakt met de console en configureert. Kan werken op kleine statische netwerken.
• ZTP - Zero Touch-inrichting. De hardware arriveerde, stond op, kreeg een adres via DHCP, ging naar een speciale server en configureerde zichzelf.
• De infrastructuur van consoleservers, waarbij de initiële configuratie plaatsvindt via de consolepoort in automatische modus.

We zullen over alle drie praten in een apart artikel.

Component 5: Leverancier-onafhankelijk configuratiemodel

Tot nu toe waren alle systemen ongelijksoortige patches die variabelen en een declaratieve beschrijving gaven van wat we graag op het netwerk zouden willen zien. Maar vroeg of laat krijgt u te maken met specifieke details.
In dit stadium worden voor elk specifiek apparaat primitieven, services en variabelen gecombineerd tot een configuratiemodel dat feitelijk de volledige configuratie van een specifiek apparaat beschrijft, alleen op een leveranciersneutrale manier.
Wat doet deze stap? Waarom maakt u niet meteen een apparaatconfiguratie die u eenvoudig kunt uploaden?
In feite lost dit drie problemen op:

1. Pas u niet aan een specifieke interface aan voor interactie met het apparaat. Of het nu CLI, NETCONF, RESTCONF, SNMP is - het model zal hetzelfde zijn.
2. Houd het aantal sjablonen/scripts niet aan op basis van het aantal leveranciers op het netwerk, en als het ontwerp verandert, verander dan hetzelfde op verschillende plaatsen.
3. Laad de configuratie vanaf het apparaat (back-up), plaats deze in exact hetzelfde model en vergelijk de doelconfiguratie direct met de bestaande om de delta te berekenen en een configuratiepatch voor te bereiden die alleen die onderdelen verandert die nodig zijn of om afwijkingen te identificeren.

Als resultaat van deze fase verkrijgen we een leverancier-onafhankelijke configuratie.

Component 6. Leverancierspecifieke driverinterface

Je moet jezelf niet vleien met de hoop dat het op een dag mogelijk zal zijn om een ​​ciska op precies dezelfde manier te configureren als een Juniper, simpelweg door er precies dezelfde oproepen naar te sturen. Ondanks de groeiende populariteit van whiteboxen en de opkomst van ondersteuning voor NETCONF, RESTCONF en OpenConfig, verschilt de specifieke inhoud die deze protocollen leveren van leverancier tot leverancier, en dit is een van hun concurrentieverschillen die ze niet zo gemakkelijk zullen opgeven.
Dit is ongeveer hetzelfde als OpenContrail en OpenStack, die RestAPI als hun NorthBound-interface hebben, totaal andere oproepen verwachten.

Dus in de vijfde stap moet het leveranciersonafhankelijke model de vorm aannemen waarin het naar hardware zal gaan.
En hier zijn alle middelen goed (niet): CLI, NETCONF, RESTCONF, SNMP gewoon.

Daarom hebben we een stuurprogramma nodig dat het resultaat van de vorige stap overzet naar het vereiste formaat van een specifieke leverancier: een set CLI-opdrachten, een XML-structuur.

Component 7. Mechanisme voor het leveren van configuratie aan het apparaat

We hebben de configuratie gegenereerd, maar deze moet nog op de apparaten worden afgeleverd - en uiteraard niet met de hand.
In de eerste plaatsworden we geconfronteerd met de vraag welk transport we zullen gebruiken? En vandaag is de keuze niet langer klein:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (hoewel het een uitbijter is omdat het een manier is om FIB te leveren, geen instellingen)

Laten we de puntjes op de i zetten. CLI is verouderd. SNMP... hoest hoest.
RESTCONF is nog een onbekend dier; de REST API wordt door vrijwel niemand ondersteund. Daarom zullen we ons in de serie concentreren op NETCONF.

Zoals de lezer al heeft begrepen, hebben we op dit punt al een beslissing genomen over de interface - het resultaat van de vorige stap wordt al gepresenteerd in het formaat van de gekozen interface.

In de tweede plaats, en met welke tools gaan we dit doen?
Ook hier is de keuze groot:

• Zelfgeschreven script of platform. Laten we ons bewapenen met ncclient en asyncIO en alles zelf doen. Wat kost het ons om een ​​implementatiesysteem helemaal opnieuw op te bouwen?
• Ansible met zijn rijke bibliotheek met netwerkmodules.
• Zout met zijn magere werk met het netwerk en verbinding met Napalm.
• Eigenlijk Napalm, die een paar leveranciers kent en dat is alles, tot ziens.
• Nornir is een ander dier dat we in de toekomst zullen ontleden.

Hier is de favoriet nog niet gekozen - we gaan zoeken.

Wat is hier nog meer belangrijk? Gevolgen van het toepassen van de configuratie.
Succesvol of niet. Is er nog toegang tot de hardware of niet?
Het lijkt erop dat commit hier zal helpen met bevestiging en validatie van wat naar het apparaat is gedownload.
Dit, gecombineerd met de correcte implementatie van NETCONF, verkleint het aantal geschikte apparaten aanzienlijk - niet veel fabrikanten ondersteunen normale commits. Maar dit is slechts een van de voorwaarden voor een RFP. Uiteindelijk maakt niemand zich zorgen dat geen enkele Russische leverancier zal voldoen aan de 32*100GE-interfacevoorwaarde. Of maakt hij zich zorgen?

Component 8. CI/CD

Op dit moment hebben we de configuratie al klaar voor alle netwerkapparaten.
Ik schrijf “voor alles” omdat we het hebben over het versiebeheer van de netwerkstatus. En zelfs als u de instellingen van slechts één switch moet wijzigen, worden de wijzigingen voor het hele netwerk berekend. Het is duidelijk dat ze voor de meeste knooppunten nul kunnen zijn.

Maar zoals hierboven al werd gezegd, wij zijn geen soort barbaren die alles meteen in productie willen rollen.
De gegenereerde configuratie moet eerst via Pipeline CI/CD gaan.

CI/CD staat voor Continuous Integration, Continuous Deployment. Dit is een aanpak waarbij het team niet alleen elke zes maanden een nieuwe grote release uitbrengt, die de oude volledig vervangt, maar regelmatig stapsgewijs nieuwe functionaliteit in kleine porties implementeert (Deployment), die elk uitgebreid worden getest op compatibiliteit, beveiliging en veiligheid. prestaties (integratie).

Hiervoor hebben we een versiebeheersysteem dat configuratiewijzigingen monitort, een laboratorium dat controleert of de klantenservice kapot is, een monitoringsysteem dat dit controleert en als laatste stap het uitrollen van wijzigingen in het productienetwerk.

Met uitzondering van de debugging-opdrachten moeten absoluut alle veranderingen op het netwerk via de CI/CD Pipeline gaan - dit is onze garantie voor een rustig leven en een lange, gelukkige carrière.

Component 9. Systeem voor back-up- en anomaliedetectie

Nou, het is niet nodig om nog een keer over back-ups te praten.
We zullen ze eenvoudigweg in git plaatsen op basis van de kroon of op basis van een configuratiewijziging.

Maar het tweede deel is interessanter: iemand moet deze back-ups in de gaten houden. En in sommige gevallen moet deze iemand alles omdraaien zoals het was, en in andere gevallen miauwen tegen iemand dat er iets mis is.
Als er bijvoorbeeld een nieuwe gebruiker is verschenen die niet in de variabelen is geregistreerd, moet u hem uit de hack verwijderen. En als het beter is om een ​​nieuwe firewallregel niet aan te raken, heeft iemand misschien gewoon foutopsporing ingeschakeld, of misschien is de nieuwe dienst, een knoeier, niet geregistreerd volgens de regelgeving, maar zijn er al mensen lid van geworden.

We ontkomen nog steeds niet aan een kleine delta op de schaal van het hele netwerk, ondanks eventuele automatiseringssystemen en de stalen hand van het management. Om problemen op te lossen, zal niemand sowieso configuratie aan de systemen toevoegen. Bovendien zijn ze mogelijk niet eens opgenomen in het configuratiemodel.

Een firewallregel voor het tellen van het aantal pakketten per specifiek IP-adres om een ​​probleem te lokaliseren is bijvoorbeeld een volkomen gewone tijdelijke configuratie.

Component 10. Monitoringsysteem

In eerste instantie was ik niet van plan het onderwerp monitoring te bespreken; het is nog steeds een omvangrijk, controversieel en complex onderwerp. Maar naarmate de zaken vorderden, bleek dat dit een integraal onderdeel van de automatisering was. En het is onmogelijk om het te omzeilen, zelfs zonder oefening.

Evoluerend denken is een organisch onderdeel van het CI/CD-proces. Nadat we de configuratie op het netwerk hebben uitgerold, moeten we kunnen vaststellen of alles nu in orde is.
En we hebben het niet alleen en niet zozeer over interfacegebruiksschema's of knooppuntbeschikbaarheid, maar over subtielere dingen: de aanwezigheid van de noodzakelijke routes, attributen daarop, het aantal BGP-sessies, OSPF-buren, end-to-end-prestaties van bovenliggende diensten.
Zijn de syslogs naar de externe server gestopt met het optellen, of is de SFlow-agent kapot gegaan, of zijn de dalingen in de wachtrijen beginnen te groeien, of is de connectiviteit tussen een paar voorvoegsels verbroken?

We zullen hier in een apart artikel op reflecteren.

Conclusie

Als basis heb ik een van de moderne datacenternetwerkontwerpen gekozen: L3 Clos Fabric met BGP als routeringsprotocol.
Deze keer bouwen we het netwerk op Juniper, omdat de JunOs-interface nu een vanlove is.

Laten we ons leven moeilijker maken door alleen Open Source-tools en een netwerk van meerdere leveranciers te gebruiken. Dus naast Juniper kies ik onderweg nog een gelukkig persoon.

Het plan voor komende publicaties ziet er ongeveer zo uit:
Eerst zal ik het hebben over virtuele netwerken. Ten eerste omdat ik dat wil, en ten tweede omdat zonder dit het ontwerp van het infrastructuurnetwerk niet erg duidelijk zal zijn.
Dan over het netwerkontwerp zelf: topologie, routing, beleid.
Laten we een laboratoriumstandaard samenstellen.
Laten we erover nadenken en misschien oefenen met het initialiseren van het apparaat op het netwerk.
En dan over elk onderdeel tot in de kleinste details.

En ja, ik beloof niet dat ik deze cyclus netjes zal beëindigen met een kant-en-klare oplossing. 🙂

Nuttige links

• Voordat je je in de serie verdiept, is het de moeite waard om het boek van Natasha Samoilenko te lezen Python voor netwerkingenieurs. En misschien passeren cursus.
• Het zal ook nuttig zijn om te lezen RFC over het ontwerp van datacenterfabrieken van Facebook door Peter Lapukhov.
• De architectuurdocumentatie geeft u een idee van hoe Overlay SDN werkt. Wolfraam stof (voorheen Open Contrail).

Bedankt

Romeinse kloof. Voor opmerkingen en bewerkingen.
Artjom Tsjernobaai. Voor KDPV.

Bron: www.habr.com