Tapos na ang SDSM, ngunit nananatili ang hindi mapigilang pagnanais na magsulat.

Sa loob ng maraming taon, nagdusa ang ating kapatid sa paggawa ng nakagawiang gawain, nagkrus ang kanyang mga daliri bago gumawa at kulang sa tulog dahil sa gabi-gabi na mga rollback.
Ngunit ang madilim na panahon ay malapit nang magwakas.

Sa artikulong ito magsisimula ako ng isang serye kung paano sa akin nakikita ang automation.
Sa daan, mauunawaan natin ang mga yugto ng automation, pag-iimbak ng mga variable, pag-formalize ng disenyo, RestAPI, NETCONF, YANG, YDK at gagawa tayo ng maraming programming.
Sa akin ay nangangahulugan na a) ito ay hindi isang layunin na katotohanan, b) ito ay hindi walang kondisyon na pinakamahusay na diskarte, c) ang aking opinyon, kahit na sa panahon ng paggalaw mula sa una hanggang sa huling artikulo, ay maaaring magbago - upang maging matapat, mula sa yugto ng draft hanggang publikasyon, muling isinulat ko ang lahat nang ganap nang dalawang beses.

nilalaman

1. Mga Layunin
   1. Ang network ay parang iisang organismo
   2. Pagsubok sa configuration
   3. Pag-bersyon
   4. Pagsubaybay at pagpapagaling sa sarili ng mga serbisyo

2. Pondo
   1. Sistema ng imbentaryo
   2. Sistema ng pamamahala ng espasyo ng IP
   3. Sistema ng paglalarawan ng serbisyo sa network
   4. Mekanismo ng pagsisimula ng device
   5. Vendor-agnostic na modelo ng pagsasaayos
   6. Interface ng driver na partikular sa vendor
   7. Mekanismo para sa paghahatid ng configuration sa device
   8. CI / CD
   9. Mekanismo para sa backup at paghahanap para sa mga deviations
   10. Systemang pang-monitor

3. Konklusyon

Susubukan kong magsagawa ng ADSM sa isang format na bahagyang naiiba sa SDSM. Malalaki, detalyado, may bilang na mga artikulo ay patuloy na lalabas, at sa pagitan ng mga ito ay maglalathala ako ng maliliit na tala mula sa pang-araw-araw na karanasan. Susubukan kong labanan ang pagiging perpekto dito at hindi dilaan ang bawat isa sa kanila.

Nakakatuwa na sa pangalawang pagkakataon kailangan mong dumaan sa parehong landas.

Sa una kailangan kong magsulat ng mga artikulo tungkol sa mga network sa aking sarili dahil sa katotohanan na wala sila sa RuNet.

Ngayon hindi ako makahanap ng isang komprehensibong dokumento na mag-systematize ng mga diskarte sa automation at pag-aralan ang mga teknolohiya sa itaas gamit ang mga simpleng praktikal na halimbawa.

Maaaring mali ako, kaya mangyaring magbigay ng mga link sa mga kapaki-pakinabang na mapagkukunan. Gayunpaman, hindi nito mababago ang aking determinasyon na magsulat, dahil ang pangunahing layunin ay upang matuto ng isang bagay sa aking sarili, at gawing mas madali ang buhay para sa iba ay isang kaaya-ayang bonus na humahaplos sa gene para sa pagbabahagi ng karanasan.

Susubukan naming kumuha ng medium-sized na LAN DC data center at gagawin ang buong automation scheme.
May mga bagay akong gagawin halos sa unang pagkakataon kasama ka.

Hindi ako magiging orihinal sa mga ideya at tool na inilarawan dito. Si Dmitry Figol ay may mahusay channel na may mga stream sa paksang ito.
Ang mga artikulo ay magkakapatong sa kanila sa maraming aspeto.

Ang LAN DC ay may 4 na DC, humigit-kumulang 250 switch, kalahating dosenang router at ilang firewall.
Hindi Facebook, ngunit sapat na para makapag-isip ka ng malalim tungkol sa automation.
Gayunpaman, mayroong isang opinyon na kung mayroon kang higit sa 1 aparato, kailangan na ang automation.
Sa katunayan, mahirap isipin na ang sinuman ay maaari na ngayong mabuhay nang walang kahit isang pakete ng mga script ng tuhod.
Bagama't narinig ko na may mga opisina kung saan ang mga IP address ay pinananatili sa Excel, at bawat isa sa libu-libong mga network device ay manu-manong na-configure at may sariling natatanging configuration. Ito, siyempre, ay maaaring ipasa bilang modernong sining, ngunit ang damdamin ng inhinyero ay tiyak na masasaktan.

Mga Layunin

Ngayon ay magtatakda kami ng mga pinaka-abstract na layunin:

• Ang network ay parang iisang organismo
• Pagsubok sa configuration
• Pag-bersyon ng estado ng network
• Pagsubaybay at pagpapagaling sa sarili ng mga serbisyo

Mamaya sa artikulong ito ay titingnan natin kung ano ang ibig sabihin ng ating gagamitin, at sa mga sumusunod, titingnan natin nang detalyado ang mga layunin at paraan.

Ang network ay parang iisang organismo

Ang pagtukoy ng parirala ng serye, bagaman sa unang tingin ay maaaring hindi ito gaanong kabuluhan: iko-configure namin ang network, hindi ang mga indibidwal na device.
Sa nakalipas na mga taon, nakita namin ang pagbabago sa diin patungo sa pagtrato sa network bilang isang entity, kaya ang Defined Networking Software, Mga Network na Pinaandar ng Layunin и Mga Autonomous na Network.
Pagkatapos ng lahat, ano ang kailangan ng mga application sa buong mundo mula sa network: pagkakakonekta sa pagitan ng mga punto A at B (well, minsan +B-Z) at paghihiwalay mula sa iba pang mga application at user.

At kaya ang aming gawain sa seryeng ito ay bumuo ng isang sistema, pinapanatili ang kasalukuyang configuration ang buong network, na na-decompose na sa aktwal na configuration sa bawat device alinsunod sa tungkulin at lokasyon nito.
Sistema Ang pamamahala ng network ay nagpapahiwatig na upang gumawa ng mga pagbabago ay nakikipag-ugnayan kami dito, at ito naman, ay kinakalkula ang nais na estado para sa bawat device at kino-configure ito.
Sa ganitong paraan, binabawasan namin ang manu-manong pag-access sa CLI sa halos zero - anumang mga pagbabago sa mga setting ng device o disenyo ng network ay dapat na gawing pormal at dokumentado - at pagkatapos lamang ilunsad sa mga kinakailangang elemento ng network.

Iyon ay, halimbawa, kung nagpasya kami na mula ngayon sa mga rack switch sa Kazan ay dapat magpahayag ng dalawang network sa halip na isa, kami

1. Una naming idokumento ang mga pagbabago sa mga system
2. Pagbuo ng target na configuration ng lahat ng network device
3. Inilunsad namin ang programa sa pag-update ng configuration ng network, na kinakalkula kung ano ang kailangang alisin sa bawat node, kung ano ang idaragdag, at dinadala ang mga node sa nais na estado.

Kasabay nito, manu-mano kaming gumagawa ng mga pagbabago sa unang hakbang lamang.

Pagsubok sa configuration

Ay kilalana 80% ng mga problema ay nangyayari sa panahon ng mga pagbabago sa pagsasaayos - hindi direktang katibayan nito ay na sa panahon ng pista opisyal ng Bagong Taon ang lahat ay karaniwang kalmado.
Personal kong nasaksihan ang dose-dosenang mga global downtime dahil sa error ng tao: ang maling command, ang configuration ay naisakatuparan sa maling branch, ang komunidad ay nakalimutan, ang MPLS ay na-demolish sa buong mundo sa router, limang piraso ng hardware ang na-configure, ngunit ang error ay hindi napansin sa ikaanim, ang mga lumang pagbabagong ginawa ng ibang tao ay ginawa . Mayroong isang tonelada ng mga senaryo.

Ang automation ay magbibigay-daan sa amin na gumawa ng mas kaunting mga pagkakamali, ngunit sa mas malaking sukat. Sa ganitong paraan maaari kang mag-brick hindi lamang ng isang device, ngunit ang buong network nang sabay-sabay.

Mula pa noong una, sinuri ng aming mga lolo ang tama ng mga pagbabagong ginawa nang may matalas na mata, mga bola ng bakal at ang pag-andar ng network pagkatapos na ilunsad ang mga ito.
Ang mga lolo na iyon na ang trabaho ay humantong sa downtime at sakuna na pagkalugi ay nag-iwan ng mas kaunting mga supling at dapat mamatay sa paglipas ng panahon, ngunit ang ebolusyon ay isang mabagal na proseso, at samakatuwid hindi pa rin lahat ay sumusubok muna ng mga pagbabago sa laboratoryo.
Gayunpaman, ang nangunguna sa pag-unlad ay ang mga nag-automate sa proseso ng pagsubok sa pagsasaayos at sa karagdagang aplikasyon nito sa network. Sa madaling salita, hiniram ko ang pamamaraan ng CI/CD (Patuloy na Pagsasama, Patuloy na Deployment) mula sa mga developer.
Sa isa sa mga bahagi ay titingnan natin kung paano ito ipatupad gamit ang isang version control system, malamang na Github.

Kapag nasanay ka na sa ideya ng network CI/CD, magdamag ang paraan ng pagsuri ng configuration sa pamamagitan ng paglalapat nito sa isang production network ay magmumukhang maagang medieval na kamangmangan. Parang pagtama ng warhead gamit ang martilyo.

Isang organikong pagpapatuloy ng mga ideya tungkol sa sistema pamamahala ng network at CI/CD ay nagiging isang buong bersyon ng configuration.

Pag-bersyon

Ipagpalagay namin na sa anumang mga pagbabago, kahit na ang pinakamaliit na pagbabago, kahit na sa isang hindi napapansing device, ang buong network ay gumagalaw mula sa isang estado patungo sa isa pa.
At palagi kaming hindi nagpapatupad ng command sa device, binabago namin ang estado ng network.
Kaya't tawagin natin itong mga bersyon ng estado?

Sabihin nating ang kasalukuyang bersyon ay 1.0.0.
Nagbago ba ang IP address ng Loopback interface sa isa sa mga ToR? Ito ay isang menor de edad na bersyon at bibigyan ng bilang na 1.0.1.
Binago namin ang mga patakaran para sa pag-import ng mga ruta sa BGP - medyo seryoso - 1.1.0 na
Nagpasya kaming alisin ang IGP at lumipat sa BGP lamang - isa na itong radikal na pagbabago sa disenyo - 2.0.0.

Kasabay nito, ang iba't ibang mga DC ay maaaring may iba't ibang mga bersyon - ang network ay umuunlad, ang mga bagong kagamitan ay ini-install, ang mga bagong antas ng mga spine ay idinagdag sa isang lugar, hindi sa iba, atbp.

Tungkol sa semantic versioning pag-uusapan natin sa isang hiwalay na artikulo.

Uulitin ko - ang anumang pagbabago (maliban sa mga utos sa pag-debug) ay isang pag-update ng bersyon. Dapat maabisuhan ang mga administrator ng anumang mga paglihis mula sa kasalukuyang bersyon.

Ang parehong naaangkop sa pagbabalik ng mga pagbabago - hindi nito kinakansela ang mga huling utos, hindi ito rollback gamit ang operating system ng device - dinadala nito ang buong network sa isang bagong (lumang) bersyon.

Pagsubaybay at pagpapagaling sa sarili ng mga serbisyo

Ang maliwanag na gawain na ito ay umabot sa isang bagong antas sa mga modernong network.
Kadalasan, ang mga malalaking service provider ay gumagamit ng diskarte na ang isang nabigong serbisyo ay kailangang maayos nang napakabilis at isang bago, sa halip na alamin kung ano ang nangyari.
Nangangahulugan ang "Very" na kailangan mong maging mapagbigay sa lahat ng panig ng pagsubaybay, na sa loob ng ilang segundo ay matutukoy ang pinakamaliit na paglihis mula sa pamantayan.
At dito ang mga karaniwang sukatan, tulad ng pag-load ng interface o pagkakaroon ng node, ay hindi na sapat. Hindi rin sapat ang manual monitoring sa kanila ng duty officer.
Para sa maraming bagay ay dapat na mayroon Pagpapagaling sa Sarili — ang mga ilaw ng pagsubaybay ay naging pula at pumunta kami at inilapat namin ang plantain kung saan ito masakit.

At dito, sinusubaybayan din namin hindi lamang ang mga indibidwal na aparato, kundi pati na rin ang kalusugan ng buong network, parehong whitebox, na medyo naiintindihan, at blackbox, na mas kumplikado.

Ano ang kailangan natin upang maipatupad ang gayong mga ambisyosong plano?

• Magkaroon ng listahan ng lahat ng device sa network, ang kanilang lokasyon, mga tungkulin, modelo, mga bersyon ng software.
  kazan-leaf-1.lmu.net, Kazan, dahon, Juniper QFX 5120, R18.3.
• Magkaroon ng isang sistema para sa paglalarawan ng mga serbisyo sa network.
  IGP, BGP, L2/3VPN, Patakaran, ACL, NTP, SSH.
• Ma-initialize ang device.
  Hostname, Mgmt IP, Mgmt Route, Users, RSA-Keys, LLDP, NETCONF
• I-configure ang device at dalhin ang configuration sa gustong (kabilang ang lumang) bersyon.
• Pagsubok ng configuration
• Pana-panahong suriin ang katayuan ng lahat ng mga aparato para sa mga paglihis mula sa mga kasalukuyang at iulat kung kanino ito dapat.
  Magdamag, may tahimik na nagdagdag ng panuntunan sa ACL.
• Subaybayan ang pagganap.

Pondo

Mukhang kumplikado ito upang simulan ang pag-decomposing ng proyekto sa mga bahagi.

At magkakaroon ng sampu sa kanila:

1. Sistema ng imbentaryo
2. Sistema ng pamamahala ng espasyo ng IP
3. Sistema ng paglalarawan ng serbisyo sa network
4. Mekanismo ng pagsisimula ng device
5. Vendor-agnostic na modelo ng pagsasaayos
6. Interface ng driver na partikular sa vendor
7. Mekanismo para sa paghahatid ng configuration sa device
8. CI / CD
9. Mekanismo para sa backup at paghahanap para sa mga deviations
10. Systemang pang-monitor

Ito, sa pamamagitan ng paraan, ay isang halimbawa kung paano nagbago ang pananaw sa mga layunin ng cycle - mayroong 4 na bahagi sa draft.

Sa ilustrasyon ay inilarawan ko ang lahat ng mga bahagi at ang aparato mismo.
Ang mga interseksyon na bahagi ay nakikipag-ugnayan sa isa't isa.
Kung mas malaki ang bloke, mas maraming pansin ang kailangang bayaran sa bahaging ito.

Bahagi 1: Sistema ng Imbentaryo

Malinaw, gusto naming malaman kung anong kagamitan ang matatagpuan kung saan, kung ano ang konektado.
Ang sistema ng imbentaryo ay isang mahalagang bahagi ng anumang negosyo.
Kadalasan, ang isang negosyo ay may hiwalay na sistema ng imbentaryo para sa mga device sa network, na lumulutas ng mas tiyak na mga problema.
Bilang bahagi ng seryeng ito ng mga artikulo, tatawagin natin itong DCIM - Pamamahala ng Infrastructure ng Data Center. Bagama't ang terminong DCIM mismo, sa mahigpit na pagsasalita, ay may kasamang higit pa.

Para sa aming mga layunin, iimbak namin ang sumusunod na impormasyon tungkol sa device sa loob nito:

• Numero ng imbentaryo
• Pahayag ng pamagat
• modelo (Huawei CE12800, Juniper QFX5120, atbp.)
• Mga parameter ng katangian (mga board, interface, atbp.)
• Tungkulin (Leaf, Spine, Border Router, atbp.)
• Lokasyon (rehiyon, lungsod, data center, rack, unit)
• Mga koneksyon sa pagitan ng mga device
• Topology ng network

Ito ay ganap na malinaw na tayo mismo ay nais na malaman ang lahat ng ito.
Ngunit makakatulong ba ito para sa mga layunin ng automation?
Walang duda.
Halimbawa, alam namin na sa isang naibigay na data center sa mga switch ng Leaf, kung ito ay Huawei, ang mga ACL upang i-filter ang ilang partikular na trapiko ay dapat ilapat sa VLAN, at kung ito ay Juniper, pagkatapos ay sa unit 0 ng pisikal na interface.
O kailangan mong maglunsad ng bagong server ng Syslog sa lahat ng hangganan sa rehiyon.

Dito ay mag-iimbak kami ng mga virtual network device, halimbawa mga virtual router o root reflector. Maaari kaming magdagdag ng mga DNS server, NTP, Syslog at sa pangkalahatan lahat ng bagay na sa isang paraan o iba pang nauugnay sa network.

Bahagi 2: IP space management system

Oo, at sa ngayon ay may mga pangkat ng mga tao na sumusubaybay sa mga prefix at IP address sa isang Excel file. Ngunit ang modernong diskarte ay isang database pa rin, na may front-end sa nginx/apache, API at malawak na mga function para sa pagtatala ng mga IP address at network na nahahati sa mga VRF.
IPAM - Pamamahala ng IP Address.

Para sa aming mga layunin, iimbak namin ang sumusunod na impormasyon dito:

• Mga VLAN
• VRF
• Mga Network/Subnet
• mga IP address
• Nagbubuklod na mga address sa mga device, network sa mga lokasyon at mga numero ng VLAN

Muli, malinaw na gusto naming tiyakin na kapag naglaan kami ng bagong IP address para sa loopback ng ToR, hindi kami matitisod sa katotohanang naitalaga na ito sa isang tao. O na ginamit namin ang parehong prefix nang dalawang beses sa magkaibang dulo ng network.
Ngunit paano ito nakakatulong sa automation?
Ito ay madali.
Humihiling kami ng prefix sa system na may tungkuling Loopbacks, na naglalaman ng mga IP address na magagamit para sa paglalaan - kung ito ay natagpuan, ilalaan namin ang address, kung hindi, hinihiling namin ang paglikha ng isang bagong prefix.
O kapag gumagawa ng configuration ng device, malalaman natin mula sa parehong sistema kung saan dapat matatagpuan ang VRF interface.
At kapag nagsimula ng isang bagong server, ang script ay nag-log in sa system, nalaman kung aling switch ang server ay nasa, kung aling port at kung aling subnet ang itinalaga sa interface - at ilalaan ang address ng server mula dito.

Nagmumungkahi ito ng pagnanais na pagsamahin ang DCIM at IPAM sa isang sistema upang hindi ma-duplicate ang mga function at hindi magsilbi sa dalawang magkatulad na entity.
Yan ang gagawin natin.

Bahagi 3. Sistema para sa paglalarawan ng mga serbisyo ng network

Kung ang unang dalawang system ay nag-iimbak ng mga variable na kailangan pa ring gamitin sa anumang paraan, ang pangatlo ay naglalarawan para sa bawat tungkulin ng device kung paano ito dapat i-configure.
Ito ay nagkakahalaga ng pagkilala sa dalawang magkakaibang uri ng mga serbisyo sa network:

• Imprastraktura
• Kliyente.

Ang una ay idinisenyo upang magbigay ng pangunahing koneksyon at kontrol ng device. Kabilang dito ang VTY, SNMP, NTP, Syslog, AAA, mga routing protocol, CoPP, atbp.
Ang huli ay nag-aayos ng serbisyo para sa kliyente: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, atbp.
Siyempre, mayroon ding mga borderline na kaso - kung saan isasama ang MPLS LDP, BGP? Oo, at maaaring gamitin ang mga routing protocol para sa mga kliyente. Ngunit ito ay hindi mahalaga.

Ang parehong uri ng mga serbisyo ay nabubulok sa mga primitive ng configuration:

• pisikal at lohikal na mga interface (tag/anteg, mtu)
• Mga IP address at VRF (IP, IPv6, VRF)
• Mga ACL at patakaran sa pagproseso ng trapiko
• Mga Protocol (IGP, BGP, MPLS)
• Mga patakaran sa pagruruta (mga listahan ng prefix, komunidad, mga filter ng ASN).
• Mga serbisyo ng utility (SSH, NTP, LLDP, Syslog...)
• atbp.

Kung paano natin ito gagawin, wala pa akong ideya. Susuriin natin ito sa isang hiwalay na artikulo.

Kung medyo malapit sa buhay, maaari nating ilarawan iyon
Ang Leaf switch ay dapat may mga BGP session kasama ang lahat ng konektadong Spine switch, mag-import ng mga konektadong network sa proseso, at tumanggap lamang ng mga network mula sa isang partikular na prefix mula sa Spine switch. Limitahan ang CoPP IPv6 ND sa 10 pps, atbp.
Sa turn, ang mga spine ay nagsasagawa ng mga session kasama ang lahat ng konektadong lead, na kumikilos bilang root reflector, at tinatanggap mula sa kanila ang mga ruta lamang na may partikular na haba at may partikular na komunidad.

Bahagi 4: Mekanismo ng Pagsisimula ng Device

Sa ilalim ng heading na ito, pinagsama-sama ko ang marami sa mga aksyon na dapat mangyari para lumabas ang isang device sa radar at ma-access nang malayuan.

1. Ilagay ang device sa sistema ng imbentaryo.
2. Pumili ng IP address ng pamamahala.
3. I-set up ang pangunahing pag-access dito:
   Hostname, IP address ng pamamahala, ruta sa network ng pamamahala, mga gumagamit, mga SSH key, mga protocol - telnet/SSH/NETCONF

Mayroong tatlong mga diskarte:

• Ang lahat ay ganap na manu-mano. Ang aparato ay dinadala sa kinatatayuan, kung saan ang isang ordinaryong organikong tao ay ipasok ito sa mga system, kumonekta sa console at i-configure ito. Maaaring gumana sa maliliit na static na network.
• ZTP - Zero Touch Provisioning. Dumating ang hardware, tumayo, nakatanggap ng address sa pamamagitan ng DHCP, pumunta sa isang espesyal na server, at na-configure ang sarili nito.
• Ang imprastraktura ng mga console server, kung saan ang paunang pagsasaayos ay nangyayari sa pamamagitan ng console port sa awtomatikong mode.

Pag-uusapan natin ang lahat ng tatlo sa isang hiwalay na artikulo.

Bahagi 5: Modelo ng configuration ng vendor-agnostic

Hanggang ngayon, ang lahat ng mga system ay magkakaibang mga patch na nagbibigay ng mga variable at isang deklaratibong paglalarawan ng kung ano ang gusto naming makita sa network. Ngunit maaga o huli, kailangan mong harapin ang mga detalye.
Sa yugtong ito, para sa bawat partikular na device, pinagsama-sama ang mga primitive, serbisyo, at variable sa isang configuration model na aktwal na naglalarawan sa kumpletong configuration ng isang partikular na device, sa paraang neutral na vendor.
Ano ang ginagawa ng hakbang na ito? Bakit hindi agad gumawa ng configuration ng device na maaari mo lang i-upload?
Sa katunayan, malulutas nito ang tatlong problema:

1. Huwag umangkop sa isang partikular na interface para sa pakikipag-ugnayan sa device. Maging ito ay CLI, NETCONF, RESTCONF, SNMP - ang modelo ay magiging pareho.
2. Huwag panatilihin ang bilang ng mga template/script ayon sa bilang ng mga vendor sa network, at kung magbago ang disenyo, baguhin ang parehong bagay sa ilang lugar.
3. I-load ang configuration mula sa device (backup), ilagay ito sa eksaktong kaparehong modelo at direktang ikumpara ang target na configuration sa umiiral na para kalkulahin ang delta at maghanda ng configuration patch na babaguhin lamang ang mga bahaging iyon na kinakailangan o upang makilala ang mga deviation.

Bilang resulta ng yugtong ito, nakakakuha kami ng configuration na independyente sa vendor.

Bahagi 6. Interface ng driver na partikular sa vendor

Hindi mo dapat purihin ang iyong sarili nang may pag-asa na balang araw posible na i-configure ang isang ciska sa eksaktong parehong paraan tulad ng isang Juniper, sa pamamagitan lamang ng pagpapadala ng eksaktong parehong mga tawag sa kanila. Sa kabila ng lumalagong katanyagan ng mga whitebox at ang paglitaw ng suporta para sa NETCONF, RESTCONF, OpenConfig, ang partikular na nilalaman na inihahatid ng mga protocol na ito ay naiiba sa bawat vendor, at ito ay isa sa kanilang mapagkumpitensyang mga pagkakaiba na hindi sila susuko nang ganoon kadali.
Ito ay halos kapareho ng OpenContrail at OpenStack, na mayroong RestAPI bilang kanilang NorthBound interface, inaasahan ang ganap na magkakaibang mga tawag.

Kaya, sa ikalimang hakbang, ang modelong independiyenteng vendor ay dapat kunin ang anyo kung saan ito mapupunta sa hardware.
At dito lahat ng paraan ay mabuti (hindi): CLI, NETCONF, RESTCONF, SNMP simple.

Samakatuwid, kakailanganin namin ng driver na maglilipat ng resulta ng nakaraang hakbang sa kinakailangang format ng isang partikular na vendor: isang set ng mga CLI command, isang XML structure.

Bahagi 7. Mekanismo para sa paghahatid ng configuration sa device

Binuo namin ang configuration, ngunit kailangan pa rin itong maihatid sa mga device - at, malinaw naman, hindi sa pamamagitan ng kamay.
Una, nahaharap tayo sa tanong kung anong sasakyan ang gagamitin natin? At ngayon ang pagpipilian ay hindi na maliit:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (bagaman ito ay isang outlier dahil ito ay isang paraan upang maihatid ang FIB, hindi mga setting)

Let's dot the t's dito. Ang CLI ay legacy. SNMP... ubo ubo.
Ang RESTCONF ay isa pa ring hindi kilalang hayop; ang REST API ay sinusuportahan ng halos walang sinuman. Kaya naman, tututukan natin ang NETCONF sa serye.

Sa katunayan, tulad ng naintindihan na ng mambabasa, sa puntong ito ay nagpasya na kami sa interface - ang resulta ng nakaraang hakbang ay ipinakita na sa format ng interface na napili.

Ikalawa, at anong mga tool ang gagawin natin dito?
Mayroon ding malaking pagpipilian dito:

• Self-written script o platform. Armasin natin ang ating sarili ng ncclient at asyncIO at gawin ang lahat sa ating sarili. Ano ang gastos sa amin upang bumuo ng isang deployment system mula sa simula?
• Ansible sa mayamang library ng networking modules nito.
• Ang asin kasama ang kaunting trabaho nito sa network at koneksyon sa Napalm.
• Actually Napalm, which knows a couple of vendors and that's it, goodbye.
• Si Nornir ay isa pang hayop na ating hihimayin sa hinaharap.

Narito ang paborito ay hindi pa napili - kami ay maghahanap.

Ano pa ang mahalaga dito? Mga kahihinatnan ng paglalapat ng pagsasaayos.
Successful man o hindi. May access pa ba sa hardware o wala?
Mukhang makakatulong ang commit dito sa kumpirmasyon at pagpapatunay kung ano ang na-download sa device.
Ito, kasama ng wastong pagpapatupad ng NETCONF, ay makabuluhang nagpapaliit sa hanay ng mga angkop na device - hindi maraming mga tagagawa ang sumusuporta sa mga normal na commit. Ngunit ito ay isa lamang sa mga kinakailangan sa RFP. Sa huli, walang nag-aalala na walang isang Russian vendor ang susunod sa kondisyon ng interface na 32*100GE. O nag-aalala siya?

Bahagi 8. CI/CD

Sa puntong ito, handa na namin ang configuration para sa lahat ng device sa network.
Sumulat ako ng "para sa lahat" dahil pinag-uusapan natin ang pag-bersyon ng estado ng network. At kahit na kailangan mong baguhin ang mga setting ng isang switch lamang, ang mga pagbabago ay kinakalkula para sa buong network. Malinaw, maaari silang maging zero para sa karamihan ng mga node.

Ngunit, tulad ng nasabi na sa itaas, hindi kami isang uri ng mga barbaro na gustong i-roll ang lahat nang diretso sa produksyon.
Ang nabuong configuration ay dapat munang dumaan sa Pipeline CI/CD.

Ang CI/CD ay nangangahulugang Continuous Integration, Continuous Deployment. Ito ay isang diskarte kung saan ang team ay hindi lamang naglalabas ng bagong major release tuwing anim na buwan, ganap na pinapalitan ang luma, ngunit regular na unti-unting nagpapatupad ng (Deployment) bagong functionality sa maliliit na bahagi, na ang bawat isa ay komprehensibong sinubok para sa compatibility, seguridad at pagganap (Pagsasama-sama).

Para magawa ito, mayroon kaming version control system na sumusubaybay sa mga pagbabago sa configuration, isang laboratoryo na nagsusuri kung ang serbisyo ng kliyente ay sira, isang monitoring system na sumusuri sa katotohanang ito, at ang huling hakbang ay ang paglulunsad ng mga pagbabago sa production network.

Maliban sa mga utos sa pag-debug, talagang lahat ng pagbabago sa network ay dapat dumaan sa CI/CD Pipeline - ito ang aming garantiya ng isang tahimik na buhay at isang mahaba, masayang karera.

Bahagi 9. Backup at anomaly detection system

Well, hindi na kailangang pag-usapan muli ang tungkol sa mga backup.
Ilalagay lang namin ang mga ito sa git ayon sa korona o sa katotohanan ng pagbabago ng pagsasaayos.

Ngunit ang pangalawang bahagi ay mas kawili-wili - dapat bantayan ng isang tao ang mga backup na ito. At sa ilang mga kaso, ang isang taong ito ay dapat pumunta at ibalik ang lahat tulad ng dati, at sa iba pa, ngumyaw sa isang tao na may mali.
Halimbawa, kung may lumitaw na bagong user na hindi nakarehistro sa mga variable, kailangan mong alisin siya sa hack. At kung mas mahusay na huwag hawakan ang isang bagong panuntunan sa firewall, maaaring may nag-on lang sa pag-debug, o marahil ang bagong serbisyo, isang bungler, ay hindi nakarehistro ayon sa mga regulasyon, ngunit ang mga tao ay sumali na dito.

Hindi pa rin kami makakatakas sa ilang maliit na delta sa laki ng buong network, sa kabila ng anumang mga sistema ng automation at matibay na kamay ng pamamahala. Upang i-debug ang mga problema, walang magdadagdag ng configuration sa mga system pa rin. Bukod dito, maaaring hindi man lang sila maisama sa modelo ng pagsasaayos.

Halimbawa, ang isang panuntunan sa firewall para sa pagbibilang ng bilang ng mga packet sa bawat partikular na IP upang ma-localize ang isang problema ay isang ganap na ordinaryong pansamantalang pagsasaayos.

Bahagi 10. Sistema ng pagsubaybay

Sa una ay hindi ko tatalakayin ang paksa ng pagsubaybay - ito ay isang napakalaki, kontrobersyal at kumplikadong paksa. Ngunit habang umuunlad ang mga bagay, ito ay naging mahalagang bahagi ng automation. At imposibleng laktawan ito, kahit na walang pagsasanay.

Ang Evolving Thought ay isang organikong bahagi ng proseso ng CI/CD. Pagkatapos ilunsad ang configuration sa network, kailangan nating matukoy kung okay na ang lahat dito ngayon.
At pinag-uusapan natin hindi lamang at hindi gaanong tungkol sa mga iskedyul ng paggamit ng interface o pagkakaroon ng node, ngunit tungkol sa mas banayad na mga bagay - ang pagkakaroon ng mga kinakailangang ruta, mga katangian sa kanila, ang bilang ng mga sesyon ng BGP, mga kapitbahay ng OSPF, End-to-End na pagganap ng labis na mga serbisyo.
Huminto ba ang mga syslog sa external na server sa pagdaragdag, o nasira ba ang ahente ng SFlow, o nagsimula bang lumaki ang mga pagbaba sa mga pila, o nasira ba ang koneksyon sa pagitan ng ilang pares ng prefix?

Pag-isipan natin ito sa isang hiwalay na artikulo.

Konklusyon

Bilang batayan, pinili ko ang isa sa mga modernong disenyo ng network ng data center - L3 Clos Fabric na may BGP bilang routing protocol.
Sa pagkakataong ito ay bubuuin namin ang network sa Juniper, dahil ngayon ang interface ng JunOs ay isang vanlove.

Gawin nating mas mahirap ang ating buhay sa pamamagitan ng paggamit lamang ng mga Open Source na tool at isang multi-vendor network - kaya bilang karagdagan sa Juniper, pipili ako ng isa pang maswerteng tao sa daan.

Ang plano para sa paparating na mga publikasyon ay katulad nito:
Una ay magsasalita ako tungkol sa mga virtual network. Una sa lahat, dahil gusto ko, at pangalawa, dahil kung wala ito, ang disenyo ng network ng imprastraktura ay hindi masyadong malinaw.
Pagkatapos ay tungkol sa disenyo ng network mismo: topology, pagruruta, mga patakaran.
Mag-assemble tayo ng laboratory stand.
Pag-isipan natin ito at baka magsanay sa pagsisimula ng device sa network.
At pagkatapos ay tungkol sa bawat bahagi sa matalik na detalye.

At oo, hindi ako nangangako na tatapusin ang cycle na ito sa isang handa na solusyon. 🙂

Kapaki-pakinabang na mga link

• Bago suriin ang serye, sulit na basahin ang libro ni Natasha Samoilenko Python para sa Network Engineers. At baka pumasa kurso.
• Magiging kapaki-pakinabang din ang pagbabasa RFC tungkol sa disenyo ng mga pabrika ng data center mula sa Facebook ni Peter Lapukhov.
• Ang dokumentasyon ng arkitektura ay magbibigay sa iyo ng ideya kung paano gumagana ang Overlay SDN. Tela ng Tungsten (dating Open Contrail).

Salamat

Roman Gorge. Para sa mga komento at pag-edit.
Artyom Chernobay. Para sa KDPV.

Pinagmulan: www.habr.com