SDSM sudah berakhir, tetapi keinginan yang tidak terkendali untuk menulis tetap ada.

Selama bertahun-tahun, saudara lelaki kami menderita karena pekerjaan rutin, menyilangkan jari sebelum melakukan, dan kurang tidur karena kembalikan malam.
Namun masa-masa kelam akan segera berakhir.

Dengan artikel ini, saya akan memulai seri tentang bagaimana saya melihat otomatisasi.
Dalam prosesnya, kita akan berurusan dengan tahapan otomatisasi, menyimpan variabel, meresmikan desain, dengan RestAPI, NETCONF, YANG, YDK dan kami akan banyak memprogram.
Ini berarti bagi saya bahwa a) ini bukan kebenaran obyektif, b) bukan pendekatan terbaik tanpa syarat c) pendapat saya dapat berubah bahkan selama perpindahan dari artikel pertama ke terakhir - sejujurnya, dari tahap konsep ke publikasi saya sepenuhnya menulis ulang semuanya dua kali.

Isi

Tujuan
1. Jaringan itu seperti organisme tunggal
2. Pengujian konfigurasi
3. Versi
4. Layanan pemantauan dan penyembuhan diri
Berarti
1. Sistem persediaan
2. Sistem Manajemen Ruang IP
3. Sistem Deskripsi Layanan Jaringan
4. Mekanisme inisialisasi perangkat
5. Model konfigurasi agnostik vendor
6. Driver khusus vendor
7. Mekanisme untuk mengirimkan konfigurasi ke perangkat
8. CI / CD
9. Mekanisme pencadangan dan penyimpangan
10. Sistem pemantauan
Kesimpulan

Saya akan mencoba untuk menjaga ADSM dalam format yang sedikit berbeda dari SDSM. Artikel bernomor besar dan terperinci akan terus muncul, dan di antara mereka saya akan menerbitkan catatan kecil dari pengalaman sehari-hari. Saya akan mencoba untuk melawan perfeksionisme di sini dan tidak menjilat mereka masing-masing.

Betapa lucu bahwa kedua kalinya Anda harus pergi dengan cara yang sama.

Pertama, saya harus menulis artikel tentang jaringan itu sendiri karena fakta bahwa mereka tidak ada di RuNet.

Sekarang saya tidak dapat menemukan dokumen komprehensif yang akan mensistematisasikan pendekatan untuk otomatisasi dan menggunakan contoh praktis sederhana untuk menganalisis teknologi di atas.

Mungkin saya salah, oleh karena itu, melemparkan tautan ke sumber daya yang sesuai. Namun, ini tidak akan mengubah tekad saya untuk menulis, karena tujuan utama masih belajar sesuatu sendiri, dan untuk membuat hidup lebih mudah bagi tetangga saya adalah bonus yang menyenangkan yang membelai gen untuk penyebaran pengalaman.

Kami akan mencoba mengambil pusat data LAN DC berukuran sedang dan menyusun seluruh skema otomasi.
Saya akan melakukan beberapa hal hampir pertama kali dengan Anda.

Dalam ide dan alat yang dijelaskan di sini, saya tidak akan asli. Dmitry Figol memiliki saluran yang sangat baik dengan aliran pada topik ini .
Artikel dalam banyak aspek akan tumpang tindih dengannya.

LAN DC memiliki 4 DC, sekitar 250 sakelar, setengah lusin router, dan beberapa firewall.
Bukan facebook, tetapi cukup untuk berpikir mendalam tentang otomatisasi.
Namun, ada pendapat bahwa jika Anda memiliki lebih dari 1 perangkat, Anda sudah membutuhkan otomatisasi.
Faktanya, sulit untuk membayangkan bahwa seseorang sekarang dapat hidup tanpa setidaknya banyak naskah setinggi lutut.
Meskipun saya mendengar bahwa ada kantor seperti itu di mana alamat IP disimpan di Excel, dan masing-masing dari ribuan perangkat jaringan secara manual dikonfigurasi dan memiliki konfigurasi uniknya sendiri. Ini, tentu saja, dapat dianggap sebagai seni kontemporer, tetapi perasaan insinyur pasti akan tersinggung.

Tujuan

Sekarang kita akan menetapkan tujuan yang paling abstrak:

Jaringan itu seperti organisme tunggal
Pengujian konfigurasi
Versi Status Jaringan
Layanan pemantauan dan penyembuhan diri

Nanti dalam artikel ini kita akan menganalisis yang berarti kita akan menggunakan, dan berikut ini, tujuan dan sarana secara rinci.

Jaringan itu seperti organisme tunggal

Ungkapan yang menentukan dari siklus, meskipun pada pandangan pertama itu mungkin tidak tampak begitu signifikan: kita akan mengkonfigurasi jaringan, bukan perangkat individual .
Selama beberapa tahun terakhir, kami telah melihat perubahan dalam penekanan pada bagaimana memperlakukan jaringan sebagai satu kesatuan, karenanya perangkat lunak mendefinisikan jaringan , jaringan yang digerakkan oleh niat , dan jaringan otonom yang memasuki kehidupan kita.
Bagaimanapun, apa yang dibutuhkan secara global oleh aplikasi dari jaringan: konektivitas antara titik A dan B (well, terkadang + B-Z) dan isolasi dari aplikasi dan pengguna lain.

Dan dengan demikian, tugas kita dalam seri ini adalah membangun sistem yang mendukung konfigurasi saat ini dari seluruh jaringan , yang sudah diuraikan menjadi konfigurasi saat ini pada setiap perangkat sesuai dengan peran dan lokasinya.
Sistem manajemen jaringan menyiratkan bahwa untuk melakukan perubahan kita beralih ke itu, dan itu, pada gilirannya, menghitung keadaan yang diinginkan untuk setiap perangkat dan mengkonfigurasinya.
Dengan cara ini, kami meminimalkan penggunaan CLI di tangan kami menjadi hampir nol - setiap perubahan dalam pengaturan perangkat atau desain jaringan harus diformalkan dan didokumentasikan - dan baru kemudian diluncurkan ke elemen jaringan yang diperlukan.

Itu, misalnya, jika kami memutuskan bahwa mulai sekarang switch rack-mount di Kazan harus mengumumkan dua jaringan, bukan satu, kami
Pertama, kami mendokumentasikan perubahan dalam sistem
Kami menghasilkan konfigurasi target semua perangkat jaringan
Kami memulai 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, dengan tangan kami, kami melakukan perubahan hanya pada langkah pertama.

Pengujian konfigurasi

Diketahui bahwa 80% masalah terjadi selama perubahan konfigurasi - bukti tidak langsung dari hal ini adalah bahwa selama liburan Tahun Baru, semuanya biasanya tenang.
Saya pribadi menyaksikan puluhan downtime global karena kesalahan manusia: perintah yang salah, konfigurasi dieksekusi di cabang yang salah, komunitas lupa, menghancurkan MPLS secara global pada router, mengkonfigurasi lima potong besi, dan tidak melihat kesalahan keenam, melakukan perubahan lama yang dilakukan oleh orang lain . Skenario kegelapan itu gelap.

Otomasi akan memungkinkan kita melakukan lebih sedikit kesalahan, tetapi dalam skala yang lebih besar. Jadi, Anda dapat membuat bata bukan hanya satu perangkat, tetapi seluruh jaringan sekaligus.

Sejak zaman dahulu, kakek kami memeriksa kebenaran dari perubahan yang dibuat dengan mata yang tajam, telur baja, dan efisiensi jaringan setelah meluncurkannya.
Kakek-kakek itu, yang karyanya menyebabkan downtime dan kerugian bencana, meninggalkan lebih sedikit keturunan dan harus mati seiring waktu, tetapi evolusi adalah proses yang lambat, dan karenanya tidak semua orang memeriksa perubahan di laboratorium sebelumnya.
Namun, di garis depan mereka yang mengotomatisasi proses pengujian konfigurasi, dan aplikasi lebih lanjut ke jaringan. Dengan kata lain, saya meminjam prosedur CI / CD ( Continuous Integration, Depuous Deployment ) dari pengembang.
Pada satu bagian, kita akan melihat bagaimana menerapkan ini menggunakan sistem kontrol versi, mungkin github.

Segera setelah Anda terbiasa dengan ide CI / CD jaringan, semalaman metode memeriksa konfigurasi dengan menerapkannya ke jaringan yang bekerja bagi Anda akan menjadi ketidaktahuan awal abad pertengahan. Tentang cara memalu hulu ledak dengan palu.

Kelanjutan organik dari ide-ide tentang sistem manajemen jaringan dan CI / CD adalah versi lengkap dari konfigurasi.

Versi

Kami akan menganggap bahwa dengan perubahan apa pun, bahkan yang paling kecil, bahkan pada satu perangkat yang tidak mencolok, seluruh jaringan beralih dari satu kondisi ke kondisi lainnya.
Dan kami selalu tidak menjalankan perintah pada perangkat, kami mengubah keadaan jaringan.
Sekarang mari kita dapatkan status ini dan menyebutnya versi?

Katakanlah versi saat ini adalah 1.0.0.
Apakah alamat IP dari antarmuka Loopback berubah pada salah satu ToR? Ini adalah versi minor - dapatkan nomor 1.0.1.
Meninjau kebijakan impor rute di BGP - sedikit lebih serius - sudah 1.1.0
Kami memutuskan untuk menyingkirkan IGP dan beralih hanya ke BGP - ini adalah perubahan desain radikal - 2.0.0.

Pada saat yang sama, DC yang berbeda mungkin memiliki versi yang berbeda - jaringan sedang berkembang, peralatan baru sedang dipasang, di suatu tempat tingkat tulang belakang baru ditambahkan, di suatu tempat - tidak, dll.

Kami akan berbicara tentang versi semantik dalam artikel terpisah.

Saya ulangi - perubahan apa pun (kecuali untuk perintah debugging) adalah pembaruan versi. Administrator harus diberitahu tentang penyimpangan dari versi saat ini.

Hal yang sama berlaku untuk rollback perubahan - ini bukan penghapusan perintah terakhir, ini bukan rollback oleh sistem operasi perangkat - ini membawa seluruh jaringan ke versi baru (lama).

Layanan pemantauan dan penyembuhan diri

Tugas yang terbukti sendiri dalam jaringan modern ini naik ke tingkat yang baru.
Seringkali, penyedia layanan besar mempraktikkan pendekatan bahwa layanan yang jatuh harus segera diselesaikan dan yang baru dinaikkan, alih-alih mencari tahu apa yang terjadi.
"Sangat" berarti bahwa dari semua pihak perlu untuk mengolesi secara mendalam dengan pemantauan, yang dalam hitungan detik akan mendeteksi penyimpangan sekecil apa pun dari norma.
Dan di sini tidak cukup metrik yang familier, seperti memuat antarmuka atau aksesibilitas sebuah node. Tidak cukup dan pelacakan manual petugas jaga untuk mereka.
Untuk banyak hal, umumnya harus ada Penyembuhan Diri - kontrol menyala merah dan pergi pisang raja sendiri, di mana itu menyakitkan.

Dan di sini kita juga memantau tidak hanya perangkat individual, tetapi juga kesehatan jaringan secara keseluruhan, baik kotak putih, yang relatif jelas, dan kotak hitam, yang sudah lebih rumit.

Apa yang kita butuhkan untuk mengimplementasikan rencana ambisius tersebut?

Memiliki daftar semua perangkat di jaringan, lokasi, peran, model, versi perangkat lunaknya.
kazan-leaf-1.lmu.net, Kazan, leaf, Juniper QFX 5120, R18.3.
Memiliki sistem untuk menggambarkan layanan jaringan.
IGP, BGP, L2 / 3VPN, Kebijakan, ACL, NTP, SSH.
Mampu menginisialisasi perangkat.
Hostname, Mgmt IP, Mgmt Route, Pengguna, RSA-Keys, LLDP, NETCONF
Konfigurasikan perangkat dan bawa konfigurasi ke versi yang diinginkan (termasuk yang lama).
Konfigurasi tes
Secara berkala periksa status semua perangkat untuk penyimpangan dari perangkat saat ini dan beri tahu siapa yang harus.
Di malam hari, seseorang diam-diam menambahkan aturan ke ACL .
Monitor kinerja.

Berarti

Kedengarannya cukup rumit untuk mulai menguraikan proyek menjadi komponen.

Dan akan ada sepuluh dari mereka:

Sistem persediaan
Sistem Manajemen Ruang IP
Sistem Deskripsi Layanan Jaringan
Mekanisme inisialisasi perangkat
Model konfigurasi agnostik vendor
Driver khusus vendor
Mekanisme untuk mengirimkan konfigurasi ke perangkat
CI / CD
Mekanisme pencadangan dan penyimpangan
Sistem pemantauan

Omong-omong, ini adalah contoh bagaimana pandangan tentang tujuan siklus berubah - ada 4 komponen dalam konsep komponen.

Dalam ilustrasi, saya menggambarkan semua komponen dan perangkat itu sendiri.
Komponen berpotongan saling berinteraksi.
Semakin besar blok, semakin banyak perhatian yang Anda butuhkan untuk komponen ini.

Komponen 1. Sistem inventaris

Jelas, kami ingin tahu peralatan apa, di mana tempatnya, apa yang terhubung.
Sistem persediaan adalah bagian integral dari perusahaan mana pun.
Paling sering, untuk perangkat jaringan, perusahaan memiliki sistem persediaan terpisah yang menyelesaikan tugas yang lebih spesifik.
Sebagai bagian dari serangkaian artikel, kami akan menyebutnya DCIM - Manajemen Infrastruktur Pusat Data. Meskipun istilah DCIM itu sendiri, sebenarnya, mencakup lebih banyak.

Untuk tugas kami, kami akan menyimpan informasi berikut tentang perangkat di dalamnya:

Nomor inventaris
Judul / Deskripsi
Model ( Huawei CE12800, Juniper QFX5120, dll. )
Parameter umum ( papan, antarmuka, dll. )
Peranan ( Leaf, Spine, Border Router, dll. )
Lokasi ( wilayah, kota, pusat data, rak, unit )
Interkoneksi antar perangkat
Topologi jaringan

Sangat jelas bahwa kita sendiri ingin mengetahui semua ini.
Tetapi apakah akan membantu untuk otomatisasi?
Tentu saja
Misalnya, kita tahu bahwa di pusat data ini pada sakelar Daun, jika itu adalah Huawei, ACL untuk memfilter lalu lintas tertentu harus diterapkan pada VLAN, dan jika itu adalah Juniper, maka pada unit 0 dari antarmuka fisik.
Atau Anda perlu meluncurkan server Syslog baru ke semua asrama di wilayah tersebut.

Di dalamnya, kami akan menyimpan perangkat jaringan virtual, seperti router virtual atau reflektor-root. Kita dapat menambahkan server DNS, NTP, Syslog, dan umumnya segala sesuatu yang terkait dengan jaringan.

Komponen 2. Sistem Manajemen Ruang IP

Ya, dan di zaman kita ada tim orang yang melacak awalan dan alamat IP dalam file Excel. Tetapi pendekatan modern masih merupakan basis data, dengan tampilan depan pada nginx / apache, API dan fungsi yang luas untuk memperhitungkan alamat IP dan jaringan dengan pemisahan ke dalam VRF.
IPAM - Manajemen Alamat IP.

Untuk tugas-tugas 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 dengan mengalokasikan alamat IP baru untuk loopback ToR, kami tidak akan tersandung pada kenyataan bahwa itu sudah ditugaskan kepada seseorang. Atau kami menggunakan awalan yang sama dua kali di ujung jaringan yang berbeda.
Tetapi bagaimana ini membantu dalam otomatisasi?
Mudah
Kami meminta awalan dalam sistem dengan peran Loopbacks, di mana ada alamat IP yang tersedia untuk alokasi - jika ya, pilih alamatnya, jika tidak, kami meminta pembuatan awalan baru.
Atau, saat membuat konfigurasi perangkat, kami dari sistem yang sama dapat mencari tahu di mana VRF berada.
Dan ketika Anda memulai server baru, skrip masuk ke dalam sistem, mencari tahu di server mana sakelar, di mana port dan subnet mana yang ditugaskan ke antarmuka - ia akan memilih alamat server dari itu.

Ini memohon keinginan DCIM dan IPAM untuk bergabung menjadi satu sistem agar tidak menduplikasi fungsi dan tidak melayani dua entitas yang serupa.
Jadi kita akan lakukan.

Komponen 3. Sistem Deskripsi Layanan Jaringan

Jika dua sistem pertama menyimpan variabel yang masih perlu digunakan entah bagaimana, maka yang ketiga menjelaskan untuk setiap peran perangkat bagaimana harus dikonfigurasi.
Layak menyoroti dua jenis layanan jaringan:

Infrastruktur
Klien

Yang pertama dirancang untuk memberikan konektivitas dasar dan manajemen perangkat. Ini termasuk VTY, SNMP, NTP, Syslog, AAA, protokol routing, CoPP, dll.
Yang kedua mengatur layanan untuk klien: MPLS L2 / L3VPN, GRE, VXLAN, VLAN, L2TP, dll.
Tentu saja, ada juga kasus perbatasan - di mana memasukkan MPLS LDP, BGP? Ya, dan protokol routing dapat digunakan untuk klien. Tetapi ini tidak penting.

Kedua jenis layanan tersebut didekomposisi menjadi konfigurasi primitif:

antarmuka fisik dan logis (tag / anteg, mtu)
Alamat IP dan VRF (IP, IPv6, VRF)
ACL dan kebijakan penanganan lalu lintas
Protokol (IGP, BGP, MPLS)
Kebijakan perutean (daftar awalan, komunitas, filter ASN).
Layanan layanan (SSH, NTP, LLDP, Syslog ...)
Dll

Bagaimana tepatnya kita akan melakukan ini, saya belum akan memikirkannya. Kami akan membahas artikel terpisah.

Jika sedikit lebih dekat dengan kehidupan, maka kita bisa menggambarkannya
Switch daun harus memiliki sesi BGP dengan semua sakelar Spine yang terhubung, mengimpor jaringan yang terhubung ke proses, dan hanya menerima jaringan dari awalan spesifik dari sakelar Spine. Batasi CoPP IPv6 ND hingga 10 pps, dll.
Pada gilirannya, spin mengadakan sesi dengan semua bodi yang terhubung, bertindak sebagai reflektor-root, dan menerima dari mereka hanya rute dengan panjang tertentu dan dengan komunitas tertentu.

Komponen 4. Mekanisme inisialisasi perangkat

Di bawah judul ini, saya menggabungkan banyak tindakan yang harus terjadi agar perangkat muncul di radar dan diakses dari jarak jauh.

Mulai perangkat di sistem inventaris.
Sorot alamat IP manajemen.
Konfigurasikan akses dasar untuk itu:
Hostname, 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 membawanya ke sistem, terhubung ke konsol dan mengkonfigurasi. Dapat bekerja pada jaringan statis kecil.
ZTP - Penyediaan Tanpa Sentuhan. Besi datang, berdiri, menerima alamat melalui DHCP, pergi ke server khusus, dan mengonfigurasi sendiri.
Infrastruktur server konsol, tempat konfigurasi awal terjadi melalui port konsol dalam mode otomatis.

Kami akan membicarakan ketiganya di artikel terpisah.

Komponen 5. Model konfigurasi vendor-agnostik

Sampai sekarang, semua sistem telah tersebar kain memberikan variabel dan deskripsi deklaratif tentang apa yang ingin kita lihat di jaringan. Tetapi cepat atau lambat, Anda harus berurusan dengan 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 yang tidak tergantung vendor.
Apa yang memberi langkah ini? Mengapa tidak segera mengkonfigurasi perangkat, yang bisa Anda isi?
Bahkan, ini memungkinkan kita untuk menyelesaikan tiga masalah:

Jangan beradaptasi dengan antarmuka spesifik untuk berinteraksi dengan perangkat. Apakah itu CLI, NETCONF, RESTCONF, SNMP - modelnya akan sama.
Jangan menyimpan jumlah templat / skrip dengan jumlah vendor di jaringan, dan jika terjadi perubahan desain, ubah yang sama di beberapa tempat.
Unduh konfigurasi dari perangkat (cadangan), lay out dalam model yang persis sama dan langsung membandingkan konfigurasi target dan yang tersedia untuk menghitung delta dan menyiapkan tambalan konfigurasi, yang hanya akan mengubah bagian-bagian yang diperlukan atau untuk mendeteksi penyimpangan.

Sebagai hasil dari tahap ini, kami mendapatkan konfigurasi independen-vendor.

Komponen 6. Driver khusus antarmuka vendor

Jangan menghibur diri Anda dengan harapan bahwa sekali Anda dapat mengkonfigurasi tsiska, itu akan dimungkinkan dengan cara yang sama seperti pelompat, hanya mengirim mereka panggilan yang persis sama. Meskipun popularitas whitebox semakin meningkat dan munculnya dukungan untuk NETCONF, RESTCONF, OpenConfig, konten spesifik yang diberikan oleh protokol-protokol ini berbeda dari vendor ke vendor, dan ini adalah salah satu perbedaan kompetitif mereka yang mereka tidak akan menyerah.
Ini hampir sama dengan OpenContrail dan OpenStack, yang memiliki RestAPI sebagai antarmuka NorthBound mereka, mengharapkan panggilan yang sama sekali berbeda.

Jadi, pada langkah kelima, model vendor-independent harus mengambil bentuk yang akan digunakan.
Dan di sini, segala cara baik (tidak): CLI, NETCONF, RESTCONF, SNMP dalam kejatuhan sederhana.

Oleh karena itu, kita memerlukan driver yang menerjemahkan hasil dari langkah sebelumnya ke format yang diinginkan untuk vendor tertentu: seperangkat perintah CLI, struktur XML.

Komponen 7. Mekanisme untuk mengirimkan konfigurasi ke perangkat

Kami membuat konfigurasi, tetapi masih perlu dikirim ke perangkat - dan, tentu saja, tidak dengan tangan.
Pertama , kita dihadapkan pada pertanyaan, jenis transportasi apa yang akan kita gunakan? Dan pilihan hari ini tidak lagi kecil:

CLI (telnet, ssh)
~~SNMP~~
NETCONF
RESTCONF
API SISA
OpenFlow (meskipun tersingkir dari daftar, karena ini adalah cara untuk memberikan FIB, bukan pengaturan)

Mari titik di sini dengan e. CLI adalah Legacy. SNMP ... hehe.
RESTCONF masih merupakan hewan yang tidak dikenal, API REST hampir tidak didukung oleh siapa pun. Oleh karena itu, kami akan fokus pada NETCONF dalam satu lingkaran.

Bahkan, seperti yang sudah dipahami pembaca, kami telah memutuskan antarmuka pada saat ini - hasil dari langkah sebelumnya sudah disajikan dalam format antarmuka yang dipilih.

Kedua , dengan alat apa yang akan kita lakukan ini?
Di sini pilihannya juga besar:

Skrip atau platform yang ditulis sendiri. Kami mempersenjatai diri dengan ncclient dan asyncIO dan melakukan semuanya sendiri. Berapa biayanya kita untuk membangun sistem penyebaran dari awal?
Mungkin dengan pustaka modul modul yang kaya.
Garam dengan kerja jaringannya yang sedikit dan bundel dengan Napalm.
Sebenarnya Napalm, yang tahu beberapa vendor dan itu saja, selamat tinggal.
Nornir adalah binatang buas lain yang kami persiapkan untuk masa depan.

Masih belum ada favorit yang dipilih - kami akan menginjak.

Apa lagi yang penting di sini? Konsekuensi dari penerapan konfigurasi.
Berhasil atau tidak. Akses yang tersisa ke perangkat keras atau tidak.
Tampaknya komit akan membantu di sini dengan konfirmasi dan validasi apa yang diunduh ke perangkat.
Ini, dikombinasikan dengan implementasi NETCONF yang benar, secara signifikan mempersempit jangkauan perangkat yang sesuai - tidak banyak produsen yang mendukung komitmen normal. Tetapi ini hanyalah salah satu prasyarat dalam RFP . Pada akhirnya, tidak ada yang khawatir bahwa tidak satu pun vendor Rusia akan lulus dalam kondisi antarmuka 32 * 100GE. Atau khawatir?

Komponen 8. CI / CD

Pada titik ini, kami sudah siap untuk semua perangkat jaringan.
Saya menulis "untuk semuanya" karena kita berbicara tentang versi keadaan jaringan. Dan bahkan jika Anda perlu mengubah pengaturan hanya satu switch, perubahan untuk seluruh jaringan dihitung. Jelas, mereka bisa nol untuk sebagian besar node.

Tapi, seperti yang telah disebutkan, di atas, kita bukan orang barbar untuk menggulung semuanya sekaligus ke dalam dorongan.
Konfigurasi yang dihasilkan terlebih dahulu harus melalui Pipeline CI / CD.

CI / CD adalah singkatan dari Continuous Integration, Continuous Deployment. Ini adalah pendekatan di mana tim menerbitkan rilis besar utama lebih dari sekali setiap enam bulan, sepenuhnya menggantikan yang lama, dan secara teratur Deploment memperkenalkan fungsionalitas baru dalam batch kecil, yang masing-masing secara komprehensif menguji kompatibilitas, keamanan dan kinerja (Integrasi).

Untuk melakukan ini, kami memiliki sistem kontrol versi yang memantau perubahan konfigurasi, laboratorium tempat kami memeriksa untuk melihat apakah layanan pelanggan rusak, sistem pemantauan yang memeriksa fakta ini, dan langkah terakhir adalah meluncurkan perubahan ke jaringan produksi.

Dengan pengecualian dari tim debugging, benar-benar semua perubahan pada jaringan harus melalui CI / CD Pipeline - ini adalah jaminan kami akan kehidupan yang tenang dan karier yang panjang dan bahagia.

Komponen 9. Sistem pencadangan dan penolakan

Yah, saya tidak perlu berbicara tentang cadangan lagi.
Kami hanya akan menambahkannya sesuai dengan mahkota atau berdasarkan fakta perubahan konfigurasi pada git.

Tetapi bagian kedua lebih menarik - seseorang harus mengawasi cadangan ini. Dan dalam beberapa kasus, seseorang ini harus pergi dan memutar segala sesuatu sebagaimana adanya, dan dalam kasus lain, mengeong seseorang, itulah gangguannya.
Misalnya, jika ada pengguna baru yang tidak terdaftar dalam variabel, Anda harus menghapusnya dari peretasan. Dan jika lebih baik tidak menyentuh aturan firewall baru, mungkin seseorang hanya menyalakan debugging, atau mungkin layanan baru, berantakan, tidak mendaftar sesuai dengan aturan, tetapi orang-orang sudah melakukannya.

Kami masih tidak akan lolos dari delta kecil tertentu pada skala seluruh jaringan, terlepas dari sistem otomasi dan tangan baja manajemen. Untuk men-debug masalah, tidak ada yang akan membawa konfigurasi ke sistem. Selain itu, mereka bahkan mungkin tidak disediakan oleh model konfigurasi.

Misalnya, aturan firewall untuk menghitung jumlah paket pada IP tertentu, untuk melokalisasi masalah - konfigurasi sementara yang benar-benar biasa.

Komponen 10. Sistem Pemantauan

Pada awalnya, saya tidak akan membahas topik pemantauan - masih merupakan topik yang banyak, kontroversial dan kompleks. Tetapi di sepanjang jalan, ternyata ini adalah bagian integral dari otomatisasi. Dan Anda tidak bisa menyiasatinya bahkan tanpa latihan.

Mengembangkan pemikiran adalah bagian organik dari proses CI / CD. Setelah meluncurkan konfigurasi ke jaringan, kita harus dapat menentukan apakah semuanya baik-baik saja dengan itu sekarang.
Dan itu tidak hanya dan tidak begitu banyak tentang grafik penggunaan antarmuka atau ketersediaan host, tetapi tentang hal-hal yang lebih halus - ketersediaan rute yang diperlukan, atribut pada mereka, jumlah sesi BGP, tetangga OSPF, layanan uptime End-to-End.
Tetapi apakah syslog pada server eksternal berhenti melipat, apakah agen SFlow mogok, apakah tetes dalam antrian mulai tumbuh, dan apakah koneksi antara sepasang awalan putus?

Dalam artikel terpisah, kami merenungkan hal ini.

Kesimpulan

Sebagai dasar, saya memilih salah satu desain jaringan pusat data modern - L3 Clos Fabric dengan BGP sebagai protokol routing.
Kali ini kita akan membangun jaringan di Juniper, karena sekarang antarmuka JunOs adalah vanlav.

Mari kita mempersulit hidup kita hanya dengan menggunakan alat Open Source dan jaringan multi-vendor - oleh karena itu, selain dari Juniper, sepanjang jalan saya akan memilih pria yang beruntung lainnya.

Rencana publikasi yang akan datang adalah sesuatu seperti ini:
Pertama saya akan berbicara tentang jaringan virtual. Pertama-tama, karena saya ingin, dan kedua, karena tanpa ini, desain jaringan infrastruktur tidak akan terlalu jelas.
Lalu tentang desain jaringan itu sendiri: topologi, routing, kebijakan.
Mari kita pasang dudukan laboratorium.
Mari kita renungkan dan mungkin berlatih menginisialisasi perangkat di jaringan.
Dan kemudian tentang setiap komponen dalam detail intim.

Dan ya, saya tidak berjanji untuk mengakhiri siklus ini dengan elegan dengan solusi yang sudah jadi. :)

Tautan yang bermanfaat

Sebelum mempelajari seri ini, Anda harus membaca buku karya Natasha Samoilenko Python untuk insinyur jaringan . Dan, mungkin, ambil kursus .
Ini juga akan berguna untuk membaca RFC tentang desain pabrik pusat data dari Facebook untuk kepengarangan Peter Lapukhov.
Dokumentasi arsitektur Tungsten Fabric (sebelumnya Open Contrail) akan memberi Anda gambaran tentang cara kerja Overlay SDN .

Terima kasih

Roman Gorge. Untuk komentar dan pengeditan.
Artyom Chernobay. Untuk KDPV.

Otomatisasi untuk yang terkecil. Bagian nol. Perencanaan

Isi