SDSM imekwisha, lakini hamu isiyoweza kudhibitiwa ya kuandika bado.

Kwa miaka mingi, ndugu yetu aliteseka kwa kufanya kazi za kawaida, kuvuka vidole vyake kabla ya kufanya kazi na kukosa usingizi kwa sababu ya kurudi nyuma usiku.
Lakini nyakati za giza zinakuja mwisho.

Na makala hii nitaanza mfululizo wa jinsi gani kwangu otomatiki inaonekana.
Njiani, tutaelewa hatua za automatisering, kuhifadhi vigezo, kubuni rasmi, RestAPI, NETCONF, YANG, YDK na tutafanya programu nyingi.
Me inamaanisha kuwa a) sio ukweli wa kusudi, b) sio njia bora bila masharti, c) maoni yangu, hata wakati wa harakati kutoka kwa kifungu cha kwanza hadi cha mwisho, inaweza kubadilika - kuwa waaminifu, kutoka hatua ya rasimu hadi. uchapishaji, niliandika tena kila kitu mara mbili.

yaliyomo

1. Malengo ya
   1. Mtandao ni kama kiumbe kimoja
   2. Mtihani wa usanidi
   3. Inatayarisha
   4. Ufuatiliaji na uponyaji wa kibinafsi wa huduma

2. Fedha
   1. Mfumo wa hesabu
   2. Mfumo wa usimamizi wa nafasi ya IP
   3. Mfumo wa maelezo ya huduma ya mtandao
   4. Utaratibu wa kuanzisha kifaa
   5. Muundo wa usanidi wa muuzaji-agnostic
   6. Kiolesura cha kiendeshi mahususi cha muuzaji
   7. Utaratibu wa kupeana usanidi kwenye kifaa
   8. CI / CD
   9. Utaratibu wa kuhifadhi nakala na kutafuta mikengeuko
   10. Mfumo wa ufuatiliaji

3. Hitimisho

Nitajaribu kufanya ADSM katika umbizo tofauti kidogo na SDSM. Nakala kubwa, za kina, zilizohesabiwa zitaendelea kuonekana, na kati yao nitachapisha maelezo madogo kutoka kwa uzoefu wa kila siku. Nitajaribu kupigana na ukamilifu hapa na sio kulamba kila mmoja wao.

Inafurahisha jinsi gani kwamba mara ya pili lazima upitie njia ile ile.

Mwanzoni nilipaswa kuandika makala kuhusu mitandao mwenyewe kutokana na ukweli kwamba hawakuwa kwenye RuNet.

Sasa sikuweza kupata hati kamili ambayo ingepanga mbinu za uwekaji kiotomatiki na kuchambua teknolojia zilizo hapo juu kwa kutumia mifano rahisi ya vitendo.

Huenda nimekosea, kwa hivyo tafadhali toa viungo vya nyenzo muhimu. Walakini, hii haitabadilisha azimio langu la kuandika, kwa sababu lengo kuu ni kujifunza kitu mwenyewe, na kurahisisha maisha kwa wengine ni bonasi ya kupendeza inayobembeleza jeni kwa kubadilishana uzoefu.

Tutajaribu kuchukua kituo cha data cha LAN DC cha ukubwa wa kati na kutayarisha mpango mzima wa otomatiki.
Nitakuwa nikifanya baadhi ya mambo karibu kwa mara ya kwanza na wewe.

Sitakuwa asili katika mawazo na zana zilizoelezwa hapa. Dmitry Figol ana bora chaneli yenye mitiririko kwenye mada hii.
Makala yataingiliana nao katika nyanja nyingi.

LAN DC ina DC 4, swichi 250 hivi, ruta nusu dazeni na ngome kadhaa.
Sio Facebook, lakini inatosha kukufanya ufikirie kwa kina juu ya otomatiki.
Kuna, hata hivyo, maoni kwamba ikiwa una kifaa zaidi ya 1, automatisering tayari inahitajika.
Kwa kweli, ni vigumu kufikiria kwamba mtu yeyote sasa anaweza kuishi bila angalau pakiti ya maandishi ya magoti.
Ingawa nilisikia kuwa kuna ofisi ambazo anwani za IP huhifadhiwa katika Excel, na kila moja ya maelfu ya vifaa vya mtandao husanidiwa kwa mikono na ina usanidi wake wa kipekee. Hii, kwa kweli, inaweza kupitishwa kama sanaa ya kisasa, lakini hisia za mhandisi hakika zitakasirika.

Malengo ya

Sasa tutaweka malengo ya kufikirika zaidi:

• Mtandao ni kama kiumbe kimoja
• Mtihani wa usanidi
• Toleo la hali ya mtandao
• Ufuatiliaji na uponyaji wa kibinafsi wa huduma

Baadaye katika makala hii tutaangalia ni njia gani tutatumia, na katika zifuatazo, tutaangalia malengo na njia kwa undani.

Mtandao ni kama kiumbe kimoja

Kifungu cha kufafanua cha safu, ingawa kwa mtazamo wa kwanza kinaweza kuonekana sio muhimu sana: tutasanidi mtandao, sio vifaa vya mtu binafsi.
Katika miaka ya hivi karibuni, tumeona mabadiliko katika msisitizo kuelekea kuchukulia mtandao kama chombo kimoja, kwa hivyo Programu Imefafanuliwa Mtandao, Mitandao Inayoendeshwa kwa Nia и Mitandao inayojiendesha.
Baada ya yote, maombi yanahitaji nini kimataifa kutoka kwa mtandao: uunganisho kati ya pointi A na B (vizuri, wakati mwingine +B-Z) na kutengwa na programu nyingine na watumiaji.

Na hivyo kazi yetu katika mfululizo huu ni kujenga mfumo, kudumisha usanidi wa sasa mtandao mzima, ambayo tayari imetenganishwa kuwa usanidi halisi kwenye kila kifaa kwa mujibu wa jukumu na eneo lake.
System usimamizi wa mtandao unamaanisha kwamba ili kufanya mabadiliko tunawasiliana nayo, nayo, nayo, huhesabu hali inayotakiwa kwa kila kifaa na kukisanidi.
Kwa njia hii, tunapunguza ufikiaji wa mwongozo kwa CLI hadi karibu sifuri - mabadiliko yoyote katika mipangilio ya kifaa au muundo wa mtandao lazima yawe rasmi na kurekodiwa - na kisha kupitishwa kwa vipengele muhimu vya mtandao.

Hiyo ni, kwa mfano, ikiwa tuliamua kwamba kuanzia sasa swichi za rack huko Kazan zinapaswa kutangaza mitandao miwili badala ya moja, sisi.

1. Kwanza tunaandika mabadiliko katika mifumo
2. Inazalisha usanidi unaolengwa wa vifaa vyote vya mtandao
3. Tunazindua programu ya sasisho la usanidi wa mtandao, ambayo huhesabu kile kinachohitajika kuondolewa kwenye kila node, nini cha kuongeza, na huleta nodes kwa hali inayotakiwa.

Wakati huo huo, tunafanya mabadiliko kwa mikono tu katika hatua ya kwanza.

Mtihani wa usanidi

Inajulikanakwamba 80% ya matatizo hutokea wakati wa mabadiliko ya usanidi - ushahidi usio wa moja kwa moja wa hii ni kwamba wakati wa likizo ya Mwaka Mpya kila kitu ni kawaida shwari.
Binafsi nimeshuhudia nyakati nyingi za chini duniani kutokana na makosa ya kibinadamu: amri isiyo sahihi, usanidi ulitekelezwa katika tawi lisilo sahihi, jumuiya ilisahau, MPLS ilibomolewa duniani kote kwenye kipanga njia, vipande vitano vya maunzi vilisanidiwa, lakini hitilafu haikuwa hivyo. niliona siku ya sita, mabadiliko ya zamani yaliyofanywa na mtu mwingine yalifanywa. Kuna tani ya matukio.

Automation itaturuhusu kufanya makosa machache, lakini kwa kiwango kikubwa. Kwa njia hii unaweza matofali sio kifaa kimoja tu, lakini mtandao mzima mara moja.

Tangu nyakati za zamani, babu zetu waliangalia usahihi wa mabadiliko yaliyofanywa kwa jicho la makini, mipira ya chuma na utendaji wa mtandao baada ya kupigwa nje.
Wale babu ambao kazi yao ilisababisha kupungua kwa muda na hasara kubwa iliacha watoto wachache na wanapaswa kufa baada ya muda, lakini mageuzi ni mchakato wa polepole, na kwa hiyo si kila mtu bado anajaribu mabadiliko katika maabara kwanza.
Hata hivyo, mbele ya maendeleo ni wale ambao wamejiendesha mchakato wa kupima usanidi na matumizi yake zaidi kwenye mtandao. Kwa maneno mengine, nilikopa utaratibu wa CI/CD (Ujumuishaji Unaoendelea, Usambazaji Unaoendelea) kutoka kwa watengenezaji.
Katika moja ya sehemu tutaangalia jinsi ya kutekeleza hii kwa kutumia mfumo wa kudhibiti toleo, labda Github.

Mara tu unapozoea wazo la mtandao wa CI/CD, mara moja njia ya kuangalia usanidi kwa kuitumia kwenye mtandao wa uzalishaji itaonekana kama ujinga wa mapema. Ni kama kupiga kichwa cha vita na nyundo.

Muendelezo wa kikaboni wa mawazo kuhusu mfumo usimamizi wa mtandao na CI/CD inakuwa toleo kamili la usanidi.

Inatayarisha

Tutafikiri kwamba kwa mabadiliko yoyote, hata yale madogo zaidi, hata kwenye kifaa kimoja kisichoonekana, mtandao wote unatoka kutoka hali moja hadi nyingine.
Na sisi daima hatutekelezi amri kwenye kifaa, tunabadilisha hali ya mtandao.
Kwa hivyo wacha tuite matoleo haya ya majimbo?

Wacha tuseme toleo la sasa ni 1.0.0.
Je, anwani ya IP ya kiolesura cha Loopback kwenye mojawapo ya ToRs imebadilika? Hili ni toleo dogo na litapewa nambari 1.0.1.
Tulirekebisha sera za kuingiza njia ndani ya BGP - kwa umakini zaidi - tayari 1.1.0
Tuliamua kuondokana na IGP na kubadili BGP pekee - hii tayari ni mabadiliko makubwa ya kubuni - 2.0.0.

Wakati huo huo, DC tofauti zinaweza kuwa na matoleo tofauti - mtandao unaendelea, vifaa vipya vinawekwa, viwango vipya vya miiba vinaongezwa mahali fulani, si kwa wengine, nk.

juu ya toleo la kisemantiki tutazungumza katika makala tofauti.

Ninarudia - mabadiliko yoyote (isipokuwa kwa amri za kurekebisha) ni sasisho la toleo. Wasimamizi lazima waarifiwe kuhusu mkengeuko wowote kutoka kwa toleo la sasa.

Vile vile inatumika kwa kubadilisha mabadiliko - hii sio kughairi amri za mwisho, hii sio kurudi nyuma kwa kutumia mfumo wa uendeshaji wa kifaa - hii inaleta mtandao mzima kwa toleo jipya (la zamani).

Ufuatiliaji na uponyaji wa kibinafsi wa huduma

Kazi hii inayojidhihirisha imefikia kiwango kipya katika mitandao ya kisasa.
Mara nyingi, watoa huduma wakubwa huchukua njia ambayo huduma iliyoshindwa inahitaji kurekebishwa haraka sana na mpya kuinuliwa, badala ya kufikiria kilichotokea.
"Sana" inamaanisha kuwa unahitaji kuvikwa kwa ukarimu pande zote na ufuatiliaji, ambao ndani ya sekunde utagundua kupotoka kidogo kutoka kwa kawaida.
Na hapa vipimo vya kawaida, kama vile upakiaji wa kiolesura au upatikanaji wa nodi, havitoshi tena. Ufuatiliaji wao wenyewe na afisa wa zamu hautoshi pia.
Kwa mambo mengi inapaswa kuwa Kujiponya - taa za ufuatiliaji ziligeuka nyekundu na tukaenda na kupaka ndizi wenyewe ambapo iliumiza.

Na hapa sisi pia hufuatilia sio vifaa vya mtu binafsi tu, bali pia afya ya mtandao mzima, sanduku nyeupe, ambayo inaeleweka, na sanduku nyeusi, ambayo ni ngumu zaidi.

Tutahitaji nini kutekeleza mipango kabambe kama hii?

• Kuwa na orodha ya vifaa vyote kwenye mtandao, eneo lao, majukumu, mifano, matoleo ya programu.
  kazan-leaf-1.lmu.net, Kazan, jani, Juniper QFX 5120, R18.3.
• Kuwa na mfumo wa kuelezea huduma za mtandao.
  IGP, BGP, L2/3VPN, Sera, ACL, NTP, SSH.
• Uweze kuanzisha kifaa.
  Jina la mpangishaji, Mgmt IP, Njia ya Mgmt, Watumiaji, RSA-Funguo, LLDP, NETCONF
• Sanidi kifaa na ulete usanidi kwa toleo linalohitajika (pamoja na la zamani).
• Usanidi wa jaribio
• Mara kwa mara angalia hali ya vifaa vyote kwa kupotoka kutoka kwa vya sasa na uripoti kwa nani inapaswa kuwa.
  Mara moja, mtu aliongeza kwa utulivu sheria kwa ACL.
• Kufuatilia utendaji.

Fedha

Inasikika kuwa ngumu vya kutosha kuanza kutenganisha mradi katika vipengee.

Na kutakuwa na kumi kati yao:

1. Mfumo wa hesabu
2. Mfumo wa usimamizi wa nafasi ya IP
3. Mfumo wa maelezo ya huduma ya mtandao
4. Utaratibu wa kuanzisha kifaa
5. Muundo wa usanidi wa muuzaji-agnostic
6. Kiolesura cha kiendeshi mahususi cha muuzaji
7. Utaratibu wa kupeana usanidi kwenye kifaa
8. CI / CD
9. Utaratibu wa kuhifadhi nakala na kutafuta mikengeuko
10. Mfumo wa ufuatiliaji

Hii, kwa njia, ni mfano wa jinsi mtazamo juu ya malengo ya mzunguko ulibadilika - kulikuwa na vipengele 4 katika rasimu.

Katika mfano nilionyesha vipengele vyote na kifaa yenyewe.
Vipengele vinavyoingiliana vinaingiliana.
Kizuizi kikubwa, umakini zaidi unahitajika kulipwa kwa sehemu hii.

Sehemu ya 1: Mfumo wa Malipo

Kwa wazi, tunataka kujua ni vifaa gani viko wapi, ni nini kinachounganishwa.
Mfumo wa hesabu ni sehemu muhimu ya biashara yoyote.
Mara nyingi, biashara ina mfumo tofauti wa hesabu kwa vifaa vya mtandao, ambayo hutatua matatizo maalum zaidi.
Kama sehemu ya mfululizo huu wa makala, tutaiita DCIM - Usimamizi wa Miundombinu ya Kituo cha Data. Ingawa neno DCIM lenyewe, kwa kusema madhubuti, linajumuisha mengi zaidi.

Kwa madhumuni yetu, tutahifadhi habari ifuatayo kuhusu kifaa ndani yake:

• Nambari ya hesabu
• Kichwa/Maelezo
• Mfano (Huawei CE12800, Juniper QFX5120, nk.)
• Vigezo vya tabia (bodi, violesura, nk.)
• Jukumu (Jani, Mgongo, Njia ya Mpaka, nk.)
• Mahali (mkoa, jiji, kituo cha data, rack, kitengo)
• Uunganisho kati ya vifaa
• Topolojia ya mtandao

Ni wazi kabisa kwamba sisi wenyewe tunataka kujua haya yote.
Lakini hii itasaidia kwa madhumuni ya kiotomatiki?
Bila shaka.
Kwa mfano, tunajua kuwa katika kituo fulani cha data kwenye swichi za Leaf, ikiwa ni Huawei, ACL za kuchuja trafiki fulani zinapaswa kutumika kwenye VLAN, na ikiwa ni Juniper, basi kwenye kitengo cha 0 cha kiolesura halisi.
Au unahitaji kusambaza seva mpya ya Syslog kwa mipaka yote katika eneo.

Ndani yake tutahifadhi vifaa vya mtandao wa kawaida, kwa mfano routers za kawaida au viashiria vya mizizi. Tunaweza kuongeza seva za DNS, NTP, Syslog na kwa ujumla kila kitu ambacho kwa njia moja au nyingine kinahusiana na mtandao.

Kipengele cha 2: Mfumo wa usimamizi wa nafasi ya IP

Ndiyo, na siku hizi kuna timu za watu ambao hufuatilia viambishi awali na anwani za IP katika faili ya Excel. Lakini mbinu ya kisasa bado ni hifadhidata, iliyo na mwisho wa mbele kwenye nginx/apache, API na utendakazi mpana wa kurekodi anwani za IP na mitandao iliyogawanywa katika VRF.
IPAM - Usimamizi wa Anwani ya IP.

Kwa madhumuni yetu, tutahifadhi habari ifuatayo ndani yake:

• VLAN
• Ugani wa VRF
• Mitandao/Njia ndogo
• Anwani za IP
• Kufunga anwani kwa vifaa, mitandao kwa maeneo na nambari za VLAN

Tena, ni wazi kwamba tunataka kuhakikisha kuwa tunapotenga anwani mpya ya IP kwa kitanzi cha nyuma cha ToR, hatutakwama kwa sababu tayari imekabidhiwa kwa mtu fulani. Au kwamba tulitumia kiambishi kimoja mara mbili kwenye ncha tofauti za mtandao.
Lakini hii inasaidiaje na otomatiki?
Rahisi
Tunaomba kiambishi awali katika mfumo na jukumu la Loopbacks, ambalo lina anwani za IP zinazopatikana kwa ugawaji - ikiwa inapatikana, tunatenga anwani, ikiwa sio, tunaomba kuundwa kwa kiambishi kipya.
Au wakati wa kuunda usanidi wa kifaa, tunaweza kujua kutoka kwa mfumo huo ambao kiolesura cha VRF kinapaswa kupatikana.
Na wakati wa kuanzisha seva mpya, hati huingia kwenye mfumo, hugundua ni swichi gani ambayo seva iko, ni bandari gani na ni subnet gani iliyopewa kiolesura - na itatenga anwani ya seva kutoka kwake.

Hii inapendekeza hamu ya kuchanganya DCIM na IPAM katika mfumo mmoja ili kutorudia kazi na kutohudumia huluki mbili zinazofanana.
Hiyo ndiyo tutafanya.

Sehemu ya 3. Mfumo wa kuelezea huduma za mtandao

Ikiwa mifumo miwili ya kwanza itahifadhi vigeu ambavyo bado vinahitaji kutumiwa kwa namna fulani, basi ya tatu inaeleza kwa kila jukumu la kifaa jinsi inapaswa kusanidiwa.
Inastahili kutofautisha aina mbili za huduma za mtandao:

• Miundombinu
• Mteja.

Ya kwanza imeundwa ili kutoa muunganisho wa msingi na udhibiti wa kifaa. Hizi ni pamoja na VTY, SNMP, NTP, Syslog, AAA, itifaki za uelekezaji, CoPP, n.k.
Mwisho hupanga huduma kwa mteja: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, nk.
Bila shaka, pia kuna kesi za mpaka - wapi kujumuisha MPLS LDP, BGP? Ndio, na itifaki za uelekezaji zinaweza kutumika kwa wateja. Lakini hii si muhimu.

Aina zote mbili za huduma zimegawanywa katika primitives ya usanidi:

• miingiliano ya kimwili na kimantiki (tag/anteg, mtu)
• Anwani za IP na VRF (IP, IPv6, VRF)
• ACL na sera za uchakataji wa trafiki
• Itifaki (IGP, BGP, MPLS)
• Sera za uelekezaji (orodha za kiambishi awali, jumuiya, vichujio vya ASN).
• Huduma za matumizi (SSH, NTP, LLDP, Syslog...)
• Na kadhalika.

Jinsi hasa tutafanya hivi, sijui bado. Tutazingatia katika makala tofauti.

Ikiwa karibu kidogo na maisha, basi tunaweza kuelezea hilo
Swichi ya Leaf lazima iwe na vipindi vya BGP na swichi zote za Spine zilizounganishwa, kuleta mitandao iliyounganishwa kwenye mchakato, na ukubali mitandao pekee kutoka kwa kiambishi awali kutoka kwa swichi za Spine. Weka kikomo cha CoPP IPv6 ND hadi pps 10, nk.
Kwa upande mwingine, miiba hufanya vikao na miongozo yote iliyounganishwa, ikifanya kazi kama viakisishi vya mizizi, na kukubali kutoka kwayo njia za urefu fulani tu na jumuiya fulani.

Kipengele cha 4: Utaratibu wa Kuanzisha Kifaa

Chini ya kichwa hiki ninachanganya vitendo vingi ambavyo lazima vitokee ili kifaa kionekane kwenye rada na kufikiwa kwa mbali.

1. Ingiza kifaa katika mfumo wa hesabu.
2. Chagua anwani ya IP ya usimamizi.
3. Sanidi ufikiaji wa msingi kwa hiyo:
   Jina la mwenyeji, anwani ya IP ya usimamizi, njia ya mtandao wa usimamizi, watumiaji, funguo za SSH, itifaki - telnet/SSH/NETCONF

Kuna mbinu tatu:

• Kila kitu ni mwongozo kabisa. Kifaa kinaletwa kwenye msimamo, ambapo mtu wa kawaida wa kikaboni ataingia ndani ya mifumo, kuunganisha kwenye console na kuisanidi. Inaweza kufanya kazi kwenye mitandao ndogo tuli.
• ZTP - Utoaji Sifuri wa Kugusa. Vifaa vilifika, vilisimama, vikapokea anwani kupitia DHCP, vikaenda kwa seva maalum, na kujipanga.
• Miundombinu ya seva za console, ambapo usanidi wa awali hutokea kupitia bandari ya console katika hali ya moja kwa moja.

Tutazungumza juu ya zote tatu katika nakala tofauti.

Kipengele cha 5: Muundo wa usanidi wa muuzaji-utambuzi

Hadi sasa, mifumo yote imekuwa viraka tofauti ambavyo hutoa vigeuzo na maelezo ya kutangaza yale tungependa kuona kwenye mtandao. Lakini mapema au baadaye, itabidi ushughulike na maalum.
Katika hatua hii, kwa kila kifaa maalum, malighafi, huduma na vigeu huunganishwa katika muundo wa usanidi ambao kwa kweli unaelezea usanidi kamili wa kifaa mahususi, kwa njia ya kutoegemea upande wowote kwa muuzaji.
Je, hatua hii inafanya nini? Kwa nini usifanye mara moja usanidi wa kifaa ambacho unaweza kupakia tu?
Kwa kweli, hii inasuluhisha shida tatu:

1. Usikubaliane na kiolesura maalum cha kuingiliana na kifaa. Kuwa CLI, NETCONF, RESTCONF, SNMP - mfano utakuwa sawa.
2. Usiweke idadi ya templates/scripts kulingana na idadi ya wauzaji kwenye mtandao, na ikiwa muundo unabadilika, badilisha kitu kimoja katika maeneo kadhaa.
3. Pakia usanidi kutoka kwa kifaa (chelezo), kiweke katika muundo sawa kabisa na ulinganishe moja kwa moja usanidi lengwa na uliopo ili kukokotoa delta na kuandaa kiraka cha usanidi ambacho kitabadilisha sehemu zile tu ambazo ni muhimu au kutambua mikengeuko.

Kama matokeo ya hatua hii, tunapata usanidi wa kujitegemea wa muuzaji.

Kipengele cha 6. Kiolesura cha dereva maalum cha muuzaji

Haupaswi kujipendekeza kwa matumaini kwamba siku moja itawezekana kusanidi ciska kwa njia sawa na Juniper, kwa kutuma simu sawa kwao. Licha ya umaarufu unaokua wa visanduku vyeupe na kuibuka kwa usaidizi kwa NETCONF, RESTCONF, OpenConfig, maudhui mahususi ambayo itifaki hizi hutoa hutofautiana kutoka kwa muuzaji hadi muuzaji, na hii ni mojawapo ya tofauti zao za ushindani ambazo hawatakata tamaa kwa urahisi.
Hii ni takriban sawa na OpenContrail na OpenStack, ambazo zina RestAPI kama kiolesura chao cha NorthBound, zinatarajia simu tofauti kabisa.

Kwa hiyo, katika hatua ya tano, mfano wa kujitegemea wa muuzaji lazima uchukue fomu ambayo itaenda kwenye vifaa.
Na hapa njia zote ni nzuri (sio): CLI, NETCONF, RESTCONF, SNMP kwa urahisi.

Kwa hiyo, tutahitaji dereva ambaye atahamisha matokeo ya hatua ya awali kwenye muundo unaohitajika wa muuzaji maalum: seti ya amri za CLI, muundo wa XML.

Kipengele cha 7. Utaratibu wa kutoa usanidi kwenye kifaa

Tumeunda usanidi, lakini bado inahitaji kutolewa kwa vifaa - na, kwa wazi, sio kwa mkono.
Kwanza, tunakabiliwa na swali kwamba tutatumia usafiri gani? Na leo chaguo sio ndogo tena:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• API YA REST
• OpenFlow (ingawa ni ya nje kwa sababu ni njia ya kutoa FIB, sio mipangilio)

Hebu tuangazie t hapa. CLI ni urithi. SNMP... kikohozi kikohozi.
RESTCONF bado ni mnyama asiyejulikana; API ya REST inaungwa mkono na karibu hakuna mtu yeyote. Kwa hiyo, tutazingatia NETCONF katika mfululizo.

Kwa kweli, kama msomaji ameelewa tayari, kwa hatua hii tayari tumeamua juu ya interface - matokeo ya hatua ya awali tayari yamewasilishwa katika muundo wa interface iliyochaguliwa.

Pili, na tutafanya hivi kwa zana gani?
Pia kuna chaguo kubwa hapa:

• Hati au jukwaa la kujiandikia. Wacha tujizatiti na ncclient na asyncIO na tufanye kila kitu sisi wenyewe. Inatugharimu nini kujenga mfumo wa kupeleka kutoka mwanzo?
• Inastahili na maktaba yake tajiri ya moduli za mitandao.
• Chumvi na kazi yake ndogo na mtandao na unganisho na Napalm.
• Kwa kweli Napalm, ambayo inajua wachuuzi kadhaa na ndivyo ilivyo, kwaheri.
• Nornir ni mnyama mwingine ambaye tutamchambua katika siku zijazo.

Hapa kipendwa bado hakijachaguliwa - tutakuwa tunatafuta.

Ni nini kingine muhimu hapa? Matokeo ya kutumia usanidi.
Imefanikiwa au la. Bado kuna ufikiaji wa vifaa au la?
Inaonekana kujitolea kutasaidia hapa na uthibitisho na uthibitisho wa kile kilichopakuliwa kwenye kifaa.
Hii, pamoja na utekelezaji sahihi wa NETCONF, hupunguza kwa kiasi kikubwa anuwai ya vifaa vinavyofaa - sio wazalishaji wengi wanaounga mkono ahadi za kawaida. Lakini hii ni moja tu ya mahitaji ya ndani RFP. Mwishoni, hakuna mtu ana wasiwasi kwamba hakuna muuzaji mmoja wa Kirusi atakayezingatia hali ya interface ya 32 * 100GE. Au ana wasiwasi?

Sehemu ya 8. CI/CD

Katika hatua hii, tayari tuna usanidi tayari kwa vifaa vyote vya mtandao.
Ninaandika "kwa kila kitu" kwa sababu tunazungumzia kuhusu toleo la hali ya mtandao. Na hata ikiwa unahitaji kubadilisha mipangilio ya swichi moja tu, mabadiliko yanahesabiwa kwa mtandao mzima. Kwa wazi, wanaweza kuwa sifuri kwa nodi nyingi.

Lakini, kama ilivyosemwa hapo juu, sisi sio aina fulani ya washenzi ambao wanataka kuingiza kila kitu moja kwa moja kwenye uzalishaji.
Usanidi unaozalishwa lazima kwanza upitie Pipeline CI/CD.

CI/CD inasimama kwa Ujumuishaji Unaoendelea, Usambazaji Unaoendelea. Hii ni mbinu ambayo timu haitoi toleo jipya tu kila baada ya miezi sita, ikibadilisha kabisa ile ya zamani, lakini mara kwa mara hutumia (Usambazaji) utendakazi mpya katika sehemu ndogo, ambayo kila moja inajaribiwa kikamilifu kwa utangamano, usalama na. utendaji (Ushirikiano).

Ili kufanya hivyo, tuna mfumo wa udhibiti wa toleo ambao hufuatilia mabadiliko ya usanidi, maabara ambayo hukagua ikiwa huduma ya mteja imevunjwa, mfumo wa ufuatiliaji ambao hukagua ukweli huu, na hatua ya mwisho ni kufanya mabadiliko kwenye mtandao wa uzalishaji.

Isipokuwa amri za utatuzi, mabadiliko yote kwenye mtandao lazima yapitie Bomba la CI/CD - hii ni dhamana yetu ya maisha ya utulivu na kazi ndefu na yenye furaha.

Kipengele cha 9. Mfumo wa ugunduzi na chelezo

Kweli, hakuna haja ya kuzungumza juu ya chelezo tena.
Tutawaongeza tu kwenye taji au juu ya ukweli wa mabadiliko ya usanidi katika git.

Lakini sehemu ya pili ni ya kuvutia zaidi - mtu anapaswa kuzingatia nakala hizi. Na katika hali nyingine, mtu huyu lazima aende na kugeuza kila kitu kama ilivyokuwa, na kwa wengine, meow kwa mtu kwamba kuna kitu kibaya.
Kwa mfano, ikiwa mtumiaji mpya ameonekana ambaye hajasajiliwa katika vigezo, unahitaji kumwondoa mbali na hack. Na ikiwa ni bora si kugusa sheria mpya ya firewall, labda mtu amegeuka tu kufuta, au labda huduma mpya, bungler, haikusajiliwa kulingana na kanuni, lakini watu tayari wamejiunga nayo.

Bado hatutaepuka delta ndogo kwenye saizi ya mtandao mzima, licha ya mifumo yoyote ya kiotomatiki na usimamizi wa chuma. Ili kutatua matatizo, hakuna mtu atakayeongeza usanidi kwa mifumo hata hivyo. Aidha, huenda hata zisijumuishwe katika muundo wa usanidi.

Kwa mfano, sheria ya ngome ya kuhesabu idadi ya pakiti kwa IP maalum ili kubinafsisha shida ni usanidi wa muda wa kawaida kabisa.

Sehemu ya 10. Mfumo wa ufuatiliaji

Mara ya kwanza sikuenda kufunika mada ya ufuatiliaji - bado ni mada yenye utata, yenye utata na ngumu. Lakini mambo yalivyoendelea, ikawa kwamba hii ilikuwa sehemu muhimu ya automatisering. Na haiwezekani kuipita, hata bila mazoezi.

Mawazo ya Kuendeleza ni sehemu ya kikaboni ya mchakato wa CI/CD. Baada ya kuweka usanidi kwenye mtandao, tunahitaji kuwa na uwezo wa kuamua ikiwa kila kitu kiko sawa nayo sasa.
Na tunazungumza sio tu na sio sana juu ya ratiba za utumiaji wa kiolesura au upatikanaji wa nodi, lakini juu ya vitu vya hila zaidi - uwepo wa njia muhimu, sifa juu yao, idadi ya vikao vya BGP, majirani wa OSPF, Utendaji wa Mwisho hadi Mwisho. ya huduma za ziada.
Je, silogi za seva ya nje ziliacha kujumlisha, au wakala wa SFlow aliharibika, au matone kwenye foleni yalianza kukua, au muunganisho kati ya baadhi ya viambishi awali ulivunjika?

Tutatafakari juu ya hili katika makala tofauti.

Hitimisho

Kama msingi, nilichagua moja ya miundo ya kisasa ya kituo cha data - L3 Clos Fabric na BGP kama itifaki ya uelekezaji.
Wakati huu tutajenga mtandao kwenye Juniper, kwa sababu sasa interface ya JunOs ni vanlove.

Wacha tufanye maisha yetu kuwa magumu zaidi kwa kutumia zana za Open Source pekee na mtandao wa wachuuzi wengi - kwa hivyo pamoja na Juniper, nitachagua mtu mmoja zaidi aliyebahatika njiani.

Mpango wa machapisho yajayo ni kama hii:
Kwanza nitazungumza juu ya mitandao ya mtandao. Kwanza kabisa, kwa sababu nataka, na pili, kwa sababu bila hii, muundo wa mtandao wa miundombinu hautakuwa wazi sana.
Kisha kuhusu muundo wa mtandao yenyewe: topolojia, uelekezaji, sera.
Hebu tukusanye stendi ya maabara.
Hebu tufikirie juu yake na labda tujizoeze kuanzisha kifaa kwenye mtandao.
Na kisha kuhusu kila sehemu kwa undani wa karibu.

Na ndio, siahidi kumaliza mzunguko huu kwa uzuri na suluhisho lililotengenezwa tayari. 🙂

Viungo muhimu

• Kabla ya kuzama kwenye safu hiyo, inafaa kusoma kitabu cha Natasha Samoilenko Python kwa Wahandisi wa Mtandao. Na labda kupita kozi.
• Pia itakuwa muhimu kusoma RFC kuhusu muundo wa viwanda vya kituo cha data kutoka Facebook na Peter Lapukhov.
• Nyaraka za usanifu zitakupa wazo la jinsi Overlay SDN inavyofanya kazi. Kitambaa cha Tungsten (zamani Open Contrail).

Asante

Roman Gorge. Kwa maoni na marekebisho.
Artyom Chernobay. Kwa KDPV.

Chanzo: mapenzi.com