SDSM sudah tamat, tetapi keinginan yang tidak terkawal untuk menulis masih ada.
Selama bertahun-tahun, saudara kita menderita kerana melakukan kerja rutin, menyilangkan jari sebelum melakukan dan kurang tidur akibat pusing malam.
Tetapi masa gelap akan berakhir.
Dengan artikel ini saya akan memulakan siri tentang bagaimana saya automasi dilihat.
Sepanjang perjalanan, kami akan memahami peringkat automasi, menyimpan pembolehubah, memformalkan reka bentuk, RestAPI, NETCONF, YANG, YDK dan kami akan melakukan banyak pengaturcaraan.
Me bermakna a) ia bukan kebenaran objektif, b) ia bukan pendekatan terbaik tanpa syarat, c) pendapat saya, walaupun semasa pergerakan dari artikel pertama hingga terakhir, boleh berubah - jujur, dari peringkat draf ke penerbitan, saya menulis semula semuanya sepenuhnya dua kali.
Π‘ΠΎΠ΄Π΅ΡΠΆΠ°Π½ΠΈΠ΅
- Objektif
- Rangkaian adalah seperti organisma tunggal
- Ujian konfigurasi
- Versi
- Pemantauan dan penyembuhan diri perkhidmatan
- Dana
- Sistem inventori
- Sistem pengurusan ruang IP
- Sistem penerangan perkhidmatan rangkaian
- Mekanisme permulaan peranti
- Model konfigurasi vendor-agnostik
- Antara muka pemacu khusus vendor
- Mekanisme untuk menghantar konfigurasi ke peranti
- CI / CD
- Mekanisme untuk sandaran dan mencari penyelewengan
- Sistem pemantauan
- Kesimpulan
Saya akan cuba menjalankan ADSM dalam format yang berbeza sedikit daripada SDSM. Artikel yang besar, terperinci, bernombor akan terus muncul, dan di antara mereka saya akan menerbitkan nota kecil dari pengalaman seharian. Saya akan cuba melawan perfeksionisme di sini dan tidak menjilat setiap satu daripada mereka.
Alangkah lucunya apabila kali kedua anda perlu melalui jalan yang sama.
Pada mulanya saya terpaksa menulis sendiri artikel tentang rangkaian kerana fakta bahawa mereka tidak berada di RuNet.
Sekarang saya tidak dapat mencari dokumen komprehensif yang akan mensistematisasikan pendekatan untuk automasi dan menganalisis teknologi di atas menggunakan contoh praktikal yang mudah.
Saya mungkin salah, jadi sila berikan pautan ke sumber yang berguna. Walau bagaimanapun, ini tidak akan mengubah keazaman saya untuk menulis, kerana matlamat utama adalah untuk mempelajari sesuatu sendiri, dan menjadikan hidup lebih mudah untuk orang lain adalah bonus yang menyenangkan yang membelai gen untuk berkongsi pengalaman.
Kami akan cuba mengambil pusat data LAN DC bersaiz sederhana dan menyelesaikan keseluruhan skema automasi.
Saya akan melakukan beberapa perkara hampir buat kali pertama dengan anda.
Saya tidak akan menjadi asli dalam idea dan alatan yang diterangkan di sini. Dmitry Figol mempunyai yang sangat baik .
Artikel akan bertindih dengan mereka dalam banyak aspek.
LAN DC mempunyai 4 DC, kira-kira 250 suis, setengah dozen penghala dan beberapa tembok api.
Bukan Facebook, tetapi cukup untuk membuat anda berfikir secara mendalam tentang automasi.
Walau bagaimanapun, terdapat pendapat bahawa jika anda mempunyai lebih daripada 1 peranti, automasi sudah diperlukan.
Malah, sukar untuk membayangkan bahawa sesiapa sahaja kini boleh hidup tanpa sekurang-kurangnya satu pek skrip lutut.
Walaupun saya mendengar bahawa terdapat pejabat di mana alamat IP disimpan dalam Excel, dan setiap daripada beribu-ribu peranti rangkaian dikonfigurasikan secara manual dan mempunyai konfigurasi uniknya sendiri. Ini, sudah tentu, boleh dianggap sebagai seni moden, tetapi perasaan jurutera pasti akan tersinggung.
Objektif
Sekarang kita akan menetapkan matlamat yang paling abstrak:
- Rangkaian adalah seperti organisma tunggal
- Ujian konfigurasi
- Versi keadaan rangkaian
- Pemantauan dan penyembuhan diri perkhidmatan
Kemudian dalam artikel ini kita akan melihat apa cara yang akan kita gunakan, dan seterusnya, kita akan melihat matlamat dan cara secara terperinci.
Rangkaian adalah seperti organisma tunggal
Frasa penentu siri ini, walaupun pada pandangan pertama ia mungkin tidak begitu penting: kami akan mengkonfigurasi rangkaian, bukan peranti individu.
Dalam beberapa tahun kebelakangan ini, kami telah melihat peralihan dalam penekanan ke arah menganggap rangkaian sebagai satu entiti, justeru Perisian yang Ditetapkan Peranti, Rangkaian Didorong Niat ΠΈ Rangkaian Autonomi.
Lagipun, apakah yang diperlukan oleh aplikasi secara global daripada rangkaian: ketersambungan antara titik A dan B (baik, kadangkala +B-Z) dan pengasingan daripada aplikasi dan pengguna lain.
Dan tugas kami dalam siri ini adalah membina sistem, mengekalkan konfigurasi semasa keseluruhan rangkaian, yang telah diuraikan ke dalam konfigurasi sebenar pada setiap peranti mengikut peranan dan lokasinya.
Sistem pengurusan rangkaian membayangkan bahawa untuk membuat perubahan, kami menghubunginya, dan ia, seterusnya, mengira keadaan yang dikehendaki untuk setiap peranti dan mengkonfigurasinya.
Dengan cara ini, kami meminimumkan capaian manual kepada CLI kepada hampir sifar - sebarang perubahan dalam tetapan peranti atau reka bentuk rangkaian mesti diformalkan dan didokumenkan - dan hanya kemudian dilancarkan kepada elemen rangkaian yang diperlukan.
Iaitu, sebagai contoh, jika kami memutuskan bahawa mulai sekarang suis rak di Kazan harus mengumumkan dua rangkaian dan bukannya satu, kami
- Mula-mula kita mendokumentasikan perubahan dalam sistem
- Menjana konfigurasi sasaran semua peranti rangkaian
- Kami melancarkan program kemas kini konfigurasi rangkaian, yang mengira perkara yang perlu dialih keluar pada setiap nod, perkara yang perlu ditambah dan membawa nod ke keadaan yang diingini.
Pada masa yang sama, kami membuat perubahan secara manual hanya pada langkah pertama.
Ujian konfigurasi
bahawa 80% masalah berlaku semasa perubahan konfigurasi - bukti tidak langsung ini ialah semasa cuti Tahun Baru semuanya biasanya tenang.
Saya sendiri telah menyaksikan berpuluh-puluh masa henti global akibat kesilapan manusia: arahan yang salah, konfigurasi telah dilaksanakan di cawangan yang salah, komuniti terlupa, MPLS telah dirobohkan secara global pada penghala, lima keping perkakasan telah dikonfigurasikan, tetapi ralat itu tidak perasan pada keenam, perubahan lama yang dibuat oleh orang lain telah dilakukan. Terdapat satu tan senario.
Automasi akan membolehkan kita membuat lebih sedikit kesilapan, tetapi pada skala yang lebih besar. Dengan cara ini anda boleh membuat bata bukan hanya satu peranti, tetapi keseluruhan rangkaian sekaligus.
Sejak dahulu lagi, datuk kita menyemak ketepatan perubahan yang dibuat dengan teliti, bola keluli dan kefungsian rangkaian selepas ia dilancarkan.
Datuk mereka yang kerjanya membawa kepada masa henti dan kerugian besar meninggalkan lebih sedikit keturunan dan akan mati dari semasa ke semasa, tetapi evolusi adalah proses yang perlahan, dan oleh itu tidak semua orang masih menguji perubahan di makmal terlebih dahulu.
Walau bagaimanapun, di barisan hadapan kemajuan adalah mereka yang telah mengautomasikan proses menguji konfigurasi dan aplikasi selanjutnya ke rangkaian. Dengan kata lain, saya meminjam prosedur CI/CD () daripada pemaju.
Dalam salah satu bahagian kita akan melihat bagaimana untuk melaksanakan ini menggunakan sistem kawalan versi, mungkin Github.
Sebaik sahaja anda membiasakan diri dengan idea rangkaian CI/CD, semalaman kaedah menyemak konfigurasi dengan menerapkannya pada rangkaian pengeluaran akan kelihatan seperti kejahilan awal zaman pertengahan. Macam pukul kepala peledak dengan tukul.
Kesinambungan organik idea tentang sistem pengurusan rangkaian dan CI/CD menjadi versi penuh konfigurasi.
Versi
Kami akan menganggap bahawa dengan sebarang perubahan, walaupun yang paling kecil, walaupun pada satu peranti yang tidak dapat dilihat, keseluruhan rangkaian bergerak dari satu keadaan ke keadaan yang lain.
Dan kami sentiasa tidak melaksanakan arahan pada peranti, kami menukar keadaan rangkaian.
Jadi mari kita panggil versi negeri ini?
Katakan versi semasa ialah 1.0.0.
Adakah alamat IP antara muka Loopback pada salah satu ToR telah berubah? Ini adalah versi kecil dan akan diberi nombor 1.0.1.
Kami menyemak semula dasar untuk mengimport laluan ke BGP - sedikit lebih serius - sudah 1.1.0
Kami memutuskan untuk menyingkirkan IGP dan beralih kepada BGP sahaja - ini sudah menjadi perubahan reka bentuk radikal - 2.0.0.
Pada masa yang sama, DC yang berbeza mungkin mempunyai versi yang berbeza - rangkaian sedang berkembang, peralatan baru sedang dipasang, tahap duri baru sedang ditambah di suatu tempat, bukan di tempat lain, dsb.
pada kita akan bercakap dalam artikel berasingan.
Saya ulangi - sebarang perubahan (kecuali untuk arahan penyahpepijatan) ialah kemas kini versi. Pentadbir mesti dimaklumkan tentang sebarang penyelewengan daripada versi semasa.
Perkara yang sama berlaku untuk mengubah semula perubahan - ini bukan membatalkan arahan terakhir, ini bukan rollback menggunakan sistem pengendalian peranti - ini membawa keseluruhan rangkaian kepada versi baharu (lama).
Pemantauan dan penyembuhan diri perkhidmatan
Tugas yang jelas ini telah mencapai tahap baharu dalam rangkaian moden.
Selalunya, penyedia perkhidmatan besar mengambil pendekatan bahawa perkhidmatan yang gagal perlu diperbaiki dengan cepat dan perkhidmatan baharu dibangkitkan, bukannya memikirkan apa yang berlaku.
"Sangat" bermakna bahawa anda perlu disaluti dengan baik pada semua pihak dengan pemantauan, yang dalam beberapa saat akan mengesan sedikit penyelewengan daripada norma.
Dan di sini metrik biasa, seperti pemuatan antara muka atau ketersediaan nod, tidak lagi mencukupi. Pemantauan manual terhadap mereka oleh pegawai bertugas juga tidak mencukupi.
Untuk banyak perkara mesti ada β lampu pemantauan bertukar merah dan kami pergi dan menggunakan pisang raja sendiri di tempat ia menyakitkan.
Dan di sini kami juga memantau bukan sahaja peranti individu, tetapi juga kesihatan keseluruhan rangkaian, kedua-dua kotak putih, yang agak mudah difahami, dan kotak hitam, yang lebih rumit.
Apa yang kita perlukan untuk melaksanakan rancangan bercita-cita tinggi itu?
- Mempunyai senarai semua peranti pada rangkaian, lokasi, peranan, model, versi perisiannya.
kazan-leaf-1.lmu.net, Kazan, daun, Juniper QFX 5120, R18.3. - Mempunyai sistem untuk menerangkan perkhidmatan rangkaian.
IGP, BGP, L2/3VPN, Polisi, ACL, NTP, SSH. - Dapat memulakan peranti.
Nama hos, IP Mgmt, Laluan Mgmt, Pengguna, RSA-Keys, LLDP, NETCONF - Konfigurasikan peranti dan bawa konfigurasi ke versi yang dikehendaki (termasuk lama).
- Konfigurasi ujian
- Semak status semua peranti secara berkala untuk penyimpangan daripada yang semasa dan laporkan kepada siapa ia sepatutnya.
Semalaman, seseorang menambahkan peraturan pada ACL secara senyap-senyap. - Pantau prestasi.
Dana
Kedengarannya cukup rumit untuk mula menguraikan projek kepada komponen.
Dan akan ada sepuluh daripada mereka:
- Sistem inventori
- Sistem pengurusan ruang IP
- Sistem penerangan perkhidmatan rangkaian
- Mekanisme permulaan peranti
- Model konfigurasi vendor-agnostik
- Antara muka pemacu khusus vendor
- Mekanisme untuk menghantar konfigurasi ke peranti
- CI / CD
- Mekanisme untuk sandaran dan mencari penyelewengan
- Sistem pemantauan
Ini, dengan cara ini, adalah contoh bagaimana pandangan tentang matlamat kitaran berubah - terdapat 4 komponen dalam draf.
Dalam ilustrasi saya menggambarkan semua komponen dan peranti itu sendiri.
Komponen yang bersilang berinteraksi antara satu sama lain.
Lebih besar blok, lebih banyak perhatian perlu diberikan kepada komponen ini.
Komponen 1: Sistem inventori
Jelas sekali, kami ingin tahu peralatan apa yang terletak di mana, apa yang disambungkan.
Sistem inventori adalah bahagian penting dalam mana-mana perusahaan.
Selalunya, perusahaan mempunyai sistem inventori berasingan untuk peranti rangkaian, yang menyelesaikan masalah yang lebih khusus.
Sebagai sebahagian daripada siri artikel ini, kami akan memanggilnya DCIM - Pengurusan Infrastruktur Pusat Data. Walaupun istilah DCIM itu sendiri, secara tegasnya, merangkumi lebih banyak lagi.
Untuk tujuan kami, kami akan menyimpan maklumat berikut tentang peranti di dalamnya:
- Nombor inventori
- Tajuk/Penerangan
- model (Huawei CE12800, Juniper QFX5120, dsb.)
- Parameter ciri (papan, antara muka, dsb.)
- Peranan (Daun, Tulang Belakang, Penghala Sempadan, dsb.)
- lokasi (wilayah, bandar, pusat data, rak, unit)
- Saling sambungan antara peranti
- Topologi rangkaian
Jelas sekali bahawa kita sendiri ingin mengetahui semua ini.
Tetapi adakah ini membantu untuk tujuan automasi?
Sudah tentu.
Sebagai contoh, kita tahu bahawa dalam pusat data tertentu pada suis Daun, jika ia adalah Huawei, ACL untuk menapis trafik tertentu harus digunakan pada VLAN, dan jika ia adalah Juniper, maka pada unit 0 antara muka fizikal.
Atau anda perlu melancarkan pelayan Syslog baharu ke semua sempadan di rantau ini.
Di dalamnya kita akan menyimpan peranti rangkaian maya, contohnya penghala maya atau pemantul akar. Kami boleh menambah pelayan DNS, NTP, Syslog dan secara umum segala-galanya yang dalam satu cara atau yang lain berkaitan dengan rangkaian.
Komponen 2: Sistem pengurusan ruang IP
Ya, dan pada masa kini terdapat sekumpulan orang yang menjejaki awalan dan alamat IP dalam fail Excel. Tetapi pendekatan moden masih merupakan pangkalan data, dengan bahagian hadapan pada nginx/apache, API dan fungsi yang luas untuk merekod alamat IP dan rangkaian dibahagikan kepada VRF.
IPAM - Pengurusan Alamat IP.
Untuk tujuan kami, kami akan menyimpan maklumat berikut di dalamnya:
- VLAN
- VRF
- Rangkaian/Subnet
- alamat IP
- Mengikat alamat ke peranti, rangkaian ke lokasi dan nombor VLAN
Sekali lagi, adalah jelas bahawa kami ingin memastikan bahawa apabila kami memperuntukkan alamat IP baharu untuk gelung balik ToR, kami tidak akan tersandung pada fakta bahawa ia telah diberikan kepada seseorang. Atau kita menggunakan awalan yang sama dua kali pada hujung rangkaian yang berbeza.
Tetapi bagaimana ini membantu dengan automasi?
Mudah
Kami meminta awalan dalam sistem dengan peranan Loopbacks, yang mengandungi alamat IP yang tersedia untuk peruntukan - jika ia dijumpai, kami memperuntukkan alamat, jika tidak, kami meminta penciptaan awalan baharu.
Atau apabila mencipta konfigurasi peranti, kita boleh mengetahui daripada sistem yang sama di mana antara muka VRF harus ditempatkan.
Dan apabila memulakan pelayan baharu, skrip log masuk ke dalam sistem, mengetahui suis mana pelayan berada, port mana dan subnet mana yang diberikan kepada antara muka - dan akan memperuntukkan alamat pelayan daripadanya.
Ini menunjukkan keinginan untuk menggabungkan DCIM dan IPAM ke dalam satu sistem supaya tidak menduplikasi fungsi dan tidak melayani dua entiti yang serupa.
Itulah yang akan kita lakukan.
Komponen 3. Sistem untuk menerangkan perkhidmatan rangkaian
Jika dua sistem pertama menyimpan pembolehubah yang masih perlu digunakan entah bagaimana, maka yang ketiga menerangkan untuk setiap peranan peranti cara ia harus dikonfigurasikan.
Perlu dibezakan dua jenis perkhidmatan rangkaian yang berbeza:
- Infrastruktur
- Pelanggan.
Yang pertama direka untuk menyediakan sambungan asas dan kawalan peranti. Ini termasuk VTY, SNMP, NTP, Syslog, AAA, protokol penghalaan, CoPP, dsb.
Yang terakhir mengatur perkhidmatan untuk pelanggan: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, dsb.
Sudah tentu, terdapat juga kes sempadan - di mana untuk memasukkan MPLS LDP, BGP? Ya, dan protokol penghalaan boleh digunakan untuk pelanggan. Tetapi ini tidak penting.
Kedua-dua jenis perkhidmatan diuraikan menjadi primitif konfigurasi:
- antara muka fizikal dan logik (tag/anteg, mtu)
- Alamat IP dan VRF (IP, IPv6, VRF)
- ACL dan dasar pemprosesan lalu lintas
- Protokol (IGP, BGP, MPLS)
- Dasar penghalaan (senarai awalan, komuniti, penapis ASN).
- Perkhidmatan utiliti (SSH, NTP, LLDP, Syslog...)
- Dan lain-lain.
Bagaimana sebenarnya kita akan melakukan ini, saya tidak tahu lagi. Kami akan melihatnya dalam artikel berasingan.
Jika sedikit lebih dekat dengan kehidupan, maka kita boleh menggambarkannya
Suis Daun mesti mempunyai sesi BGP dengan semua suis Spine yang disambungkan, mengimport rangkaian yang disambungkan ke dalam proses dan menerima hanya rangkaian daripada awalan tertentu daripada suis Spine. Hadkan CoPP IPv6 ND kepada 10 pps, dsb.
Sebaliknya, tulang belakang mengadakan sesi dengan semua petunjuk yang disambungkan, bertindak sebagai pemantul akar, dan menerima daripada mereka hanya laluan dengan panjang tertentu dan dengan komuniti tertentu.
Komponen 4: Mekanisme Permulaan Peranti
Di bawah tajuk ini saya menggabungkan banyak tindakan yang mesti berlaku agar peranti muncul pada radar dan boleh diakses dari jauh.
- Masukkan peranti dalam sistem inventori.
- Pilih alamat IP pengurusan.
- Sediakan akses asas kepadanya:
Nama hos, alamat IP pengurusan, laluan ke rangkaian pengurusan, pengguna, kunci SSH, protokol - telnet/SSH/NETCONF
Terdapat tiga pendekatan:
- Semuanya manual sepenuhnya. Peranti dibawa ke tempat duduk, di mana orang organik biasa akan memasukkannya ke dalam sistem, menyambung ke konsol dan mengkonfigurasinya. Boleh berfungsi pada rangkaian statik kecil.
- ZTP - Peruntukan Sentuhan Sifar. Perkakasan tiba, berdiri, menerima alamat melalui DHCP, pergi ke pelayan khas, dan mengkonfigurasi dirinya sendiri.
- Infrastruktur pelayan konsol, di mana konfigurasi awal berlaku melalui port konsol dalam mod automatik.
Kami akan bercakap tentang ketiga-tiga dalam artikel berasingan.
Komponen 5: Model konfigurasi vendor-agnostik
Sehingga kini, semua sistem adalah tampung berbeza yang menyediakan pembolehubah dan penerangan deklaratif tentang perkara yang ingin kami lihat pada rangkaian. Tetapi lambat laun, anda perlu berurusan dengan perkara khusus.
Pada peringkat ini, untuk setiap peranti tertentu, primitif, perkhidmatan dan pembolehubah digabungkan menjadi model konfigurasi yang sebenarnya menerangkan konfigurasi lengkap peranti tertentu, hanya dalam cara neutral vendor.
Apakah yang dilakukan oleh langkah ini? Mengapa tidak segera membuat konfigurasi peranti yang boleh anda muat naik?
Malah, ini menyelesaikan tiga masalah:
- Jangan sesuaikan dengan antara muka khusus untuk berinteraksi dengan peranti. Sama ada CLI, NETCONF, RESTCONF, SNMP - modelnya akan sama.
- Jangan simpan bilangan templat/skrip mengikut bilangan vendor pada rangkaian, dan jika reka bentuk berubah, tukar perkara yang sama di beberapa tempat.
- Muatkan konfigurasi daripada peranti (sandaran), masukkannya ke dalam model yang sama dan bandingkan terus konfigurasi sasaran dengan yang sedia ada untuk mengira delta dan sediakan tampung konfigurasi yang akan menukar bahagian yang perlu sahaja atau untuk mengenal pasti penyelewengan.
Hasil daripada peringkat ini, kami memperoleh konfigurasi bebas vendor.
Komponen 6. Antara muka pemacu khusus vendor
Anda tidak sepatutnya menyanjung diri anda dengan harapan bahawa suatu hari nanti anda boleh mengkonfigurasi ciska dengan cara yang sama seperti Juniper, hanya dengan menghantar panggilan yang sama kepada mereka. Walaupun semakin populariti kotak putih dan kemunculan sokongan untuk NETCONF, RESTCONF, OpenConfig, kandungan khusus yang dihantar oleh protokol ini berbeza dari vendor ke vendor, dan ini adalah salah satu perbezaan daya saing yang mereka tidak akan berputus asa dengan begitu mudah.
Ini kira-kira sama dengan OpenContrail dan OpenStack, yang mempunyai RestAPI sebagai antara muka NorthBound mereka, mengharapkan panggilan yang sama sekali berbeza.
Jadi, dalam langkah kelima, model bebas vendor mesti mengambil bentuk di mana ia akan pergi ke perkakasan.
Dan di sini semua cara adalah baik (bukan): CLI, NETCONF, RESTCONF, SNMP semata-mata.
Oleh itu, kami memerlukan pemacu yang akan memindahkan hasil langkah sebelumnya ke dalam format yang diperlukan vendor tertentu: satu set arahan CLI, struktur XML.
Komponen 7. Mekanisme untuk menghantar konfigurasi kepada peranti
Kami telah menghasilkan konfigurasi, tetapi ia masih perlu dihantar ke peranti - dan, jelas sekali, bukan dengan tangan.
Pertama, kita berhadapan dengan persoalan pengangkutan apa yang akan kita gunakan? Dan hari ini pilihannya tidak lagi kecil:
- CLI (telnet, ssh)
- SNMP
- NETCONF
- RESTCONF
- REST API
- OpenFlow (walaupun ia adalah outlier kerana ia adalah cara untuk menyampaikan FIB, bukan tetapan)
Mari kita dot the t di sini. CLI adalah warisan. SNMP... batuk batuk.
RESTCONF masih haiwan yang tidak diketahui; API REST disokong oleh hampir tiada sesiapa pun. Oleh itu, kami akan memberi tumpuan kepada NETCONF dalam siri ini.
Malah, seperti yang telah difahami oleh pembaca, pada ketika ini kami telah memutuskan antara muka - hasil langkah sebelumnya telah dibentangkan dalam format antara muka yang dipilih.
Kedua, dan alat apakah yang akan kami lakukan ini?
Terdapat juga pilihan yang besar di sini:
- Skrip atau platform yang ditulis sendiri. Mari kita memperlengkapi diri dengan ncclient dan asyncIO dan melakukan segala-galanya sendiri. Apakah kos kami untuk membina sistem penempatan dari awal?
- Boleh dengan perpustakaan modul rangkaian yang kaya.
- Garam dengan kerja yang tidak seberapa dengan rangkaian dan sambungan dengan Napalm.
- Sebenarnya Napalm, yang mengenali beberapa vendor dan itu sahaja, selamat tinggal.
- Nornir adalah satu lagi haiwan yang akan kita rungkai pada masa hadapan.
Di sini kegemaran belum lagi dipilih - kami akan mencari.
Apa lagi yang penting di sini? Akibat menggunakan konfigurasi.
Berjaya atau tidak. Adakah masih terdapat akses kepada perkakasan atau tidak?
Nampaknya komit akan membantu di sini dengan pengesahan dan pengesahan perkara yang dimuat turun ke peranti.
Ini, digabungkan dengan pelaksanaan NETCONF yang betul, mengecilkan julat peranti yang sesuai dengan ketara - tidak banyak pengeluar menyokong komitmen biasa. Tetapi ini hanyalah salah satu prasyarat dalam . Pada akhirnya, tiada siapa yang bimbang bahawa tidak ada vendor Rusia yang akan mematuhi syarat antara muka 32*100GE. Atau dia risau?
Komponen 8. CI/CD
Pada ketika ini, kami sudah mempunyai konfigurasi sedia untuk semua peranti rangkaian.
Saya menulis "untuk segala-galanya" kerana kita bercakap tentang versi keadaan rangkaian. Dan walaupun anda perlu menukar tetapan hanya satu suis, perubahan dikira untuk keseluruhan rangkaian. Jelas sekali, mereka boleh menjadi sifar untuk kebanyakan nod.
Tetapi, seperti yang telah dinyatakan di atas, kami bukanlah sejenis orang gasar yang mahu melancarkan segala-galanya terus ke dalam pengeluaran.
Konfigurasi yang dijana mesti terlebih dahulu melalui Pipeline CI/CD.
CI/CD bermaksud Integrasi Berterusan, Penerapan Berterusan. Ini ialah pendekatan di mana pasukan bukan sahaja mengeluarkan keluaran utama baharu setiap enam bulan, menggantikan sepenuhnya yang lama, tetapi secara berperingkat-peringkat memperkenalkan (Pengerahan) fungsi baharu dalam bahagian kecil, setiap satunya diuji secara menyeluruh untuk keserasian, keselamatan dan prestasi (Integrasi).
Untuk melakukan ini, kami mempunyai sistem kawalan versi yang memantau perubahan konfigurasi, makmal yang menyemak sama ada perkhidmatan pelanggan rosak, sistem pemantauan yang menyemak fakta ini dan langkah terakhir ialah melancarkan perubahan pada rangkaian pengeluaran.
Dengan pengecualian arahan penyahpepijatan, semua perubahan pada rangkaian mesti melalui Talian Paip CI/CD - ini adalah jaminan kami untuk kehidupan yang tenang dan kerjaya yang panjang dan bahagia.
Komponen 9. Sistem sandaran dan pengesanan anomali
Nah, tidak perlu bercakap tentang sandaran lagi.
Kami hanya akan meletakkannya dalam git mengikut mahkota atau berdasarkan fakta perubahan konfigurasi.
Tetapi bahagian kedua lebih menarik - seseorang harus memerhatikan sandaran ini. Dan dalam beberapa kes, seseorang ini mesti pergi dan membalikkan segala-galanya seperti sedia ada, dan dalam keadaan lain, mengeong kepada seseorang bahawa ada sesuatu yang tidak kena.
Sebagai contoh, jika pengguna baharu telah muncul yang tidak didaftarkan dalam pembolehubah, anda perlu mengalih keluarnya daripada penggodaman. Dan jika adalah lebih baik untuk tidak menyentuh peraturan tembok api baharu, mungkin seseorang baru sahaja menghidupkan penyahpepijatan, atau mungkin perkhidmatan baharu, seorang yang bodoh, tidak didaftarkan mengikut peraturan, tetapi orang telah menyertainya.
Kami masih tidak akan terlepas daripada beberapa delta kecil pada skala keseluruhan rangkaian, walaupun terdapat sistem automasi dan pengurusan yang kukuh. Untuk menyahpepijat masalah, tiada siapa yang akan menambah konfigurasi pada sistem. Lebih-lebih lagi, mereka mungkin tidak disertakan dalam model konfigurasi.
Sebagai contoh, peraturan firewall untuk mengira bilangan paket bagi setiap IP khusus untuk menyetempatkan masalah ialah konfigurasi sementara yang sama sekali biasa.
Komponen 10. Sistem pemantauan
Pada mulanya saya tidak akan membincangkan topik pemantauan - ia masih merupakan topik yang banyak, kontroversi dan kompleks. Tetapi apabila keadaan berkembang, ternyata ini adalah sebahagian daripada automasi. Dan mustahil untuk memintasnya, walaupun tanpa latihan.
Pemikiran Berkembang ialah bahagian organik proses CI/CD. Selepas melancarkan konfigurasi ke rangkaian, kita perlu dapat menentukan sama ada semuanya baik-baik saja dengannya sekarang.
Dan kita bercakap bukan sahaja dan bukan sahaja mengenai jadual penggunaan antara muka atau ketersediaan nod, tetapi tentang perkara yang lebih halus - kehadiran laluan yang diperlukan, atribut pada mereka, bilangan sesi BGP, jiran OSPF, prestasi End-to-End perkhidmatan overlying.
Adakah syslog ke pelayan luaran berhenti menambah, atau adakah ejen SFlow rosak, atau adakah kejatuhan dalam baris gilir mula berkembang, atau adakah ketersambungan antara beberapa pasangan awalan rosak?
Kami akan memikirkan perkara ini dalam artikel berasingan.
Kesimpulan
Sebagai asas, saya memilih salah satu reka bentuk rangkaian pusat data moden - L3 Clos Fabric dengan BGP sebagai protokol penghalaan.
Kali ini kami akan membina rangkaian pada Juniper, kerana kini antara muka JunOs adalah vanlove.
Mari jadikan hidup kita lebih sukar dengan hanya menggunakan alat Sumber Terbuka dan rangkaian berbilang vendor - jadi selain Juniper, saya akan memilih seorang lagi yang bertuah di sepanjang jalan.
Pelan untuk penerbitan akan datang adalah seperti ini:
Mula-mula saya akan bercakap tentang rangkaian maya. Pertama sekali, kerana saya mahu, dan kedua, kerana tanpa ini, reka bentuk rangkaian infrastruktur tidak akan begitu jelas.
Kemudian mengenai reka bentuk rangkaian itu sendiri: topologi, penghalaan, dasar.
Mari kita pasang pendirian makmal.
Mari kita fikirkan dan mungkin berlatih memulakan peranti pada rangkaian.
Dan kemudian mengenai setiap komponen secara terperinci.
Dan ya, saya tidak berjanji untuk menamatkan kitaran ini dengan penyelesaian yang sedia dibuat. π
Pautan berguna
- Sebelum mendalami siri ini, ia patut membaca buku Natasha Samoilenko . Dan mungkin lulus .
- Ia juga akan berguna untuk dibaca mengenai reka bentuk kilang pusat data dari Facebook oleh Peter Lapukhov.
- Dokumentasi seni bina akan memberi anda gambaran tentang cara Overlay SDN berfungsi. (dahulunya Open Contrail).
Terima kasih
Gaung Rom. Untuk komen dan suntingan.
Artyom Chernobay. Untuk KDPV.
Sumber: www.habr.com