SDSM qediya, lê daxwaza nivîsandinê ya bê kontrol dimîne.

Bi gelek salan, birayê me ji ber karê rûtîn dikişand, tiliyên xwe li hev dixist berî ku bikeve û ji ber şevan vedigere.
Lê demên tarî ber bi dawîbûnê ve diçin.

Bi vê gotarê ez ê dest bi rêzek li ser çawa bikim ji min re otomasyon tê dîtin.
Di rê de, em ê qonaxên otomasyonê, hilanîna guherbaran, fermîkirina sêwiranê, RestAPI, NETCONF, YANG, YDK fam bikin û em ê gelek bernamesaziyê bikin.
Ji min re tê wê wateyê ku a) ew ne rastiyek objektîf e, b) ne nêzîkatiya bê şert û merc e, c) nêrîna min, di dema tevgerê de ji gotara yekem heya ya paşîn jî, dikare biguhezîne - bi rastî, ji qonaxa pêşnûmeyê heya weşan, min her tişt bi tevahî du caran ji nû ve nivîsand.

Contains

1. Armancên
   1. Tora mîna organîzmek yekane ye
   2. testkirina veavakirinê
   3. Versioning
   4. Şopandin û xwe-safakirina xizmetên

2. Fonan
   1. Sîstema envanterê
   2. pergala rêveberiya cîhê IP
   3. Sîstema danasîna karûbarê torê
   4. Mekanîzmaya destpêkirina cîhazê
   5. Modela veavakirina vendor-agnostîk
   6. Navrûya ajokerê ya vendor-taybet
   7. Mekanîzmaya radestkirina veavakirina amûrê
   8. CI / CD
   9. Mekanîzmaya paşvegirtin û lêgerîna devjêberan
   10. Sîstema çavdêriyê

3. encamê

Ez ê hewl bidim ku ADSM-ê bi formatek ji SDSM-ê hinekî cûdatir bimeşînim. Gotarên mezin, hûrgulî, hejmarî dê berdewam bin, û di navbera wan de ez ê notên piçûk ji ezmûna rojane biweşînim. Ez ê hewl bidim ku li vir bi kamilîzmê re şer bikim û her yek ji wan nekim.

Çiqas xweş e ku cara duyemîn divê hûn di heman rê de derbas bibin.

Di destpêkê de min neçar ma ku bixwe gotarên li ser toran binivîsim ji ber ku ew ne li ser RuNet bûn.

Naha min nikarî belgeyek berfereh bibînim ku nêzîkatiyên otomasyonê bi pergal bike û teknolojiyên jorîn bi karanîna mînakên pratîkî yên hêsan analîz bike.

Dibe ku ez xelet bim, ji ber vê yekê ji kerema xwe girêdanên çavkaniyên bikêr peyda bikin. Lêbelê, ev ê biryardariya min a nivîsandinê neguhezîne, ji ber ku armanca sereke ew e ku ez bixwe tiştek fêr bibim, û hêsankirina jiyanê ji yên din re bonusek xweş e ku genê ji bo parvekirina ezmûnê dixemilîne.

Em ê hewl bidin ku navendek daneya LAN DC-ya navîn hildin û tevaya pilana otomasyonê bixebitin.
Ez ê hema cara yekem bi we re hin tiştan bikim.

Ez ê di raman û amûrên ku li vir hatine vegotin de ne orîjînal bim. Dmitry Figol xwedan karekî hêja ye kanala bi streams li ser vê mijarê.
Gotar dê di gelek aliyan de bi wan re li hev bikin.

LAN DC xwedan 4 DC, nêzîkê 250 guhêrbar, nîv dozin router û çend dîwarên agir hene.
Ne Facebook, lê têra we dike ku hûn li ser otomasyonê kûr bifikirin.
Lêbelê, ramanek heye ku heke we ji 1 amûrek zêdetir hebe, jixwe otomatîkî hewce ye.
Di rastiyê de, dijwar e ku meriv xeyal bike ku kes naha dikare bêyî kêmasî pakêtek nivîsarên çokê bijî.
Her çend min bihîst ku nivîsgeh hene ku navnîşanên IP-yê di Excel de têne girtin, û her yek ji hezaran cîhazên torê bi destan têne mîheng kirin û veavakirina xweya yekta heye. Ev, bê guman, dikare wekî hunera nûjen were derbas kirin, lê hestên endezyar dê bê guman aciz bibin.

Armancên

Naha em ê armancên herî razber destnîşan bikin:

• Tora mîna organîzmek yekane ye
• testkirina veavakirinê
• Guhertoya dewleta torê
• Şopandin û xwe-safakirina xizmetên

Dûv re di vê gotarê de em ê binihêrin ka em ê çi navgînan bikar bînin, û di pey de jî em ê bi berfirehî li armanc û wateyan binêrin.

Tora mîna organîzmek yekane ye

Gotina diyarker a rêzê, her çend di nihêrîna pêşîn de ew qas girîng xuya neke jî: em ê torê mîheng bikin, ne cîhazên takekesî.
Di van salên dawî de, me dît ku guheztinek li ser girtina torê wekî saziyek yekane, ji ber vê yekê Nermalava Torgilokê Diyar kir, Niyeta ajotinê Torên и Torên Xweser.
Beriya her tiştî, serîlêdan li seranserê cîhanê ji torê çi hewce dikin: girêdana di navbera xalên A û B (baş, carinan + B-Z) û veqetandina ji serîlêdan û bikarhênerên din.

Û ji ber vê yekê peywira me di vê rêzê de ye sîstemekê ava bikin, parastina veavakirina heyî tevaya torê, ku jixwe li ser her amûrekê li gorî rol û cîhê xwe di veavakirina rastîn de tê hilweşandin.
sîstem rêveberiya torê tê vê wateyê ku ji bo guhartinan em pê re têkilî daynin, û ew, di encamê de, rewşa xwestî ji bo her cîhazê hesab dike û wê mîheng dike.
Bi vî rengî, em gihîştina bi destan a CLI-yê hema hema sifir kêm dikin - her guheztinek di mîhengên cîhazê an sêwirana torê de pêdivî ye ku fermî û belgekirî be - û tenê dûv re bi hêmanên torê yên pêwîst re were şandin.

Ango, wek nimûne, heke me biryar da ku ji nuha û pê ve li Kazanê divê li şûna yek torê du şebek ragihînin, em

1. Pêşî em guhertinên di pergalan de belge dikin
2. Hilberîna veavakirina armancê ya hemî amûrên torê
3. Em bernameya nûvekirina veavakirina torê didin destpêkirin, ya ku hewce dike ku li ser her girêkek çi were rakirin, çi lê zêde bike, hesab dike û girêkan digihîne rewşa xwestinê.

Di heman demê de, em tenê di gava yekem de bi destan guhertinan dikin.

testkirina veavakirinê

Tê zanînku 80% ji pirsgirêkan di dema guhertinên mîhengê de çêdibin - delîlên nerasterast vê yekê ev e ku di betlaneyên Sersalê de her tişt bi gelemperî aram e.
Ez bi xwe bûm şahidê bi dehan têkçûnên gerdûnî yên ji ber xeletiya mirovî: fermana xelet, veavakirin di şaxek xelet de hate darve kirin, civat ji bîr kir, MPLS li gerdûnî li ser routerê hate hilweşandin, pênc perçe hardware hatin mîheng kirin, lê xelet nebû. di şeşemîn de hate dîtin, guhertinên kevn ên ku ji hêla kesek din ve hatine çêkirin, hatine kirin. Gelek senaryo hene.

Otomasyon dê rê bide me ku em kêm xeletiyan bikin, lê di astek mezin de. Bi vî rengî hûn dikarin ne tenê amûrek, lê tevahiya torê di yekcar de bişkînin.

Ji demên kevnar ve, bapîrên me rastbûna guheztinên ku hatine çêkirin bi çavek hişk, topên pola û fonksiyona torê piştî ku ew hatin avêtin kontrol kirin.
Ew bapîrên ku karê wan bû sedema kêmbûn û windahiyên felaketî kêmtir dûndan hiştin û divê bi demê re bimirin, lê peşveçûn pêvajoyek hêdî ye, û ji ber vê yekê ne her kes hîna jî pêşî li laboratûwaran diceribîne.
Lêbelê, di pêşiya pêşkeftinê de yên ku pêvajoya ceribandina mîhengê û serîlêdana wê ya bêtir ji torê re otomatîk kirine hene. Bi gotineke din, min pêvajoya CI/CD deyn kir (Yekbûnek Berdewam, Pêkhatina Berdewam) ji pêşdebiran.
Di yek ji beşan de em ê binihêrin ka meriv çawa vê yekê bi karanîna pergalek kontrolkirina guhertoyê, belkî Github, bicîh tîne.

Gava ku hûn bi ramana torê CI/CD-ê re fêr bibin, di şevekê de rêbaza kontrolkirina veavakirinê bi sepandina wê li tora hilberînê dê wekî nezaniya destpêka navîn xuya bike. Mîna lêdana serê şerekî bi çakûçê.

Berdewamek organîk a ramanên li ser sîstem rêveberiya torê û CI/CD dibe guhertoyek tevahî ya veavakirinê.

Versioning

Em ê texmîn bikin ku bi her guhertinan re, hetta yên herî piçûk, tewra li ser yek amûrek nedîtbar, tevaya torê ji rewşek din diçe.
Û em her gav fermanek li ser cîhazê bicîh nakin, em rewşa torê diguherînin.
Ji ber vê yekê em ji van dewletan re bibêjin versiyonên?

Em bêjin guhertoya heyî 1.0.0 e.
Ma navnîşana IP-ya pêwendiya Loopback li ser yek ji ToR-an guherî? Ev guhertoyek piçûk e û dê jimareya 1.0.1 be.
Me polîtîkayên îtxalkirina rê li BGP-yê - hinekî ciddîtir - jixwe 1.1.0 guhezand
Me biryar da ku em ji IGP xilas bibin û tenê bi BGP-ê veguherînin - ev jixwe guhertinek sêwiranê ya radîkal e - 2.0.0.

Di heman demê de, DC-yên cihêreng dibe ku guhertoyên cihêreng hebin - torgilok pêş dikeve, alavên nû têne saz kirin, astên nû yên spin li cîhek têne zêdekirin, ne li yên din, hwd.

li ser guhertoya semantîk em ê di gotarek cuda de biaxivin.

Ez dubare dikim - her guhertin (ji bilî fermanên xeletkirinê) nûvekirinek guhertoyek e. Pêdivî ye ku rêvebir ji her cûrbecûr guhertoya heyî werin agahdar kirin.

Heman tişt ji bo vegerandina guhertinan jî derbas dibe - ev ne betalkirina fermanên paşîn e, ev ne vegerek bi karanîna pergala xebitandina cîhazê ye - ev yek tevaya torê tîne guhertoyek nû (kevn).

Şopandin û xwe-safakirina xizmetên

Ev erka ku ji xwe diyar e, di torên modern de gihîştiye asteke nû.
Bi gelemperî, pêşkêşkerên karûbarê mezin nêzîkatiya xwe digirin ku karûbarek têkçûyî pêdivî ye ku pir zû were sererast kirin û karûbarek nû were rakirin, li şûna ku fêhm bikin ka çi bûye.
"Gelek" tê vê wateyê ku hûn hewce ne ku ji her alî ve bi dilşewatî bi çavdêriyê ve werin pêçan, ku di nav çirkeyan de dê guheztinên piçûk ji normê kifş bike.
Û li vir metrîkên asayî, wek barkirina navberê an hebûna nodê, êdî têrê nakin. Çavdêriya wan a bi destan ji aliyê peywirdarê ve jî têrê nake.
Ji bo gelek tiştan divê hebe Xwe qenckirin - çirayên çavdêriyê sor bûn û em çûn û me xwe li dera ku diêşiya çîmenê danî.

Û li vir em ne tenê cîhazên kesane, lê di heman demê de tenduristiya tevahiya torê jî çavdêrî dikin, hem whitebox, ku bi nisbî tê fêm kirin, hem jî qutiya reş, ku tevlihevtir e.

Ji bo bicihanîna planên wisa azwerî em ê çi hewce bikin?

• Navnîşek hemî amûrên li ser torê, cîhê wan, rol, model, guhertoyên nermalavê hebe.
  kazan-leaf-1.lmu.net, Kazan, pel, Juniper QFX 5120, R18.3.
• Pergalek ji bo danasîna karûbarên torê hebe.
  IGP, BGP, L2/3VPN, Siyaset, ACL, NTP, SSH.
• Dikarin amûrê dest pê bikin.
  Navê mêvandar, Mgmt IP, Mgmt Route, Bikarhêner, RSA-Keys, LLDP, NETCONF
• Amûrê mîheng bikin û veavakirinê bînin guhertoya xwestinê (tevî kevin).
• Veavakirina testê
• Bi periyodîk rewşa hemî cîhazan ji bo veqetîna ji yên heyî kontrol bikin û ji kê re rapor bikin.
  Di şevekê de, kesek bi bêdengî qaîdeyek li ACL zêde kir.
• Monitor performansa.

Fonan

Ew têra xwe tevlihev xuya dike ku meriv dest bi veqetandina projeyê li pêkhateyan bike.

Û dê ji wan deh hebin:

1. Sîstema envanterê
2. pergala rêveberiya cîhê IP
3. Sîstema danasîna karûbarê torê
4. Mekanîzmaya destpêkirina cîhazê
5. Modela veavakirina vendor-agnostîk
6. Navrûya ajokerê ya vendor-taybet
7. Mekanîzmaya radestkirina veavakirina amûrê
8. CI / CD
9. Mekanîzmaya paşvegirtin û lêgerîna devjêberan
10. Sîstema çavdêriyê

Ev, bi awayê, mînakek e ku meriv çawa nêrîna li ser armancên çerxê guherî - di pêşnûmeyê de 4 pêkhate hebûn.

Di nîgarê de min hemû pêkhate û amûrê xwe bi xwe xêz kir.
Pêkhateyên hevgirtî bi hevûdu re tevdigerin.
Her ku blok mezintir be, pêdivî ye ku bêtir baldarî li ser vê pêkhateyê were dayîn.

Parçeyek 1: Sîstema envanterê

Eşkere ye, em dixwazin zanibin ka kîjan amûr li ku ye, bi çi ve girêdayî ye.
Pergala envanterê parçeyek yekbûyî ya her pargîdaniyek e.
Bi gelemperî, pargîdaniyek ji bo cîhazên torê xwedan pergalek envanterê ya cihê ye, ku pirsgirêkên taybetî çareser dike.
Wekî beşek ji vê rêzika gotaran, em ê jê re bibêjin DCIM - Rêvebiriya Binesaziya Navenda Daneyê. Her çend têgîna DCIM bixwe, bi hişkî dipeyivî, pir zêde dihewîne.

Ji bo mebestên me, em ê agahdariya jêrîn li ser cîhazê di wê de hilînin:

• Hejmara navgîniyê
• Sernav / Danasîn
• Model (Huawei CE12800, Juniper QFX5120, hwd.)
• Parametreyên taybetmendiyê (panel, navber, hwd.)
• Rol (Leaf, Spine, Border Router, hwd.)
• Cih (herêm, bajar, navenda daneyê, rack, yekîne)
• Têkiliyên di navbera cîhazan de
• Topolojiya torê

Bi tevahî zelal e ku em bixwe dixwazin van hemîyan bizanibin.
Lê gelo ev ê ji bo mebestên otomasyonê bibe alîkar?
Bê guman.
Mînakî, em dizanin ku di navendek daneyê ya li ser guheztina Leaf-ê de, heke ew Huawei be, ACL-yên ku hin seyrûseferê fîltre dikin divê li ser VLAN-ê werin sepandin, û heke ew Juniper be, wê hingê li ser yekîneya 0-ya pêwendiya laşî.
An jî hûn hewce ne ku serverek Syslog-a nû li hemî sînorên herêmê derxînin.

Di wê de em ê amûrên torê yên virtual hilînin, mînakî rêwerên virtual an refleksên root. Em dikarin pêşkêşkerên DNS, NTP, Syslog û bi gelemperî her tiştê ku bi rengek an din bi torê ve girêdayî ye lê zêde bikin.

Parçeyek 2: Pergala rêveberiya cîhê IP

Erê, û îroj tîmên mirovan hene ku di pelek Excel de pêşgir û navnîşanên IP-yê dişopînin. Lê nêzîkatiya nûjen hîn jî databasek e, bi pêş-endek li ser nginx/apache, API û fonksiyonên berfireh ji bo tomarkirina navnîşanên IP-yê û torên ku di nav VRF de têne dabeş kirin.
IPAM - Rêvebiriya Navnîşana IP.

Ji bo mebestên me, em ê agahdariya jêrîn tê de hilînin:

• VLANs
• VRF
• Tora / Subnets
• navnîşanên IP
• Girêdana navnîşan bi cîhazan re, toran bi cîh û hejmarên VLAN re

Dîsa, diyar e ku em dixwazin pê ewle bin ku gava ku em navnîşanek IP-ya nû ji bo ToR loopback veqetînin, em ê li ser rastiya ku ew berê ji kesek re hatî veqetandin nekevin. An jî ku me heman pêşgira du caran li deverên cûda yên torê bikar anî.
Lê ev çawa bi otomatê re dibe alîkar?
Zehf.
Em di pergalê de pêşgirek bi rola Loopbacks daxwaz dikin, ku tê de navnîşanên IP-yê yên ji bo veqetandinê hene - heke were dîtin, em navnîşan vediqetînin, heke na, em daxwaza afirandina pêşgirek nû dikin.
An jî dema ku mîhengek amûrekê diafirînin, em dikarin ji heman pergalê fêr bibin ku tê de navbeynkariya VRF-ê tê de hebe.
Û dema ku serverek nû dest pê dike, skrîpt têkeve pergalê, fêr dibe ku server li kîjan guhêrbar e, li kîjan portê û kîjan subnet ji navbeynê re hatî veqetandin - û dê navnîşana serverê jê veqetîne.

Ev daxwazek pêşniyar dike ku DCIM û IPAM-ê di yek pergalê de tevlihev bikin da ku fonksiyonan dubare nekin û ji du saziyên wekhev re xizmetê nekin.
Ya ku em ê bikin ev e.

Parçeyek 3. Pergala danasîna karûbarên torê

Ger du pergalên yekem guhêrbarên ku hîn jî hewce ne ku bi rengekî werin bikar anîn hilînin, wê hingê ya sêyemîn ji bo her rola cîhazê diyar dike ka ew çawa divê were mîheng kirin.
Hêja ye ku du celeb karûbarên torê yên cûda cûda bikin:

• Binesaziyê
• Kirrîxwaz.

Yên berê ji bo peydakirina girêdana bingehîn û kontrola cîhazê têne çêkirin. Di nav wan de VTY, SNMP, NTP, Syslog, AAA, protokolên rêvekirinê, CoPP, hwd.
Ya paşîn karûbarê ji bo xerîdar organîze dike: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, hwd.
Bê guman, dozên sînorî jî hene - MPLS LDP, BGP li ku derê têxin nav xwe? Erê, û protokolên rêvekirinê dikare ji bo xerîdaran were bikar anîn. Lê ev ne girîng e.

Her du celeb karûbar di nav primitives veavakirinê de têne dabeş kirin:

• pêwendiyên laşî û mentiqî (tag/anteg, mtu)
• Navnîşanên IP û VRF (IP, IPv6, VRF)
• ACL û polîtîkayên pêvajoya trafîkê
• Protokol (IGP, BGP, MPLS)
• Polîtîkayên rêvekirinê (lîsteyên pêşgir, civak, fîlterên ASN).
• Karûbarên karûbar (SSH, NTP, LLDP, Syslog...)
• hwd.

Em ê çawa bi rastî vê yekê bikin, ez hîna nizanim. Em ê di gotarek cuda de lê binêrin.

Heger piçekî nêzikî jiyanê bibe, wê demê em dikarin wê vebêjin
Guhestina Leaf divê bi hemî guheztinên Spine yên girêdayî re danişînên BGP-ê hebe, torgilokên pêvekirî têxe pêvajoyê, û tenê torên ji pêşgirek diyarkirî ji guhezkerên Spine qebûl bike. CoPP IPv6 ND bi 10 pps, hwd.
Di encamê de, spines bi hemî pêşengên girêdayî re rûniştinan pêk tînin, wekî refleksên root tevdigerin, û ji wan tenê rêçên bi dirêjiyek diyar û bi civakek diyarkirî re qebûl dikin.

Parçeyek 4: Mekanîzmaya Destpêkirina Amûrê

Di bin vê sernavê de ez gelek tevgerên ku divê çêbibin ji bo ku amûrek li ser radarê xuya bibe û ji dûr ve were gihîştinê berhev dikim.

1. Di pergala envanterê de amûrê têkevin.
2. Navnîşanek IP-ê ya rêveberiyê hilbijêrin.
3. Gihîştina bingehîn a wê saz bikin:
   Navê mêvandar, navnîşana IP-ya rêveberiyê, rêça tora rêveberiyê, bikarhêner, mifteyên SSH, protokol - telnet / SSH / NETCONF

Sê rêbaz hene:

• Her tişt bi tevahî manual e. Amûr tê stendin, li wir kesek organîk a asayî wê têkeve nav pergalan, bi konsolê ve girêbide û wê mîheng bike. Dikare li ser torên statîk ên piçûk bixebite.
• ZTP - Dabînkirina Zero Touch. Zehf gihîşt, rabû ser xwe, bi navgîniya DHCP-ê navnîşek wergirt, çû serverek taybetî, û xwe mîheng kir.
• Binesaziya pêşkêşkerên konsolê, ku veavakirina destpêkê bi riya porta konsolê di moda otomatîkî de pêk tê.

Em ê di gotarek cuda de behsa van hersêyan bikin.

Parçeyek 5: Modela veavakirina vendor-agnostîk

Heya nuha, hemî pergal paçên cihêreng bûn ku guhêrbar û ravekirinek eşkere ya tiştê ku em dixwazin li ser torê bibînin peyda dikin. Lê zû an dereng, hûn ê neçar bibin ku bi taybetmendiyan re mijûl bibin.
Di vê qonaxê de, ji bo her amûrek taybetî, primitive, karûbar û guhêrbar di modelek vesazkirinê de têne hev kirin ku bi rastî veavakirina bêkêmasî ya amûrek taybetî, tenê bi rengek firoşkar-bêalî diyar dike.
Ev gav çi dike? Çima tavilê mîhengek amûrek ku hûn dikarin bi hêsanî barkirin biafirînin?
Bi rastî, ev sê pirsgirêkan çareser dike:

1. Ji bo danûstendina bi cîhazê re bi navgînek taybetî re adapte nekin. CLI, NETCONF, RESTCONF, SNMP be - model dê heman be.
2. Hejmara şablonan/skrîptan li gorî hejmara firoşkarên li ser torê nehêlin, û ger sêwiran biguheze, heman tişt li çend deveran biguhezînin.
3. Veavakirinê ji cîhazê bar bikin (paqij), wê têxin tam heman modelê û rasterast veavakirina armancê bi ya heyî re bidin ber hev da ku delta bihesibîne û pêvek verastkirinê amade bike ku dê tenê wan beşên ku hewce ne biguhezîne an ji bo tespîtkirina deviyan biguhezîne.

Di encama vê qonaxê de, em mîhengek serbixwe-firotanê werdigirin.

Component 6. Navrûya ajokerê-taybetî ya vendor

Pêdivî ye ku hûn xwe bi hêviyên ku rojekê mimkun e ku meriv ciska bi heman rengî wekî Juniper-ê mîheng bike, bi tenê bi şandina tam heman bangan ji wan re mimkun neke. Tevî mezinbûna populerbûna qutiyên spî û peydabûna piştgirî ji bo NETCONF, RESTCONF, OpenConfig, naveroka taybetî ya ku van protokolan radigihînin ji firoşkar heya firoşkar cûda dibe, û ev yek ji cûdahiyên wan ên pêşbaziyê ye ku ew ê ew qas hêsan dev jê bernedin.
Ev hema hema heman OpenContrail û OpenStack e, ku RestAPI wekî navbeynkariya xwe ya NorthBound heye, bangên bi tevahî cûda hêvî dikin.

Ji ber vê yekê, di gava pêncemîn de, pêdivî ye ku modela serbixwe-firoşkar forma ku ew ê biçe ser hardware bigire.
Û li vir hemî rêgez baş in (ne): CLI, NETCONF, RESTCONF, SNMP bi hêsanî.

Ji ber vê yekê, em ê hewceyê ajokerek ku dê encama qonaxa berê veguhezîne forma pêdivî ya firoşkarek taybetî: komek fermanên CLI, avahiyek XML.

Parçeyek 7. Mekanîzmaya radestkirina veavakirina amûrê

Me veavakirin çêkiriye, lê dîsa jî pêdivî ye ku ew ji cîhazan re were radest kirin - û, eşkere, ne bi destan.
Yekem, em bi pirsê re rû bi rû ne ku em ê çi veguhastinê bikar bînin? Û îro hilbijartin êdî ne piçûk e:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (her çend ew xerîbek e ji ber ku ew rêyek e ku FIB peyda dike, ne mîhengan)

Werin em t li vir xal bikin. CLI mîras e. SNMP... kuxikê.
RESTCONF hîn jî heywanek nenas e; REST API hema hema ji hêla tu kesî ve nayê piştgirî kirin. Ji ber vê yekê, em ê di rêzê de li ser NETCONF-ê bisekinin.

Di rastiyê de, wekî ku xwendevan jixwe fêm kiriye, heya vê gavê me berê li ser navbeynkariyê biryar daye - encama qonaxa berê jixwe di forma navbeynkariya ku hatî hilbijartin de tê pêşkêş kirin.

Duyemîn, û em ê bi kîjan amûran vê yekê bikin?
Li vir vebijarkek mezin jî heye:

• Nivîsar an platforma xwe-nivîsandî. Werin em xwe bi ncclient û asyncIO çekdar bikin û her tiştî bi xwe bikin. Ma mesrefa me çi ye ku em pergalek bicîhkirinê ji nû ve ava bikin?
• Ansible bi pirtûkxaneya xweya dewlemend a modulên torê re.
• Xwê bi xebata xwe ya kêm a bi torê û girêdana bi Napalmê re.
• Bi rastî Napalm, ku çend firoşkaran nas dike û ew e, bi xatirê te.
• Nornir heywanek din e ku em ê di pêşerojê de veqetînin.

Li vir bijare hîn nehatiye hilbijartin - em ê bigerin.

Li vira din çi girîng e? Encamên sepandina veavakirinê.
Serkeftin an ne. Hîn jî gihîştina hardware heye an na?
Wusa dixuye ku commit dê li vir bi piştrastkirin û pejirandina tiştê ku li cîhazê hatî dakêşandin re bibe alîkar.
Ev, digel pêkanîna rast a NETCONF-ê, bi girîngî rêza cîhazên maqûl teng dike - ne pir hilberîner piştgirî didin peywirên normal. Lê ev tenê yek ji şertên pêşîn e RFP. Di dawiyê de, kes ne fikar e ku ne yek firoşkarê rûsî bi şerta navbeynkariya 32 * 100GE re tevbigere. An jî ew xemgîn e?

Beşa 8. CI/CD

Di vê nuqteyê de, me jixwe veavakirina ji bo hemî amûrên torê amade ye.
Ez "ji bo her tiştî" dinivîsim ji ber ku em li ser guhertoya dewleta torê diaxivin. Û tewra ku hûn hewce ne ku mîhengên tenê yek guheztinê biguhezînin, guhertin ji bo tevaya torê têne hesibandin. Eşkere ye, ew dikarin ji bo piraniya nokan sifir bin.

Lê, wekî ku li jor jî hate gotin, em ne celebek barbar in ku dixwazin her tiştî rasterast bixin nav hilberînê.
Veavakirina çêkirî divê pêşî di Pipeline CI/CD-ê re derbas bibe.

CI/CD ji bo entegrasyona domdar, sazkirina domdar radiweste. Ev nêzîkatiyek e ku tîm ne tenê her şeş mehan carekê serbestberdanek mezin a nû derdixe, bi tevahî li şûna ya kevin, lê bi rêkûpêk bi zêdeyî fonksiyonên nû di beşên piçûk de destnîşan dike, ku her yek ji wan bi berfirehî ji bo lihevhatî, ewlehî û ceribandin têne ceribandin. performansa (Integrasyon).

Ji bo vê yekê, me pergalek kontrolkirina guhertoyê heye ku guheztinên mîhengê dişopîne, laboratûwarek ku kontrol dike ka karûbarê xerîdar şikestî ye, pergalek çavdêriyê ku vê rastiyê kontrol dike, û gava paşîn guheztina guhertinên li tora hilberînê ye.

Ji xeynî fermanên xeletkirinê, bê guman hemî guhertinên li ser torê divê di xeta CI/CD de derbas bibin - ev garantiya me ya jiyanek bêdeng û kariyerek dirêj û bextewar e.

Pêkhatî 9. Pergala paşvekişandin û tespîtkirina anomalî

Welê, ne hewce ye ku dîsa li ser paşvekişandinê biaxivin.
Em ê bi tenê wan li ser tacê an li ser rastiya guheztina mîhengê di git de zêde bikin.

Lê beşa duyemîn balkêştir e - divê kes çavê xwe li van paşkêşan bigire. Û di hin rewşan de, divê ev kes biçe û her tiştî wekî ku bû bizivirîne, û di hinên din de, ji yekî re meow ku tiştek xelet e.
Mînakî, heke bikarhênerek nû xuya bû ku di guhêrbaran de ne qeydkirî ye, hûn hewce ne ku wî ji hakê dûr bixin. Û heke çêtir e ku meriv dest nede qaîdeyek nû ya dîwarê agir, dibe ku kesek tenê debugging vekiriye, an jî dibe ku karûbarê nû, bungler, li gorî rêziknameyê nehatibe qeyd kirin, lê mirov jixwe tevlî wê bûne.

Em ê dîsa jî ji hin deltaya piçûk a li ser pîvana tevahiya torê nerevin, tevî her pergalên otomasyonê û destê pola yên rêveberiyê. Ji bo çareserkirina pirsgirêkan, tu kes dê bi her awayî veavakirinê li pergalan zêde neke. Digel vê yekê, dibe ku ew di modela veavakirinê de jî nebin.

Mînakî, qaîdeyek dîwarê agir ji bo jimartina hejmara pakêtan li ser IP-ya taybetî ji bo herêmîkirina pirsgirêkê vesazkirinek demkî ya bi tevahî asayî ye.

Pêkhatî 10. Sîstema şopandinê

Di destpêkê de ez ê neçim mijara çavdêriyê - ew hîn jî mijarek berfireh, nakokî û tevlihev e. Lê her ku tişt pêşve diçû, derket holê ku ev beşek yekbûyî ya otomatê bû. Û ne mimkûn e ku meriv wê bê pratîk jî derbas bike.

Ramana Pêşveçûn beşek organîk a pêvajoya CI/CDê ye. Piştî ku veavakirinê li ser torê derxistin, pêdivî ye ku em karibin diyar bikin ka niha her tişt bi wê re baş e.
Û em ne tenê û ne ew qas li ser nexşeyên karanîna navberê an hebûna girêk, lê li ser tiştên naziktir diaxivin - hebûna rêyên pêwîst, taybetmendiyên li ser wan, hejmara danişînên BGP, cîranên OSPF, performansa End-to-End xizmetên sergirtî.
Ma syslogên servera derveyî lê zêde kirin rawestiyan, an nûnerê SFlow têk çû, an dilopên di rêzan de dest pê kir mezin bûn, an girêdana di navbera çend cot pêşgiran de têk çû?

Em ê di gotarek cuda de li ser vê yekê bisekinin.

encamê

Wekî bingeh, min yek ji sêwiranên torê yên navenda daneyê ya nûjen hilbijart - L3 Clos Fabric bi BGP wekî protokola rêvekirinê.
Vê carê em ê torê li ser Juniper ava bikin, ji ber ku naha navbeynkariya JunOs vanlove ye.

Werin em bi karanîna tenê amûrên Çavkaniya Vekirî û torgilokek pir-firotanê jiyana xwe dijwartir bikin - ji ber vê yekê ji bilî Juniper, ez ê di rê de kesek din jî bi şens hilbijêrin.

Plana weşanên pêşeroj tiştek wiha ye:
Pêşî ez ê qala torên virtual bikim. Berî her tiştî, ji ber ku ez dixwazim, û ya duyemîn jî, ji ber ku bêyî vê yekê, sêwirana tora binesaziyê dê pir zelal nebe.
Dûv re li ser sêwirana torê bixwe: topolojî, rêveçûn, polîtîka.
Werin em stendek laboratîfê berhev bikin.
Ka em li ser wê bifikirin û belkî destpêkirina amûrê li ser torê pratîk bikin.
Û dûv re li ser her pêkhateyê bi hûrgulî.

Û erê, ez soz nadim ku bi xêrhatinî vê dewrê bi çareseriyek amade biqedînim. 🙂

Girêdanên bikarhêner

• Berî ku hûn di rêzê de hûr bibin, hêjayî xwendina pirtûka Natasha Samoilenko ye Python ji bo Endezyarên Torê. Û dibe ku derbas bibe kursê.
• Ji bo xwendinê jî dê kêrhatî be RFC li ser sêwirana kargehên navenda daneyê ji Facebookê ji hêla Peter Lapukhov ve.
• Belgekirina mîmariyê dê ramanek bide we ka Overlay SDN çawa dixebite. Fabric Tungsten (berê Open Contrail).

Sipas ji were

Girê Roman. Ji bo şîrove û guhertinan.
Artyom Chernobay. Ji bo KDPV.

Source: www.habr.com