SDSM tugadi, lekin yozishga bo'lgan boshqarib bo'lmaydigan istak saqlanib qolmoqda.

Birodarimiz ko'p yillar davomida odatdagi ish bilan shug'ullanib, barmoqlarini kesib o'tishdan azob chekardi va tungi orqaga qaytish tufayli uxlamas edi.
Ammo qorong'u davrlar nihoyasiga yetmoqda.

Ushbu maqola bilan men qanday qilib bir qator boshlayman men bilan avtomatlashtirish ko'rinadi.
Yo'l davomida biz avtomatlashtirish, o'zgaruvchilarni saqlash, dizaynni rasmiylashtirish, RestAPI, NETCONF, YANG, YDK bosqichlarini tushunamiz va biz juda ko'p dasturlash qilamiz.
Menga a) bu ob'ektiv haqiqat emas, b) bu ​​so'zsiz eng yaxshi yondashuv emas, c) mening fikrim, hatto birinchi maqoladan oxirgi maqolaga o'tish paytida ham o'zgarishi mumkin - rostini aytganda, loyiha bosqichidan. nashr, men hamma narsani ikki marta butunlay qayta yozdim.

Mundarija

1. Maqsadlar
   1. Tarmoq yagona organizmga o'xshaydi
   2. Konfiguratsiya sinovi
   3. Versiyalash
   4. Xizmatlarni monitoring qilish va o'z-o'zini davolash

2. Pul mablag'lari
   1. Inventarizatsiya tizimi
   2. IP makonini boshqarish tizimi
   3. Tarmoq xizmatlarini tavsiflash tizimi
   4. Qurilmani ishga tushirish mexanizmi
   5. Sotuvchi-agnostik konfiguratsiya modeli
   6. Sotuvchiga xos drayver interfeysi
   7. Konfiguratsiyani qurilmaga etkazib berish mexanizmi
   8. CI / CD
   9. Zaxiralash va chetlanishlarni qidirish mexanizmi
   10. Monitoring tizimi

3. xulosa

Men ADSM-ni SDSM-dan biroz farqli formatda o'tkazishga harakat qilaman. Katta, batafsil, raqamlangan maqolalar paydo bo'lishda davom etadi va ular orasida men kundalik tajribadan kichik eslatmalarni nashr etaman. Men bu erda perfektsionizmga qarshi kurashishga harakat qilaman va ularning har birini yalamayman.

Qanday kulgili, ikkinchi marta xuddi shu yo'ldan o'tishga to'g'ri keladi.

Avvaliga men o'zim tarmoqlar haqida maqolalar yozishga majbur bo'ldim, chunki ular RuNetda yo'q edi.

Endi men avtomatlashtirishga yondashuvlarni tizimlashtiradigan va yuqoridagi texnologiyalarni oddiy amaliy misollar yordamida tahlil qiladigan keng qamrovli hujjat topa olmadim.

Men noto'g'ri bo'lishim mumkin, shuning uchun foydali manbalarga havolalar bering. Biroq, bu mening yozishga bo'lgan qat'iyatimni o'zgartirmaydi, chunki asosiy maqsad - o'zim nimanidir o'rganish va boshqalarning hayotini osonlashtirish - bu tajriba almashish genini silaydigan yoqimli bonus.

Biz o'rta o'lchamdagi LAN DC ma'lumotlar markazini olishga va butun avtomatlashtirish sxemasini ishlab chiqishga harakat qilamiz.
Men siz bilan deyarli birinchi marta ba'zi narsalarni qilyapman.

Men bu erda tasvirlangan g'oyalar va vositalarda original bo'lmayman. Dmitriy Figol juda zo'r ushbu mavzu bo'yicha oqimlari bo'lgan kanal.
Maqolalar ular bilan ko'p jihatdan bir-biriga mos keladi.

LAN DCda 4 ta DC, 250 ga yaqin kalit, yarim o'nlab router va bir nechta xavfsizlik devori mavjud.
Facebook emas, balki sizni avtomatlashtirish haqida chuqur o'ylash uchun etarli.
Biroq, agar sizda 1 dan ortiq qurilma bo'lsa, avtomatlashtirish allaqachon kerak degan fikr mavjud.
Darhaqiqat, endi har kim hech bo'lmaganda tizza skriptisiz yashashi mumkinligini tasavvur qilish qiyin.
Men Excelda IP manzillar saqlanadigan ofislar borligini va minglab tarmoq qurilmalarining har biri qo'lda sozlanganligini va o'ziga xos konfiguratsiyasiga ega ekanligini eshitgan bo'lsam ham. Bu, albatta, zamonaviy san'at sifatida qabul qilinishi mumkin, ammo muhandisning his-tuyg'ulari, albatta, xafa bo'ladi.

Maqsadlar

Endi biz eng mavhum maqsadlarni belgilaymiz:

• Tarmoq yagona organizmga o'xshaydi
• Konfiguratsiya sinovi
• Tarmoq holati versiyasi
• Xizmatlarni monitoring qilish va o'z-o'zini davolash

Keyinchalik ushbu maqolada biz qanday vositalarni qo'llashimizni ko'rib chiqamiz, keyin esa maqsad va vositalarni batafsil ko'rib chiqamiz.

Tarmoq yagona organizmga o'xshaydi

Seriyaning aniqlovchi iborasi, garchi birinchi qarashda unchalik ahamiyatli bo'lmasa ham: biz alohida qurilmalarni emas, tarmoqni sozlaymiz.
So'nggi yillarda biz tarmoqqa yagona ob'ekt sifatida qarashga e'tiborning o'zgarishini ko'rdik, shuning uchun Dasturlashtirilgan Tarmoq, Niyatga asoslangan tarmoqlar и Avtonom tarmoqlar.
Axir, ilovalar global tarmoqdan nimaga muhtoj: A va B nuqtalari orasidagi ulanish (yaxshi, ba'zan + B-Z) va boshqa ilovalar va foydalanuvchilardan izolyatsiya.

Va bu seriyadagi bizning vazifamiz tizimini qurish, joriy konfiguratsiyani saqlash butun tarmoq, bu allaqachon o'z roli va joylashuviga muvofiq har bir qurilmada haqiqiy konfiguratsiyaga ajratilgan.
tizim tarmoq boshqaruvi shuni anglatadiki, o'zgartirishlar kiritish uchun biz u bilan bog'lanamiz va u o'z navbatida har bir qurilma uchun kerakli holatni hisoblab chiqadi va uni sozlaydi.
Shunday qilib, biz CLI-ga qo'lda kirishni deyarli nolga kamaytiramiz - qurilma sozlamalari yoki tarmoq dizaynidagi har qanday o'zgarishlar rasmiylashtirilishi va hujjatlashtirilishi kerak - va shundan keyingina tarmoqning kerakli elementlariga o'tkaziladi.

Ya'ni, masalan, agar biz bundan buyon Qozondagi rack kalitlari bitta emas, ikkita tarmoqni e'lon qilishiga qaror qilsak, biz

1. Avval tizimdagi o'zgarishlarni hujjatlashtiramiz
2. Barcha tarmoq qurilmalarining maqsadli konfiguratsiyasini yaratish
3. Biz tarmoq konfiguratsiyasini yangilash dasturini ishga tushiramiz, u har bir tugunda nimani olib tashlash kerakligini, nimani qo'shish kerakligini hisoblab chiqadi va tugunlarni kerakli holatga keltiradi.

Shu bilan birga, biz o'zgarishlarni faqat birinchi bosqichda qo'lda qilamiz.

Konfiguratsiya sinovi

Bu ma'lum80% muammolar konfiguratsiyani o'zgartirish paytida yuzaga kelishi - buning bilvosita dalili shundaki, Yangi yil bayramlarida hamma narsa odatda tinch bo'ladi.
Men shaxsan inson xatosi tufayli o'nlab global uzilishlarning guvohi bo'lganman: noto'g'ri buyruq, konfiguratsiya noto'g'ri filialda bajarilgan, jamoa unutgan, MPLS routerda global miqyosda buzib tashlangan, beshta apparat sozlangan, ammo xatolik yuz bermagan. oltinchi kuni sezilib, boshqa shaxs tomonidan qilingan eski o'zgarishlar sodir bo'lgan. Bir tonna stsenariy mavjud.

Avtomatlashtirish bizga kamroq xato qilish imkonini beradi, lekin kattaroq miqyosda. Shunday qilib, siz bir vaqtning o'zida bitta qurilmani emas, balki butun tarmoqni g'ishtlashingiz mumkin.

Qadim zamonlardan buyon bizning bobolarimiz o'tkir ko'z bilan qilingan o'zgarishlarning to'g'riligini, po'latdan yasalgan sharlar va tarmoqning funksionalligini ular chiqarilgandan keyin tekshirib ko'rdilar.
Ishlari uzilishlar va halokatli yo'qotishlarga olib kelgan bobolar kamroq avlod qoldirgan va vaqt o'tishi bilan o'lishi kerak, ammo evolyutsiya sekin jarayondir va shuning uchun hamma ham o'zgarishlarni laboratoriyada sinab ko'rmaydi.
Biroq, taraqqiyotning boshida konfiguratsiyani sinovdan o'tkazish jarayonini va uni tarmoqqa keyingi qo'llash jarayonini avtomatlashtirganlar turadi. Boshqacha qilib aytganda, men CI/CD protsedurasini oldim (Uzluksiz integratsiya, uzluksiz joylashtirish) ishlab chiquvchilardan.
Qismlarning birida biz buni versiyani boshqarish tizimi, ehtimol Github yordamida qanday amalga oshirishni ko'rib chiqamiz.

Tarmoq CI/CD g'oyasiga o'rganib qolganingizdan so'ng, bir kechada konfiguratsiyani ishlab chiqarish tarmog'iga qo'llash orqali tekshirish usuli erta o'rta asrlarning jaholatiga o'xshab ko'rinadi. Urush kallagini bolg'a bilan urishga o'xshaydi.

haqidagi g'oyalarning organik davomi tizim tarmoq boshqaruvi va CI/CD konfiguratsiyaning to'liq versiyasiga aylanadi.

Versiyalash

Biz taxmin qilamizki, har qanday o'zgarishlar, hatto eng kichiklari ham, hatto bitta sezilmaydigan qurilmada ham butun tarmoq bir holatdan ikkinchisiga o'tadi.
Va biz har doim qurilmada buyruqni bajarmaymiz, biz tarmoq holatini o'zgartiramiz.
Xo'sh, keling, bu shtatlarni versiyalar deb ataymiz?

Aytaylik, joriy versiya 1.0.0.
ToRlardan biridagi Loopback interfeysining IP manzili o'zgarganmi? Bu kichik versiya va 1.0.1 raqamlangan bo'ladi.
Biz BGPga marshrutlarni import qilish siyosatini qayta ko'rib chiqdik - biroz jiddiyroq - allaqachon 1.1.0
Biz IGP dan xalos bo'lishga va faqat BGP ga o'tishga qaror qildik - bu allaqachon dizaynning tub o'zgarishi - 2.0.0.

Shu bilan birga, turli DClar turli xil versiyalarga ega bo'lishi mumkin - tarmoq rivojlanmoqda, yangi uskunalar o'rnatilmoqda, boshqa joylarda emas, balki bir joyda yangi darajadagi tikanlar qo'shilmoqda va hokazo.

haqida semantik versiyalash biz alohida maqolada gaplashamiz.

Takrorlayman - har qanday o'zgarish (disk raskadrovka buyruqlaridan tashqari) versiyani yangilashdir. Ma'murlar joriy versiyadan har qanday og'ishlar haqida xabardor qilinishi kerak.

Xuddi shu narsa o'zgarishlarni orqaga qaytarish uchun ham amal qiladi - bu oxirgi buyruqlarni bekor qilish emas, bu qurilmaning operatsion tizimidan foydalangan holda orqaga qaytarish emas - bu butun tarmoqni yangi (eski) versiyaga olib keladi.

Xizmatlarni monitoring qilish va o'z-o'zini davolash

Bu o'z-o'zidan ravshan vazifa zamonaviy tarmoqlarda yangi bosqichga ko'tarildi.
Ko'pincha yirik xizmat ko'rsatuvchi provayderlar nima bo'lganini aniqlash o'rniga, muvaffaqiyatsiz xizmatni juda tez tuzatib, yangisini ko'tarish kerak degan yondashuvni qo'llashadi.
"Juda" sizni har tomondan saxiylik bilan monitoring bilan qoplashingiz kerakligini anglatadi, bu bir necha soniya ichida me'yordan eng kichik og'ishlarni aniqlaydi.
Va bu erda interfeysni yuklash yoki tugun mavjudligi kabi odatiy ko'rsatkichlar endi etarli emas. Navbatchi tomonidan ularni qo'lda nazorat qilish ham etarli emas.
Ko'p narsalar uchun bo'lishi kerak O'z-o'zini davolash — kuzatuv chiroqlari qizarib ketdi va biz borib chinorni og‘rigan joyiga surdik.

Va bu erda biz nafaqat alohida qurilmalarni, balki butun tarmoqning sog'lig'ini ham kuzatib boramiz, nisbatan tushunarli oq quti va murakkabroq qora quti.

Bunday ulkan rejalarni amalga oshirish uchun bizga nima kerak?

• Tarmoqdagi barcha qurilmalar, ularning joylashuvi, rollari, modellari, dasturiy ta'minot versiyalari ro'yxatiga ega bo'ling.
  kazan-leaf-1.lmu.net, Qozon, barg, Juniper QFX 5120, R18.3.
• Tarmoq xizmatlarini tavsiflash tizimiga ega bo'ling.
  IGP, BGP, L2/3VPN, siyosat, ACL, NTP, SSH.
• Qurilmani ishga tushira olish.
  Xost nomi, Mgmt IP, Mgmt Route, foydalanuvchilar, RSA-keys, LLDP, NETCONF
• Qurilmani sozlang va konfiguratsiyani kerakli (shu jumladan eski) versiyaga keltiring.
• Sinov konfiguratsiyasi
• Vaqti-vaqti bilan barcha qurilmalarning holatini joriy qurilmalardan chetga chiqish uchun tekshiring va kimga xabar bering.
  Bir kechada kimdir jimgina ACLga qoida qo'shdi.
• Ishlash monitoringi.

Pul mablag'lari

Loyihani tarkibiy qismlarga ajratishni boshlash uchun bu juda murakkab tuyuladi.

Va ulardan o'ntasi bo'ladi:

1. Inventarizatsiya tizimi
2. IP makonini boshqarish tizimi
3. Tarmoq xizmatlarini tavsiflash tizimi
4. Qurilmani ishga tushirish mexanizmi
5. Sotuvchi-agnostik konfiguratsiya modeli
6. Sotuvchiga xos drayver interfeysi
7. Konfiguratsiyani qurilmaga etkazib berish mexanizmi
8. CI / CD
9. Zaxiralash va chetlanishlarni qidirish mexanizmi
10. Monitoring tizimi

Aytgancha, bu tsikl maqsadlariga qarash qanday o'zgarganiga misol - loyihada 4 ta komponent mavjud edi.

Rasmda men barcha komponentlarni va qurilmaning o'zini tasvirladim.
Kesishgan komponentlar bir-biri bilan o'zaro ta'sir qiladi.
Blok qanchalik katta bo'lsa, ushbu komponentga ko'proq e'tibor berish kerak.

1-komponent: Inventarizatsiya tizimi

Shubhasiz, biz qaysi asbob-uskunalar qayerda joylashganligini, nimaga ulanganligini bilmoqchimiz.
Inventarizatsiya tizimi har qanday korxonaning ajralmas qismi hisoblanadi.
Ko'pincha korxonada tarmoq qurilmalari uchun alohida inventarizatsiya tizimi mavjud bo'lib, u aniqroq muammolarni hal qiladi.
Ushbu maqolalar turkumining bir qismi sifatida biz uni DCIM - Ma'lumotlar markazi infratuzilmasini boshqarish deb nomlaymiz. Garchi DCIM atamasining o'zi, aniq aytganda, yana ko'p narsalarni o'z ichiga oladi.

Bizning maqsadlarimiz uchun biz qurilma haqidagi quyidagi ma'lumotlarni unda saqlaymiz:

• Inventar raqami
• Sarlavha/tavsif
• Model (Huawei CE12800, Juniper QFX5120 va boshqalar.)
• Xarakterli parametrlar (taxtalar, interfeyslar va boshqalar.)
• Rol (Barg, orqa miya, chegara yo'riqchisi va boshqalar.)
• Manzil (viloyat, shahar, ma'lumotlar markazi, raf, birlik)
• Qurilmalar orasidagi o'zaro aloqalar
• Tarmoq topologiyasi

Bularning barchasini o'zimiz bilishni xohlayotganimiz aniq.
Lekin bu avtomatlashtirish maqsadlarida yordam beradimi?
Shubhasiz.
Misol uchun, biz bilamizki, Leaf kalitlaridagi ma'lum bir ma'lumot markazida, agar u Huawei bo'lsa, VLAN-da ma'lum trafikni filtrlash uchun ACL-lar qo'llanilishi kerak, agar u Juniper bo'lsa, u holda jismoniy interfeysning 0 blokida qo'llanilishi kerak.
Yoki mintaqadagi barcha chegaralarga yangi Syslog serverini yoyish kerak.

Unda biz virtual tarmoq qurilmalarini, masalan, virtual routerlar yoki ildiz reflektorlarini saqlaymiz. Biz DNS-serverlar, NTP, Syslog va umuman, u yoki bu tarzda tarmoqqa tegishli bo'lgan barcha narsalarni qo'shishimiz mumkin.

2-komponent: IP makonini boshqarish tizimi

Ha, va bugungi kunda Excel faylida prefikslar va IP-manzillarni kuzatib boradigan odamlar guruhlari mavjud. Biroq, zamonaviy yondashuv hali ham ma'lumotlar bazasi bo'lib, nginx/apache, API va VRF-larga bo'lingan IP-manzillar va tarmoqlarni yozib olish uchun keng funksiyalarga ega.
IPAM - IP manzillarni boshqarish.

Bizning maqsadlarimiz uchun biz unda quyidagi ma'lumotlarni saqlaymiz:

• VLANlar
• VRF
• Tarmoqlar/pastki tarmoqlar
• IP manzillar
• Manzillarni qurilmalarga, tarmoqlarni joylarga va VLAN raqamlariga ulash

Shunga qaramay, biz ToR loopback uchun yangi IP-manzilni ajratganimizda, u allaqachon kimgadir tayinlanganiga qoqilmasligimizga ishonch hosil qilishni xohlayotganimiz aniq. Yoki biz tarmoqning turli uchlarida bir xil prefiksdan ikki marta foydalanganmiz.
Ammo bu avtomatlashtirishga qanday yordam beradi?
Osonlik bilan.
Biz tizimda Loopbacks rolli prefiksni so'raymiz, unda ajratish uchun mavjud bo'lgan IP-manzillar mavjud - agar u topilsa, biz manzilni ajratamiz, bo'lmasa, yangi prefiks yaratishni so'raymiz.
Yoki qurilma konfiguratsiyasini yaratishda biz VRF interfeysi joylashgan tizimdan bilib olamiz.
Va yangi serverni ishga tushirganda, skript tizimga kiradi, server qaysi kalitda ekanligini, qaysi port va qaysi pastki tarmoq interfeysga tayinlanganligini aniqlaydi va undan server manzilini ajratadi.

Bu funksiyalarni takrorlamaslik va ikkita o'xshash ob'ektga xizmat qilmaslik uchun DCIM va IPAMni bitta tizimga birlashtirish istagini bildiradi.
Biz shunday qilamiz.

Komponent 3. Tarmoq xizmatlarini tavsiflash tizimi

Agar birinchi ikkita tizim hali ham qandaydir tarzda ishlatilishi kerak bo'lgan o'zgaruvchilarni saqlasa, uchinchisi har bir qurilma roli uchun uni qanday sozlash kerakligini tavsiflaydi.
Tarmoq xizmatlarining ikki turini ajratib ko'rsatishga arziydi:

• Infratuzilma
• Mijoz.

Birinchisi, asosiy ulanish va qurilma boshqaruvini ta'minlash uchun mo'ljallangan. Bularga VTY, SNMP, NTP, Syslog, AAA, marshrutlash protokollari, CoPP va boshqalar kiradi.
Ikkinchisi mijoz uchun xizmatni tashkil qiladi: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP va boshqalar.
Albatta, chegara holatlari ham bor - MPLS LDP, BGPni qaerga kiritish kerak? Ha, va mijozlar uchun marshrutlash protokollaridan foydalanish mumkin. Lekin bu muhim emas.

Ikkala turdagi xizmatlar ham konfiguratsiya primitivlariga ajratilgan:

• jismoniy va mantiqiy interfeyslar (teg/anteg, mtu)
• IP manzillar va VRF (IP, IPv6, VRF)
• ACL va trafikni qayta ishlash siyosati
• Protokollar (IGP, BGP, MPLS)
• Marshrutlash siyosati (prefiks ro'yxatlari, jamoalar, ASN filtrlari).
• Kommunal xizmatlar (SSH, NTP, LLDP, Syslog...)
• Va hokazo.

Buni qanday qilib aniq qilamiz, men hozircha bilmayman. Biz buni alohida maqolada ko'rib chiqamiz.

Agar hayotga biroz yaqinroq bo'lsa, biz buni tasvirlashimiz mumkin
Leaf kaliti barcha ulangan Spine kalitlari bilan BGP seanslariga ega bo'lishi, jarayonga ulangan tarmoqlarni import qilishi va faqat Spine kalitlaridan ma'lum bir prefiksdan tarmoqlarni qabul qilishi kerak. CoPP IPv6 ND ni 10 pps va hokazo bilan cheklang.
O'z navbatida, umurtqa pog'onasi ildiz reflektori vazifasini bajaradigan barcha bog'langan simlar bilan sessiyalarni o'tkazadi va ulardan faqat ma'lum uzunlikdagi va ma'lum bir jamoa bilan marshrutlarni qabul qiladi.

4-komponent: Qurilmani ishga tushirish mexanizmi

Ushbu sarlavha ostida men qurilmaning radarda paydo bo'lishi va masofadan turib kirishi uchun bajarilishi kerak bo'lgan ko'plab harakatlarni birlashtiraman.

1. Qurilmani inventarizatsiya tizimiga kiriting.
2. Boshqaruv IP manzilini tanlang.
3. Unga asosiy kirishni sozlang:
   Xost nomi, boshqaruv IP-manzili, boshqaruv tarmog'iga marshrut, foydalanuvchilar, SSH kalitlari, protokollar - telnet/SSH/NETCONF

Uchta yondashuv mavjud:

• Hammasi to'liq qo'lda. Qurilma stendga keltiriladi, u erda oddiy organik odam uni tizimlarga kiritadi, konsolga ulanadi va uni sozlaydi. Kichik statik tarmoqlarda ishlashi mumkin.
• ZTP - Zero Touch Provisioning. Uskuna keldi, o'rnidan turdi, DHCP orqali manzilni oldi, maxsus serverga o'tdi va o'zini sozladi.
• Dastlabki konfiguratsiya avtomatik rejimda konsol porti orqali amalga oshiriladigan konsol serverlari infratuzilmasi.

Uchalasi haqida alohida maqolada gaplashamiz.

Komponent 5: Sotuvchi-agnostik konfiguratsiya modeli

Hozirgacha barcha tizimlar o'zgaruvchilar va biz tarmoqda ko'rishni xohlagan narsalarning deklarativ tavsifini ta'minlaydigan bir-biridan farq qiluvchi yamoqlar edi. Ammo ertami-kechmi, siz aniqlik bilan shug'ullanishingiz kerak bo'ladi.
Ushbu bosqichda har bir aniq qurilma uchun primitivlar, xizmatlar va o'zgaruvchilar konfiguratsiya modeliga birlashtiriladi, bu aslida ma'lum bir qurilmaning to'liq konfiguratsiyasini tavsiflaydi, faqat sotuvchiga neytral tarzda.
Bu qadam nima qiladi? Nega darhol yuklab olishingiz mumkin bo'lgan qurilma konfiguratsiyasini yaratmaysiz?
Aslida, bu uchta muammoni hal qiladi:

1. Qurilma bilan ishlash uchun ma'lum bir interfeysga moslashmang. CLI, NETCONF, RESTCONF, SNMP bo'lsin - model bir xil bo'ladi.
2. Shablonlar/skriptlar sonini tarmoqdagi sotuvchilar soniga qarab saqlamang va agar dizayn o'zgarsa, bir xil narsani bir necha joyda o'zgartiring.
3. Konfiguratsiyani qurilmadan yuklang (zaxira), uni aynan bir xil modelga qo'ying va deltani hisoblash uchun maqsadli konfiguratsiyani mavjud bilan to'g'ridan-to'g'ri solishtiring va faqat kerakli qismlarni o'zgartiradigan yoki og'ishlarni aniqlaydigan konfiguratsiya yamog'ini tayyorlang.

Ushbu bosqich natijasida biz sotuvchidan mustaqil konfiguratsiyani olamiz.

Komponent 6. Sotuvchiga xos drayver interfeysi

Bir kun kelib ciskani xuddi Juniperga o'xshab, ularga xuddi shunday qo'ng'iroqlarni yuborish orqali sozlash mumkin bo'ladi degan umidda o'zingizni xushomad qilmasligingiz kerak. Oq qutilarning tobora ommalashib borishiga va NETCONF, RESTCONF, OpenConfig-ni qo'llab-quvvatlashning paydo bo'lishiga qaramay, ushbu protokollar taqdim etadigan o'ziga xos tarkib sotuvchidan sotuvchiga farq qiladi va bu ularning raqobatdosh farqlaridan biri bo'lib, ular osonlikcha taslim bo'lmaydi.
Bu NorthBound interfeysi sifatida RestAPI-ga ega bo'lgan OpenContrail va OpenStack bilan bir xil bo'lib, butunlay boshqacha qo'ng'iroqlarni kutishadi.

Shunday qilib, beshinchi bosqichda sotuvchidan mustaqil model apparatga o'tadigan shaklni olishi kerak.
Va bu erda barcha vositalar yaxshi (yo'q): CLI, NETCONF, RESTCONF, SNMP oddiygina.

Shuning uchun bizga oldingi qadam natijasini ma'lum bir ishlab chiqaruvchining kerakli formatiga o'tkazadigan drayver kerak bo'ladi: CLI buyruqlar to'plami, XML tuzilishi.

Komponent 7. Qurilmaga konfiguratsiyani yetkazib berish mexanizmi

Biz konfiguratsiyani yaratdik, lekin uni hali ham qurilmalarga etkazish kerak - va, albatta, qo'lda emas.
Birinchidan, biz qanday transportdan foydalanamiz degan savolga duch kelamiz? Va bugungi kunda tanlov endi kichik emas:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (sozlamalarni emas, balki FIBni etkazib berish usuli bo'lgani uchun bu juda katta bo'lsa ham)

Keling, bu erda t belgisini qo'yamiz. CLI - bu meros. SNMP... yo'tal yo'tal.
RESTCONF hali ham noma'lum hayvon; REST API deyarli hech kim tomonidan qo'llab-quvvatlanmaydi. Shuning uchun biz ushbu seriyada NETCONF ga e'tibor qaratamiz.

Aslida, o'quvchi allaqachon tushunganidek, biz allaqachon interfeys haqida qaror qabul qildik - oldingi bosqichning natijasi allaqachon tanlangan interfeys formatida taqdim etilgan.

Ikkinchidan, va buni qanday vositalar bilan qilamiz?
Bu erda ham katta tanlov mavjud:

• O'z-o'zidan yozilgan skript yoki platforma. Keling, ncclient va asyncIO bilan qurollanaylik va hamma narsani o'zimiz qilaylik. Joylashtirish tizimini noldan qurish bizga qancha turadi?
• Tarmoq modullarining boy kutubxonasi bilan Ansible.
• Tarmoq bilan arzimagan ishi va Napalm bilan aloqasi bilan tuz.
• Aslida bir nechta sotuvchilarni biladigan Napalm va bu, xayr.
• Nornir - biz kelajakda parchalanadigan yana bir hayvon.

Bu erda sevimli hali tanlanmagan - biz qidiramiz.

Bu erda yana nima muhim? Konfiguratsiyani qo'llash oqibatlari.
Muvaffaqiyatli yoki yo'q. Uskunaga kirish hali ham bormi yoki yo'qmi?
Aftidan, commit bu yerda qurilmaga yuklab olingan narsalarni tasdiqlash va tasdiqlashda yordam beradi.
Bu NETCONF-ni to'g'ri amalga oshirish bilan birgalikda mos qurilmalar qatorini sezilarli darajada toraytiradi - ko'pchilik ishlab chiqaruvchilar oddiy majburiyatlarni qo'llab-quvvatlamaydi. Ammo bu old shartlardan biri xolos RFP. Oxir-oqibat, hech kim birorta rus sotuvchisi 32 * 100GE interfeysi shartiga mos kelmasligidan xavotirda emas. Yoki u xavotirdami?

Komponent 8. CI/CD

Ayni paytda bizda barcha tarmoq qurilmalari uchun konfiguratsiya allaqachon tayyor.
Men "hamma narsa uchun" deb yozaman, chunki biz tarmoq holatini versiyalash haqida gapiramiz. Va agar siz faqat bitta kalit sozlamalarini o'zgartirishingiz kerak bo'lsa ham, o'zgarishlar butun tarmoq uchun hisoblanadi. Shubhasiz, ular ko'pchilik tugunlar uchun nolga teng bo'lishi mumkin.

Ammo, yuqorida aytib o'tilganidek, biz hamma narsani to'g'ridan-to'g'ri ishlab chiqarishga aylantirmoqchi bo'lgan vahshiylar emasmiz.
Yaratilgan konfiguratsiya birinchi navbatda Pipeline CI/CD orqali o'tishi kerak.

CI/CD uzluksiz integratsiya, uzluksiz joylashtirish degan ma'noni anglatadi. Bu jamoa nafaqat har olti oyda bir marta eskisini to'liq o'zgartirib, yangi yirik nashrni chiqaradi, balki muntazam ravishda kichik qismlarda yangi funksiyalarni (tartibga solish) amalga oshiradi, ularning har biri muvofiqlik, xavfsizlik va har tomonlama sinovdan o'tkaziladi. ishlash (Integratsiya).

Buning uchun bizda konfiguratsiya o'zgarishlarini kuzatuvchi versiyani boshqarish tizimi, mijoz xizmati buzilganligini tekshiradigan laboratoriya, bu faktni tekshiradigan monitoring tizimi va oxirgi qadam ishlab chiqarish tarmog'iga o'zgarishlarni tarqatishdir.

Nosozliklarni tuzatish buyruqlari bundan mustasno, tarmoqdagi barcha o'zgarishlar CI/CD quvur liniyasi orqali o'tishi kerak - bu bizning tinch hayotimiz va uzoq, baxtli martaba kafolatimizdir.

Komponent 9. Zaxira va anomaliyalarni aniqlash tizimi

Xo'sh, zaxira nusxalari haqida yana gapirishning hojati yo'q.
Biz ularni shunchaki tojga yoki git konfiguratsiyasi o'zgarganiga qarab qo'shamiz.

Ammo ikkinchi qism qiziqroq - kimdir bu zaxiralarni kuzatishi kerak. Va ba'zi hollarda, bu kimdir borib, hamma narsani avvalgidek o'zgartirishi kerak, boshqalari esa kimdirga nimadir noto'g'ri ekanligini miyovlaydi.
Misol uchun, agar o'zgaruvchilarda ro'yxatdan o'tmagan yangi foydalanuvchi paydo bo'lsa, uni hackdan olib tashlashingiz kerak. Va agar yangi xavfsizlik devori qoidasiga tegmaslik yaxshiroq bo'lsa, ehtimol kimdir nosozliklarni tuzatishni yoqdi yoki yangi xizmat, bungler qoidalarga muvofiq ro'yxatdan o'tmagan bo'lishi mumkin, lekin odamlar allaqachon unga qo'shilgan.

Har qanday avtomatlashtirish tizimlari va boshqaruvning po'lat qo'liga qaramay, biz hali ham butun tarmoq miqyosida kichik deltadan qochib qutula olmaymiz. Muammolarni tuzatish uchun hech kim tizimlarga konfiguratsiya qo'shmaydi. Bundan tashqari, ular konfiguratsiya modeliga ham kiritilmasligi mumkin.

Masalan, muammoni lokalizatsiya qilish uchun ma'lum bir IP uchun paketlar sonini hisoblash uchun xavfsizlik devori qoidasi mutlaqo oddiy vaqtinchalik konfiguratsiyadir.

Komponent 10. Monitoring tizimi

Avvaliga men monitoring mavzusini yoritmoqchi emas edim - bu hali ham katta hajmli, bahsli va murakkab mavzu. Ammo ishlar davom etar ekan, bu avtomatlashtirishning ajralmas qismi ekanligi ma'lum bo'ldi. Va hatto amaliyotsiz ham uni chetlab o'tish mumkin emas.

Rivojlanayotgan fikr CI/CD jarayonining organik qismidir. Konfiguratsiyani tarmoqqa o'tkazgandan so'ng, biz hozir hamma narsa yaxshi yoki yo'qligini aniqlashimiz kerak.
Va biz nafaqat interfeysdan foydalanish jadvallari yoki tugunlarning mavjudligi haqida emas, balki juda nozik narsalar haqida - kerakli marshrutlarning mavjudligi, ulardagi atributlar, BGP seanslari soni, OSPF qo'shnilari, End-to-End ishlashi haqida. qo'shimcha xizmatlar.
Tashqi serverga sysloglar qo'shishni to'xtatdimi yoki SFlow agenti buzildimi yoki navbatlardagi pasayishlar o'sishni boshladimi yoki ba'zi bir juft prefikslar o'rtasidagi aloqa buzildimi?

Bu haqda alohida maqolada fikr yuritamiz.

xulosa

Asos sifatida men zamonaviy ma'lumotlar markazi tarmog'i dizaynlaridan birini tanladim - marshrutlash protokoli sifatida BGP bilan L3 Clos Fabric.
Bu safar biz Juniper-da tarmoqni quramiz, chunki endi JunOs interfeysi vanlove.

Keling, faqat Ochiq manba vositalari va ko'p sotuvchilar tarmog'idan foydalanish orqali hayotimizni qiyinlashtiraylik - shuning uchun Juniperdan tashqari, men yo'lda yana bitta omadli odamni tanlayman.

Kelgusi nashrlar rejasi quyidagicha:
Avval virtual tarmoqlar haqida gapiraman. Birinchidan, men xohlayotganim uchun, ikkinchidan, busiz infratuzilma tarmog'ining dizayni juda aniq bo'lmaydi.
Keyin tarmoq dizaynining o'zi haqida: topologiya, marshrutlash, siyosatlar.
Keling, laboratoriya stendini yig'amiz.
Keling, bu haqda o'ylab ko'raylik va ehtimol tarmoqdagi qurilmani ishga tushirishni mashq qilaylik.
Va keyin har bir komponent haqida batafsil ma'lumot.

Va ha, men bu tsiklni tayyor yechim bilan chiroyli tarzda tugatishga va'da bermayman. 🙂

Foydali havolalar

• Seriyani o'rganishdan oldin, Natasha Samoilenkoning kitobini o'qishga arziydi Tarmoq muhandislari uchun Python. Va, ehtimol, o'tish albatta.
• O'qish ham foydali bo'ladi RFC Peter Lapuxov tomonidan Facebook-dan ma'lumotlar markazlari zavodlari dizayni haqida.
• Arxitektura hujjatlari sizga Overlay SDN qanday ishlashi haqida fikr beradi. Volfram mato (ilgari Open Contrail).

rahmat

Rim darasi. Fikrlar va tahrirlar uchun.
Artyom Chernobay. KDPV uchun.

Manba: www.habr.com