SDSM is foarby, mar de ûnkontrolearbere skriuwlust bliuwt.

In protte jierren hat ús broer te lijen fan it dwaan fan routine wurk, syn fingers oerstekke foar it begean en it ûntbrekken fan sliep fanwegen nachtlike rollbacks.
Mar de tsjustere tiden komme ta in ein.

Mei dit artikel sil ik in searje begjinne oer hoe me automatisearring wurdt sjoen.
Underweis sille wy de stadia fan automatisearring begripe, fariabelen opslaan, ûntwerp formalisearje, RestAPI, NETCONF, YANG, YDK en wy sille in protte programmearje.
Foar my betsjut dat a) it is gjin objektive wierheid, b) it is net sûnder betingst de bêste oanpak, c) myn miening, sels yn 'e beweging fan it earste nei it lêste artikel, kin feroarje - om earlik te wêzen, fan' e konseptstadium oant publikaasje, Ik skreaun alles folslein twa kear.

Ynhâld

1. Objektiven
   1. It netwurk is as ien organisme
   2. Konfiguraasje testen
   3. Ferzjefoarming
   4. Tafersjoch en sels-healing fan tsjinsten

2. Means
   1. Ynventarisaasje systeem
   2. IP romte behear systeem
   3. Netwurk tsjinst beskriuwing systeem
   4. Inisjalisaasjemeganisme fan apparaat
   5. Vendor-agnostyske konfiguraasje model
   6. Vendor-spesifike bestjoerder ynterface
   7. Mechanisme foar it leverjen fan konfiguraasje oan it apparaat
   8. CI / CD
   9. Mechanisme foar reservekopy en sykjen nei ôfwikingen
   10. Monitoringsysteem

3. konklúzje

Ik sil besykje ADSM út te fieren yn in formaat wat oars as SDSM. Grutte, detaillearre, nûmere artikels sille trochgean te ferskinen, en tusken har sil ik lytse notysjes publisearje út deistige ûnderfining. Ik sil besykje om hjir perfeksjonisme te bestriden en net elk fan har te slikjen.

Wat is it grappich dat jo de twadde kear troch itselde paad moatte.

Ik moast earst sels artikels skriuwe oer netwurken trochdat se net op it RuNet stiene.

No koe ik net fine in wiidweidich dokumint dat soe systematize oanpak fan automatisearring en analysearje de boppesteande technologyen mei help fan ienfâldige praktyske foarbylden.

Ik kin ferkeard wêze, dus jou asjebleaft keppelings nei nuttige boarnen. Dit sil lykwols myn fêststelling om te skriuwen net feroarje, om't it haaddoel is om sels wat te learen, en it libben makliker te meitsjen foar oaren is in noflike bonus dy't it gen foar it dielen fan ûnderfining streart.

Wy sille besykje in middelgrutte LAN DC-datasintrum te nimmen en it hiele automatisearringskema út te wurkjen.
Ik sil wat dingen hast foar it earst mei dy dwaan.

Ik sil net orizjineel wêze yn 'e hjir beskreaune ideeën en ark. Dmitry Figol hat in poerbêste kanaal mei streamen oer dit ûnderwerp.
De artikels sille har oerlaapje yn in protte aspekten.

De LAN DC hat 4 DC's, sawat 250 switches, in heal dozen routers en in pear firewalls.
Net Facebook, mar genôch om jo djip nei te tinken oer automatisearring.
D'r is lykwols in miening dat as jo mear as 1 apparaat hawwe, automatisearring al nedich is.
Yn feite is it dreech foar te stellen dat elkenien no libje kin sûnder op syn minst in pak knibbelskriften.
Hoewol ik hearde dat d'r kantoaren binne wêr't IP-adressen yn Excel wurde bewarre, en elk fan 'e tûzenen netwurkapparaten is manuell konfigureare en hat syn eigen unike konfiguraasje. Dit kin fansels trochjûn wurde as moderne keunst, mar de gefoelens fan 'e yngenieur sille perfoarst misledigje.

Objektiven

No sille wy de meast abstrakte doelen ynstelle:

• It netwurk is as ien organisme
• Konfiguraasje testen
• Netwurk steat ferzje
• Tafersjoch en sels-healing fan tsjinsten

Letter yn dit artikel sille wy sjen nei hokker middels wy sille brûke, en yn 'e folgjende sille wy sjen nei de doelen en middels yn detail.

It netwurk is as ien organisme

De bepalende sin fan 'e searje, hoewol it op it earste each miskien net sa wichtich liket: wy sille it netwurk konfigurearje, net yndividuele apparaten.
Yn 'e ôfrûne jierren hawwe wy in ferskowing yn' e klam sjoen nei it behanneljen fan it netwurk as ien entiteit, dus de Software Defined Networking, Intent Driven Networks и Autonome netwurken.
Ommers, wat hawwe applikaasjes wrâldwiid nedich fan it netwurk: ferbining tusken punten A en B (goed, soms + B-Z) en isolaasje fan oare applikaasjes en brûkers.

En sa is ús taak yn dizze searje bouwe in systeem, behâld fan de hjoeddeiske konfiguraasje it hiele netwurk, dy't al yn 'e eigentlike konfiguraasje op elk apparaat is ferdield yn oerienstimming mei syn rol en lokaasje.
systeem netwurkbehear betsjut dat om feroaringen te meitsjen, wy kontakt opnimme, en it, op syn beurt, berekkent de winske steat foar elk apparaat en konfigurearret it.
Op dizze manier minimalisearje wy hânmjittige tagong ta de CLI oant hast nul - alle feroaringen yn apparaatynstellingen of netwurkûntwerp moatte formalisearre en dokuminteare wurde - en pas dan útrôle nei de nedige netwurkeleminten.

Dat is, bygelyks, as wy beslute dat fan no ôf rack switches yn Kazan moatte oankundigje twa netwurken ynstee fan ien, wy

1. Earst dokumintearje wy feroaringen yn systemen
2. It generearjen fan de doelkonfiguraasje fan alle netwurkapparaten
3. Wy lansearje it updateprogramma foar netwurkkonfiguraasje, dat berekkent wat op elke knooppunt fuortsmiten wurde moat, wat ta te foegjen en de knopen nei de winske steat bringt.

Tagelyk meitsje wy wizigingen manuell allinich yn 'e earste stap.

Konfiguraasje testen

Is bekenddat 80% fan problemen foarkomme by konfiguraasjewizigingen - yndirekte bewiis hjirfan is dat yn 'e nijjiersfakânsje alles meastal kalm is.
Ik haw persoanlik tsjûge west fan tsientallen globale downtimes fanwege minsklike flater: it ferkearde kommando, de konfiguraasje waard útfierd yn 'e ferkearde branch, de mienskip fergeat, MPLS waard wrâldwiid sloopt op' e router, fiif stikken hardware waarden konfigurearre, mar de flater wie net opmurken op de sechsde, âlde feroarings makke troch in oare persoan waarden begien. D'r binne in ton fan senario's.

Automatisearring sil ús tastean om minder flaters te meitsjen, mar op gruttere skaal. Op dizze manier kinne jo net allinich ien apparaat bakje, mar it heule netwurk tagelyk.

Fan âlds hawwe ús pakesizzers de krektens fan 'e wizigingen kontrolearre mei in skerp each, ballen fan stiel en de funksjonaliteit fan it netwurk nei't se útrôle.
Dy pakes, waans wurk late ta downtime en katastrophale ferliezen lieten minder neiteam en moatte stjerre út oer de tiid, mar evolúsje is in stadich proses, en dêrom net elkenien is noch teste feroarings yn it laboratoarium earst.
Oan 'e foargrûn fan' e foarútgong binne lykwols dejingen dy't it proses fan it testen fan 'e konfiguraasje en har fierdere tapassing op it netwurk automatisearre hawwe. Mei oare wurden, ik liende de CI/CD-proseduere (Trochrinnende yntegraasje, trochgeande ynset) fan de ûntwikkelders.
Yn ien fan 'e dielen sille wy sjen hoe't jo dit kinne ymplementearje mei in ferzjekontrôlesysteem, wierskynlik Github.

As jo ​​​​ienris wend binne oan it idee fan netwurk CI / CD, sil de metoade fan 'e nacht om in konfiguraasje te kontrolearjen troch it oan te passen op in produksjenetwurk lykje as iere midsieuske ûnwittendheid. Soart as it slaan op in warhead mei in hammer.

In organyske fuortsetting fan ideeën oer systeem netwurk behear en CI / CD wurdt in folsleine ferzje fan de konfiguraasje.

Ferzjefoarming

Wy sille oannimme dat mei alle feroarings, sels de meast lytse, sels op ien unnoticeable apparaat, it hiele netwurk beweecht fan de iene steat nei de oare.
En wy dogge altyd gjin kommando op it apparaat, wy feroarje de steat fan it netwurk.
Dat litte wy dizze steaten ferzjes neame?

Litte wy sizze dat de hjoeddeistige ferzje 1.0.0 is.
Is it IP-adres fan 'e Loopback-ynterface op ien fan' e ToR's feroare? Dit is in lytse ferzje en sil nûmere 1.0.1 wêze.
Wy hawwe it belied foar it ymportearjen fan rûtes yn BGP feroare - in bytsje serieuzer - al 1.1.0
Wy besletten om IGP kwyt te reitsjen en allinich te wikseljen nei BGP - dit is al in radikale ûntwerpferoaring - 2.0.0.

Tagelyk kinne ferskate DC's ferskate ferzjes hawwe - it netwurk ûntwikkelet, nije apparatuer wurdt ynstalleare, nije nivo's fan spines wurde earne tafoege, net yn oaren, ensfh.

op semantyske ferzje wy sille prate yn in apart artikel.

Ik werhelje - elke feroaring (útsein foar debuggen kommando's) is in ferzje update. Behearders moatte op 'e hichte brocht wurde fan alle ôfwikingen fan' e hjoeddeistige ferzje.

Itselde jildt foar it weromdraaien fan wizigingen - dit is net it annulearjen fan de lêste kommando's, dit is gjin weromdraaien mei it bestjoeringssysteem fan it apparaat - dit bringt it heule netwurk nei in nije (âlde) ferzje.

Tafersjoch en sels-healing fan tsjinsten

Dizze fanselssprekkende taak hat in nij nivo berikt yn moderne netwurken.
Faak nimme grutte tsjinstferlieners de oanpak dat in mislearre tsjinst hiel fluch reparearre wurde moat en in nije ophelle wurde moat, ynstee fan út te finen wat der bard is.
"Hiel" betsjut dat jo moatte wurde royaal coated oan alle kanten mei tafersjoch, dy't binnen sekonden sil detect de minste ôfwikingen fan de noarm.
En hjir binne de gewoane metriken, lykas laden fan ynterface of knooppuntbeskikberens, net mear genôch. De manuele kontrôle derfan troch de tsjinstoffisier is ek net genôch.
Foar in protte dingen moat der wêze Sels genêzing - de monitoarljochten waarden read en wy gongen de weegbree sels oanbrocht dêr't it sear die.

En hjir kontrolearje wy ek net allinich yndividuele apparaten, mar ek de sûnens fan it heule netwurk, sawol whitebox, dat is relatyf begryplik, en blackbox, dat is komplisearre.

Wat sille wy nedich wêze om sokke ambisjeuze plannen út te fieren?

• Hawwe in list fan alle apparaten op it netwurk, harren lokaasje, rollen, modellen, software ferzjes.
  kazan-leaf-1.lmu.net, Kazan, leaf, Juniper QFX 5120, R18.3.
• Hawwe in systeem foar it beskriuwen fan netwurktsjinsten.
  IGP, BGP, L2/3VPN, Belied, ACL, NTP, SSH.
• Kin it apparaat inisjalisearje.
  Hostnamme, Mgmt IP, Mgmt Route, Brûkers, RSA-Keys, LLDP, NETCONF
• Konfigurearje it apparaat en bring de konfiguraasje nei de winske (ynklusyf âlde) ferzje.
• Test konfiguraasje
• Kontrolearje periodyk de status fan alle apparaten foar ôfwikingen fan 'e hjoeddeistige en rapportearje oan wa't it wêze moat.
  Oernachtich hat immen rêstich in regel oan it ACL tafoege.
• Monitor prestaasjes.

Means

It klinkt yngewikkeld genôch om it projekt yn komponinten te ûntbinen.

En der sille tsien fan har wêze:

1. Ynventarisaasje systeem
2. IP romte behear systeem
3. Netwurk tsjinst beskriuwing systeem
4. Inisjalisaasjemeganisme fan apparaat
5. Vendor-agnostyske konfiguraasje model
6. Vendor-spesifike bestjoerder ynterface
7. Mechanisme foar it leverjen fan konfiguraasje oan it apparaat
8. CI / CD
9. Mechanisme foar reservekopy en sykjen nei ôfwikingen
10. Monitoringsysteem

Dit, trouwens, is in foarbyld fan hoe't de werjefte oer de doelen fan 'e syklus feroare - d'r wiene 4 komponinten yn it ûntwerp.

Yn 'e yllustraasje haw ik alle komponinten en it apparaat sels ôfbylde.
Kruisende komponinten ynteraksje mei elkoar.
Hoe grutter it blok, hoe mear omtinken moat wurde jûn oan dit ûnderdiel.

komponint 1: Ynventarissysteem

Fansels wolle wy witte hokker apparatuer wêr stiet, wat is ferbûn.
It ynventarissysteem is in yntegraal ûnderdiel fan elke ûndernimming.
Meastentiids hat in bedriuw in apart ynventarissysteem foar netwurkapparaten, dy't mear spesifike problemen oplost.
As ûnderdiel fan dizze searje artikels sille wy it DCIM neame - Data Center Infrastructure Management. Hoewol't de term DCIM sels, strikt sprutsen, folle mear omfettet.

Foar ús doelen sille wy de folgjende ynformaasje oer it apparaat dêryn opslaan:

• Ynventarisnûmer
• Titel / Beskriuwing
• Model (Huawei CE12800, Juniper QFX5120, ensfh.)
• Karakteristike parameters (boards, ynterfaces, ensfh.)
• Rol (Leaf, Spine, Border Router, ensfh.)
• Lokaasje (regio, stêd, datacenter, rack, ienheid)
• Ferbinings tusken apparaten
• Netwurk topology

It is folslein dúdlik dat wy dit alles sels witte wolle.
Mar sil dit helpe foar automatisearringsdoelen?
Geweldich.
Bygelyks, wy witte dat yn in opjûne gegevens sintrum op Leaf skakelaars, as it is Huawei, ACLs te filterjen bepaalde ferkear moatte wurde tapast op de VLAN, en as it is Juniper, dan op ienheid 0 fan de fysike ynterface.
Of jo moatte in nije Syslog-tsjinner útrolje nei alle grinzen yn 'e regio.

Dêryn sille wy firtuele netwurkapparaten opslaan, bygelyks firtuele routers of root-reflektors. Wy kinne DNS-tsjinners, NTP, Syslog en yn 't algemien alles tafoegje dat op ien of oare manier relatearret oan it netwurk.

Komponint 2: IP-romtebehearsysteem

Ja, en tsjintwurdich binne d'r teams fan minsken dy't foarheaksels en IP-adressen byhâlde yn in Excel-bestân. Mar de moderne oanpak is noch altyd in databank, mei in front-end op nginx / apache, API en wiidweidige funksjes foar it opnimmen fan IP-adressen en netwurken ferdield yn VRF's.
IPAM - IP-adresbehear.

Foar ús doelen sille wy de folgjende ynformaasje dêryn opslaan:

• VLANs
• VRF
• Netwurken / Subnets
• IP adressen
• Bining adressen oan apparaten, netwurken oan lokaasjes en VLAN nûmers

Nochris is it dúdlik dat wy der wis fan wolle dat as wy in nij IP-adres tawize foar de ToR-loopback, wy net sille stroffelje oer it feit dat it al oan ien is tawiisd. Of dat wy itselde foarheaksel twa kear brûkten op ferskate úteinen fan it netwurk.
Mar hoe helpt dit mei automatisearring?
It is maklik.
Wy freegje in foarheaksel yn it systeem mei de Loopbacks-rol, dy't IP-adressen befettet dy't beskikber binne foar allocaasje - as it fûn wurdt, jouwe wy it adres ta, as net, freegje wy it oanmeitsjen fan in nij foarheaksel.
Of as jo in apparaatkonfiguraasje meitsje, kinne wy ​​​​fan itselde systeem fine wêryn VRF de ynterface moat sitte.
En by it begjinnen fan in nije tsjinner logt it skript yn it systeem, fynt út hokker switch de tsjinner is yn, hokker poarte en hokker subnet wurdt tawiisd oan de ynterface - en sil it serveradres derfan tawize.

Dit suggerearret in winsk om DCIM en IPAM te kombinearjen yn ien systeem om funksjes net te duplisearjen en net twa ferlykbere entiteiten te tsjinjen.
Dat sille wy dwaan.

Komponint 3. Systeem foar it beskriuwen fan netwurk tsjinsten

As de earste twa systemen fariabelen opslaan dy't noch op ien of oare manier brûkt wurde moatte, dan beskriuwt de tredde foar elke apparaatrol hoe't it ynsteld wurde moat.
It is de muoite wurdich om twa ferskillende soarten netwurktsjinsten te ûnderskieden:

• Ynfrastruktuer
• Kliïnt.

De eardere binne ûntworpen om basisferbining en apparaatkontrôle te leverjen. Dizze omfetsje VTY, SNMP, NTP, Syslog, AAA, routingprotokollen, CoPP, ensfh.
De lêste organisearje de tsjinst foar de kliïnt: MPLS L2 / L3VPN, GRE, VXLAN, VLAN, L2TP, ensfh.
Fansels binne d'r ek grinsgefallen - wêr moatte jo MPLS LDP, BGP opnimme? Ja, en routingprotokollen kinne brûkt wurde foar kliïnten. Mar dit is net wichtich.

Beide soarten tsjinsten wurde ferdield yn konfiguraasjeprimitiven:

• fysike en logyske ynterfaces (tag/anteg, mtu)
• IP-adressen en VRF's (IP, IPv6, VRF)
• ACL's en ferkearsferwurkingsbelied
• Protokollen (IGP, BGP, MPLS)
• Routingbelied (foarheaksellisten, mienskippen, ASN-filters).
• Utility tsjinsten (SSH, NTP, LLDP, Syslog ...)
• ensfh.

Hoe't wy dit krekt dwaan sille, haw ik noch gjin idee. Wy sille it besjen yn in apart artikel.

As in bytsje tichter by it libben, dan kinne wy ​​beskriuwe dat
De Leaf switch moat hawwe BGP sesjes mei alle ferbûn Spine switches, ymportearje ferbûn netwurken yn it proses, en akseptearje allinnich netwurken út in bepaald foarheaksel fan Spine switches. Beheine CoPP IPv6 ND ta 10 pps, ensfh.
Yn beurt, spines hold sesjes mei alle ferbûn leads, fungearje as root reflectors, en akseptearje fan harren allinnich rûtes fan in bepaalde lingte en mei in bepaalde mienskip.

komponint 4: Device inisjalisaasje Mechanism

Under dizze kop kombinearje ik in protte fan 'e aksjes dy't moatte foarkomme om in apparaat op radar te ferskinen en op ôfstân te berikken.

1. Fier it apparaat yn yn it ynventarissysteem.
2. Selektearje in behear IP-adres.
3. Stel basis tagong ta it yn:
   Hostnamme, behear IP-adres, rûte nei it behear netwurk, brûkers, SSH-kaaien, protokollen - telnet/SSH/NETCONF

D'r binne trije oanpak:

• Alles is folslein hânmjittich. It apparaat wurdt nei de stand brocht, wêr't in gewoane organyske persoan it yn 'e systemen sil ynfiere, ferbine mei de konsole en konfigurearje. Kin wurkje op lytse statyske netwurken.
• ZTP - Zero Touch Provisioning. De hardware kaam oan, kaam oerein, krige in adres fia DHCP, gie nei in spesjale server en konfigureare himsels.
• De ynfrastruktuer fan konsole-tsjinners, wêr't de earste konfiguraasje foarkomt fia de konsole-poarte yn automatyske modus.

Wy sille prate oer alle trije yn in apart artikel.

Komponint 5: Vendor-agnostyske konfiguraasjemodel

Oant no ta, alle systemen hawwe west disparate patches dy't leverje fariabelen en in deklarative beskriuwing fan wat wy soene graach sjen op it netwurk. Mar ier of letter sille jo moatte omgean mei spesifiken.
Op dit poadium wurde foar elk spesifyk apparaat primitiven, tsjinsten en fariabelen kombineare yn in konfiguraasjemodel dat eins de folsleine konfiguraasje fan in spesifyk apparaat beskriuwt, allinich op in ferkeaper-neutrale manier.
Wat docht dizze stap? Wêrom net fuortendaliks in apparaatkonfiguraasje meitsje dy't jo gewoan kinne uploade?
Yn feite lost dit trije problemen op:

1. Net oanpasse oan in spesifike ynterface foar ynteraksje mei it apparaat. Wês it CLI, NETCONF, RESTCONF, SNMP - it model sil itselde wêze.
2. Net hâld it oantal sjabloanen / skripts neffens it oantal vendors op it netwurk, en as it ûntwerp feroaret, feroarje itselde ding op ferskate plakken.
3. Laad de konfiguraasje fan it apparaat (reservekopy), set it yn krekt itselde model en fergelykje de doelkonfiguraasje direkt mei de besteande om de delta te berekkenjen en in konfiguraasjepatch te meitsjen dy't allinich de dielen sil feroarje dy't nedich binne of om ôfwikingen te identifisearjen.

As gefolch fan dit poadium krije wy in ferkeaper-ûnôfhinklike konfiguraasje.

komponint 6. Vendor-spesifike driver ynterface

Jo moatte net flattere dysels mei hope dat ien dei sil wêze mooglik om te konfigurearjen in ciska op krekt deselde wize as in Juniper, gewoan troch it stjoeren fan krekt deselde oproppen nei harren. Nettsjinsteande de groeiende populariteit fan whiteboxes en it ûntstean fan stipe foar NETCONF, RESTCONF, OpenConfig, de spesifike ynhâld dy't dizze protokollen leverje, ferskilt fan ferkeaper nei ferkeaper, en dit is ien fan har kompetitive ferskillen dat se net sa maklik sille opjaan.
Dit is sawat itselde as OpenContrail en OpenStack, dy't RestAPI hawwe as har NorthBound-ynterface, ferwachtsje folslein oare oproppen.

Dat, yn 'e fyfde stap, moat it ferkeaper-ûnôfhinklike model de foarm nimme wêryn it nei hardware sil gean.
En hjir binne alle middels goed (net): CLI, NETCONF, RESTCONF, SNMP gewoan.

Dêrom sille wy in bestjoerder nedich wêze dy't it resultaat fan 'e foarige stap sil oerdrage yn it fereaske formaat fan in spesifike ferkeaper: in set fan CLI-kommando's, in XML-struktuer.

Komponint 7. Mechanisme foar it leverjen fan konfiguraasje oan it apparaat

Wy hawwe de konfiguraasje generearre, mar it moat noch wurde levere oan 'e apparaten - en, fansels, net mei de hân.
Earst, wurde wy konfrontearre mei de fraach fan hokker ferfier sille wy brûke? En hjoed is de kar net mear lyts:

• CLI (telnet, ssh)
• SNMP
• Netconf
• RESTCONF
• REST API
• OpenFlow (hoewol't it in outlier is, om't it in manier is om FIB te leverjen, net ynstellingen)

Litte wy hjir de t's stipje. CLI is legacy. SNMP... hoest hoest.
RESTCONF is noch in ûnbekend bist; de REST API wurdt stipe troch hast gjinien. Dêrom sille wy rjochtsje op NETCONF yn 'e searje.

Yn feite, lykas de lêzer hat al begrepen, op dit punt hawwe wy al besletten oer de ynterface - it resultaat fan 'e foarige stap is al presintearre yn it formaat fan' e ynterface dy't waard keazen.

Twad, en hokker ark sille wy dwaan dit mei?
D'r is hjir ek in grutte kar:

• Sels skreaun skript of platfoarm. Litte wy ússels wapene mei ncclient en asyncIO en alles sels dwaan. Wat kostet it ús om in ynsetsysteem fanôf it begjin te bouwen?
• Ansible mei syn rike bibleteek fan netwurk modules.
• Sâlt mei syn meager wurk mei it netwurk en ferbining mei Napalm.
• Eins Napalm, dy't in pear ferkeapers ken en dat is it, oant sjen.
• Nornir is in oar bist dat wy yn 'e takomst sille dissecearje.

Hjir is de favoryt noch net keazen - wy sille sykje.

Wat is hjir oars wichtich? Gefolgen fan it tapassen fan de konfiguraasje.
Suksesfol of net. Is der noch tagong ta de hardware of net?
It liket derop dat commit hjir sil helpe mei befêstiging en falidaasje fan wat is ynladen nei it apparaat.
Dit, kombinearre mei de juste ymplemintaasje fan NETCONF, fermindert it berik fan gaadlike apparaten signifikant - net in protte fabrikanten stypje normale commits. Mar dit is mar ien fan de betingsten yn RFP. Op it lêst is gjinien benaud dat net ien Russyske ferkeaper sil foldwaan oan de 32 * 100GE ynterface betingst. Of is er noed?

komponint 8. CI / CD

Op dit punt hawwe wy de konfiguraasje al klear foar alle netwurkapparaten.
Ik skriuw "foar alles" om't wy it hawwe oer ferzje fan 'e netwurkstatus. En sels as jo de ynstellings fan mar ien switch moatte feroarje, wurde feroaringen berekkene foar it heule netwurk. Fansels kinne se nul wêze foar de measte knopen.

Mar, lykas hjirboppe al sein waard, binne wy ​​net in soarte fan barbaren dy't alles direkt yn produksje rôlje wolle.
De oanmakke konfiguraasje moat earst gean troch Pipeline CI / CD.

CI / CD stiet foar Continuous Integration, Continuous Deployment. Dit is in oanpak wêryn it team net allinich elke seis moanne in nije grutte release útbringt, de âlde folslein ferfangt, mar regelmjittich ynkrementeel (ynset) nije funksjonaliteit yn lytse dielen ymplementearret, elk fan dy wurdt wiidweidich hifke op kompatibiliteit, feiligens en prestaasjes (Yntegraasje).

Om dit te dwaan, hawwe wy in ferzjekontrôlesysteem dat konfiguraasjewizigingen kontrolearret, in laboratoarium dat kontrolearret oft de klanttsjinst is brutsen, in tafersjochsysteem dat dit feit kontrolearret, en de lêste stap is wizigingen yn it produksjenetwurk út te rollen.

Mei útsûndering fan debuggen-kommando's moatte absolút alle wizigingen op it netwurk fia de CI / CD Pipeline gean - dit is ús garânsje foar in rêstich libben en in lange, lokkige karriêre.

Komponint 9. Reservekopy en anomaly detection systeem

No, it is net nedich om wer oer backups te praten.
Wy sille se gewoan tafoegje oan 'e kroan of op it feit fan in konfiguraasjeferoaring yn git.

Mar it twadde diel is ynteressanter - immen moat dizze backups yn 'e gaten hâlde. En yn guon gefallen moat dizze immen gean en alles omdraaie lykas it wie, en yn oaren, miauwe nei immen dat der wat mis is.
Bygelyks, as der in nije brûker ferskynde dy't net registrearre is yn 'e fariabelen, moatte jo him fuorthelje fan' e hack. En as it better is om in nije firewall-regel net oan te reitsjen, miskien hat ien gewoan debuggen ynskeakele, of miskien is de nije tsjinst, in bungler, net registrearre neffens de regeljouwing, mar minsken hawwe der al mei oansletten.

Wy sille noch altyd net ûntkomme oan guon lytse delta op 'e skaal fan it hiele netwurk, nettsjinsteande alle automatisearringssystemen en de stielen hân fan behear. Om problemen te debuggen, sil gjinien yn elts gefal konfiguraasje tafoegje oan de systemen. Boppedat kinne se net iens wurde opnommen yn it konfiguraasjemodel.

Bygelyks, in firewall-regel foar it tellen fan it oantal pakketten per spesifike IP om in probleem te lokalisearjen is in folslein gewoane tydlike konfiguraasje.

Komponint 10. Monitoring systeem

Yn it earstoan wie ik net fan doel it ûnderwerp fan tafersjoch te dekken - it is noch altyd in voluminous, kontroversjeel en kompleks ûnderwerp. Mar as dingen foarútgongen, die bliken dat dit in yntegraal ûnderdiel wie fan automatisearring. En it is ûnmooglik om te omgean it, sels sûnder praktyk.

Evolving Thought is in organysk ûnderdiel fan it CI/CD-proses. Nei it útroljen fan de konfiguraasje nei it netwurk, moatte wy bepale kinne oft alles der no goed mei is.
En wy prate net allinich en net sasear oer ynterface-gebrûkskema's as knooppuntbeskikberens, mar oer subtilere dingen - de oanwêzigens fan 'e nedige rûtes, attributen op har, it oantal BGP-sesjes, OSPF-buorlju, End-to-End-prestaasjes fan oerlizzende tsjinsten.
Binne de syslogs nei de eksterne tsjinner ophâlden mei it tafoegjen, of hat de SFlow-agint ôfbrutsen, of begon de drippen yn 'e wachtrigen te groeien, of wie de ferbining tusken guon pear foarheaksels ôfbrutsen?

Wy sille reflektearje oer dit yn in apart artikel.

konklúzje

As basis keas ik ien fan 'e moderne datacenternetwurkûntwerpen - L3 Clos Fabric mei BGP as it routingprotokol.
Dizze kear sille wy it netwurk bouwe op Juniper, want no is de JunOs-ynterface in vanlove.

Litte wy ús libben dreger meitsje troch allinich Open Source-ark te brûken en in netwurk fan meardere leveransiers - dus neist Juniper sil ik ûnderweis noch ien gelokkige persoan kieze.

It plan foar kommende publikaasjes is sa:
Earst sil ik prate oer firtuele netwurken. Yn it foarste plak, om't ik wol, en twad, om't sûnder dit, it ûntwerp fan it ynfrastruktuer netwurk sil net wêze hiel dúdlik.
Dan oer it netwurkûntwerp sels: topology, routing, belied.
Litte wy in laboratoariumstand gearstalle.
Litte wy der oer neitinke en miskien oefenje mei it inisjalisearjen fan it apparaat op it netwurk.
En dan oer elke komponint yn yntym detail.

En ja, ik beloof net dizze syklus sierlik te einigjen mei in klearebare oplossing. 🙂

Nuttige keppelings

• Foardat jo yn 'e searje ferdjipje, is it wurdich it boek fan Natasha Samoilenko te lêzen Python foar Network Engineers. En miskien passe de kursus.
• It sil ek nuttich wêze om te lêzen RFC oer it ûntwerp fan datacenterfabriken fan Facebook troch Peter Lapukhov.
• De arsjitektuerdokumintaasje sil jo in idee jaan fan hoe't Overlay SDN wurket. Wolfram stof (earder Open Contrail).

Dankewol

Roman Gorge. Foar opmerkings en bewurkings.
Artyom Chernobay. Foar KDPV.

Boarne: www.habr.com