SDSM är över, men den okontrollerbara lusten att skriva finns kvar.

I många år led vår bror av att göra rutinarbete, att hålla tummarna innan han förpliktade sig och sömnbrist på grund av nattliga rullningar.
Men de mörka tiderna går mot sitt slut.

Med den här artikeln börjar jag en serie om hur mig automatisering ses.
Längs vägen kommer vi att förstå stadierna av automatisering, lagring av variabler, formalisering av design, RestAPI, NETCONF, YANG, YDK och vi kommer att göra mycket programmering.
Jag betyder att a) det inte är en objektiv sanning, b) det är inte villkorslöst det bästa tillvägagångssättet, c) min åsikt, även under rörelsen från den första till den sista artikeln, kan förändras - om jag ska vara ärlig, från utkaststadiet till publicering, jag skrev om allting helt två gånger.

Innehåll

1. mål
   1. Nätverket är som en enda organism
   2. Konfigurationstestning
   3. Versionering
   4. Övervakning och självläkning av tjänster

2. fonder
   1. Inventeringssystem
   2. IP-utrymmeshanteringssystem
   3. System för beskrivning av nätverkstjänster
   4. Enhetsinitieringsmekanism
   5. Leverantör-agnostisk konfigurationsmodell
   6. Leverantörsspecifikt drivrutinsgränssnitt
   7. Mekanism för att leverera konfiguration till enheten
   8. CI / CD
   9. Mekanism för backup och sökning efter avvikelser
   10. Övervakningssystem

3. Slutsats

Jag ska försöka genomföra ADSM i ett format som skiljer sig något från SDSM. Stora, detaljerade, numrerade artiklar kommer att fortsätta dyka upp, och mellan dem kommer jag att publicera små anteckningar från vardagsupplevelsen. Jag ska försöka bekämpa perfektionism här och inte slicka varenda en av dem.

Vad roligt det är att andra gången måste man gå samma väg.

Först var jag tvungen att skriva artiklar om nätverk själv på grund av att de inte fanns på RuNet.

Nu kunde jag inte hitta ett heltäckande dokument som skulle systematisera metoder för automatisering och analysera ovanstående teknologier med hjälp av enkla praktiska exempel.

Jag kan ha fel, så ange länkar till användbara resurser. Detta kommer dock inte att ändra min beslutsamhet att skriva, eftersom huvudmålet är att lära mig något själv, och att göra livet lättare för andra är en trevlig bonus som smeker genen för att dela erfarenheter.

Vi kommer att försöka ta ett medelstort LAN DC-datacenter och arbeta fram hela automationsschemat.
Jag kommer att göra några saker nästan för första gången med dig.

Jag kommer inte att vara original i de idéer och verktyg som beskrivs här. Dmitry Figol har en utmärkt kanal med strömmar om detta ämne.
Artiklarna kommer att överlappa dem i många aspekter.

LAN DC har 4 DC, cirka 250 switchar, ett halvdussin routrar och ett par brandväggar.
Inte Facebook, men tillräckligt för att du ska tänka djupt på automatisering.
Det finns dock en åsikt att om du har mer än 1 enhet behövs redan automatisering.
Faktum är att det är svårt att föreställa sig att vem som helst nu kan leva utan åtminstone ett paket knä-manus.
Även om jag hörde att det finns kontor där IP-adresser hålls i Excel, och var och en av de tusentals nätverksenheterna är konfigurerade manuellt och har sin egen unika konfiguration. Detta kan naturligtvis framstå som modern konst, men ingenjörens känslor kommer definitivt att bli förolämpade.

mål

Nu kommer vi att sätta de mest abstrakta målen:

• Nätverket är som en enda organism
• Konfigurationstestning
• Nätverksstatusversionering
• Övervakning och självläkning av tjänster

Senare i den här artikeln kommer vi att titta på vilka medel vi kommer att använda, och i det följande kommer vi att titta på målen och medlen i detalj.

Nätverket är som en enda organism

Seriens definierande fras, även om det vid första anblicken kanske inte verkar så betydelsefullt: vi kommer att konfigurera nätverket, inte enskilda enheter.
Under de senaste åren har vi sett en förändring i tyngdpunkten mot att behandla nätverket som en enda enhet, därav Programvarudefinierat nätverk, Avsiktsdrivna nätverk и Autonoma nätverk.
När allt kommer omkring, vad behöver applikationer globalt från nätverket: anslutning mellan punkterna A och B (nåja, ibland +B-Z) och isolering från andra applikationer och användare.

Och så är vår uppgift i den här serien bygga ett system, bibehålla den nuvarande konfigurationen hela nätverket, som redan är uppdelad i den faktiska konfigurationen på varje enhet i enlighet med dess roll och plats.
System nätverkshantering innebär att vi kontaktar den för att göra ändringar, och den i sin tur beräknar önskat tillstånd för varje enhet och konfigurerar det.
På så sätt minimerar vi manuell åtkomst till CLI till nästan noll - eventuella ändringar i enhetsinställningar eller nätverksdesign måste formaliseras och dokumenteras - och först därefter rullas ut till de nödvändiga nätverkselementen.

Det vill säga, om vi till exempel bestämde oss för att från och med nu rackswitchar i Kazan ska meddela två nätverk istället för ett,

1. Först dokumenterar vi förändringar i system
2. Genererar målkonfigurationen för alla nätverksenheter
3. Vi lanserar uppdateringsprogrammet för nätverkskonfiguration, som beräknar vad som behöver tas bort på varje nod, vad som ska läggas till och för noderna till önskat tillstånd.

Samtidigt gör vi ändringar manuellt endast i första steget.

Konfigurationstestning

Kändatt 80 % av problemen uppstår under konfigurationsändringar - indirekta bevis på detta är att under nyårshelgerna är allt vanligtvis lugnt.
Jag har personligen sett dussintals globala driftstopp på grund av mänskliga fel: fel kommando, konfigurationen utfördes i fel gren, samhället glömde, MPLS revs globalt på routern, fem hårdvara konfigurerades, men felet var inte märkte den sjätte, gamla ändringar som gjorts av en annan person begicks. Det finns massor av scenarier.

Automatisering gör att vi kan göra färre misstag, men i större skala. På så sätt kan du bygga ut inte bara en enhet utan hela nätverket på en gång.

Sedan urminnes tider kontrollerade våra farfäder riktigheten av de ändringar som gjordes med ett skarpt öga, stålkulor och nätverkets funktionalitet efter att de rullats ut.
De farfäder vars arbete ledde till stillestånd och katastrofala förluster lämnade färre avkommor och borde dö ut med tiden, men evolutionen är en långsam process, och därför testar inte alla fortfarande förändringar i laboratoriet först.
Men i framkanten av framstegen är de som har automatiserat processen att testa konfigurationen och dess vidare tillämpning på nätverket. Med andra ord, jag lånade CI/CD-proceduren (Kontinuerlig integration, kontinuerlig implementering) från utvecklarna.
I en av delarna kommer vi att titta på hur man implementerar detta med hjälp av ett versionskontrollsystem, troligen Github.

När du väl har vant dig vid idén med nätverks-CI/CD, över en natt kommer metoden att kontrollera en konfiguration genom att tillämpa den på ett produktionsnätverk att verka som tidig medeltida okunskap. Ungefär som att slå en stridsspets med en hammare.

En organisk fortsättning på idéer om systemet nätverkshantering och CI/CD blir en fullständig versionering av konfigurationen.

Versionering

Vi kommer att anta att med alla ändringar, även de minsta, även på en omärklig enhet, flyttar hela nätverket från ett tillstånd till ett annat.
Och vi utför alltid inte ett kommando på enheten, vi ändrar nätverkets tillstånd.
Så låt oss kalla dessa stater versioner?

Låt oss säga att den nuvarande versionen är 1.0.0.
Har IP-adressen för Loopback-gränssnittet på en av ToR:erna ändrats? Detta är en mindre version och kommer att numreras 1.0.1.
Vi reviderade policyerna för import av rutter till BGP - lite mer seriöst - redan 1.1.0
Vi bestämde oss för att bli av med IGP och byta till endast BGP - detta är redan en radikal designändring - 2.0.0.

Samtidigt kan olika DCs ha olika versioner - nätverket utvecklas, ny utrustning installeras, nya nivåer av spines läggs till någonstans, inte i andra, etc.

Про semantisk versionering vi kommer att prata i en separat artikel.

Jag upprepar - alla ändringar (förutom felsökningskommandon) är en versionsuppdatering. Administratörer måste underrättas om eventuella avvikelser från den aktuella versionen.

Detsamma gäller för att återställa ändringar - det här är inte att avbryta de senaste kommandona, detta är inte en återställning med enhetens operativsystem - detta tar hela nätverket till en ny (gammal) version.

Övervakning och självläkning av tjänster

Denna självklara uppgift har nått en ny nivå i moderna nätverk.
Ofta tar stora tjänsteleverantörer tillvägagångssättet att en misslyckad tjänst måste åtgärdas mycket snabbt och en ny höjas, istället för att ta reda på vad som hände.
"Mycket" betyder att du behöver vara generöst belagd på alla sidor med övervakning, som inom några sekunder kommer att upptäcka de minsta avvikelser från normen.
Och här räcker inte längre de vanliga måtten, som gränssnittsladdning eller nodtillgänglighet. Det räcker inte heller med manuell övervakning av dem av vakthavande befäl.
För många saker borde det finnas Självläkning — övervakningsljusen blev röda och vi gick och applicerade själv groblad där det gjorde ont.

Och här övervakar vi inte bara enskilda enheter utan även hela nätverkets hälsa, både whitebox, vilket är relativt förståeligt, och blackbox, som är mer komplicerat.

Vad kommer vi att behöva för att genomföra sådana ambitiösa planer?

• Ha en lista över alla enheter i nätverket, deras plats, roller, modeller, programvaruversioner.
  kazan-leaf-1.lmu.net, Kazan, blad, Juniper QFX 5120, R18.3.
• Ha ett system för att beskriva nätverkstjänster.
  IGP, BGP, L2/3VPN, Policy, ACL, NTP, SSH.
• Kunna initiera enheten.
  Värdnamn, Mgmt IP, Mgmt Route, Användare, RSA-nycklar, LLDP, NETCONF
• Konfigurera enheten och föra konfigurationen till önskad (inklusive gammal) version.
• Testa konfiguration
• Kontrollera med jämna mellanrum status för alla enheter för avvikelser från de nuvarande och rapportera till vem det ska vara.
  Över natten lade någon tyst till en regel till ACL.
• Övervaka prestanda.

fonder

Det låter komplicerat nog att börja bryta ned projektet i komponenter.

Och det kommer att bli tio av dem:

1. Inventeringssystem
2. IP-utrymmeshanteringssystem
3. System för beskrivning av nätverkstjänster
4. Enhetsinitieringsmekanism
5. Leverantör-agnostisk konfigurationsmodell
6. Leverantörsspecifikt drivrutinsgränssnitt
7. Mekanism för att leverera konfiguration till enheten
8. CI / CD
9. Mekanism för backup och sökning efter avvikelser
10. Övervakningssystem

Detta är för övrigt ett exempel på hur synen på målen för cykeln förändrades - det fanns 4 komponenter i utkastet.

I illustrationen avbildade jag alla komponenter och själva enheten.
Korsande komponenter interagerar med varandra.
Ju större blocket är, desto mer uppmärksamhet måste ägnas åt denna komponent.

Komponent 1: Inventeringssystem

Självklart vill vi veta vilken utrustning som finns var, vad som är ansluten till.
Lagersystemet är en integrerad del av alla företag.
Oftast har ett företag ett separat inventeringssystem för nätverksenheter, som löser mer specifika problem.
Som en del av denna artikelserie kommer vi att kalla det DCIM – Data Center Infrastructure Management. Även om själva termen DCIM strängt taget innehåller mycket mer.

För våra ändamål kommer vi att lagra följande information om enheten i den:

• Lagernummer
• Titel Beskrivning
• Modell (Huawei CE12800, Juniper QFX5120, etc.)
• Karakteristiska parametrar (kort, gränssnitt etc.)
• Roll (Löv, Spine, Border Router, etc.)
• Plats (region, stad, datacenter, rack, enhet)
• Sammankopplingar mellan enheter
• Nätverks topologi

Det är helt klart att vi själva vill veta allt detta.
Men kommer detta att hjälpa i automatiseringssyfte?
Självklart.
Till exempel vet vi att i ett givet datacenter på Leaf-switchar, om det är Huawei, bör ACL:er för att filtrera viss trafik tillämpas på VLAN, och om det är Juniper, då på enhet 0 i det fysiska gränssnittet.
Eller så behöver du rulla ut en ny Syslog-server till alla gränser i regionen.

I den kommer vi att lagra virtuella nätverksenheter, till exempel virtuella routrar eller rotreflektorer. Vi kan lägga till DNS-servrar, NTP, Syslog och i allmänhet allt som på ett eller annat sätt relaterar till nätverket.

Komponent 2: IP-utrymmeshanteringssystem

Ja, och nu för tiden finns det team av människor som håller koll på prefix och IP-adresser i en Excel-fil. Men det moderna tillvägagångssättet är fortfarande en databas, med en front-end på nginx/apache, API och omfattande funktioner för att registrera IP-adresser och nätverk uppdelade i VRF:er.
IPAM - IP-adresshantering.

För våra ändamål kommer vi att lagra följande information i den:

• VLAN
• VRF-förlängning
• Nätverk/Subnät
• IP-adresser
• Bindande adresser till enheter, nätverk till platser och VLAN-nummer

Återigen är det klart att vi vill se till att när vi tilldelar en ny IP-adress för ToR-loopbacken, kommer vi inte att snubbla över det faktum att den redan tilldelats någon. Eller att vi använde samma prefix två gånger i olika ändar av nätverket.
Men hur hjälper detta med automatisering?
Det är enkelt.
Vi begär ett prefix i systemet med rollen Loopbacks, som innehåller IP-adresser tillgängliga för tilldelning - om det hittas tilldelar vi adressen, om inte begär vi att ett nytt prefix skapas.
Eller när vi skapar en enhetskonfiguration kan vi ta reda på från samma system i vilken VRF gränssnittet ska placeras.
Och när man startar en ny server loggar skriptet in i systemet, tar reda på vilken switch servern är i, vilken port och vilket subnät som är tilldelat gränssnittet - och kommer att tilldela serveradressen från det.

Detta tyder på en önskan att kombinera DCIM och IPAM till ett system för att inte duplicera funktioner och inte tjäna två liknande enheter.
Det är vad vi ska göra.

Komponent 3. System för beskrivning av nätverkstjänster

Om de två första systemen lagrar variabler som fortfarande behöver användas på något sätt, så beskriver det tredje för varje enhetsroll hur den ska konfigureras.
Det är värt att särskilja två olika typer av nätverkstjänster:

• Infrastruktur
• Klient.

De förstnämnda är utformade för att ge grundläggande anslutningsmöjligheter och enhetskontroll. Dessa inkluderar VTY, SNMP, NTP, Syslog, AAA, routingprotokoll, CoPP, etc.
De senare organiserar tjänsten för klienten: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, etc.
Naturligtvis finns det också gränsfall – var ska man inkludera MPLS LDP, BGP? Ja, och routingprotokoll kan användas för klienter. Men detta är inte viktigt.

Båda typerna av tjänster är uppdelade i konfigurationsprimitiver:

• fysiska och logiska gränssnitt (tag/anteg, mtu)
• IP-adresser och VRF:er (IP, IPv6, VRF)
• ACL:er och trafikbearbetningspolicyer
• Protokoll (IGP, BGP, MPLS)
• Routingpolicyer (prefixlistor, gemenskaper, ASN-filter).
• Verktygstjänster (SSH, NTP, LLDP, Syslog...)
• Etc.

Hur exakt vi ska göra detta har jag ingen aning om än. Vi kommer att titta på det i en separat artikel.

Om det är lite närmare livet, så skulle vi kunna beskriva det
Leaf-switchen måste ha BGP-sessioner med alla anslutna Spine-switchar, importera anslutna nätverk till processen och endast acceptera nätverk från ett visst prefix från Spine-switchar. Begränsa CoPP IPv6 ND till 10 pps, etc.
I sin tur håller spines sessioner med alla anslutna ledningar, fungerar som rotreflektorer och accepterar från dem endast rutter av en viss längd och med en viss gemenskap.

Komponent 4: Mekanism för enhetsinitiering

Under den här rubriken kombinerar jag många av de åtgärder som måste ske för att en enhet ska visas på radar och nås på distans.

1. Ange enheten i inventeringssystemet.
2. Välj en hanterings-IP-adress.
3. Konfigurera grundläggande åtkomst till det:
   Värdnamn, hanterings IP-adress, väg till hanteringsnätverket, användare, SSH-nycklar, protokoll - telnet/SSH/NETCONF

Det finns tre tillvägagångssätt:

• Allt är helt manuellt. Enheten förs till stativet, där en vanlig organisk person kommer att föra in den i systemen, ansluta till konsolen och konfigurera den. Kan arbeta på små statiska nätverk.
• ZTP - Zero Touch Provisioning. Hårdvaran kom, reste sig, fick en adress via DHCP, gick till en speciell server och konfigurerade sig själv.
• Infrastrukturen för konsolservrar, där den initiala konfigurationen sker via konsolporten i automatiskt läge.

Vi kommer att prata om alla tre i en separat artikel.

Komponent 5: Leverantör-agnostisk konfigurationsmodell

Fram till nu har alla system varit olika patchar som ger variabler och en deklarativ beskrivning av vad vi skulle vilja se på nätverket. Men förr eller senare måste du ta itu med detaljer.
I detta skede, för varje specifik enhet, kombineras primitiver, tjänster och variabler till en konfigurationsmodell som faktiskt beskriver den fullständiga konfigurationen av en specifik enhet, endast på ett leverantörsneutralt sätt.
Vad gör detta steg? Varför inte omedelbart skapa en enhetskonfiguration som du enkelt kan ladda upp?
I själva verket löser detta tre problem:

1. Anpassa inte till ett specifikt gränssnitt för interaktion med enheten. Oavsett om det är CLI, NETCONF, RESTCONF, SNMP - modellen kommer att vara densamma.
2. Behåll inte antalet mallar/skript efter antalet leverantörer på nätverket, och om designen ändras, ändra samma sak på flera ställen.
3. Ladda konfigurationen från enheten (backup), lägg den i exakt samma modell och jämför målkonfigurationen direkt med den befintliga för att beräkna delta och förbereda en konfigurationspatch som bara kommer att ändra de delar som är nödvändiga eller för att identifiera avvikelser.

Som ett resultat av detta steg får vi en leverantörsoberoende konfiguration.

Komponent 6. Leverantörsspecifikt drivrutinsgränssnitt

Du ska inte smickra dig själv med förhoppningar om att det en dag ska vara möjligt att konfigurera en ciska på exakt samma sätt som en Juniper, helt enkelt genom att skicka exakt samma samtal till dem. Trots den växande populariteten för whiteboxar och uppkomsten av stöd för NETCONF, RESTCONF, OpenConfig, skiljer sig det specifika innehållet som dessa protokoll levererar från leverantör till leverantör, och detta är en av deras konkurrensskillnader som de inte kommer att ge upp så lätt.
Detta är ungefär detsamma som OpenContrail och OpenStack, som har RestAPI som NorthBound-gränssnitt, förväntar sig helt andra samtal.

Så i det femte steget måste den leverantörsoberoende modellen ha den form som den kommer att gå till hårdvara.
Och här är alla medel bra (inte): CLI, NETCONF, RESTCONF, SNMP helt enkelt.

Därför kommer vi att behöva en drivrutin som överför resultatet av föregående steg till det erforderliga formatet för en specifik leverantör: en uppsättning CLI-kommandon, en XML-struktur.

Komponent 7. Mekanism för att leverera konfiguration till enheten

Vi har skapat konfigurationen, men den måste fortfarande levereras till enheterna - och naturligtvis inte för hand.
Först, vi ställs inför frågan om vilka transporter vi kommer att använda? Och idag är valet inte längre litet:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (även om det är en outlier eftersom det är ett sätt att leverera FIB, inte inställningar)

Låt oss pricka t:et här. CLI är arv. SNMP... hosta hosta.
RESTCONF är fortfarande ett okänt djur; REST API stöds av nästan ingen. Därför kommer vi att fokusera på NETCONF i serien.

Faktum är att, som läsaren redan har förstått, vid det här laget har vi redan bestämt oss för gränssnittet - resultatet av föregående steg presenteras redan i formatet för det gränssnitt som valdes.

Andra, och vilka verktyg kommer vi att göra detta med?
Här finns också ett stort urval:

• Självskrivet manus eller plattform. Låt oss beväpna oss med ncclient och asyncIO och göra allt själva. Vad kostar det oss att bygga ett distributionssystem från grunden?
• Ansible med sitt rika bibliotek av nätverksmoduler.
• Salt med sitt magra arbete med nätverket och kopplingen till Napalm.
• Egentligen Napalm, som känner ett par leverantörer och det är det, hejdå.
• Nornir är ett annat djur som vi kommer att dissekera i framtiden.

Här är favoriten ännu inte utvald – vi ska leta.

Vad är mer viktigt här? Konsekvenser av att tillämpa konfigurationen.
Framgångsrik eller inte. Finns det fortfarande tillgång till hårdvaran eller inte?
Det verkar som att commit kommer att hjälpa här med bekräftelse och validering av vad som laddades ner till enheten.
Detta, i kombination med korrekt implementering av NETCONF, minskar avsevärt utbudet av lämpliga enheter - inte många tillverkare stöder normala commits. Men detta är bara en av förutsättningarna i RFP. I slutändan är ingen orolig för att inte en enda rysk leverantör kommer att följa gränssnittsvillkoret 32*100GE. Eller är han orolig?

Komponent 8. CI/CD

Vid det här laget har vi redan konfigurationen redo för alla nätverksenheter.
Jag skriver "för allt" eftersom vi pratar om versionering av nätverkstillståndet. Och även om du behöver ändra inställningarna för bara en switch, beräknas ändringar för hela nätverket. Uppenbarligen kan de vara noll för de flesta noder.

Men, som redan sagts ovan, vi är inte någon sorts barbarer som vill rulla allt rakt in i produktionen.
Den genererade konfigurationen måste först gå genom Pipeline CI/CD.

CI/CD står för Continuous Integration, Continuous Deployment. Detta är ett tillvägagångssätt där teamet inte bara lägger ut en ny större version var sjätte månad, som helt ersätter den gamla, utan regelbundet implementerar (Deployment) ny funktionalitet i små portioner, som var och en är omfattande testade för kompatibilitet, säkerhet och prestanda (Integration).

För att göra detta har vi ett versionskontrollsystem som övervakar konfigurationsändringar, ett laboratorium som kontrollerar om klienttjänsten är trasig, ett övervakningssystem som kontrollerar detta faktum och det sista steget är att rulla ut ändringar i produktionsnätverket.

Med undantag för felsökningskommandon måste absolut alla förändringar på nätverket gå via CI/CD Pipeline - detta är vår garanti för ett lugnt liv och en lång, lycklig karriär.

Komponent 9. System för säkerhetskopiering och anomalidetektering

Tja, det finns ingen anledning att prata om säkerhetskopior igen.
Vi kommer helt enkelt att lägga dem i git enligt kronan eller vid en konfigurationsändring.

Men den andra delen är mer intressant – någon borde hålla ett öga på dessa säkerhetskopior. Och i vissa fall måste den här någon gå och vända på allt som det var, och i andra jaja till någon att något är fel.
Till exempel, om en ny användare har dykt upp som inte är registrerad i variablerna måste du ta bort honom från hacket. Och om det är bättre att inte röra en ny brandväggsregel, kanske någon precis har aktiverat felsökning, eller så har den nya tjänsten, en bungler, inte registrerats enligt bestämmelserna, men folk har redan anslutit sig till den.

Vi kommer fortfarande inte att undgå ett litet delta i hela nätverkets skala, trots eventuella automationssystem och ledningens stålsatta hand. För att felsöka problem kommer ingen att lägga till konfiguration till systemen ändå. Dessutom kanske de inte ens ingår i konfigurationsmodellen.

Till exempel är en brandväggsregel för att räkna antalet paket per specifik IP för att lokalisera ett problem en helt vanlig tillfällig konfiguration.

Komponent 10. Övervakningssystem

Först tänkte jag inte ta upp ämnet övervakning – det är fortfarande ett omfattande, kontroversiellt och komplext ämne. Men allteftersom det gick framåt visade det sig att detta var en integrerad del av automatiseringen. Och det är omöjligt att kringgå det, även utan övning.

Evolving Thought är en organisk del av CI/CD-processen. Efter att ha rullat ut konfigurationen till nätverket måste vi kunna avgöra om allt är okej med det nu.
Och vi pratar inte bara och inte så mycket om gränssnittsanvändningsscheman eller nodtillgänglighet, utan om mer subtila saker - närvaron av nödvändiga rutter, attribut på dem, antalet BGP-sessioner, OSPF-grannar, End-to-End-prestanda av överliggande tjänster.
Slutade sysloggarna till den externa servern att läggas ihop, eller gick SFlow-agenten sönder, eller började nedgångarna i köerna att växa, eller gick anslutningen mellan något par prefix sönder?

Vi kommer att reflektera över detta i en separat artikel.

Slutsats

Som grund valde jag en av de moderna datacenternätverksdesignerna - L3 Clos Fabric med BGP som routingprotokoll.
Den här gången kommer vi att bygga nätverket på Juniper, för nu är JunOs-gränssnittet en vanlove.

Låt oss göra vårt liv svårare genom att bara använda Open Source-verktyg och ett nätverk av flera leverantörer - så förutom Juniper kommer jag att välja ytterligare en lycklig person på vägen.

Planen för kommande publikationer är ungefär så här:
Först ska jag prata om virtuella nätverk. För det första för att jag vill, och för det andra för att utan detta kommer utformningen av infrastrukturnätet inte att vara särskilt tydlig.
Sedan om själva nätverksdesignen: topologi, routing, policyer.
Låt oss montera ett laboratorieställ.
Låt oss tänka på det och kanske träna på att initiera enheten i nätverket.
Och sedan om varje komponent i intim detalj.

Och ja, jag lovar inte att graciöst avsluta denna cykel med en färdig lösning. 🙂

Användbara länkar

• Innan du går in i serien är det värt att läsa Natasha Samoilenkos bok Python för nätverksingenjörer. Och kanske passera kursen.
• Det kommer också att vara nyttigt att läsa RFC om designen av datacenterfabriker från Facebook av Peter Lapukhov.
• Arkitekturdokumentationen ger dig en uppfattning om hur Overlay SDN fungerar. Tungsten tyg (tidigare Open Contrail).

Tack

Roman Gorge. För kommentarer och redigeringar.
Artyom Chernobay. För KDPV.

Källa: will.com