CDSM ka përfundoi, por dëshira e pakontrolluar për të shkruar ka mbetur.
Për shumë vite, vëllai ynë vuante nga kryerja e punëve rutinë, duke kaluar gishta përpara komitetit dhe duke mos fjetur për shkak të rikthimeve të natës.
Por erërat e errëta po skadojnë.
Me këtë artikull do të filloj një seri rreth asaj se si mua më duket automatizimi.
Gjatë rrugës ne do të shqyrtojmë fazat e automatizimit, ruajtjen e variablave, formalisimin e dizajnit, me RestAPI, NETCONF, YANG, YDK dhe do të programojmë shumë.
Mua kjo do të thotë se a) kjo nuk është një e vërtetë objektive, b) nuk është qasje e papërsëritshme më e mirë, c) mendimi im madje gjatë kalimit nga artikulli i parë tek ai i fundit mund të ndryshojë - sinqerisht, nga faza e skicës deri në publikim kam shkruar gjithçka dy herë.
PĂ«rmbajtja
- QĂ«llimet
- Rrjeti është si një organizëm i vetëm
- Testimi i konfiguracionit
- Versionimi
- Monitorimi dhe rikuperimi automatik i shërbimeve
- Mjetet
- Sistemi i inventarit
- Sistemi i menaxhimit të hapësirës IP
- Sistemi i përshkrimit të shërbimeve rrjetësore
- Mekanizmi i inicializimit të pajisjeve
- Modeli konfigurues i vendor-agnostik
- Drejtuesi specifik i vendor-interfejsit
- Mekanizmi i shpërndarjes së konfiguracionit në pajisje
- CI/CD
- Mekanizmi i kopjimit të rezervës dhe të gjetjes së devijimeve
- Sistemi i monitorimit
- PĂ«rfundim
ADSM do ta provoj të udhëheq në një format paksa të ndryshëm nga CDSML. Akoma do të shfaqen artikuj të mëdhenj dhe të hollësishëm numra, ndërsa midis tyre do të publikoj shënime të vogla nga praktikën e përditshme. Do të përpiqem të luftoj me perfeksionizmin dhe të mos rregulloj çdo prej tyre.
Sa qesharake është që për herë të dytë duhet të kaloj të njëjtën rrugë.
Fillimisht, duhet të shkruaja vetë artikuj për rrjetet për shkak se ata nuk ishin të pranishëm në runet.
Tani nuk mund ta gjej një dokument gjithëpërfshirës që të sistematizojë qasjet ndaj automatizimit dhe të shqyrtojë teknologjitë e përmendura më sipër me shembuj të thjeshtë praktikë.
Ndoshta gaboj, prandaj, dërgoni lidhje për burime të vlefshme. Megjithatë, kjo nuk do të ndryshojë vendosmërinë time për të shkruar, sepse, qëllimi kryesor është të mësoj diçka për vete, ndërsa lehtësimi i jetës së të tjerëve është një bonus i këndshëm që përkëdheli gjenin e shpërndarjes së përvojës.
Ne do të përpiqemi të marrim një qendër të mesme të të dhënave LAN DC dhe të zhvillojmë tërë skemën e automatizimit.
Disa gjëra do t'i bëj praktikisht për herë të parë me ju.
Në idetë dhe mjetet e përshkruara këtu nuk do të jem origjinal. Dmitry Figol ka një kanal të shkëlqyer .
Artikujt do të kryqëzohen me ta në shumë aspekte.
Në LAN DC ka 4 DC, rreth 250 switch-e, një duzinë router-a dhe disa firewalls.
Nuk është Facebook, por mjaftueshëm për të ndjerë thellësisht nevojën për automatizim.
Megjithatë, ka një mendim se nëse keni më shumë se 1 pajisje, automatizimi është i nevojshëm.
Në realitet, është e vështirë të imagjinohet se dikush mund të jetojë tani pa të paktën një grusht skenari të thjeshtë.
Megjithatë, kam dëgjuar se ka kompani ku regjistrimi i adresave IP bëhet në Excel, dhe çdo një nga mijëra pajisjeve të rrjetit konfigurrohet manualisht dhe ka konfigurimin e saj unik. Kjo, sigurisht, mund të paraqitet si art modern, por ndjenjat e inxhinierit do të ofendohen patjetër.
QĂ«llimet
Tani do të vendosim qëllime sa më abstrakte:
- Rrjeti është si një organizëm i vetëm
- Testimi i konfiguracionit
- Versionimi i gjendjes së rrjetit
- Monitorimi dhe rikuperimi automatik i shërbimeve
Më vonë në këtë artikull do të shqyrtojmë se cilat mjete do të përdorim, dhe në të ardhshmet do të diskutojmë dhe qëllimet dhe mjetet në detaje.
Rrjeti është si një organizëm i vetëm
Fraza përcaktuese e ciklit, edhe pse në pamje të parë mund të duket e parëndësishme: ne do të konfigurojmë rrjetin, jo pajisjet e veçanta.
Gjatë viteve të fundit kemi parë një ndryshim fokusimi drejt trajtimit të rrjetit si një entitet të vetëm, dhe si rezultat kemi Rrjetëzimi i Përcaktuar nga Softueri, Rrjetet e Drejtuara nga Qëllimi dhe Rrjetet Autonomous.
Sepse çfarë kanë nevojë aplikacionet nga rrjeti në mënyrë globale: lidhshmëria midis pikave A dhe B (ndonjëherë +B-Y) dhe izolimi nga aplikacione dhe përdorues të tjerë.
Dhe kështu, detyra jonë në këtë seri është ndërtimi i një sistemi, që mbështet konfigurimin aktual të gjithë rrjetit, që tashmë dekompozohet në konfigurimin aktual në çdo pajisje në përputhje me rolin dhe vendndodhjen e saj.
Sistemi menaxhimi i rrjetit nënkupton se për të bërë ndryshime ne lidhemi me të, dhe ajo në anën e saj llogarit gjendjen e nevojshme për çdo pajisje dhe e konfiguronte atë.
Kështu ne minimizojmë pothuajse në zero shëtitjet në CLI me duar - çdo ndryshim në konfigurimin e pajisjeve ose dizajnin e rrjetit duhet të formizohet dhe dokumentohet - dhe vetëm pastaj të aplikohet në elementet e nevojshme të rrjetit.
Praud, për shembull, nëse kemi vendosur që që nga ky moment, switch-et e kabinetit në Kazan duhet të shpallin dy rrjete në vend të një, ne
- Së pari, dokumentojmë ndryshimet në sisteme
- Generojmë konfigurimin e qëllimshëm për të gjitha pajisjet e rrjetit
- Nisim programin e përditësimit të konfigurimit të rrjetit, i cili llogarit çfarë duhet të hiqet në çdo nod, çfarë duhet të shtohet dhe e çon nodin në gjendjen e kërkuar.
Në këtë rast, ne bëjmë ndryshime me dorë vetëm në hapin e parë.
Testimi i konfiguracionit
, se 80% e problemeve ndodhin gjatë ndryshimit të konfiguracionit - një dëshmi indirekte është se gjatë festave të fundvitit zakonisht gjithçka është qetë.
Personalish kam qenë dëshmitar i dhjetra ndërprerjeve globale për shkak të gabimeve njerëzore: komanda e gabuar, ekzekutimi në degën e gabuar të konfiguracionit, harrimi i komunitetit, fshira globale e MPLS në router, konfigurohen pesë pajisje, ndërsa në të gjashtin nuk e vëmë re gabimin, kemi komituar ndryshimet e vjetra, të bëra nga një person tjetër. Ka mijëra skenarë.
Automatizimi do të na lejojë të bëjmë më pak gabime, por në një shkallë më të madhe. Kështu, mund të bllokojmë jo një pajisje, por të gjithë rrjetin njëherësh.
Që në fillim të kohës, paraardhësit tanë kontrollonin saktësinë e ndryshimeve të bëra me një sy të mprehtë, me një guxim të fortë dhe funksionalitetin e rrjetit pas aplikimit të tyre.
Ata paraardhës, puna e të cilëve çonte në ndalesa dhe humbje katastofike, linin më pak pasardhës dhe duhej të zhdukeshin me kalimin e kohës, por evolucioni është një proces i ngadaltë, dhe prandaj nuk të gjithë e kontrollojnë paraprakisht ndryshimin në laborator.
Megjithatë, në majë të progresit janë ata që kanë automatizuar procesin e testimit të konfiguracionit dhe aplikimin e mëtejshëm të tij në rrjet. Me fjalë të tjera - kanë marrë hua procedurën CI/CD () nga zhvilluesit.
Në një nga pjesët, do të shqyrtojmë si ta realizojmë këtë me një sistem kontrolli versioni, ndoshta GitHub.
Sa herë që të merrni me mendimin për CI/CD rrjetor, në një moment, metoda e kontrollit të konfiguracionit duke e aplikuar në rrjetin e punës do t'ju duket si një injorancë e mesjetës së hershme. Pothuajse si të godasësh me çekiç mbi një kokë bërthamor.
Një vazhdim organik i ideve për sistemit menaxhimin e rrjetit dhe CI/CD është versionimi i plotë i konfiguracionit.
Versionimi
Ne do ta shohim se për çdo ndryshim, madje edhe më të voglin, madje në një pajisje të padukshme, e gjithë rrjeti kalon nga një gjendje në tjetrën.
Dhe ne gjithmonë nuk e realizojmë komandën në pajisje, ne ndryshojmë gjendjen e rrjetit.
Le të quajmë këto gjendje versione?
Supozoni se versioni aktual është 1.0.0.
IP-adresa e intervistĂ«s Loopback ka ndryshuar nĂ« njĂ« nga ToR-tĂ«? Ky Ă«shtĂ« njĂ« version minor â do tĂ« marrĂ« numrin 1.0.1.
Kemi rishikuar politikat e importit tĂ« rrugĂ«ve nĂ« BGP â diçka mĂ« serioze â tashmĂ« Ă«shtĂ« 1.1.0.
Kemi vendosur tĂ« heqim IGP-nĂ« dhe tĂ« kalojmĂ« vetĂ«m nĂ« BGP â kjo Ă«shtĂ« njĂ« ndryshim radikal nĂ« dizajn â 2.0.0.
NĂ« tĂ« njĂ«jtĂ«n kohĂ«, qendrat e tĂ« dhĂ«nave tĂ« ndryshme mund tĂ« kenĂ« versione tĂ« ndryshme â rrjeti zhvillohet, vendoset pajisje e re, diku shtohen nivele tĂ« reja spina, diku â jo, etj.
Për ne do të flasim në një artikull të veçantë.
PĂ«rsĂ«ris â çdo ndryshim (pĂ«rveç komandave tĂ« ndihmĂ«s) Ă«shtĂ« njĂ« pĂ«rditĂ«sim versioni. AdministratorĂ«t duhet tĂ« njoftohen pĂ«r çdo devijim nga versioni aktual.
E njĂ«jta gjĂ« vlen edhe pĂ«r kthimin e ndryshimeve â kjo nuk Ă«shtĂ« anulimi i komandave tĂ« fundit, nuk Ă«shtĂ« rollback me forcat e sistemit operativ tĂ« pajisjes â kjo Ă«shtĂ« sjellja e gjithĂ« rrjetit nĂ« njĂ« version tĂ« ri (tĂ« vjetĂ«r).
Monitorimi dhe rikuperimi automatik i shërbimeve
Kjo është një detyrë e qartë në rrjetet moderne, duke kaluar në një nivel të ri.
shpesh praktikohet nga ofruesit e mëdhenj të shërbimeve se shërbimi i rënë duhet të rregullohet shumë shpejt dhe të ngrihet një i ri, në vend që të merret me atë që ndodhi.
«Shumë» do të thotë se nga të gjitha anët duhet të mbushet me monitorime, që brenda disa sekondave do të zbulojnë më të voglin devijim nga norma.
Dhe këtu nuk mjafton të kesh metrika të njohura, si ngarkesa e intervistës ose disponueshmëria e nyjës. Së bashku nuk është e mjaftueshme që ruajtësi të ndjekë manualisht ato.
PĂ«r shumĂ« gjĂ«ra duhet tĂ« ketĂ« â monitorimet u ndezĂ«n nĂ« tĂ« kuqe dhe shkuan vetĂ« t'i japin ndihmĂ«n, ku dhemb.
Dhe këtu ne gjithashtu monitorojmë jo vetëm pajisje të veçanta, por edhe shëndetin e rrjetit në tërësi, dhe kjo si whitebox, që është relativisht e qartë, ashtu edhe blackbox, që është më e komplikuar.
ĂfarĂ« do na nevojitet pĂ«r tĂ« realizuar kĂ«tĂ« plane ambicioze?
- Të kemi një listë të të gjitha pajisjeve në rrjet, vendndodhjet e tyre, rolet, modelet, versionet e softuerit.
kazan-leaf-1.lmu.net, Kazan, leaf, Juniper QFX 5120, R18.3. - Të kemi një sistem për përshkrimin e shërbimeve rrjetësore.
IGP, BGP, L2/3VPN, Politika, ACL, NTP, SSH. - Të jesh në gjendje të inicializosh pajisjen.
Hostname, Mgmt IP, Mgmt Route, Users, RSA-Keys, LLDP, NETCONF - Të konfigurosh pajisjen dhe ta kesh konfigurimin në versionin e duhur (përfshirë versionin e vjetër).
- TĂ« testosh konfigurimin
- Të kontrollosh rregullisht gjendjen e të gjitha pajisjeve për devijime nga aktualja dhe të njoftosh përkatësin.
Natën dikush qetësisht shtoi një rregull në ACL. - Të monitorosh funksionimin.
Mjetet
Dëgjohet mjaft e komplikuar për të filluar të dekompozosh projektin në komponente.
Dhe do të jenë dhjetë:
- Sistemi i inventarit
- Sistemi i menaxhimit të hapësirës IP
- Sistemi i përshkrimit të shërbimeve rrjetësore
- Mekanizmi i inicializimit të pajisjeve
- Modeli konfigurues i vendor-agnostik
- Drejtuesi specifik i vendor-interfejsit
- Mekanizmi i shpërndarjes së konfiguracionit në pajisje
- CI/CD
- Mekanizmi i kopjimit të rezervës dhe të gjetjes së devijimeve
- Sistemi i monitorimit
Kjo, ndryshe, Ă«shtĂ« njĂ« shembull se si ka ndryshuar vĂ«shtrimi mbi qĂ«llimet e ciklit â nĂ« draftin e komponenteve ishin 4.
Në ilustrim kam ndërtuar të gjitha komponentet dhe vetë pajisjen.
Komponentet e ndërthura bashkëpunojnë me njëra-tjetrën.
Sa më i madh të jetë blloku, aq më shumë vëmendje i duhet dedikuar këtij komponenti.
Komponenti 1. Sistemi i inventarizimit
Sigurisht, dëshirojmë të dimë se cili ekip, ku ndodhet, me çfarë është i lidhur.
Sistemi i inventarizimit është një pjesë e pandashme e çdo ndërrmarrjeje.
Së shumti, për pajisjet rrjet, ndërmarrjet kanë një sistem të veçantë inventarizimi që zgjidh probleme më specifike.
Brenda ciklit tĂ« artikujve ne do ta quajmĂ« kĂ«tĂ« DCIM â Menaxhimi i InfrastrukturĂ«s sĂ« QendrĂ«s sĂ« TĂ« DhĂ«nave. MegjithatĂ«, termi DCIM, nĂ« kuptimin e ngushtĂ«, pĂ«rfshin shumĂ« mĂ« tepĂ«r.
Për ne, në të do të ruajmë informacionin e mëposhtëm për pajisjen:
- Numri i inventarit
- Emri/përshkrimi
- Modeli (Huawei CE12800, Juniper QFX5120 etj)
- Parametrat karakteristikë (platformat, ndërfaqet etj)
- Roli (Leaf, Spine, Border Router etj)
- Lokacioni (rajoni, qyteti, qendra e të dhënave, rafti, uniti)
- Interkonneksionet mes pajisjeve
- Topologjia e rrjetit
E qartë është se edhe neve na intereson të dimë të gjitha këto.
Por, a do t'i ndihmojë kjo në automatikën?
Padyshim.
PĂ«r shembull, ne e dimĂ« qĂ« nĂ« kĂ«tĂ« qendĂ«r tĂ« tĂ« dhĂ«nave nĂ« pajisjet Leaf, nĂ«se Ă«shtĂ« Huawei, ACL pĂ«r filtrimin e trafikut tĂ« caktuar duhet tĂ« aplikohet nĂ« VLAN, dhe nĂ«se Ă«shtĂ« Juniper â atĂ«herĂ« nĂ« unitin 0 tĂ« ndĂ«rfaqes fizike.
Ose duhet të shpërndajmë një server të ri Syslog në të gjitha kufijtë e rajonit.
Aty do të ruajmë edhe pajisjet e rrjetit virtual, për shembuj ruterë virtualë ose reflektorë rrugorë. Mund të shtojmë serverë DNS, NTP, Syslog dhe në përgjithësi gjithçka që lidhet me rrjetin.
Komponenti 2. Sistemi i menaxhimit të hapësirës IP
Po, dhe nĂ« kohĂ«t tona, akoma ka grupe njerĂ«zish qĂ« mbajnĂ« njĂ« regjistĂ«r tĂ« prefikseve dhe IP-adresave nĂ« njĂ« skedar Excel. Por qasja moderne â Ă«shtĂ« njĂ« bazĂ« tĂ« dhĂ«nash, me frontend nĂ« nginx/apache, API dhe funksione tĂ« gjera pĂ«r regjistrimin e IP-adresave dhe rrjeteve me ndarje nĂ« VRF.
IPAM â Menaxhimi i Adresave IP.
Për nevojat tona në të, ne do të ruajmë informacionin e mëposhtëm:
- VLAN
- VRF
- Rrjetet/Podsetet
- Adresa IP
- Lidhja e adresave me pajisjet, rrjetet me lokacionet dhe numrat VLAN
Sërish është e qartë që ne duam të jemi të sigurt që, kur i japim një adresë të re IP për loopback-in e ToR-it, nuk do të hasim ndonjëherë se ajo tashmë është caktuar dikujt tjetër. Ose se e njëjta prefiks e kemi përdorur dy herë në dy skaje të ndryshme të rrjetit.
Por si do të ndihmojë kjo në automatizim?
Lehtë.
KĂ«rkojmĂ« nĂ« sistem njĂ« prefiks me rolin Loopbacks, nĂ« tĂ« cilin ka adresa IP tĂ« disponueshme pĂ«r caktim â nĂ«se gjendet, e cakoim adresĂ«n, nĂ«se jo, kĂ«rkojmĂ« krijimin e njĂ« prefiksi tĂ« ri.
Ose gjatë krijimit të konfiguracionit të pajisjes, ne mund të zbulojmë nga i njëjti sistem në cilin VRF duhet të ndodhet ndërfaqja.
Dhe gjatĂ« aktivizimit tĂ« njĂ« serveri tĂ« ri, skripti shkon nĂ« sistem, zbulohet nĂ« cilin switch server, nĂ« cilin port dhe cila podshet Ă«shtĂ« caktuar pĂ«r ndĂ«rfaqen â nga aty do tĂ« caktohet adresa e serverit.
Dëshira për të bashkuar DCIM dhe IPAM në një sistem po lind, për të shmangur funksionet e dyfishuara dhe për të menaxhuar dy entitete të ngjashme.
Kështu do ta bëjmë.
Komponenti 3. Sistemi i përshkrimit të shërbimeve rrjetësore
Nëse dy sistemet e para ruajnë variablat, të cilat duhet të përdoren ndryshe, atëherë e treta përshkruan për çdo rol pajisjeje, se si duhet të konfigurohet.
Duhet të dallojmë dy lloje të ndryshme të shërbimeve rrjetësore:
- Infrastrukturore
- Klientore.
Të parat kanë për qëllim të sigurojnë lidhshmërinë dhe menaxhimin e pajisjes. Këtu përfshihen VTY, SNMP, NTP, Syslog, AAA, protokollet e rrugëzimit, CoPP, etj.
Të dytat organizojnë një shërbim për klientin: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, etj.
Natyrisht, ka edhe raste tĂ« kufizuara â si do ta klasifikojmĂ« MPLS LDP, BGP? Dhe protokollet e rrugĂ«zimit mund tĂ« pĂ«rdoren pĂ«r klientĂ«t. Por kjo nuk Ă«shtĂ« thelbĂ«sore.
Të dyja llojet e shërbimeve ndahen në primitive konfigurimi:
- ndërfaqet fizike dhe logjike (tag/anteg, mtu)
- IP-adresat dhe VRF (IP, IPv6, VRF)
- ACL dhe politikat e trajtimit të trafikëve
- Protokollet (IGP, BGP, MPLS)
- Politikat e rrugëzimit (listat e prefikseve, komunitetet, filtrat ASN).
- ShĂ«rbimet operative (SSH, NTP, LLDP, SyslogâŠ)
- Etj.
Si e bëjmë këtë, nuk kam idea për momentin. Do ta shqyrtojmë në një artikull të veçantë.
Nëse e shohim nga një këndvështrim më të afërt me realitetin, mund të përshkruajmë se
Switch-i Leaf duhet të ketë sesione BGP me të gjithë switch-at Spine të lidhur, të importe themi në proces rrjetet e lidhura, duke pranuar nga switch-at Spine vetëm rrjetet me një prefiks të caktuar. Të kufizojmë CoPP IPv6 ND në 10 pps etj.
Nga ana e saj, spine-t mbajnë sesione me të gjithë leaf-at e lidhur, duke vepruar si reflektorë rrënjësorë dhe pranojnë vetëm rrugët me një gjatësi të caktuar dhe me një komunitet të caktuar nga ata.
Komponenti 4. Mekanizmi i inicializimit të pajisjes
Nën këtë titull unë bashkoj shumë veprime që duhet të ndodhin në mënyrë që pajisja të shfaqet në radar dhe të jetë e mundur të arrihet në distancë.
- Të regjistrosh pajisjen në sistemin e inventarit.
- Të alokosh një adresë IP për menaxhim.
- Të konfigurosh aksesin bazë në të:
Emri i host-it, adresa IP pĂ«r menaxhim, rruga nĂ« rrjetin e menaxhimit, pĂ«rdoruesit, çelĂ«sat SSH, protokollet â telnet/SSH/NETCONF
Këtu ekzistojnë tri qasje:
- Totali manual. Pajisja është sjellë në një stendë, ku një njeri normal do ta regjistrojë në sistem, do të lidhet me konsolën dhe do ta konfigurojë. Mund të funksionojë në rrjete të vogla statike.
- ZTP â Zero Touch Provisioning. Pajisja ka arritur, Ă«shtĂ« vendosur, ka marrĂ« njĂ« adresĂ« pĂ«rmes DHCP, Ă«shtĂ« lidhur me njĂ« server tĂ« veçantĂ« dhe Ă«shtĂ« konfiguruar vetĂ«.
- Infrastruktura e serverëve të konsolës, ku konfigurimi fillestar ndodh në mënyrë automatike përmes portit të konsolës.
Për të treja do flasim në një artikull të veçantë.
Komponenti 5. Modeli i konfigurimit vendor-agnostik
Deri tani të gjitha sistemet kanë qenë copëza të ndara, duke ofruar përshkrimin variabël dhe deklarativ të asaj që do donim të shihnim në rrjet. Por, herët ose vonë, do të duhet të merremi me konkretësinë.
Në këtë etapë, për çdo pajisje specifike, primitive, shërbimet dhe variablat kombinohen në një model konfiguracioni, që përshkruan në fakt konfigurimin e plotë të pajisjes specifike, vetëm në një mënyrë që nuk varet nga shitësi.
ĂfarĂ« sjell ky hap? Pse tĂ« mos formohej menjĂ«herĂ« konfigurimi i pajisjes qĂ« mund tĂ« ngarkohej lehtĂ«?
Në të vërtetë, kjo lejon zgjidhjen e tri detyrave:
- Mos u akomodoni me njĂ« ndĂ«rfaqe tĂ« caktuar pĂ«r tĂ« bashkĂ«vepruar me pajisjen. QoftĂ« CLI, NETCONF, RESTCONF, SNMP â modelit do tĂ« mbetet i njĂ«jtĂ«.
- Mos mbani numrin e shablloneve/skripteve në numrin e furnizuesve në rrjet, dhe në rast të ndryshimit të dizajnit, ndryshoni të njëjtën gjë në disa vende.
- Shkarkoni konfigurimin nga pajisja (rezerva), organizojeni në një model të saktë dhe përpiquni të krahasoni konfigurimin e synuar me atë ekzistues për të llogaritur diferencën dhe për të përgatitur një patch konfigurimi, i cili do të ndryshojë vetëm ato pjesë që nevojiten ose për të identifikuar devijimet.
Si rezultat i këtij hapi, ne marrim një konfigurim të pavarur nga furnizuesi.
Komponenti 6. Drejtues specifik për interfacing të furnizuesit
Mos i jepni shpresë vetes se ndonjëherë do të jetë e mundur të konfiguroni Cisco në të njëjtën mënyrë si Juniper, thjesht duke i dërguar atyre thirrje të njëjta. Pavarësisht njohjes në rritje të whitebox-ëve dhe mbështetjes për NETCONF, RESTCONF, OpenConfig, përmbajtja specifike që këto protokolle ofrojnë ndryshon nga furnizuesi në furnizues, dhe kjo është një nga dallimet e tyre konkurruese, që ata nuk do ta dorëzojnë lehtë.
Në mënyrë të ngjashme, OpenContrail dhe OpenStack, të cilat kanë RestAPI si ndërfaqen e tyre NorthBound, presin thirrje krejt të ndryshme.
Pra, në hapin e pestë modeli i pavarur nga furnizuesi duhet të marrë formën që do të shkojë në harduer.
Dhe këtu të gjitha mjetet janë të mira (jo): CLI, NETCONF, RESTCONF, SNMP, një shpjegues i thjeshtë.
Prandaj, do të na nevojitet një drejtues i cili do ta transformojë rezultatin e hapit të mëparshëm në formatin e nevojshëm për një furnizues të caktuar: një grup urdhërash CLI, strukturën XML.
Komponenti 7. Mekanizmi i paketimit të konfigurimit në pajisje
Pra, ne e kemi krijuar konfigurimin, por duhet ta dĂ«rgojmĂ« atĂ« nĂ« pajisje â dhe, natyrisht, jo me duar.
Së pari, na del këtu pyetja, çfarë transporti do të përdorim? Dhe zgjedhja sot nuk është e vogël:
- CLI (telnet, ssh)
- SNMP
- NETCONF
- RESTCONF
- REST API
- OpenFlow (edhe pse ai del nga lista, pasi është një mënyrë për të dërguar FIB, jo konfigurime)
Le të sqarojmë disa gjëra këtu. CLI është e vjetër. SNMP⊠ahem.
RESTCONF â njĂ« krijesĂ« ende e panjohur, REST API mbĂ«shtetet nga gati askush. Prandaj, nĂ« ciklin tonĂ« do tĂ« fokusohmi nĂ« NETCONF.
NĂ« tĂ« vĂ«rtetĂ«, siç e kuptoi lexuesi, ne nĂ« kĂ«tĂ« moment tashmĂ« kemi vendosur pĂ«r ndĂ«rfaqen â rezultati i hapit tĂ« mĂ«parshĂ«m Ă«shtĂ« shfaqur nĂ« formatin e asaj ndĂ«rfaqe qĂ« u zgjodh.
Së dyti, por me cilat mjete do ta bëjmë këtë?
Këtu zgjedhja është gjithashtu e madhe:
- NjĂ« skript i krijuar vetĂ« ose njĂ« platformĂ«. TĂ« armatosim ncclient dhe asyncIO dhe ta bĂ«jmĂ« vetĂ«. ĂfarĂ« na pengon tĂ« ndĂ«rtosh sistemin e deploy-it nga zero?
- Ansible me bibliotekën e tij të pasur të moduleve rrjetë.
- Salt me punën e tij të varfër me rrjetin dhe lidhjen me Napalm.
- Në vetë Napalm, i cili njeh vetëm disa furnizues, dhe përfundon kështu.
- Nornir â njĂ« tjetĂ«r kafshĂ«, tĂ« cilĂ«n ne do ta analizojmĂ« nĂ« tĂ« ardhmen.
KĂ«tu ende nuk Ă«shtĂ« zgjedhur njĂ« favorit â do tĂ« eksperimentojmĂ«.
ĂfarĂ« tjetĂ«r Ă«shtĂ« e rĂ«ndĂ«sishme kĂ«tu? Pasojat e aplikimit tĂ« konfiguracionit.
Me sukses apo jo. A ka mbetur akses në pajisje apo jo.
Duket se këtu ndihmon commit-i me konfirmimin dhe verifikimin e asaj që u ngarkua në pajisje.
Kjo sĂ« bashku me realizimin e duhur tĂ« NETCONF ngushton ndjeshĂ«m grupin e pajisjeve tĂ« pĂ«rshtatshme â komitetet normale nuk mbĂ«shteten nga shumĂ« prodhues. Por kjo Ă«shtĂ« thjesht njĂ« nga kushtet e obligueshme nĂ« . NĂ« fund tĂ« fundit, askush nuk shqetĂ«sohet se asnjĂ« furnizues rus nuk do tĂ« plotĂ«sojĂ« kushtin e 32*100GE ndĂ«rfaqes. Apo njeri shqetĂ«sohet?
Komponenti 8. CI/CD
Në këtë moment, ne tashmë kemi përfunduar konfigurimin për të gjitha pajisjet e rrjetit.
Po shkruaj «pĂ«r tĂ« gjitha», sepse po flasim pĂ«r versionimin e gjendjes sĂ« rrjetit. Dhe edhe nĂ«se duhet tĂ« ndĂ«rohet konfigurimi i njĂ« vetĂ«m switch, ndryshimet pĂ«r tĂ« gjithĂ« rrjetin llogariten. ĂshtĂ« e qartĂ«, ata mund tĂ« jenĂ« zero pĂ«r shumicĂ«n e nyjeve.
Por, siç u tha më parë, ne nuk jemi barbarë që të hedhim gjithçka menjëherë në prodhim.
Konfigurimi i krijuar duhet së pari të kalojë përmes Pipeline CI/CD.
CI/CD do të thotë Integrim të Vazhdimit, Deploy të Vazhdimit. Ky është një qasje, ku ekipi nuk publikonte një version të ri kryesor çdo gjashtë muaj, duke zëvendësuar plotësisht të vjetrit, por implementon rregullisht inkuadrime të reja (Deployment) në mënyrë të vogël, të cilat testohen në mënyrë të plotë për përputhshmëri, siguri dhe funksionalitet (Integration).
PĂ«r kĂ«tĂ«, ne kemi njĂ« sistem kontrolli versioni qĂ« monitoron ndryshimet nĂ« konfigurim, njĂ« laborator ku kontrollohet nĂ«se shĂ«rbimi i klientit nuk prishet, njĂ« sistem monitorimi qĂ« verifikon kĂ«tĂ« fakt, dhe hapi pĂ«rfundimtar â publikimi i ndryshimeve nĂ« rrjetin aktiv.
PĂ«rveç komandave tĂ« dehjes, tĂ« gjitha ndryshimet nĂ« rrjet duhet tĂ« kalojnĂ« pĂ«rmes CI/CD Pipeline â kjo Ă«shtĂ« çelĂ«si ynĂ« pĂ«r njĂ« jetĂ« tĂ« qetĂ« dhe njĂ« karrierĂ« tĂ« gjatĂ« e tĂ« lumtur.
Komponenti 9. Sistemi i kopjeve rezervë dhe kërkimit të devijimeve
Nuk ka nevojë të flasim edhe njëherë për kopjet rezervë.
Ne do tâi ruajmĂ« ato nĂ«pĂ«rmjet cron-it ose me rastin e ndryshimit tĂ« konfiguracionit nĂ« git.
Por pjesa e dytĂ« Ă«shtĂ« mĂ« interesante â pas kĂ«tyre kopjeve rezervĂ« dikush duhet tĂ« qĂ«ndrojĂ« nĂ« qendĂ«r. NĂ« disa raste, ai dikush duhet tĂ« shkojĂ« dhe tĂ« kthejĂ« gjithçka siç ishte, dhe nĂ« disa tĂ« tjera, duhet tĂ« informojĂ« dikĂ« se ndodhi njĂ« problem.
PĂ«r shembull, nĂ«se shfaqet ndonjĂ« pĂ«rdorues i ri qĂ« nuk Ă«shtĂ« regjistruar nĂ« variabla, duhet ta heqim atĂ« nga haku. Po ashtu, nĂ«se ka njĂ« rregull tĂ« ri pĂ«r firewall-in â Ă«shtĂ« mĂ« mirĂ« tĂ« mos e prekim atĂ«, ndoshta dikush thjesht aktivizoi dehjen, ose ndoshta njĂ« shĂ«rbim i ri, qĂ« nuk Ă«shtĂ« regjistruar sipas rregullave, po pĂ«rpiqet ta bĂ«jĂ« kĂ«tĂ«.
Megjithatë, nga një delta e vogël në përmasat e rrjetit të gjithë, ne nuk do të ikim, pavarësisht nga çdo sistem automatizimi dhe dora e fortë e menaxhimit. Për zgjidhjen e problemeve, askush nuk do ta vendosë konfigurimin në sisteme. Sidomos pasi modeli i konfigurimit mund të mos e parashikojë këtë.
PĂ«r shembull, rregulli i firewall-it pĂ«r llogaritjen e numrit tĂ« paketave nĂ« njĂ« IP tĂ« caktuar, pĂ«r lokalizimin e problemit â Ă«shtĂ« njĂ« konfigurim i pĂ«rkohshĂ«m mjaft normal.
Komponenti 10. Sistemi i monitorimit
Fillimisht, nuk kisha ndĂ«rmend tĂ« diskutoja temĂ«n e monitorimit â pĂ«r shkak se Ă«shtĂ« njĂ« temĂ« e gjerĂ«, e diskutueshme dhe e komplikuar. Por gjatĂ« rrugĂ«s, u shpĂ«rbĂ« se ajo Ă«shtĂ« njĂ« pjesĂ« e patjetĂ«rsueshme e automatizimit. Dhe nuk mund ta anashkalosh kĂ«tĂ« temĂ« edhe pa praktikĂ«.
Duke zhvilluar mendimin â ajo Ă«shtĂ« njĂ« pjesĂ« organike e procesit CI/CD. Pas publikimit tĂ« konfigurimit nĂ« rrjet, na nevojitet tĂ« dimĂ« tĂ« pĂ«rcaktojmĂ« nĂ«se gjithçka Ă«shtĂ« nĂ« rregull tani.
Dhe nuk bĂ«het fjalĂ« vetĂ«m pĂ«r grafikĂ«t e pĂ«rdorimit tĂ« ndĂ«rfaqeve ose pĂ«rDisponibilitetin e nyjeve, por pĂ«r gjĂ«ra mĂ« tĂ« ndjeshme â praninĂ« e rrugĂ«ve tĂ« duhura, atributeve mbi to, numrin e seancave BGP, fqinjĂ«ve OSPF, funksionalitetin End-to-End tĂ« shĂ«rbimeve mĂ« tĂ« larta.
Mos ndalojnë së grumbulluari log-et në serverin e jashtëm, a nuk është prishur agjenti SFlow, a nuk kanë filluar të rriten drop-et në radhë, a nuk është ndërlikuar lidhja mes ndonjë cifti prefix-esh?
Në një artikull të veçantë do të mendojmë edhe mbi këtë.
PĂ«rfundim
Si bazĂ« kam zgjedhur njĂ« nga dizajnet modern tĂ« rrjetit tĂ« qendrĂ«s sĂ« tĂ« dhĂ«nave â L3 Clos Fabric me BGP si protokoll rrugĂ«zimi.
Rrjetin do ta ndërtojmë këtë herë mbi Juniper, sepse tani ndërfare JunOs është një lal.
Do ta vĂ«shtirĂ«sojmĂ« jetĂ«n duke pĂ«rdorur vetĂ«m mjete Open Source dhe njĂ« rrjet multivendor â kĂ«shtu qĂ« pĂ«rveç Juniper do tĂ« zgjedh edhe njĂ« fatlum tjetĂ«r nĂ« proces.
Plani për publikimet e afërta është rreth kësaj:
Së pari, do të flas për rrjetet virtuale. Në radhë të parë, sepse më pëlqen, dhe në të dytë, sepse pa këtë dizajni i rrjetit infrastrukturor nuk do të jetë shumë i kuptueshëm.
Më pas, në fakt do të flas për dizajnin e rrjetit: topologjinë, rrugëzimin, politikën.
Do të grumbullojmë një laborator.
Do të mendojmë dhe, ndoshta, do të praktikojmë në inicializimin e pajisjes në rrjet.
Dhe më pas për çdo komponent në detaje intime.
Po ashtu, nuk premtoj qĂ« do ta pĂ«rfundoj kĂ«tĂ« cikĂ«l me njĂ« zgjidhje tĂ« gatshme. đ
Useful links
- Para se të thellohemi në këtë seri, ia vlen të lexoni librin e Natasha Samoylenko . Dhe, ndoshta, ta kaloni .
- Do të jetë gjithashtu e dobishme të lexoni për dizajnin e fabrikave të qendrës së të dhënave nga Facebook i shkruar nga Petr Lapukhov.
- Si funksionon SDN me Overlay do t'ju japë një ide dokumentacioni mbi arkitekturën (më parë Open Contrail).
Faleminderit
Roman Gorge. PĂ«r komentet dhe ndryshimet.
Artyom Chernobai. PĂ«r KDPV.
Burimi: habr.com
