SDSM wis rampung, nanging kepinginan kanggo nulis tetep ora bisa dikendhaleni.

Wis pirang-pirang taun, sedulur kita nandhang tugas rutin, nyabrang driji sadurunge nindakake lan ora turu amarga bola-bali wengi.
Nanging wektu peteng wis rampung.

Kanthi artikel iki aku bakal miwiti seri babagan carane kanggo kula otomatis katon.
Sadawane dalan, kita bakal ngerti tahapan otomatisasi, nyimpen variabel, desain formalizing, RestAPI, NETCONF, YANG, YDK lan kita bakal nindakake akeh pemrograman.
Kanggo kula tegese a) dudu bebener sing objektif, b) dudu pendekatan sing paling apik tanpa syarat, c) panemuku, sanajan sajrone gerakan saka artikel pisanan nganti artikel pungkasan, bisa diganti - jujur, saka tahap draf nganti publikasi, Aku rewrote kabeh rampung kaping pindho.

Isi

1. Tujuane
   1. Jaringan kasebut kaya organisme tunggal
   2. Pengujian konfigurasi
   3. Versiing
   4. Ngawasi lan marasake awakmu dhewe layanan

2. Tegese
   1. Sistem persediaan
   2. Sistem manajemen ruang IP
   3. Sistem deskripsi layanan jaringan
   4. Mekanisme wiwitan piranti
   5. Model konfigurasi vendor-agnostik
   6. Antarmuka driver khusus vendor
   7. Mekanisme kanggo ngirim konfigurasi menyang piranti
   8. CI / CD
   9. Mekanisme kanggo serep lan nelusuri penyimpangan
   10. Sistem monitoring

3. kesimpulan

Aku bakal nyoba kanggo nindakake ADSM ing format rada beda saka SDSM. Artikel gedhe, rinci, nomer bakal terus katon, lan ing antarane aku bakal nerbitake cathetan cilik saka pengalaman saben dina. Aku bakal nyoba nglawan perfeksionisme ing kene lan ora dilat saben wong.

Kok lucu yen kaping pindho sampeyan kudu ngliwati dalan sing padha.

Kaping pisanan, aku kudu nulis artikel babagan jaringan dhewe amarga ora ana ing RuNet.

Saiki aku ora bisa nemokake dokumen lengkap sing bakal sistematis pendekatan kanggo otomatisasi lan nganalisa teknologi ing ndhuwur nggunakake conto praktis prasaja.

Aku bisa uga salah, mula menehi link menyang sumber daya sing migunani. Nanging, iki ora bakal ngganti tekadku kanggo nulis, amarga tujuan utama yaiku sinau dhewe, lan nggawe urip luwih gampang kanggo wong liya minangka bonus sing nyenengake sing ngelus gene kanggo nuduhake pengalaman.

Kita bakal nyoba njupuk pusat data LAN DC ukuran medium lan ngrampungake kabeh skema otomatisasi.
Aku bakal nindakake sawetara perkara meh pisanan karo sampeyan.

Aku ora bakal asli ing gagasan lan alat sing diterangake ing kene. Dmitry Figol wis apik banget saluran karo aliran ing topik iki.
Artikel-artikel kasebut bakal tumpang tindih karo akeh aspek.

LAN DC wis 4 DC, bab 250 ngalih, setengah rolas router lan saperangan saka firewalls.
Ora Facebook, nanging cukup kanggo nggawe sampeyan mikir jero babagan otomatisasi.
Nanging, ana pendapat yen sampeyan duwe luwih saka 1 piranti, otomatisasi wis dibutuhake.
Nyatane, angel mbayangno manawa sapa wae saiki bisa urip tanpa paling ora sebungkus skrip lutut.
Sanajan aku krungu yen ana kantor ing ngendi alamat IP disimpen ing Excel, lan saben ewu piranti jaringan dikonfigurasi kanthi manual lan duwe konfigurasi unik dhewe. Iki, mesthi, bisa liwati mati minangka seni modern, nanging raos engineer mesthi bakal gelo.

Tujuane

Saiki kita bakal nemtokake tujuan sing paling abstrak:

• Jaringan kasebut kaya organisme tunggal
• Pengujian konfigurasi
• Versi status jaringan
• Ngawasi lan marasake awakmu dhewe layanan

Mengko ing artikel iki kita bakal ndeleng apa tegese sing bakal digunakake, lan ing ngisor iki, kita bakal nliti tujuan lan sarana kanthi rinci.

Jaringan kasebut kaya organisme tunggal

Frasa sing nemtokake seri kasebut, sanajan sepisanan bisa uga ora katon penting: kita bakal ngatur jaringan, ora piranti individu.
Ing taun-taun pungkasan, kita wis weruh owah-owahan ing emphasis menyang nambani jaringan minangka entitas siji, mulane Jaringan Disain Perangkat Lunak, Intent Driven Networks и Jaringan Otonom.
Sawise kabeh, apa sing dibutuhake aplikasi sacara global saka jaringan: konektivitas antarane titik A lan B (uga, kadhangkala +B-Z) lan isolasi saka aplikasi lan pangguna liyane.

Lan tugas kita ing seri iki mbangun sistem, njaga konfigurasi saiki kabeh jaringan, sing wis diurai dadi konfigurasi nyata ing saben piranti miturut peran lan lokasi.
sistem manajemen jaringan gawe katut sing kanggo nggawe owahan kita hubungi iku, lan iku, ing siji, ngetung negara sing dipengini kanggo saben piranti lan configures.
Kanthi cara iki, kita nyilikake akses manual menyang CLI nganti meh nol - owah-owahan apa wae ing setelan piranti utawa desain jaringan kudu diresmikake lan didokumentasikan - lan mung banjur digulung menyang unsur jaringan sing dibutuhake.

Yaiku, contone, yen kita mutusake yen wiwit saiki saklar rak ing Kazan kudu ngumumake rong jaringan tinimbang siji, kita

1. Kaping pisanan, kita nyathet owah-owahan ing sistem
2. Ngasilake konfigurasi target kabeh piranti jaringan
3. Kita miwiti program nganyari konfigurasi jaringan, sing ngetung apa sing kudu dibusak ing saben simpul, apa sing kudu ditambahake, lan nggawa simpul menyang negara sing dikarepake.

Ing wektu sing padha, kita nggawe owahan kanthi manual mung ing langkah pisanan.

Pengujian konfigurasi

Dikenalsing 80% saka masalah dumadi sak owah-owahan konfigurasi - bukti ora langsung iki sing sak preian Taun Anyar kabeh biasane kalem.
Aku dhewe wis nyekseni puluhan downtime global amarga kesalahan manungsa: prentah sing salah, konfigurasi dieksekusi ing cabang sing salah, komunitas lali, MPLS dibongkar sacara global ing router, limang potongan hardware dikonfigurasi, nanging kesalahane ora. ngeweruhi ing kaping enem, owah-owahan lawas sing ditindakake dening wong liya ditindakake. Ana akeh skenario.

Otomatisasi bakal ngidini kita nggawe kesalahan sing luwih sithik, nanging kanthi skala sing luwih gedhe. Kanthi cara iki sampeyan bisa bata ora mung siji piranti, nanging kabeh jaringan bebarengan.

Wiwit jaman biyen, mbah kakung kita mriksa kabeneran owah-owahan sing ditindakake kanthi ati-ati, bal baja lan fungsi jaringan sawise diluncurake.
Simbah-simbah sing kerjane nyebabake downtime lan kerugian bencana nyebabake turunane luwih sithik lan kudu mati sajrone wektu, nanging evolusi minangka proses sing alon, mula ora kabeh wong isih nyoba owah-owahan ing laboratorium dhisik.
Nanging, ing ngarep kemajuan yaiku wong-wong sing wis ngotomatisasi proses nguji konfigurasi lan aplikasi luwih lanjut menyang jaringan. Ing tembung liyane, aku nyilih prosedur CI/CD (Integrasi Terus-terusan, Penyebaran Terus-terusan) saka pangembang.
Ing salah sawijining bagean, kita bakal weruh carane ngleksanakake iki nggunakake sistem kontrol versi, mbokmenawa Github.

Sawise sampeyan wis biasa karo ide jaringan CI / CD, sewengi cara mriksa konfigurasi kanthi nglamar menyang jaringan produksi bakal katon kaya ora ngerti awal abad pertengahan. Kayane nabrak hulu ledak nganggo palu.

Lanjutan organik saka gagasan babagan sistem manajemen jaringan lan CI / CD dadi versi lengkap konfigurasi.

Versiing

Kita bakal nganggep manawa kanthi owah-owahan, ora ketompo carane cilik, sanajan ing siji piranti sing ora bisa ditemokake, kabeh jaringan pindhah saka siji negara menyang negara liyane.
Lan kita tansah ora nindakake printah ing piranti, kita ngganti negara jaringan.
Dadi ayo nelpon versi negara kasebut?

Ayo dadi ngomong versi saiki 1.0.0.
Wis alamat IP antarmuka Loopback ing salah siji ToR diganti? Iki versi cilik lan bakal diwenehi nomer 1.0.1.
We diubah kawicaksanan kanggo ngimpor rute menyang BGP - sethitik liyane serius - wis 1.1.0
Kita mutusaké kanggo njaluk nyisihaken saka IGP lan ngalih menyang BGP mung - iki wis owah-owahan desain radikal - 2.0.0.

Ing wektu sing padha, macem-macem DC bisa uga duwe versi sing beda - jaringan berkembang, peralatan anyar dipasang, tingkat spine anyar ditambahake ing endi wae, ora ing wong liya, lsp.

ing versi semantik kita bakal ngomong ing artikel kapisah.

Aku mbaleni - owah-owahan apa wae (kajaba printah debugging) yaiku nganyari versi. Administrator kudu diwenehi kabar babagan penyimpangan saka versi saiki.

Sing padha ditrapake kanggo mbatalake owah-owahan - iki ora mbatalake perintah pungkasan, iki dudu rollback nggunakake sistem operasi piranti - iki nggawa kabeh jaringan menyang versi anyar (lawas).

Ngawasi lan marasake awakmu dhewe layanan

Tugas sing nyata iki wis tekan tingkat anyar ing jaringan modern.
Asring, panyedhiya layanan gedhe njupuk pendekatan yen layanan sing gagal kudu didandani kanthi cepet lan sing anyar diangkat, tinimbang ngerteni apa sing kedadeyan.
"Banget" tegese sampeyan kudu dilapisi kanthi akeh ing kabeh sisi kanthi ngawasi, sing sajrone sawetara detik bakal ndeteksi panyimpangan sing paling sithik saka norma.
Lan ing kene metrik biasa, kayata loading antarmuka utawa kasedhiyan simpul, ora cukup maneh. Pemantauan manual dening petugas tugas ora cukup.
Kanggo akeh perkara kudu ana Waras awake dhewe - lampu ngawasi dadi abang lan kita lunga lan Applied plantain dhéwé ngendi lara.

Lan ing kene kita uga ngawasi ora mung piranti individu, nanging uga kesehatan kabeh jaringan, loro whitebox, sing relatif bisa dingerteni, lan blackbox, sing luwih rumit.

Apa sing dibutuhake kanggo ngetrapake rencana ambisius kasebut?

• Duwe dhaptar kabeh piranti ing jaringan, lokasi, peran, model, versi piranti lunak.
  kazan-leaf-1.lmu.net, Kazan, rwaning, Juniper QFX 5120, R18.3.
• Nduwe sistem kanggo njlèntrèhaké layanan jaringan.
  IGP, BGP, L2/3VPN, Kebijakan, ACL, NTP, SSH.
• Bisa miwiti piranti.
  Jeneng host, Mgmt IP, Mgmt Route, Users, RSA-Keys, LLDP, NETCONF
• Ngatur piranti lan nggawa konfigurasi menyang versi sing dikarepake (kalebu lawas).
• Konfigurasi tes
• Priksa kanthi periodik status kabeh piranti kanggo panyimpangan saka sing saiki lan laporake sapa sing kudune.
  Sewengi, wong quietly nambah aturan kanggo ACL.
• Ngawasi kinerja.

Tegese

Iku muni cukup rumit kanggo miwiti decomposing project menyang komponen.

Lan bakal ana sepuluh:

1. Sistem persediaan
2. Sistem manajemen ruang IP
3. Sistem deskripsi layanan jaringan
4. Mekanisme wiwitan piranti
5. Model konfigurasi vendor-agnostik
6. Antarmuka driver khusus vendor
7. Mekanisme kanggo ngirim konfigurasi menyang piranti
8. CI / CD
9. Mekanisme kanggo serep lan nelusuri penyimpangan
10. Sistem monitoring

Iki, kanthi cara, minangka conto carane tampilan ing tujuan siklus diganti - ana 4 komponen ing konsep.

Ing ilustrasi aku nggambarake kabeh komponen lan piranti kasebut dhewe.
Komponen intersecting interaksi karo saben liyane.
Sing luwih gedhe blok, luwih akeh perhatian kudu dibayar kanggo komponen iki.

Komponen 1: Sistem persediaan

Temenan, kita pengin ngerti apa peralatan dumunung ing ngendi, apa sing disambungake.
Sistem inventaris minangka bagean integral saka perusahaan apa wae.
Paling asring, perusahaan duwe sistem persediaan sing kapisah kanggo piranti jaringan, sing ngrampungake masalah sing luwih spesifik.
Minangka bagéan saka seri artikel iki, kita bakal nyebat DCIM - Manajemen Infrastruktur Pusat Data. Sanajan istilah DCIM dhewe, kanthi tegas, kalebu luwih akeh.

Kanggo tujuan kita, kita bakal nyimpen informasi ing ngisor iki babagan piranti kasebut:

• Nomer inventaris
• Judhul / Katrangan
• Model (Huawei CE12800, Juniper QFX5120, lsp.)
• Parameter karakteristik (Papan, antarmuka, lsp.)
• peran (Leaf, Spine, Border Router, lsp.)
• lokasi (wilayah, kutha, pusat data, rak, unit)
• Interconnections antarane piranti
• Topologi jaringan

Cetha banget yen awake dhewe pengin ngerti kabeh iki.
Nanging iki bakal mbantu kanggo tujuan otomatisasi?
temtunipun.
Contone, kita ngerti yen ing pusat data diwenehi ing ngalih Leaf, yen Huawei, ACLs kanggo nyaring lalu lintas tartamtu kudu Applied ing VLAN, lan yen Juniper, banjur ing unit 0 antarmuka fisik.
Utawa sampeyan kudu nggulung server Syslog anyar menyang kabeh wates ing wilayah kasebut.

Ing kono kita bakal nyimpen piranti jaringan virtual, contone, router virtual utawa reflektor root. Kita bisa nambah server DNS, NTP, Syslog lan umume kabeh sing ana hubungane karo jaringan.

Komponen 2: Sistem manajemen ruang IP

Ya, lan saiki ana tim wong sing nglacak prefiks lan alamat IP ing file Excel. Nanging pendekatan modern isih dadi basis data, kanthi front-end ing nginx / apache, API lan fungsi ekstensif kanggo ngrekam alamat IP lan jaringan sing dipérang dadi VRF.
IPAM - Manajemen Alamat IP.

Kanggo tujuan kita, kita bakal nyimpen informasi ing ngisor iki:

• VLAN
• VRF
• Jaringan/Subnet
• alamat IP
• Naleni alamat menyang piranti, jaringan menyang lokasi lan nomer VLAN

Maneh, jelas yen kita pengin mesthekake yen kita nyedhiyakake alamat IP anyar kanggo loopback ToR, kita ora bakal kesandhung amarga wis ditugasake kanggo wong liya. Utawa yen kita nggunakake ater-ater sing padha kaping pindho ing ujung jaringan sing beda.
Nanging kepiye iki mbantu otomatisasi?
Gampang.
Kita njaluk ater-ater ing sistem kanthi peran Loopbacks, sing ngemot alamat IP sing kasedhiya kanggo alokasi - yen ditemokake, kita nyedhiyakake alamat kasebut, yen ora, kita njaluk nggawe awalan anyar.
Utawa nalika nggawe konfigurasi piranti, kita bisa ngerteni saka sistem sing padha karo VRF antarmuka kudu dumunung.
Lan nalika miwiti server anyar, script log menyang sistem, golek metu kang ngalih server ing, kang port lan subnet diutus kanggo antarmuka - lan bakal nyedhiakke alamat server saka iku.

Iki nuduhake kepinginan kanggo nggabungake DCIM lan IPAM dadi siji sistem supaya ora duplikat fungsi lan ora nglayani rong entitas sing padha.
Sing bakal kita tindakake.

Komponen 3. Sistem kanggo njlentrehake layanan jaringan

Yen loro sistem pisanan nyimpen variabel sing isih kudu digunakake piye wae, banjur katelu nerangake kanggo saben peran piranti carane kudu diatur.
Perlu mbedakake rong jinis layanan jaringan:

• Infrastruktur
• Klien.

Tilas dirancang kanggo nyedhiyakake konektivitas dhasar lan kontrol piranti. Iki kalebu VTY, SNMP, NTP, Syslog, AAA, protokol routing, CoPP, lsp.
Sing terakhir ngatur layanan kanggo klien: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, lsp.
Mesthi, ana uga kasus wates - ing ngendi kalebu MPLS LDP, BGP? Ya, lan protokol routing bisa digunakake kanggo klien. Nanging iki ora penting.

Kaloro jinis layanan kasebut didekomposisi dadi primitif konfigurasi:

• antarmuka fisik lan logis (tag/anteg, mtu)
• Alamat IP lan VRF (IP, IPv6, VRF)
• ACLs lan kawicaksanan Processing lalu lintas
• Protokol (IGP, BGP, MPLS)
• Kabijakan rute (dhaptar awalan, komunitas, saringan ASN).
• Layanan utilitas (SSH, NTP, LLDP, Syslog...)
• lsp.

Kepiye carane kita bakal nindakake iki, aku durung ngerti. Kita bakal nliti ing artikel sing kapisah.

Yen luwih cedhak karo urip, mula kita bisa nggambarake
Switch Leaf kudu duwe sesi BGP karo kabeh switch Spine sing disambungake, ngimpor jaringan sing disambungake menyang proses kasebut, lan mung nampa jaringan saka awalan tartamtu saka switch Spine. Matesi CoPP IPv6 ND nganti 10 pps, lsp.
Sabanjure, spines terus sesi karo kabeh timbal sing disambungake, tumindak minangka reflektor ROOT, lan nampa saka wong-wong mau mung rute dawa tartamtu lan karo masyarakat tartamtu.

Komponen 4: Mekanisme Inisialisasi Piranti

Ing judhul iki, aku nggabungake akeh tumindak sing kudu ditindakake supaya piranti bisa katon ing radar lan bisa diakses saka jarak jauh.

1. Ketik piranti ing sistem persediaan.
2. Pilih alamat IP manajemen.
3. Setel akses dhasar menyang:
   Jeneng host, alamat IP manajemen, rute menyang jaringan manajemen, pangguna, kunci SSH, protokol - telnet/SSH/NETCONF

Ana telung pendekatan:

• Kabeh rampung manual. Piranti kasebut digawa menyang stand, ing ngendi wong organik biasa bakal mlebu menyang sistem, nyambung menyang konsol lan ngatur. Bisa digunakake ing jaringan statis cilik.
• ZTP - Penyediaan Zero Tutul. Hardware teka, ngadeg, nampa alamat liwat DHCP, pindhah menyang server khusus, lan ngatur dhewe.
• Infrastruktur server console, ing ngendi konfigurasi awal dumadi liwat port console ing mode otomatis.

Kita bakal ngomong babagan telu kasebut ing artikel sing kapisah.

Komponen 5: Model konfigurasi vendor-agnostik

Nganti saiki, kabeh sistem wis dadi patch sing beda-beda sing nyedhiyakake variabel lan deskripsi deklaratif babagan apa sing arep kita deleng ing jaringan kasebut. Nanging cepet utawa mengko, sampeyan kudu menehi hasil karo spesifik.
Ing tataran iki, kanggo saben piranti tartamtu, primitif, layanan lan variabel digabungake menyang model konfigurasi sing bener njlèntrèhaké konfigurasi lengkap saka piranti tartamtu, mung ing vendor-netral.
Apa sing ditindakake langkah iki? Apa ora langsung nggawe konfigurasi piranti sing mung bisa diunggah?
Nyatane, iki ngrampungake telung masalah:

1. Aja adaptasi karo antarmuka tartamtu kanggo sesambungan karo piranti. Dadi CLI, NETCONF, RESTCONF, SNMP - model bakal padha.
2. Aja tetep nomer Cithakan / Tulisan miturut nomer vendor ing jaringan, lan yen owah-owahan desain, ngganti bab sing padha ing sawetara panggonan.
3. Muat konfigurasi saka piranti (serep), sijine menyang persis model padha lan langsung mbandhingaké konfigurasi target karo sing wis ana kanggo ngetung delta lan nyiapake patch konfigurasi sing bakal ngganti mung bagean sing perlu utawa kanggo ngenali panyimpangan.

Minangka asil saka tataran iki, kita entuk konfigurasi vendor-independen.

Komponen 6. Antarmuka driver khusus vendor

Sampeyan kudu ora flatter dhewe karo pangarep-arep sing siji dina bakal bisa kanggo ngatur ciska ing persis cara sing padha Juniper, mung dening ngirim telpon persis padha kanggo wong-wong mau. Senadyan akeh popularitas saka whiteboxes lan emergence saka support kanggo NETCONF, RESTCONF, OpenConfig, isi tartamtu sing protokol iki ngirim bedo saka vendor kanggo vendor, lan iki salah siji saka beda competitive sing padha ora bakal nyerah supaya gampang.
Iki kira-kira padha karo OpenContrail lan OpenStack, sing duwe RestAPI minangka antarmuka NorthBound, nyana telpon sing beda banget.

Dadi, ing langkah kaping lima, model vendor-independen kudu njupuk formulir sing bakal menyang hardware.
Lan ing kene kabeh sarana apik (ora): CLI, NETCONF, RESTCONF, SNMP mung.

Mulane, kita butuh driver sing bakal nransfer asil langkah sadurunge menyang format sing dibutuhake saka vendor tartamtu: sakumpulan perintah CLI, struktur XML.

Komponen 7. Mekanisme kanggo ngirim konfigurasi menyang piranti

Kita wis nggawe konfigurasi, nanging isih kudu dikirim menyang piranti - lan, mesthi, ora nganggo tangan.
Sepisanan, kita ngadhepi pitakonan babagan transportasi apa sing bakal digunakake? Lan dina iki pilihan ora cilik:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (sanajan iku outlier amarga iku cara kanggo ngirim FIB, ora setelan)

Ayo dadi titik t ing kene. CLI minangka warisan. SNMP... watuk watuk.
RESTCONF isih kewan sing ora dingerteni; REST API ora didhukung dening sapa wae. Mulane, kita bakal fokus ing NETCONF ing seri kasebut.

Nyatane, minangka sing maca wis ngerti, ing titik iki kita wis mutusaké ing antarmuka - asil saka langkah sadurunge wis presented ing format antarmuka sing dipilih.

Kaping kalih, lan alat apa sing bakal kita lakoni?
Ana uga pilihan gedhe ing kene:

• Skrip utawa platform sing ditulis dhewe. Ayo nganggo ncclient lan asyncIO lan nindakake kabeh dhewe. Apa biaya kanggo mbangun sistem penyebaran saka awal?
• Ansible karo perpustakaan sugih modul jaringan.
• Salt karo karya meager karo jaringan lan sambungan karo Napalm.
• Bener Napalm, sing ngerti saperangan vendor lan iku, pamit.
• Nornir minangka kewan liyane sing bakal kita mbedah ing mangsa ngarep.

Ing kene favorit durung dipilih - kita bakal nggoleki.

Apa maneh sing penting ing kene? Akibat saka nglamar konfigurasi.
Sukses utawa ora. Apa isih ana akses menyang hardware utawa ora?
Kayane commit bakal mbantu konfirmasi lan validasi apa sing diundhuh menyang piranti kasebut.
Iki, digabungake karo implementasine bener saka NETCONF, Ngartekno narrows sawetara piranti cocok - ora akeh manufaktur ndhukung normal commits. Nanging iki mung salah siji saka prasyarat ing RFP. Ing pungkasan, ora ana sing kuwatir yen ora ana vendor Rusia sing bakal tundhuk karo kondisi antarmuka 32 * 100GE. Utawa dheweke kuwatir?

Komponen 8. CI/CD

Ing jalur iki, kita wis duwe konfigurasi siap kanggo kabeh piranti jaringan.
Aku nulis "kanggo kabeh" amarga kita ngomong babagan versi negara jaringan. Lan sanajan sampeyan kudu ngganti setelan mung siji ngalih, owah-owahan diwilang kanggo kabeh jaringan. Temenan, bisa dadi nol kanggo umume node.

Nanging, kaya sing wis kasebut ing ndhuwur, kita dudu wong barbar sing pengin nggawe kabeh langsung menyang produksi.
Konfigurasi sing digawe kudu liwat Pipeline CI/CD.

CI/CD singkatan saka Continuous Integration, Continuous Deployment. Iki minangka pendekatan ing ngendi tim kasebut ora mung ngetokake rilis utama anyar saben nem sasi, kanthi ngganti sing lawas, nanging kanthi rutin nindakake fungsi anyar (Panyebaran) ing bagean cilik, sing saben-saben diuji kanthi lengkap kanggo kompatibilitas, keamanan lan kinerja (Integrasi).

Kanggo nindakake iki, kita duwe sistem kontrol versi sing ngawasi owah-owahan konfigurasi, laboratorium sing mriksa manawa layanan klien rusak, sistem ngawasi sing mriksa kasunyatan iki, lan langkah pungkasan yaiku owahan ing jaringan produksi.

Kajaba saka printah debugging, pancen kabeh owah-owahan ing jaringan kudu liwat Pipeline CI / CD - iki njamin kita urip sepi lan dawa, karir seneng.

Komponen 9. Sistem deteksi serep lan anomali

Ya, ora perlu ngomong babagan serep maneh.
Kita mung bakal sijine ing git miturut makutha utawa marang kasunyatan saka owah-owahan konfigurasi.

Nanging bagean kapindho luwih menarik - ana sing kudu ngawasi serep kasebut. Lan ing sawetara kasus, wong iki kudu lunga lan ngowahi kabeh kaya sing ana, lan ing liyane, meow marang wong yen ana sing salah.
Contone, yen pangguna anyar wis katon sing ora kadhaptar ing variabel, sampeyan kudu mbusak wong adoh saka hack. Lan yen luwih becik ora ndemek aturan firewall anyar, bisa uga ana sing ngaktifake debugging, utawa bisa uga layanan anyar, bungler, ora didaftar miturut peraturan, nanging wong wis gabung.

Kita isih ora bakal uwal sawetara delta cilik ing skala kabeh jaringan, sanajan ana sistem otomatisasi lan tangan manajemen sing kuwat. Kanggo masalah debug, ora ana sing bakal nambah konfigurasi menyang sistem. Kajaba iku, bisa uga ora kalebu ing model konfigurasi.

Contone, aturan firewall kanggo ngetang jumlah paket saben IP tartamtu kanggo localize masalah iku konfigurasi sak wentoro rampung biasa.

Komponen 10. Sistem monitoring

Kaping pisanan, aku ora bakal nutupi topik pemantauan - iki isih dadi topik sing akeh, kontroversial lan rumit. Nanging nalika kedadeyan, ternyata iki minangka bagean integral saka otomatisasi. Lan ora bisa ngliwati, sanajan tanpa latihan.

Evolving Thought minangka bagean organik saka proses CI / CD. Sawise nggulung konfigurasi menyang jaringan, kita kudu bisa nemtokake manawa kabeh iku oke karo saiki.
Lan kita ngomong ora mung babagan jadwal panggunaan antarmuka utawa kasedhiyan simpul, nanging bab sing luwih subtle - anané rute sing perlu, atribut ing wong-wong mau, jumlah sesi BGP, tanggi OSPF, kinerja End-to-End. saka layanan overlying.
Apa syslogs menyang server njaba mandheg nambah munggah, utawa agen SFlow rusak, utawa irungnya ing antrian wiwit tuwuh, utawa panyambungan antarane sawetara pasangan ater-ater break mudhun?

Kita bakal nggambarake iki ing artikel sing kapisah.

kesimpulan

Minangka basis, aku milih salah siji saka desain jaringan pusat data modern - L3 Clos Fabric karo BGP minangka protokol nuntun.
Wektu iki kita bakal mbangun jaringan ing Juniper, amarga saiki antarmuka JunOs vanlove a.

Ayo nggawe urip kita luwih angel kanthi mung nggunakake alat Open Source lan jaringan multi-vendor - dadi saliyane Juniper, aku bakal milih wong sing luwih begja ing dalan.

Rencana kanggo publikasi sing bakal teka kaya mangkene:
Kaping pisanan, aku bakal ngomong babagan jaringan virtual. Kaping pisanan, amarga aku pengin, lan nomer loro, amarga tanpa iki, desain jaringan infrastruktur ora bakal cetha banget.
Banjur babagan desain jaringan dhewe: topologi, routing, kabijakan.
Ayo ngumpulake stand laboratorium.
Ayo dipikirake lan bisa uga latihan nginisialisasi piranti ing jaringan.
Lan banjur babagan saben komponèn ing rinci intim.

Lan ya, aku ora janji bakal mungkasi siklus iki kanthi solusi sing wis siap. 🙂

link migunani

• Sadurunge delving menyang seri, iku worth maca buku Natasha Samoilenko Python kanggo Network Engineers. Lan mungkin lulus mesthi wae.
• Iku uga bakal migunani kanggo maca RFC babagan desain pabrik pusat data saka Facebook dening Peter Lapukhov.
• Dokumentasi arsitektur bakal menehi ide babagan cara kerja Overlay SDN. Kain Tungsten Kab (sadurungé Open Contrail).

matur nuwun

Roman Gorge. Kanggo komentar lan suntingan.
Artyom Chernobay. Kanggo KDPV.

Source: www.habr.com