ProHoster > Blog > Administrimi > Automatizimi për të vegjlit. Pjesa zero. Planifikimi.

Automatizimi për të vegjlit. Pjesa zero. Planifikimi.

CSM përfundoi, por dëshira pa kontroll për të shkruajtur mbeti.

Automatizimi për të vegjlit. Pjesa zero. Planifikimi.

Në shumë vite, vëllai ynë vuajti nga kryerja e punëve rutinore, çdo herë duke kryqëzuar gishtat para komitimit dhe duke e kaluar natën për shkak të rrotullimeve.
Por, fundi i kohëve të errëta po vjen.

Me këtë artikull, unë do të filloj një seri rreth asaj se si informoni. shikohet automazizimi.
Gjatë procesit do të shqyrtojmë fazat e automatizimit, ruajtjen e variablëve, formalisimin e dizajnit, duke përfshirë RestAPI, NETCONF, YANG, YDK dhe do të programojmë shumë.
Mua do tĂ« thotĂ« se a) kjo nuk Ă«shtĂ« e vĂ«rteta objektive, b) nuk Ă«shtĂ« qasja mĂ« e mirĂ« pa diskutim, c) mendimi im mund tĂ« ndryshojĂ« edhe gjatĂ« kalimit nga artikulli i parĂ« nĂ« atĂ« tĂ« fundit — sinqerisht, nga faza e draftit deri nĂ« publikim, unĂ« e kam shkruar gjithçka plotĂ«sisht dy herĂ«.

PĂ«rmbajtja

  1. QĂ«llimet
    1. Rrjeti — si njĂ« organizĂ«m i vetĂ«m
    2. Testimi i konfiguracionit
    3. Versionimi
    4. Monitorimi dhe vetë-riparimi i shërbimeve

  2. Mjetet
    1. Sistemi i inventarit
    2. Sistemi i menaxhimit të hapësirës IP
    3. Sistemi i përshkrimit të shërbimeve të rrjetit
    4. Mekanizmi i inicializimit të pajisjeve
    5. Modeli i konfigurimit i pa-ndërkombëtar
    6. Drejtuesi i specifik për ndërprerësin e rendit
    7. Mekanizmi i dorëzimit të konfiguracionit në pajisje
    8. CI/CD
    9. Mekanizmi i backup-it dhe gjetjes së devijimeve
    10. Sistemi i monitorimit

  3. PĂ«rfundimi

Unë do të përpiqem të udhëheq ADSN në një format pak më të ndryshëm nga CSDM. Do të ketë ende artikuj të mëdhenj dhe përplotësues, dhe midis tyre do të publikoj shënime të vogla nga përvoja e përditshme. Do të përpiqem të luftoj me perfeksionizmin dhe të mos i poliroj të gjitha ato.

Si është e çuditshme që për herë të dytë duhet të kalojmë të njëjtin rrugë.

Fillimisht duhej të shkruaja artikuj për rrjetet vetë, për shkak se nuk kishte në Ruset.

Tani nuk mund të gjej një dokument të gjithanshëm që sistematizonte qasjet për automatizimin dhe shqyrtonte teknologjitë e lartë të përmendura me shembuj praktik.

Ndoshta gaboj, prandaj, dërgoni lidhje për burime të dobishme. 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 veten, ndërsa lehtësimi i jetës për të tjerët është një bonus i këndshëm që miraton shpërndarjen e njohurive.

Ne do të përpiqemi të marrim një qendër të mesme të të dhënave LAN DC dhe të punojmë me të gjithë skemën e automatizimit.
Disa gjëra do t'i bëj praktikisht për herë të parë së bashku me ju.

Në idetë dhe mjetet e përshkruara këtu nuk do të jem origjinal. Dmitri Figol ka një kanal të shkëlqyer me transmetime mbi këtë temë.
Artikujt do të përputhen me to në shumë aspekte.

Në LAN DC ka 4 DC, rreth 250 switch-e, gjashtë router-a dhe disa firewall-a.
Nuk është Facebook, por mjaftueshëm për të menduar thellë për automatizimin.
Megjithatë, besohet se nëse keni më shumë se 1 pajisje, automatizimi është i nevojshëm.
Në të vërtetë, është e vështirë të imagjinosh se dikush tani mund të jetojë pa as edhe një grup skenash të gotit.
Megjithatë, kam dëgjuar se ka kompani që menaxhojnë adresat IP në Excel, dhe çdo një nga mijëra pajisjeve rrjet krijohet manualisht dhe ka një konfiguracion unik. Kjo, sigurisht, mund të duket si art modern, por ndjenjat e inxhinierit do të ofendohen.

QĂ«llimet

Tani ne do të vendosim objektivat më abstraktë:

  • Rrjeti — si njĂ« organizĂ«m i vetĂ«m
  • Testimi i konfiguracionit
  • Versionimi i gjendjes sĂ« rrjetit
  • Monitorimi dhe vetĂ«-riparimi 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ë jemi të detajuar si qëllimet, ashtu edhe mjetet.

Rrjeti — si njĂ« organizĂ«m i vetĂ«m

Fraza përcaktuese e ciclit, ndonëse në pamje të parë mund të duket e parëndësishme: ne do të konfigurojmë rrjetin dhe jo pajisjet e veçanta.
Gjatë viteve të fundit, ne kemi vërejtur një kalim të theksit në trajtimin e rrjetit si një entitet të vetëm, nga ku vijnë Rrjetet e Definuara nga Softueri, Rrjetet e Drejtuara nga Qëllimi dhe Rrjetet Autonomë.
Sepse çfarë është e nevojshme për aplikacionet nga rrjeti: lidhje midis pikave A dhe B (ndonjëherë +B-Y) dhe izolim nga aplikacione dhe përdorues të tjerë.

Automatizimi për të vegjlit. Pjesa zero. Planifikimi.

Kështu detyra jonë në këtë seri është ndërtimi i një sistemi, që mbështet konfigurimin aktual të gjithë rrjetit, i cili tashmë dekompozitohet në konfigurimin aktual të çdo pajisjeje sipas rolit dhe vendndodhjes së saj.
Sistemi menaxhimi i rrjetit nënkupton se për të bërë ndryshime ne drejtohemi te ai, dhe ai përkatësisht llogarit gjendjen e nevojshme për çdo pajisje dhe e konfiguron atë.
NĂ« kĂ«tĂ« mĂ«nyrĂ«, ne minimizojmĂ« pothuajse deri nĂ« zero shkuarjen nĂ« CLI me duar — çdo ndryshim nĂ« konfigurimet e pajisjeve ose nĂ« dizajnin e rrjetit duhet tĂ« formalizohet dhe dokumentohet — dhe vetĂ«m atĂ«herĂ« tĂ« shpĂ«rndahen nĂ« elementĂ«t pĂ«rkatĂ«s tĂ« rrjetit.

Kështu, për shembull, nëse ne vendosëm se që nga ky moment, switch-et në Kazan duhet të ndajë dy rrjete në vend të njëi, ne

  1. Së pari dokumentojmë ndryshimet në sisteme
  2. Generojmë konfigurimin qëllimor të të gjitha pajisjeve në rrjet
  3. Nisin programin e përditësimit të konfigurimit të rrjetit, i cili llogarit se çfarë duhet të hiqet në secilën nyje, çfarë duhet të shtohet, dhe e sjell nyjen në gjendjen e duhur.

Në këtë rast, ne bëjmë ndryshime vetëm në hapin e parë.

Testimi i konfiguracionit

ËshtĂ« e njohur, se 80% e problemeve ndodhin gjatĂ« ndryshimit tĂ« konfigurimit — njĂ« dĂ«shmi e tĂ«rthortĂ« Ă«shtĂ« se gjatĂ« festave tĂ« Vitit tĂ« Ri zakonisht gjithçka Ă«shtĂ« e qetĂ«.
Unë vetë kam qenë dëshmitar i dhjetëra vazhdimësive globale për shkak të gabimeve të njeriut: urdhri i gabuar, u ekzekutua në një degë të papërshtatshme të konfigurimit, harroi komunitetin, hoqi MPLS globalisht në router, konfiguroi pesë pajisje, dhe në të gjashtën nuk e vuri re gabimin, angazhoi ndryshimet e vjetra, të bëra nga një person tjetër. Skenarët janë të shumtë.

Automatizimi do na ndihmojë të bëjmë më pak gabime, por në shkallë më të madhe. Kështu mund të bllokosh jo një pajisje, por të gjithë rrjetin njëherësh.

Që nga antikiteti, paraardhësit tanë verifikonin saktësinë e ndryshimeve të bëra me një sy të mprehtë, me guxim dhe funksionalitetin e rrjetit pas lançimit të tyre.
Ata paraardhës, të cilët punët e tyre çonin në ndalesa dhe humbje katastrofike, lanë më pak pasardhës dhe duhet të vdesin me kalimin e kohës, por evolucioni është një proces i ngadaltë, dhe për këtë arsye ende nuk të gjithë i kontrollojnë paraprakisht ndryshimet në laborator.
MegjithatĂ«, nĂ« skajin e pĂ«rparimit janĂ« ata qĂ« automatizuan procesin e testimit tĂ« konfigurimeve dhe aplikimin e saj mĂ« pas nĂ« rrjet. NĂ« terma tĂ« tjerĂ« — huazuan procedurĂ«n CI/CD (Integrimi i PandĂ«rprerĂ«, Implementimi i PandĂ«rprerĂ«) nga zhvilluesit.
Në një nga pjesët ne do të shqyrtojmë si ta realizojmë këtë me sistemin e kontrollit të versioneve, ndoshta GitHub.

Sapo të pajtoheni me konceptin e CI/CD rrjetor, metoda e verifikimit të konfigurimit duke e aplikuar në rrjetin punues do t'ju duket një injorancë e epokës së hershme. Ashtu si të godasësh me një çekiç një kokë shpërthyese.

Një vazhdim organik i ideve për sistemin menaxhimin e rrjetit dhe CI/CD është versionimi i plote i konfigurimeve.

Versionimi

Ne do të supozomë se për çdo ndryshim, madje edhe për ato më të pandjeshme, madje në një pajisje të padukshme, e gjithë rrjeti kalon nga një gjendje në një tjetër.
Dhe ne gjithmonë nuk ekzekutojmë komandën në pajisje, ne ndryshojmë gjendjen e rrjetit.
Le të quajmë këto gjendje versione?

Të supozojmë se versioni aktual është 1.0.0.
Ndryshoi adresa IP e interfesĂ«s Loopback nĂ« njĂ« nga ToR'Ă«t? Kjo Ă«shtĂ« njĂ« version minor — do tĂ« marrĂ« numrin 1.0.1.
Rishikuam politikat e importit tĂ« rrugĂ«ve nĂ« BGP — disi mĂ« serioze — tashmĂ« 1.1.0
VendosĂ«m tĂ« heqim IGP dhe tĂ« kalojmĂ« vetĂ«m nĂ« BGP — kjo Ă«shtĂ« njĂ« ndryshim radikal dizajni — 2.0.0.

NĂ« tĂ« njĂ«jtĂ«n kohĂ«, qendrat e tĂ« dhĂ«nave tĂ« ndryshme mund tĂ« kenĂ« versione tĂ« ndryshme — rrjeti po zhvillohet, po vendoset pajisje tĂ« reja, diku po shtohen nivele tĂ« reja spajini, diku — jo, etj.

Për versionimi semantik do të flasim në një artikull të veçantë.

TĂ« pĂ«rsĂ«ris — çdo ndryshim (pĂ«rveç komandave pĂ«r diagnostikim) Ă«shtĂ« pĂ«rditĂ«sim versioni. Administratoret duhet tĂ« njoftohen pĂ«r çdo devijim nga versioni aktual.

E njĂ«jta gjĂ« vlen pĂ«r rikthimin e ndryshimeve — nuk Ă«shtĂ« anulimi i komandave tĂ« fundit, nuk Ă«shtĂ« rikthimi me forcĂ« tĂ« sistemit operativ tĂ« pajisjes — Ă«shtĂ« trajtimi i tĂ« gjithĂ« rrjetit nĂ« njĂ« version tĂ« ri (tĂ« vjetĂ«r).

Monitorimi dhe vetë-riparimi i shërbimeve

Kjo është një detyrë e qartë në rrjetet moderne që po del në një nivel të ri.
Shpesh, te ofruesit e mëdhenj të shërbimeve praktikoheshin ato që duhet ta tregojmë të rënë shërbimin shumë shpejt dhe të ngremë një të ri, në vend që të merremi me atë që ndodhi.
"Shumë" do të thotë se nga të gjitha anët duhet të mbushim me monitoring që brenda disa sekondash do të zbulojnë çdo devijim të vogël nga norma.
Dhe këtu nuk janë të mjaftueshme metrikat e zakonshme, si p.sh. ngarkesa e interfesës ose disponueshmëria e nyjës. Nuk është e mjaftueshme as ndjekja manuale e robit për to.
PĂ«r shumĂ« gjĂ«ra, duhet tĂ« kemi VetĂ«-ShĂ«rim — monitorimet ndriçohen nĂ« tĂ« kuqe dhe shkojnĂ« vetĂ« tĂ« vendosin njĂ« bandazh aty ku dhemb.

Edhe këtu ne monitorojmë jo vetëm pajisje të veçanta, por edhe shëndetin e rrjetit në përgjithësi, si në formën e bardhë, që është relativisht e qartë, ashtu edhe në formën e zezë, e cila është më e komplikuar.

ÇfarĂ« na nevojitet pĂ«r tĂ« realizuar kĂ«to plane ambicioze?

  • TĂ« kemi njĂ« listĂ« tĂ« tĂ« gjitha pajisjeve nĂ« rrjet, pozitat 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 tĂ« rrjetit.
    IGP, BGP, L2/3VPN, Politika, ACL, NTP, SSH.
  • TĂ« dimĂ« si tĂ« inicializojmĂ« pajisjen.
    Emri i hostit, IP menaxhimi, Routes menaxhimi, PĂ«rdoruesit, ÇelĂ«sat RSA, LLDP, NETCONF
  • TĂ« konfigurojmĂ« pajisjen dhe ta sjellim konfigurimin nĂ« versionin e dĂ«shiruar (pĂ«rfshirĂ« atĂ« tĂ« vjetĂ«r).
  • TĂ« testojmĂ« konfigurimin
  • Kontrolloni periodikisht gjendjen e tĂ« gjitha pajisjeve pĂ«r t'u siguruar qĂ« ato nuk shkulin nga aktualiteti dhe informoni ata qĂ« duhet.
    Disa shtoi një rregull në ACL gjatë natës..
  • Vazhdo tĂ« monitorosh funksionimin.

Mjetet

Duket mjaft kompleks për të filluar të dekompozosh projektin në komponentët e tij.

Dhe do të jenë dhjetë:

  1. Sistemi i inventarit
  2. Sistemi i menaxhimit të hapësirës IP
  3. Sistemi i përshkrimit të shërbimeve të rrjetit
  4. Mekanizmi i inicializimit të pajisjeve
  5. Modeli i konfigurimit i pa-ndërkombëtar
  6. Drejtuesi i specifik për ndërprerësin e rendit
  7. Mekanizmi i dorëzimit të konfiguracionit në pajisje
  8. CI/CD
  9. Mekanizmi i backup-it dhe gjetjes së devijimeve
  10. Sistemi i monitorimit

SĂ« shpejti, ky Ă«shtĂ« njĂ« shembull se si Ă«shtĂ« ndryshuar perceptimi ndaj objekteve tĂ« ciklit — nĂ« skicĂ«n e komponentĂ«ve ishin 4.

Automatizimi për të vegjlit. Pjesa zero. Planifikimi.

Në ilustrim kam paraqitur të gjitha komponentët dhe pajisjen përkatëse.
Komponentët e ndërthurur bashkëveprojnë me njëri-tjetrin.
Sa më i madh të jetë blloku, aq më shumë vëmendje duhet t'i kushtohet këtij komponenti.

Komponenti 1. Sistemi i inventarit

Natyrisht, ne duam të dimë se cilat pajisje ndodhen, ku janë të vendosura dhe në çfarë lidhjesh janë.
Sistemi i inventarit është një pjesë thelbësore e çdo ndërmarrjeje.
Shpesh, për pajisjet rrjet, ndërmarrjet kanë një sistem inventari të veçantë që adresa më specifike.
NĂ« kuadĂ«r tĂ« kĂ«tij cikli artikujsh do ta quajmĂ« kĂ«tĂ« DCIM — Menaxhimi i InfrastrukturĂ«s sĂ« QendrĂ«s sĂ« tĂ« DhĂ«nave. MegjithatĂ«, termi DCIM pĂ«rfshin shumĂ« mĂ« tepĂ«r se kaq.

Për nevojat tona në këtë sistem do të ruajmë informacionin e mëposhtëm për pajisjet:

  • Numri i inventarit
  • Emri/opis
  • Modeli (Huawei CE12800, Juniper QFX5120 etj.)
  • Parametrat karakteristikĂ« (tĂ« pllakave, ndĂ«rfaqeve etj.)
  • Roli (Leaf, Spine, Border Router etj.)
  • Lokacioni (rajoni, qyteti, qendra e tĂ« dhĂ«nave, rafti, njĂ«si.)
  • Interkonnekset midis pajisjeve
  • Topologjia e rrjetit

Automatizimi për të vegjlit. Pjesa zero. Planifikimi.

Qartë është se ne vetë dëshirojmë të dimë gjithçka rreth këtyre.
Por kjo do të ndihmojë në qëllimin e automatizimit?
Pa dyshim.
Për shembull, dimë se në këtë qendër të të dhënave në switch-at Leaf, nëse është Huawei, ACL për filtrimin e trafikut të caktuar duhet të aplikohet në VLAN, ndryshe, nëse është Juniper, atëherë në njësinë 0 të ndërfaqes fizike.
Ose është e nevojshme të hapim një server të ri Syslog në të gjitha kufijtë e rajonit.

Aty do të ruajmë edhe pajisje virtuale rrjetesh, si routerat virtualë apo reflektorët BGP. Mund të shtojmë servera DNS, NTP, Syslog dhe madje gjithçka që ka lidhje me rrjetin.

Komponenti 2. Sistemi i menaxhimit të hapësirës IP

Po, në kohën tonë, akoma ka grupe njerëzish që mbajnë llogari për prefikset dhe adresat IP në skedarë Excel. Por qasja moderne është një bazë të dhënash, me frontend në nginx/apache, API dhe funksione të gjera për llogaritjen e adresave IP dhe rrjeteve me ndarje në VRF.
IPAM — Menaxhimi i Adresave IP.

Për nevojat tona në këtë sistem do të ruajmë informacionin e mëposhtëm:

  • VLAN
  • VRF
  • Rrjetet/Subrrjetet
  • adresat IP
  • Lidhja e adresave me pajisjet, rrjetet me lokacionet dhe numrat e VLAN

Automatizimi për të vegjlit. Pjesa zero. Planifikimi.

Sërish, është e qartë se duam të jemi të sigurtë se, kur ndanin një adresë të re IP për loopback-in e ToR-së, nuk do të bie në ndonjë problem me faktin që ajo tashmë është caktuar dikujt. Ose që një prefiks i njëjtë është përdorur dy herë në skajet e ndryshme të rrjetit.
Por si do të ndihmojë kjo në automatizim?
Lehtë.
KĂ«rkojmĂ« nĂ« sistem njĂ« prefiks me rol Loopbacks, nĂ« tĂ« cilin ka adresa IP tĂ« disponueshme pĂ«r ndarje — nĂ«se ndodhet, e ndajmĂ« adresĂ«n, pĂ«rndryshe kĂ«rkojmĂ« krijimin e njĂ« prefiksi tĂ« ri.
Ose gjatë krijimit të konfiguracionit të pajisjes mund të mësojmë nga ky sistem, se në cilin VRF duhet të ndodhet ndërfaqja.
Dhe kur startojmĂ« njĂ« server tĂ« ri, skedari shkon nĂ« sistem, mĂ«son se nĂ« cilin kalim serveri ndodhet, nĂ« cilin port dhe cila nĂ«nrrjet Ă«shtĂ« caktuar pĂ«r ndĂ«rfaqen — nga ajo do tĂ« ndajĂ« adresĂ«n e serverit.

Shfaqet dëshira për të bashkuar DCIM dhe IPAM në një sistem, për të mos duplikuar funksionet dhe për të mos mbajtur dy entitete të ngjashme.
Kështu do ta bëjmë.

Komponenti 3. Sistemi i përshkrimit të shërbimeve rrjetërore

Nëse dy sistemet e para ruajnë variablat që ende duhet të përdoren ndokund, e treta përshkruan se si çdo rol pajisjeje duhet të konfigurohet.
Duhet të dallohen dy lloje të ndryshme të shërbimeve rrjetërore:

  • Infrastrukturor
  • Klientor.

Të parat synojnë të sigurojnë lidhshmërinë bazë dhe menaxhimin e pajisjes. Këtu përfshihen VTY, SNMP, NTP, Syslog, AAA, protokollet e ruterimit, CoPP etj.
Të dytat organizojnë shërbimin për klientin: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP etj.
Natyrisht, ka edhe raste kufitare — si t'i japim MPLS LDP, BGP? Edhe protokollet e ruterimit mund tĂ« pĂ«rdoren pĂ«r klientĂ«t. Por kjo nuk Ă«shtĂ« thelbĂ«sore.

Të dy llojet e shërbimeve shkojnë në primitivët e konfigurimit:

  • ndĂ«rfaqet fizike dhe logjike (tag/untag, mtu)
  • Adresat IP dhe VRF (IP, IPv6, VRF)
  • ACL dhe politikat e trajtimit tĂ« trafikut
  • Protokollet (IGP, BGP, MPLS)
  • Politikat e ruterimit (lista e prefikseve, komunitetet, filtrat ASN).
  • ShĂ«rbimet ndihmĂ«se (SSH, NTP, LLDP, Syslog
)
  • Etj.

Si do ta bëjmë këtë, nuk e kam ende në mend. Do ta shqyrtojmë në një artikull të veçantë.

Automatizimi për të vegjlit. Pjesa zero. Planifikimi.

Nëse i afrohemi më shumë jetës, mund të përshkruajmë se
Switchi Leaf duhet të ketë seanca BGP me të gjithë switch-ët Spine të lidhur, të importojë rrjetet e lidhura në proces, dhe të pranojë nga switch-ët Spine vetëm rrjetet me një prefiks të caktuar. Kufizoni CoPP IPv6 ND në 10 pps etj.
Në anën tjetër, switch-et Spine mbajnë seansa me të gjithë Leaf-ët e lidhur, duke vepruar si rreth-reflektues dhe pranojnë vetëm rrugët e një gjatësie të caktuar dhe me një komunitet të caktuar.

Komponenti 4. Mekanizmi i iniciativës së pajisjes

Nën këtë titull unë bashkoj shumë veprime që duhet të ndodhin që pajisja të shfaqet në radarë dhe të mund të arrihet nga distanca.

  1. Shtoni pajisjen në sistemin e inventarizimit.
  2. Caktoni një adresë IP për menaxhim.
  3. Konfiguroni qasje bazike për të:
    Emri i hostit, adresa IP pĂ«r menaxhim, rruga nĂ« rrjetin e menaxhimit, pĂ«rdoruesit, çelĂ«sat SSH, protokollet — telnet/SSH/NETCONF

Këtu ekzistojnë tre qasje:

  • KrejtĂ«sisht manualisht. Pajisja sjellĂ«t nĂ« qĂ«ndĂ«r, ku njĂ« njeri i zakonshĂ«m do ta regjistrojĂ« nĂ« sistemet, do tĂ« lidhet me konsolĂ« dhe do ta konfiguronte. Mund tĂ« funksionojĂ« nĂ« rrjete tĂ« vogla statike.
  • ZTP — Zero Touch Provisioning. Hardueri ka ardhur, Ă«shtĂ« ngarkuar, ka marrĂ« njĂ« adresĂ« pĂ«rmes DHCP, Ă«shtĂ« lidhur me njĂ« server tĂ« veçantĂ« dhe Ă«shtĂ« vetĂ«-konfiguruar.
  • Infrastruktura e serverĂ«ve tĂ« konsolĂ«s, ku konfigurimi fillestar ndodh nĂ« mĂ«nyrĂ« automatike pĂ«rmes portit tĂ« konsolĂ«s.

Për të tre do të flasim në një artikull të veçantë.

Automatizimi për të vegjlit. Pjesa zero. Planifikimi.

Komponenti 5. Modeli i konfigurimit të pa-varur nga prodhuesi

Derisa të gjitha sistemet ishin copëza të ndara, duke dhënë variabla dhe një përshkrim deklarativ të asaj që do të dëshironim të shihnim në rrjet. Por, herët a vonë, do të duhet të ballafaqohemi me detaje të sakta.
Në këtë fazë, për çdo pajisje të caktuar, primitivat, shërbimet dhe variablat kombinohen në një model konfigurimi, që në thelb përshkruan konfigurimin e plotë të pajisjes specifike, vetëm në një mënyrë të pavarur nga prodhuesi.
ÇfarĂ« e sjell ky hap? Pse tĂ« mos e formoni menjĂ«herĂ« konfigurimin e pajisjes, tĂ« cilin mund ta ngarkoni thjesht?
Në të vërtetë, kjo lejon zgjidhjen e tre problemeve:

  1. TĂ« mos adaptohemi me ndĂ«rfaqen specifike tĂ« pajisjes. QoftĂ« CLI, NETCONF, RESTCONF, SNMP — modeli do tĂ« jetĂ« i njĂ«jtĂ«.
  2. Të mos mbani numrin e shablloneve/skripteve në numrin e prodhuesve në rrjet, dhe në rast të ndryshimit të dizajnit, të ndryshoni të njëjtën gjë në disa vende.
  3. Të ngarkoni konfigurimin nga pajisja (backup), ta shpërndani atë në modelin e saktë dhe të kryeni krahasimin mes konfigurimit të synuar dhe atij ekzistues për të llogaritur diferencën dhe përgatitur një patch konfigurimi që do të ndryshojë vetëm ato pjesë që janë të nevojshme ose për të identifikuar devijimet.

Automatizimi për të vegjlit. Pjesa zero. Planifikimi.

Si rezultat i kësaj faze, ne marrim një konfigurim të pavarur nga prodhuesi.

Komponenti 6. Shofer specifik për ndërfaqen e prodhuesit

Mos u bëni të iluzionuar se një ditë do të jetë e mundur të konfigurohen pajisjet Cisco në të njëjtën mënyrë si ato Juniper, duke i dërguar ata thjesht thirrje të njëjta. Pavarësisht nga rritja e popullaritetit të whitebox-eve dhe mbështetjes për NETCONF, RESTCONF, OpenConfig, përmbajtja specifike që këto protokolle ofrojnë ndryshon nga prodhuesi në prodhues dhe kjo është një nga dallimet e tyre konkurruese që nuk do t'ua japin lehtë.
Kjo është përafërsisht si OpenContrail dhe OpenStack, të cilat kanë RestAPI si ndërfaqen e tyre NorthBound, presin thirrje të ndryshme.

Pra, në hapin e pestë, modeli i pavarur nga prodhuesi duhet të marrë formën në të cilën do të shkojë në harduer.
Dhe këtu janë të gjitha mjetet që janë të nevojshme (jo): CLI, NETCONF, RESTCONF, SNMP thjesht në një farë favori.

Prandaj, do të na nevojitet një shofer që do ta konvertojë rezultatin e hapit të mëparshëm në formatin e nevojshëm të prodhuesit të caktuar: një set komandash CLI, një strukturë XML.

Automatizimi për të vegjlit. Pjesa zero. Planifikimi.

Komponenti 7. Mekanizmi i dorëzimit të konfigurimit në pajisje

Ne kemi gjeneruar konfigurimin, por tani duhet ta dorĂ«zojmĂ« nĂ« pajisje — dhe, natyrisht, jo me duar.
Së pari, para nesh shfaqet pyetja, cila transport do të përdorim? Dhe zgjedhja sot nuk është e vogël:

  • CLI (telnet, ssh)
  • SNMP
  • NETCONF
  • RESTCONF
  • REST API
  • OpenFlow (pavarĂ«sisht se ai bie jashtĂ« listĂ«s, pasi Ă«shtĂ« njĂ« mĂ«nyrĂ« pĂ«r tĂ« dorĂ«zuar FIB, jo konfigurime)

Le tĂ« sqarojmĂ« kĂ«tu disa pika. CLI — Ă«shtĂ« legjendar. SNMP
 khem-khem.
RESTCONF — akoma njĂ« krijesĂ« e panjohur, REST API mbĂ«shtetet nga pak. Prandaj, ne do tĂ« fokusohemi nĂ« NETCONF.

NĂ« tĂ« vĂ«rtetĂ«, siç e kuptoi tashmĂ« lexuesi, me ndĂ«rfaqen, ne tashmĂ« jemi pĂ«rcaktuar — rezultati i hapit tĂ« mĂ«parshĂ«m Ă«shtĂ« tashmĂ« nĂ« formatin e ndĂ«rfaqes qĂ« ishte zgjedhur.

Në radhë të dytë, dhe me cilat mjete do ta bëjmë këtë?
Këtu gjithashtu ka një zgjedhje të madhe:

  • Script apo tĂ« dashura ose platformĂ«. Do tĂ« armatosemi me ncclient dhe asyncIO dhe do ta bĂ«jmĂ« vetĂ«. ÇfarĂ« na kushton tĂ« ndĂ«rtojmĂ« njĂ« sistem deployi nga zero?
  • Ansible me bibliotekĂ«n e tij tĂ« pasur tĂ« moduleve rrjetĂ«sore.
  • Salt me punĂ«n e tij tĂ« kufizuar me rrjetin dhe lidhjen me Napalm.
  • Pra, Napalm, i cili njeh disa furnizues dhe asgjĂ« mĂ« tepĂ«r, mirupafshim.
  • Nornir — njĂ« tjetĂ«r krijesĂ« qĂ« do ta shqyrtojmĂ« nĂ« tĂ« ardhmen.

Nuk Ă«shtĂ« zgjedhur ende njĂ« favorit kĂ«tu — do tĂ« eksplorojmĂ«.

ÇfarĂ« tjetĂ«r Ă«shtĂ« e rĂ«ndĂ«sishme kĂ«tu? Pasojat e pĂ«rdorimit tĂ« konfiguracionit.
A është e suksesshme apo jo. A mbeti qasje në pajisje apo jo.
Duket se ndihmon komitimi me konfirmim dhe validim të asaj që është ngarkuar në pajisje.
Kjo, sĂ« bashku me implementimin e duhur tĂ« NETCONF, ndihmon pĂ«r tĂ« ngushtuar numrin e pajisjeve tĂ« pĂ«rshtatshme — komitetet e zakonshme nuk mbĂ«shtesin aq shumĂ« prodhues. Por kjo Ă«shtĂ« thjesht njĂ« nga kushtet e detyrueshme nĂ« RFP. NĂ« fund tĂ« fundit, askush nuk shqetĂ«sohet se asnjĂ« furnizues rus nuk do tĂ« kalojĂ« nĂ«n kushtin e 32*100GE interfaces. Apo ndoshta shqetĂ«sohen?

Automatizimi për të vegjlit. Pjesa zero. Planifikimi.

Komponenti 8. CI/CD

Në këtë pikë, ne kemi përfunduar konfigurimin për të gjitha pajisjet e rrjetit.
Po e shkruaj «për të gjitha», sepse flasim për versionimin e gjendjes së rrjetit. Edhe nëse duhet të ndryshojmë vetëm cilësimet e një switch-i, ndryshimet llogariten për të gjithë rrjetin. Natyrisht, ato mund të jenë zero për shumicën e nyjeve.

Por, siç është thënë më parë, ne nuk jemi barbarë që të dërgojmë gjithçka menjëherë në prodhim.
Konfigurimi i gjeneruar duhet të kalojë fillimisht përmes Pipeline CI/CD.

CI/CD do të thotë Integrimi i vazhdueshëm, Shkarkimi i vazhdueshëm. Ky është një qasje ku ekipi nuk publikon një version të ri gjysmëvjetor, duke e zëvendësuar plotësisht të vjetrin, por zhvillon rregullisht funksionalitet të ri në porcione të vogla, çdo njërin të cilin e teston në mënyrë të plotë për përputhshmërinë, sigurinë dhe funksionalitetin.

PĂ«r kĂ«tĂ«, ne kemi njĂ« sistem kontrolli versioni qĂ« ndjek ndryshimet nĂ« konfigurim, njĂ« laborator ku kontrollohet nĂ«se shĂ«rbimi i klientit nuk Ă«shtĂ« thyer, njĂ« sistem monitorimi qĂ« verifikon kĂ«tĂ« fakt, dhe hapi i fundit — pĂ«rhapja e ndryshimeve nĂ« rrjetin aktiv.

PĂ«rveç komandave tĂ« debugut, tĂ« gjitha ndryshimet nĂ« rrjet duhet tĂ« kalojnĂ« pĂ«rmes Pipeline CI/CD — kjo Ă«shtĂ« garancia jonĂ« pĂ«r njĂ« jetĂ« tĂ« qetĂ« dhe njĂ« karrierĂ« tĂ« gjatĂ« e tĂ« lumtur.

Automatizimi për të vegjlit. Pjesa zero. Planifikimi.

Komponenti 9. Sistemi i kopjimeve rezervë dhe ndjekjes së devijimeve

Nuk ka nevojë të flasim më shumë për kopjet rezervë.
Do t'i grumbullojmë ato sipas kronit ose pas ndonjë ndryshimi në konfigurim në git.

Por pjesa e dytĂ« Ă«shtĂ« mĂ« interesante — dikush duhet tĂ« mbajĂ« vĂ«zhgim mbi kĂ«to kopje rezervĂ«. Dhe nĂ« disa raste, ky dikush duhet tĂ« shkojĂ« dhe ta kthejĂ« gjithçka siç ishte, ndĂ«rsa nĂ« raste tĂ« tjera, duhet tĂ« njoftojĂ« dikĂ« pĂ«r çfarĂ«do problemi.
Për shembull, nëse një përdorues i ri është shtuar, i cili nuk është i regjistruar në variablat, duhet ta heqim atë sa më larg nga hakimi. Ndërsa nëse është një rregull i ri firewall, është më mirë të mos e prekim, ndoshta dikush ka aktivizuar ndihmën e debugut, ose ndoshta një shërbim i ri, që ka ndodhur jashtë rregullave.

Nga një diferencë e vogël në shkallë në të gjithë rrjetin, ne gjithsesi nuk do t'ia dalim, pavarësisht ndonjë sistemi automatizimi dhe dorë të hekurt të udhëheqjes. Për zgjidhjen e problemeve, askush nuk do të bëjë ndryshime në konfigurimin e sistemeve. Sidomos sepse modelimi i konfigurimit nuk mund të parashikojë asgjë të tillë.

PĂ«r shembull, njĂ« rregull firewall pĂ«r numĂ«rimin e paketave pĂ«r njĂ« IP tĂ« caktuar, pĂ«r tĂ« lokalizuar problemin — Ă«shtĂ« njĂ« konfigurim i zakonshĂ«m pĂ«r pĂ«rkohĂ«si.

Automatizimi për të vegjlit. Pjesa zero. Planifikimi.

Komponenti 10. Sistemi i monitorimit

NĂ« fillim nuk doja tĂ« preka temĂ«n e monitorimit — pĂ«r shkak se Ă«shtĂ« njĂ« temĂ« e gjerĂ«, e diskutueshme dhe e komplikuar. Por gjatĂ« rrugĂ«s, doli se Ă«shtĂ« njĂ« pjesĂ« e pandashme e automatizimit. Dhe nuk mund ta anashkaloni ashtu si asnjĂ«herĂ«.

Duke zhvilluar idenĂ« — kjo Ă«shtĂ« njĂ« pjesĂ« organike e procesit CI/CD. Pas pĂ«rhapjes sĂ« konfigurimit nĂ« rrjet, na nevojitet tĂ« dimĂ« nĂ«se gjithçka Ă«shtĂ« nĂ« rregull me tĂ«.
Dhe nuk flasim vetĂ«m dhe jo aq shumĂ« pĂ«r grafikat e pĂ«rdorimit tĂ« interfecave ose pĂ«r aksesin nĂ« nyje, por edhe pĂ«r gjĂ«ra mĂ« delikate — praninĂ« e rrugĂ«ve tĂ« nevojshme, atyre tĂ« atribuuara, numrin e lidhjeve BGP, fqinjĂ«ve OSPF, funksionalitetin End-to-End tĂ« shĂ«rbimeve qĂ« varen.
A nuk kanë pushuar të grumbullohen log-et në serverin e jashtëm, a nuk ka dështuar agjenti SFlow, a nuk ka filluar rritja e drop-ave në radhët, a nuk është thyer lidhja mes ndonjë pale prefikse?

Në një artikull të veçantë, ne do të mendojmë edhe për këtë.

Automatizimi për të vegjlit. Pjesa zero. Planifikimi.

Automatizimi për të vegjlit. Pjesa zero. Planifikimi.

PĂ«rfundimi

Si bazĂ«, kam zgjedhur njĂ« nga dizajnet moderne tĂ« rrjetit tĂ« qendrĂ«s tĂ« dhĂ«nash — L3 Clos Fabric me BGP si protokollin e routing.
Do ta ndërtojmë rrjetin këtë herë në Juniper, sepse tani interfeisi JunOs është i bërë me kapele.

Do tĂ« complicojmĂ« jetĂ«n tonĂ« duke pĂ«rdorur vetĂ«m mjete Open Source dhe njĂ« rrjet multivendor — kĂ«shtu qĂ« pĂ«rveç Juniper do tĂ« zgjedh edhe njĂ« tĂ« lumtur tjetĂ«r.

Plani i publikimeve të afërta është afërsisht kështu:
Së pari, do të flas për rrjetet virtuale. Kryesisht, sepse më pëlqen, dhe së dyti, sepse pa këtë dizajni i rrjetit infrastrukturor do të jetë i paqartë.
Më pas, konkretisht për dizajnin e rrjetit: topologjia, rrugëkalimi, politikat.
Do të krijojmë një ambient laboratori.
Do të mendojmë dhe, ndoshta, do të praktikojmë në inicializimin e pajisjes në rrjet.
Dhe pastaj për çdo komponent në detaje intime.

Dhe po, nuk premtoj tĂ« pĂ«rfundoj kĂ«tĂ« cikĂ«l me njĂ« zgjidhje tĂ« pĂ«rsosur. 🙂

Linqe të dobishme

  • Para se tĂ« thellohem nĂ« serinĂ«, ia vlen tĂ« lexoni librin e Natasha Samoylenko Python pĂ«r inxhinierĂ«t e rrjetit. Dhe ndoshta, tĂ« kaloni kursin.
  • Do tĂ« jetĂ« gjithashtu e dobishme tĂ« lexoni RFC pĂ«r dizajnin e fabrikave tĂ« qendrave tĂ« tĂ« dhĂ«nave nga Facebook, tĂ« shkruar nga Petar Lapukhov.
  • Dokumentacioni pĂ«r arkitekturĂ«n do tĂ« japĂ« njĂ« ide se si funksionon SDN Overlay Tungsten Fabric (mĂ« pare Open Contrail).
Faleminderit

Roman Gorgi. PĂ«r komentet dhe korrigjimet.
Artyom Chernobay. PĂ«r KDPV.

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster