SDSM sudah usai, namun keinginan menulis yang tak terkendali masih ada.
Selama bertahun-tahun, saudara kita menderita karena melakukan pekerjaan rutin, menyilangkan jari sebelum melakukan pekerjaan, dan kurang tidur karena harus bekerja di malam hari.
Namun masa-masa kelam akan segera berakhir.
Dengan artikel ini saya akan memulai seri tentang caranya ΠΌΠ½Π΅ otomatisasi terlihat.
Sepanjang jalan kita akan memahami tahapan otomatisasi, penyimpanan variabel, formalisasi desain, RestAPI, NETCONF, YANG, YDK dan kita akan melakukan banyak pemrograman.
Saya Artinya a) ini bukan kebenaran obyektif, b) ini bukan pendekatan terbaik tanpa syarat, c) pendapat saya, bahkan selama perpindahan dari artikel pertama ke artikel terakhir, dapat berubah - sejujurnya, dari tahap draf ke publikasi, saya menulis ulang semuanya sepenuhnya dua kali.
kadar
- Tujuan
- Jaringan itu seperti organisme tunggal
- Pengujian konfigurasi
- Pembuatan versi
- Pemantauan dan penyembuhan diri layanan
- Berarti
- Sistem inventaris
- Sistem manajemen ruang IP
- Sistem deskripsi layanan jaringan
- Mekanisme inisialisasi perangkat
- Model konfigurasi vendor-agnostik
- Antarmuka driver khusus vendor
- Mekanisme untuk mengirimkan konfigurasi ke perangkat
- CI / CD
- Mekanisme pencadangan dan pencarian penyimpangan
- Sistem pemantauan
- Kesimpulan
Saya akan mencoba menjalankan ADSM dalam format yang sedikit berbeda dengan SDSM. Artikel-artikel besar, rinci, dan bernomor akan terus bermunculan, dan di antaranya saya akan menerbitkan catatan-catatan kecil dari pengalaman sehari-hari. Saya akan mencoba melawan perfeksionisme di sini dan tidak menjilat semuanya.
Lucunya untuk kedua kalinya harus melalui jalan yang sama.
Pada awalnya saya harus menulis artikel tentang jaringan sendiri karena faktanya mereka tidak ada di Runet.
Sekarang saya tidak dapat menemukan dokumen komprehensif yang akan mensistematisasikan pendekatan terhadap otomatisasi dan menganalisis teknologi di atas menggunakan contoh-contoh praktis yang sederhana.
Saya mungkin salah, jadi harap berikan tautan ke sumber daya yang bermanfaat. Namun hal ini tidak akan mengubah tekad saya untuk menulis, karena tujuan utamanya adalah mempelajari sesuatu sendiri, dan membuat hidup lebih mudah bagi orang lain adalah bonus menyenangkan yang membelai gen untuk berbagi pengalaman.
Kami akan mencoba mengambil pusat data LAN DC berukuran sedang dan mengerjakan seluruh skema otomasi.
Saya akan melakukan beberapa hal hampir untuk pertama kalinya bersama Anda.
Saya tidak akan orisinal dalam ide dan alat yang dijelaskan di sini. Dmitry Figol memiliki yang luar biasa .
Artikel-artikel tersebut akan tumpang tindih dengan mereka dalam banyak aspek.
LAN DC memiliki 4 DC, sekitar 250 switch, setengah lusin router dan beberapa firewall.
Bukan Facebook, tapi cukup untuk membuat Anda berpikir mendalam tentang otomatisasi.
Namun ada yang berpendapat jika memiliki lebih dari 1 perangkat, otomatisasi sudah diperlukan.
Faktanya, sulit untuk membayangkan bahwa siapa pun sekarang dapat hidup tanpa setidaknya satu set skrip lutut.
Meskipun saya mendengar bahwa ada kantor yang menyimpan alamat IP di Excel, dan masing-masing dari ribuan perangkat jaringan dikonfigurasi secara manual dan memiliki konfigurasi uniknya sendiri. Hal ini tentu saja bisa dianggap sebagai seni modern, namun perasaan sang insinyur pasti akan tersinggung.
Tujuan
Sekarang kita akan menetapkan tujuan yang paling abstrak:
- Jaringan itu seperti organisme tunggal
- Pengujian konfigurasi
- Pembuatan versi status jaringan
- Pemantauan dan penyembuhan diri layanan
Nanti di artikel ini kita akan melihat cara apa yang akan kita gunakan, dan selanjutnya kita akan melihat tujuan dan cara secara detail.
Jaringan itu seperti organisme tunggal
Ungkapan yang menentukan dari seri ini, meskipun pada pandangan pertama mungkin tampak tidak begitu signifikan: kami akan mengonfigurasi jaringan, bukan perangkat individual.
Dalam beberapa tahun terakhir, kita telah melihat adanya pergeseran penekanan ke arah memperlakukan jaringan sebagai satu kesatuan, oleh karena itu Jaringan yang Ditetapkan Perangkat Lunak, Jaringan Berbasis Niat ΠΈ Jaringan Otonom.
Lagi pula, apa yang dibutuhkan aplikasi secara global dari jaringan: konektivitas antara titik A dan B (terkadang +B-Z) dan isolasi dari aplikasi dan pengguna lain.
Jadi tugas kita dalam seri ini adalah membangun sebuah sistem, mempertahankan konfigurasi saat ini seluruh jaringan, yang sudah didekomposisi menjadi konfigurasi sebenarnya pada setiap perangkat sesuai dengan peran dan lokasinya.
Sistem manajemen jaringan menyiratkan bahwa untuk membuat perubahan, kami menghubunginya, dan, pada gilirannya, menghitung status yang diinginkan untuk setiap perangkat dan mengkonfigurasinya.
Dengan cara ini, kami meminimalkan akses manual ke CLI hingga hampir nol - setiap perubahan dalam pengaturan perangkat atau desain jaringan harus diformalkan dan didokumentasikan - dan baru kemudian diterapkan ke elemen jaringan yang diperlukan.
Misalnya, jika kami memutuskan bahwa mulai sekarang sakelar rak di Kazan harus mengumumkan dua jaringan, bukan satu, kami
- Pertama kami mendokumentasikan perubahan dalam sistem
- Menghasilkan konfigurasi target semua perangkat jaringan
- Kami meluncurkan program pembaruan konfigurasi jaringan, yang menghitung apa yang perlu dihapus pada setiap node, apa yang harus ditambahkan, dan membawa node ke keadaan yang diinginkan.
Pada saat yang sama, kami melakukan perubahan secara manual hanya pada langkah pertama.
Pengujian konfigurasi
bahwa 80% masalah terjadi selama perubahan konfigurasi - bukti tidak langsung dari hal ini adalah bahwa selama liburan Tahun Baru semuanya biasanya tenang.
Saya pribadi telah menyaksikan lusinan downtime global karena kesalahan manusia: perintah yang salah, konfigurasi dijalankan di cabang yang salah, komunitas lupa, MPLS dihancurkan secara global di router, lima perangkat keras dikonfigurasi, tetapi kesalahannya tidak terjadi. diperhatikan pada tanggal enam, perubahan lama yang dilakukan oleh orang lain telah dilakukan. Ada banyak sekali skenario.
Otomatisasi akan memungkinkan kita membuat lebih sedikit kesalahan, namun dalam skala yang lebih besar. Dengan cara ini Anda tidak hanya dapat memblokir satu perangkat, tetapi seluruh jaringan sekaligus.
Sejak dahulu kala, kakek kami memeriksa kebenaran perubahan yang dilakukan dengan mata tajam, bola baja, dan fungsionalitas jaringan setelah diluncurkan.
Kakek-kakek yang pekerjaannya menyebabkan downtime dan kerugian yang sangat besar akan meninggalkan lebih sedikit keturunan dan akan punah seiring berjalannya waktu, namun evolusi adalah proses yang lambat, dan oleh karena itu tidak semua orang masih menguji perubahan di laboratorium terlebih dahulu.
Namun, kemajuan terdepan adalah mereka yang telah mengotomatiskan proses pengujian konfigurasi dan penerapannya lebih lanjut ke jaringan. Dengan kata lain, saya meminjam prosedur CI/CD () dari pengembang.
Di salah satu bagian kita akan melihat bagaimana mengimplementasikannya menggunakan sistem kontrol versi, mungkin Github.
Setelah Anda terbiasa dengan gagasan jaringan CI/CD, dalam semalam metode memeriksa konfigurasi dengan menerapkannya ke jaringan produksi akan tampak seperti ketidaktahuan awal abad pertengahan. Seperti memukul hulu ledak dengan palu.
Kelanjutan organik dari ide tentang sistem manajemen jaringan dan CI/CD menjadi konfigurasi versi lengkap.
Pembuatan versi
Kami akan berasumsi bahwa dengan perubahan apa pun, bahkan perubahan terkecil sekalipun, bahkan pada satu perangkat yang tidak terlalu mencolok, seluruh jaringan berpindah dari satu keadaan ke keadaan lainnya.
Dan kami tidak selalu menjalankan perintah pada perangkat, kami mengubah status jaringan.
Jadi sebut saja versi negara bagian ini?
Katakanlah versi saat ini adalah 1.0.0.
Apakah alamat IP antarmuka Loopback di salah satu ToR berubah? Ini adalah versi minor dan akan diberi nomor 1.0.1.
Kami merevisi kebijakan untuk mengimpor rute ke BGP - sedikit lebih serius - sudah menjadi 1.1.0
Kami memutuskan untuk membuang IGP dan beralih ke BGP saja - ini sudah merupakan perubahan desain yang radikal - 2.0.0.
Pada saat yang sama, DC yang berbeda mungkin memiliki versi yang berbeda - jaringan berkembang, peralatan baru sedang dipasang, level duri baru ditambahkan di suatu tempat, bukan di tempat lain, dll.
Tentang kita akan berbicara di artikel terpisah.
Saya ulangi - perubahan apa pun (kecuali untuk perintah debugging) adalah pembaruan versi. Administrator harus diberitahu jika ada penyimpangan dari versi saat ini.
Hal yang sama berlaku untuk mengembalikan perubahan - ini bukan membatalkan perintah terakhir, ini bukan mengembalikan menggunakan sistem operasi perangkat - ini membawa seluruh jaringan ke versi baru (lama).
Pemantauan dan penyembuhan diri layanan
Tugas yang jelas ini telah mencapai tingkatan baru dalam jaringan modern.
Seringkali, penyedia layanan besar mengambil pendekatan bahwa layanan yang gagal perlu diperbaiki dengan sangat cepat dan layanan baru harus dimunculkan, alih-alih mencari tahu apa yang terjadi.
βSangatβ berarti Anda harus diliputi pemantauan dari semua sisi, yang dalam hitungan detik akan mendeteksi penyimpangan sekecil apa pun dari norma.
Dan di sini metrik biasa, seperti pemuatan antarmuka atau ketersediaan node, tidak lagi cukup. Pemantauan manual terhadap mereka oleh petugas jaga juga tidak cukup.
Untuk banyak hal seharusnya ada β lampu pemantauan berubah menjadi merah dan kami pergi dan mengoleskan pisang raja itu sendiri di bagian yang sakit.
Dan di sini kami juga memantau tidak hanya perangkat individual, tetapi juga kesehatan seluruh jaringan, baik whitebox, yang relatif dapat dimengerti, dan blackbox, yang lebih rumit.
Apa yang kita perlukan untuk melaksanakan rencana ambisius tersebut?
- Miliki daftar semua perangkat di jaringan, lokasinya, peran, model, versi perangkat lunak.
kazan-leaf-1.lmu.net, Kazan, daun, Juniper QFX 5120, R18.3. - Memiliki sistem untuk menggambarkan layanan jaringan.
IGP, BGP, L2/3VPN, Kebijakan, ACL, NTP, SSH. - Mampu menginisialisasi perangkat.
Nama Host, IP Pengelolaan, Rute Pengelolaan, Pengguna, Kunci RSA, LLDP, NETCONF - Konfigurasikan perangkat dan bawa konfigurasi ke versi yang diinginkan (termasuk versi lama).
- Konfigurasi pengujian
- Periksa secara berkala status semua perangkat untuk mengetahui adanya penyimpangan dari perangkat saat ini dan laporkan kepada siapa perangkat tersebut seharusnya.
Semalam, seseorang diam-diam menambahkan aturan ke ACL. - Memantau kinerja.
Berarti
Kedengarannya cukup rumit untuk mulai menguraikan proyek menjadi beberapa komponen.
Dan akan ada sepuluh di antaranya:
- Sistem inventaris
- Sistem manajemen ruang IP
- Sistem deskripsi layanan jaringan
- Mekanisme inisialisasi perangkat
- Model konfigurasi vendor-agnostik
- Antarmuka driver khusus vendor
- Mekanisme untuk mengirimkan konfigurasi ke perangkat
- CI / CD
- Mekanisme pencadangan dan pencarian penyimpangan
- Sistem pemantauan
Omong-omong, ini adalah contoh bagaimana pandangan tentang tujuan siklus berubah - ada 4 komponen dalam drafnya.
Dalam ilustrasi tersebut saya menggambarkan semua komponen dan perangkat itu sendiri.
Komponen-komponen yang berpotongan saling berinteraksi satu sama lain.
Semakin besar bloknya, semakin banyak perhatian yang perlu diberikan pada komponen ini.
Komponen 1: Sistem Inventaris
Tentunya kita ingin mengetahui peralatan apa saja yang letaknya dimana, terhubung dengan apa.
Sistem inventaris merupakan bagian integral dari perusahaan mana pun.
Paling sering, suatu perusahaan memiliki sistem inventaris terpisah untuk perangkat jaringan, yang memecahkan masalah yang lebih spesifik.
Sebagai bagian dari rangkaian artikel ini, kami akan menyebutnya DCIM - Manajemen Infrastruktur Pusat Data. Meskipun istilah DCIM sendiri sebenarnya mencakup lebih banyak hal.
Untuk tujuan kami, kami akan menyimpan informasi berikut tentang perangkat di dalamnya:
- Nomor persediaan
- Deskripsi judul
- Model (Huawei CE12800, Juniper QFX5120, dll.)
- Parameter karakteristik (papan, antarmuka, dll.)
- Peran (Daun, Tulang Belakang, Router Perbatasan, dll.)
- Lokasi (wilayah, kota, pusat data, rak, unit)
- Interkoneksi antar perangkat
- Topologi jaringan
Sangat jelas bahwa kita sendiri ingin mengetahui semua ini.
Namun apakah ini akan membantu untuk tujuan otomatisasi?
Tentu saja
Misalnya, kita tahu bahwa di pusat data tertentu pada switch Leaf, jika itu adalah Huawei, ACL untuk memfilter lalu lintas tertentu harus diterapkan pada VLAN, dan jika itu adalah Juniper, maka pada unit 0 antarmuka fisik.
Atau Anda perlu meluncurkan server Syslog baru ke seluruh perbatasan di wilayah tersebut.
Di dalamnya kita akan menyimpan perangkat jaringan virtual, misalnya router virtual atau root reflektor. Kita dapat menambahkan server DNS, NTP, Syslog dan secara umum segala sesuatu yang berhubungan dengan jaringan.
Komponen 2: Sistem manajemen ruang IP
Ya, dan saat ini ada tim yang terdiri dari orang-orang yang melacak awalan dan alamat IP dalam file Excel. Namun pendekatan modern masih berupa database, dengan front-end pada nginx/Apache, API dan fungsi ekstensif untuk mencatat alamat IP dan jaringan yang dibagi menjadi VRF.
IPAM - Manajemen Alamat IP.
Untuk tujuan kami, kami akan menyimpan informasi berikut di dalamnya:
- VLAN
- VRF
- Jaringan/Subnet
- Alamat IP
- Mengikat alamat ke perangkat, jaringan ke lokasi dan nomor VLAN
Sekali lagi, jelas bahwa kami ingin memastikan bahwa ketika kami mengalokasikan alamat IP baru untuk loopback ToR, kami tidak akan tersandung pada fakta bahwa alamat tersebut sudah ditetapkan ke seseorang. Atau kami menggunakan awalan yang sama dua kali di ujung jaringan yang berbeda.
Namun bagaimana hal ini membantu otomatisasi?
Mudah
Kami meminta awalan dalam sistem dengan peran Loopbacks, yang berisi alamat IP yang tersedia untuk alokasi - jika ditemukan, kami mengalokasikan alamat tersebut, jika tidak, kami meminta pembuatan awalan baru.
Atau saat membuat konfigurasi perangkat, kita dapat mengetahui dari sistem yang sama di mana antarmuka VRF harus ditempatkan.
Dan ketika memulai server baru, skrip masuk ke sistem, mencari tahu di switch mana server berada, port mana dan subnet mana yang ditetapkan ke antarmuka - dan akan mengalokasikan alamat server darinya.
Hal ini menunjukkan keinginan untuk menggabungkan DCIM dan IPAM ke dalam satu sistem agar tidak menduplikasi fungsi dan tidak melayani dua entitas serupa.
Itulah yang akan kami lakukan.
Komponen 3. Sistem untuk mendeskripsikan layanan jaringan
Jika dua sistem pertama menyimpan variabel yang masih perlu digunakan, maka sistem ketiga menjelaskan untuk setiap peran perangkat cara mengonfigurasinya.
Perlu dibedakan dua jenis layanan jaringan yang berbeda:
- Infrastruktur
- Klien.
Yang pertama dirancang untuk menyediakan konektivitas dasar dan kontrol perangkat. Ini termasuk VTY, SNMP, NTP, Syslog, AAA, protokol routing, CoPP, dll.
Yang terakhir mengatur layanan untuk klien: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, dll.
Tentu saja, ada juga kasus yang berada di ambang batas - di mana memasukkan MPLS LDP, BGP? Ya, dan protokol perutean dapat digunakan untuk klien. Tapi ini tidak penting.
Kedua jenis layanan didekomposisi menjadi konfigurasi primitif:
- antarmuka fisik dan logis (tag/anteg, mtu)
- Alamat IP dan VRF (IP, IPv6, VRF)
- ACL dan kebijakan pemrosesan lalu lintas
- Protokol (IGP, BGP, MPLS)
- Kebijakan perutean (daftar awalan, komunitas, filter ASN).
- Layanan utilitas (SSH, NTP, LLDP, Syslog...)
- Dll.
Bagaimana tepatnya kami akan melakukan ini, saya belum tahu. Kami akan membahasnya di artikel terpisah.
Jika sedikit lebih dekat dengan kehidupan, maka kita bisa menggambarkannya
Switch Leaf harus memiliki sesi BGP dengan semua switch Spine yang terhubung, mengimpor jaringan yang terhubung ke dalam proses, dan hanya menerima jaringan dari awalan tertentu dari switch Spine. Batasi CoPP IPv6 ND hingga 10 pps, dll.
Pada gilirannya, spine mengadakan sesi dengan semua lead yang terhubung, bertindak sebagai reflektor akar, dan hanya menerima rute dengan panjang tertentu dan dengan komunitas tertentu.
Komponen 4: Mekanisme Inisialisasi Perangkat
Di bawah judul ini saya menggabungkan banyak tindakan yang harus dilakukan agar perangkat muncul di radar dan diakses dari jarak jauh.
- Masukkan perangkat ke dalam sistem inventaris.
- Pilih alamat IP manajemen.
- Siapkan akses dasar ke sana:
Nama host, alamat IP manajemen, rute ke jaringan manajemen, pengguna, kunci SSH, protokol - telnet/SSH/NETCONF
Ada tiga pendekatan:
- Semuanya serba manual. Perangkat dibawa ke stand, di mana orang organik biasa akan memasukkannya ke dalam sistem, menghubungkannya ke konsol dan mengkonfigurasinya. Dapat bekerja pada jaringan statis kecil.
- ZTP - Penyediaan Zero Touch. Perangkat keras tiba, berdiri, menerima alamat melalui DHCP, pergi ke server khusus, dan mengkonfigurasi sendiri.
- Infrastruktur server konsol, tempat konfigurasi awal dilakukan melalui port konsol dalam mode otomatis.
Kami akan membicarakan ketiganya dalam artikel terpisah.
Komponen 5: Model konfigurasi vendor-agnostik
Hingga saat ini, semua sistem merupakan patch berbeda yang menyediakan variabel dan deskripsi deklaratif tentang apa yang ingin kita lihat di jaringan. Namun cepat atau lambat, Anda harus menghadapi hal-hal spesifik.
Pada tahap ini, untuk setiap perangkat tertentu, primitif, layanan, dan variabel digabungkan menjadi model konfigurasi yang benar-benar menggambarkan konfigurasi lengkap perangkat tertentu, hanya dengan cara netral vendor.
Apa gunanya langkah ini? Mengapa tidak segera membuat konfigurasi perangkat yang bisa Anda unggah saja?
Faktanya, ini memecahkan tiga masalah:
- Jangan beradaptasi dengan antarmuka tertentu untuk berinteraksi dengan perangkat. Baik CLI, NETCONF, RESTCONF, SNMP - modelnya akan sama.
- Jangan menyimpan jumlah template/script sesuai dengan jumlah vendor di jaringan, dan jika desain berubah, ubahlah hal yang sama di beberapa tempat.
- Muat konfigurasi dari perangkat (cadangan), masukkan ke dalam model yang sama persis dan bandingkan langsung konfigurasi target dengan yang sudah ada untuk menghitung delta dan siapkan patch konfigurasi yang hanya akan mengubah bagian-bagian yang diperlukan atau untuk mengidentifikasi penyimpangan.
Sebagai hasil dari tahap ini, kami memperoleh konfigurasi yang tidak bergantung pada vendor.
Komponen 6. Antarmuka driver khusus vendor
Anda tidak boleh menyanjung diri sendiri dengan harapan bahwa suatu hari nanti ciska dapat dikonfigurasi dengan cara yang persis sama seperti Juniper, cukup dengan mengirimkan panggilan yang persis sama kepada mereka. Meskipun semakin populernya whitebox dan munculnya dukungan untuk NETCONF, RESTCONF, OpenConfig, konten spesifik yang diberikan oleh protokol ini berbeda dari satu vendor ke vendor lainnya, dan ini adalah salah satu perbedaan kompetitif mereka yang tidak akan mereka serahkan begitu saja.
Ini kira-kira sama dengan OpenContrail dan OpenStack, yang memiliki RestAPI sebagai antarmuka NorthBoundnya, mengharapkan panggilan yang sangat berbeda.
Jadi, pada langkah kelima, model yang tidak bergantung pada vendor harus mengambil bentuk yang akan diterapkan pada perangkat keras.
Dan di sini semua artinya baik (tidak): CLI, NETCONF, RESTCONF, SNMP saja.
Oleh karena itu, kita memerlukan driver yang akan mentransfer hasil langkah sebelumnya ke dalam format yang diperlukan vendor tertentu: sekumpulan perintah CLI, struktur XML.
Komponen 7. Mekanisme penyampaian konfigurasi ke perangkat
Kami telah membuat konfigurasinya, namun masih perlu dikirimkan ke perangkat - dan, tentu saja, tidak dengan tangan.
Pertama, kita dihadapkan pada pertanyaan transportasi apa yang akan kita gunakan? Dan saat ini pilihannya tidak lagi kecil:
- CLI (telnet, ssh)
- SNMP
- NETCONF
- RESTCONF
- SISA API
- OpenFlow (walaupun ini merupakan outlier karena merupakan cara untuk menyampaikan FIB, bukan pengaturan)
Mari kita beri tanda t di sini. CLI adalah warisan. SNMP... batuk batuk.
RESTCONF masih merupakan hewan yang belum diketahui; REST API hampir tidak didukung oleh siapa pun. Oleh karena itu, kami akan fokus pada NETCONF di seri ini.
Faktanya, seperti yang telah dipahami pembaca, pada titik ini kita telah memutuskan antarmukanya - hasil dari langkah sebelumnya sudah disajikan dalam format antarmuka yang dipilih.
Kedua, dan alat apa yang akan kita gunakan untuk melakukan hal ini?
Ada juga banyak pilihan di sini:
- Skrip atau platform yang ditulis sendiri. Mari mempersenjatai diri dengan ncclient dan asyncIO dan melakukan semuanya sendiri. Berapa biaya yang harus dikeluarkan untuk membangun sistem penerapan dari awal?
- Mungkin dengan perpustakaan modul jaringannya yang kaya.
- Salt dengan sedikit kerjanya dengan jaringan dan koneksi dengan Napalm.
- Sebenarnya Napalm, yang kenal beberapa vendor dan hanya itu, selamat tinggal.
- Nornir adalah hewan lain yang akan kami bedah di masa depan.
Di sini favorit belum dipilih - kami akan mencari.
Apa lagi yang penting di sini? Konsekuensi penerapan konfigurasi.
Berhasil atau tidak. Apakah masih ada akses ke hardware atau tidak?
Tampaknya komit akan membantu di sini dengan konfirmasi dan validasi atas apa yang telah diunduh ke perangkat.
Hal ini, dikombinasikan dengan penerapan NETCONF yang benar, secara signifikan mempersempit jangkauan perangkat yang sesuai - tidak banyak produsen yang mendukung penerapan normal. Tapi ini hanyalah salah satu prasyarat . Pada akhirnya, tidak ada yang khawatir bahwa tidak ada satu pun vendor Rusia yang akan mematuhi ketentuan antarmuka 32*100GE. Atau dia khawatir?
Komponen 8. CI/CD
Pada titik ini, kami sudah menyiapkan konfigurasi untuk semua perangkat jaringan.
Saya menulis "untuk semuanya" karena kita berbicara tentang membuat versi status jaringan. Dan bahkan jika Anda perlu mengubah pengaturan hanya satu saklar, perubahan dihitung untuk seluruh jaringan. Tentu saja, nilainya bisa menjadi nol untuk sebagian besar node.
Namun, seperti disebutkan di atas, kami bukanlah orang barbar yang ingin memasukkan semuanya langsung ke dalam produksi.
Konfigurasi yang dihasilkan harus melalui Pipeline CI/CD terlebih dahulu.
CI/CD adalah singkatan dari Continuous Integration, Continuous Deployment. Ini adalah pendekatan di mana tim tidak hanya mengeluarkan rilis besar baru setiap enam bulan, sepenuhnya menggantikan yang lama, namun secara teratur secara bertahap mengimplementasikan (Deployment) fungsionalitas baru dalam porsi kecil, yang masing-masing diuji secara komprehensif untuk kompatibilitas, keamanan dan kinerja (Integrasi).
Untuk melakukan ini, kami memiliki sistem kontrol versi yang memantau perubahan konfigurasi, laboratorium yang memeriksa apakah layanan klien rusak, sistem pemantauan yang memeriksa fakta ini, dan langkah terakhir adalah meluncurkan perubahan pada jaringan produksi.
Dengan pengecualian perintah debugging, semua perubahan pada jaringan harus melalui Pipa CI/CD - ini adalah jaminan kami akan kehidupan yang tenang dan karier yang panjang dan bahagia.
Komponen 9. Sistem cadangan dan deteksi anomali
Ya, tidak perlu membicarakan tentang backup lagi.
Kami hanya akan menempatkannya di git sesuai dengan mahkota atau berdasarkan fakta perubahan konfigurasi.
Namun bagian kedua lebih menarik - seseorang harus mengawasi cadangan ini. Dan dalam beberapa kasus, seseorang harus pergi dan membalikkan keadaan seperti semula, dan dalam kasus lain, mengeong kepada seseorang bahwa ada sesuatu yang salah.
Misalnya, jika pengguna baru muncul yang tidak terdaftar dalam variabel, Anda harus menghapusnya dari peretasan. Dan jika lebih baik tidak menyentuh aturan firewall baru, mungkin seseorang baru saja mengaktifkan debugging, atau mungkin layanan baru, yang ceroboh, tidak terdaftar sesuai peraturan, tetapi orang sudah bergabung.
Kami tetap tidak bisa lepas dari perubahan kecil dalam skala keseluruhan jaringan, meskipun ada sistem otomasi dan manajemen yang sangat tangguh. Untuk men-debug masalah, tidak ada yang akan menambahkan konfigurasi ke sistem. Selain itu, mereka bahkan mungkin tidak disertakan dalam model konfigurasi.
Misalnya, aturan firewall untuk menghitung jumlah paket per IP tertentu untuk melokalisasi masalah adalah konfigurasi sementara yang biasa.
Komponen 10. Sistem pemantauan
Pada awalnya saya tidak akan membahas topik pemantauan - ini masih merupakan topik yang banyak, kontroversial dan kompleks. Namun seiring berjalannya waktu, ternyata hal ini merupakan bagian integral dari otomatisasi. Dan tidak mungkin untuk melewatinya, bahkan tanpa latihan.
Evolusi Pemikiran adalah bagian organik dari proses CI/CD. Setelah meluncurkan konfigurasi ke jaringan, kita harus dapat menentukan apakah semuanya baik-baik saja sekarang.
Dan kita tidak hanya berbicara banyak tentang jadwal penggunaan antarmuka atau ketersediaan node, tetapi tentang hal-hal yang lebih halus - keberadaan rute yang diperlukan, atribut di dalamnya, jumlah sesi BGP, tetangga OSPF, kinerja End-to-End layanan di atasnya.
Apakah syslog ke server eksternal berhenti bertambah, atau apakah agen SFlow rusak, atau apakah penurunan antrian mulai bertambah, atau apakah konektivitas antara sepasang awalan rusak?
Kami akan merenungkan hal ini dalam artikel terpisah.
Kesimpulan
Sebagai dasar, saya memilih salah satu desain jaringan pusat data modern - L3 Clos Fabric dengan BGP sebagai protokol peruteannya.
Kali ini kita akan membangun jaringan di Juniper, karena sekarang antarmuka JunOs adalah vanlove.
Mari kita buat hidup kita lebih sulit dengan hanya menggunakan alat Open Source dan jaringan multi-vendor - jadi selain Juniper, saya akan memilih satu lagi orang yang beruntung.
Rencana untuk publikasi mendatang kira-kira seperti ini:
Pertama saya akan berbicara tentang jaringan virtual. Pertama, karena saya ingin, dan kedua, karena tanpa ini, desain jaringan infrastruktur tidak akan jelas.
Lalu soal desain jaringan itu sendiri: topologi, routing, kebijakan.
Mari kita merakit stand laboratorium.
Mari kita pikirkan dan mungkin berlatih menginisialisasi perangkat di jaringan.
Dan kemudian tentang setiap komponen dengan detail yang mendalam.
Dan ya, saya tidak berjanji untuk mengakhiri siklus ini dengan baik dengan solusi yang sudah jadi. π
Berguna Link
- Sebelum mempelajari serial ini, ada baiknya membaca buku Natasha Samoilenko . Dan mungkin lulus .
- Ini juga akan bermanfaat untuk dibaca tentang desain pabrik pusat data dari Facebook oleh Peter Lapukhov.
- Dokumentasi arsitektur akan memberi Anda gambaran tentang cara kerja Overlay SDN. (sebelumnya Buka Contrail).
Terima kasih
Ngarai Romawi. Untuk komentar dan pengeditan.
Artyom Chernobay. Untuk KDPV.
Sumber: www.habr.com