SDSM bitdi, amma idarəolunmaz yazmaq istəyi qalır.

Qardaşımız uzun illər rutin işlərdən, iş görməzdən əvvəl barmaqlarını keçməkdən və gecə geri çəkilmələri səbəbindən yuxusuzluqdan əziyyət çəkirdi.
Ancaq qaranlıq vaxtlar sona çatır.

Bu yazı ilə necə bir sıra başlayacağam mən avtomatlaşdırılması görünür.
Bu yolda biz avtomatlaşdırma, dəyişənlərin saxlanması, dizaynın rəsmiləşdirilməsi, RestAPI, NETCONF, YANG, YDK mərhələlərini başa düşəcəyik və bir çox proqramlaşdırma edəcəyik.
Mən o deməkdir ki, a) obyektiv həqiqət deyil, b) qeyd-şərtsiz ən yaxşı yanaşma deyil, c) mənim fikrim, hətta birinci məqalədən axırıncı məqaləyə keçid zamanı belə dəyişə bilər - düzünü desək, layihə mərhələsindən nəşr, hər şeyi iki dəfə tamamilə yenidən yazdım.

Məzmun

1. Məqsədlər
   1. Şəbəkə tək bir orqanizm kimidir
   2. Konfiqurasiya testi
   3. Versiyalaşdırma
   4. Xidmətlərin monitorinqi və özünü sağalması

2. Fondlar
   1. İnventar sistemi
   2. IP məkan idarəetmə sistemi
   3. Şəbəkə xidmətinin təsviri sistemi
   4. Cihazın işə salınması mexanizmi
   5. Satıcı-aqnostik konfiqurasiya modeli
   6. Satıcıya məxsus sürücü interfeysi
   7. Konfiqurasiyanın cihaza çatdırılması mexanizmi
   8. CI / CD
   9. Yedəkləmə və sapmaların axtarışı mexanizmi
   10. Monitorinq sistemi

3. Nəticə

ADSM-ni SDSM-dən bir qədər fərqli formatda keçirməyə çalışacağam. Böyük, ətraflı, nömrələnmiş məqalələr görünməyə davam edəcək və onların arasında gündəlik təcrübədən kiçik qeydlər dərc edəcəyəm. Mən burada mükəmməlliyə qarşı mübarizə aparmağa çalışacağam və onların hər birini yalamayacağam.

Necə də gülməli odur ki, ikinci dəfə eyni yoldan keçməli olursan.

Əvvəlcə RuNet-də olmadığı üçün şəbəkələr haqqında məqalələr yazmalı oldum.

İndi avtomatlaşdırmaya yanaşmaları sistemləşdirən və yuxarıda göstərilən texnologiyaları sadə praktik nümunələrdən istifadə edərək təhlil edən hərtərəfli sənəd tapa bilmədim.

Mən səhv edə bilərəm, ona görə də faydalı mənbələrə keçid verin. Ancaq bu, mənim yazmaq əzmimi dəyişməyəcək, çünki əsas məqsəd özüm nəsə öyrənməkdir və başqalarının həyatını asanlaşdırmaq təcrübə mübadiləsi genini sığallayan xoş bonusdur.

Biz orta ölçülü LAN DC məlumat mərkəzini götürməyə və bütün avtomatlaşdırma sxemini işləməyə çalışacağıq.
Demək olar ki, ilk dəfə sizinlə bəzi şeylər edəcəm.

Mən burada təsvir olunan fikir və vasitələrdə orijinal olmayacağam. Dmitri Fiqol əladır bu mövzuda axınları olan kanal.
Məqalələr bir çox cəhətdən onlarla üst-üstə düşəcək.

LAN DC-də 4 DC, təxminən 250 açar, yarım düzənləndirici və bir neçə firewall var.
Facebook deyil, ancaq avtomatlaşdırma haqqında dərindən düşünməyə vadar etmək üçün kifayətdir.
Bununla belə, bir fikir var ki, 1-dən çox cihazınız varsa, avtomatlaşdırma artıq lazımdır.
Əslində, indi hər kəsin ən azı diz skriptləri olmadan yaşaya biləcəyini təsəvvür etmək çətindir.
Baxmayaraq ki, Excel-də IP ünvanlarının saxlandığı ofislər var və minlərlə şəbəkə qurğusunun hər biri əl ilə konfiqurasiya edilir və özünəməxsus konfiqurasiyaya malikdir. Bu, əlbəttə ki, müasir sənət kimi qəbul edilə bilər, lakin mühəndisin hissləri mütləq inciyəcəkdir.

Məqsədlər

İndi ən mücərrəd məqsədləri təyin edəcəyik:

• Şəbəkə tək bir orqanizm kimidir
• Konfiqurasiya testi
• Şəbəkə vəziyyəti versiyası
• Xidmətlərin monitorinqi və özünü sağalması

Daha sonra bu yazıda hansı vasitələrdən istifadə edəcəyimizə baxacağıq, bundan sonra isə məqsəd və vasitələri ətraflı nəzərdən keçirəcəyik.

Şəbəkə tək bir orqanizm kimidir

İlk baxışdan o qədər də əhəmiyyətli görünməsə də, seriyanın təyinedici ifadəsi: biz fərdi cihazları deyil, şəbəkəni konfiqurasiya edəcəyik.
Son illərdə biz şəbəkəyə vahid bir qurum kimi baxmağa diqqətin dəyişdiyini gördük, buna görə də Proqram Təminatı Şəbəkəsi, Niyyətə əsaslanan şəbəkələr и Avtonom şəbəkələr.
Axı, tətbiqlərə qlobal olaraq şəbəkədən nə lazımdır: A və B nöqtələri arasında əlaqə (yaxşı, bəzən +B-Z) və digər tətbiqlərdən və istifadəçilərdən təcrid.

Və bu seriyadakı vəzifəmiz belədir sistem qurmaq, cari konfiqurasiyanın saxlanması bütün şəbəkə, artıq hər bir cihazda öz roluna və yerinə uyğun olaraq faktiki konfiqurasiyaya parçalanmışdır.
Система şəbəkə idarəetməsi o deməkdir ki, dəyişiklik etmək üçün onunla əlaqə saxlayırıq və o, öz növbəsində hər bir cihaz üçün istənilən vəziyyəti hesablayır və onu konfiqurasiya edir.
Bu yolla, biz CLI-yə əl ilə girişi demək olar ki, sıfıra endirdik - cihaz parametrlərində və ya şəbəkə dizaynında hər hansı dəyişikliklər rəsmiləşdirilməli və sənədləşdirilməlidir - və yalnız bundan sonra lazımi şəbəkə elementlərinə ötürülür.

Yəni, məsələn, biz qərara alsaq ki, bundan sonra Kazanda rack açarları bir əvəzinə iki şəbəkə elan etməlidir, biz

1. Əvvəlcə sistemlərdəki dəyişiklikləri sənədləşdiririk
2. Bütün şəbəkə cihazlarının hədəf konfiqurasiyasının yaradılması
3. Şəbəkə konfiqurasiyasını yeniləmək proqramını işə salırıq, bu proqram hər bir qovşaqda nəyin silinməli olduğunu, nə əlavə ediləcəyini hesablayır və qovşaqları istədiyiniz vəziyyətə gətirir.

Eyni zamanda, biz yalnız ilk addımda əl ilə dəyişikliklər edirik.

Konfiqurasiya testi

Məlumdurproblemlərin 80% konfiqurasiya dəyişiklikləri zamanı baş verir - bunun dolayı sübutu Yeni il tətillərində hər şeyin adətən sakit olmasıdır.
Mən şəxsən insan səhvinə görə onlarla qlobal dayanmaların şahidi olmuşam: səhv əmr, konfiqurasiya səhv filialda yerinə yetirilib, cəmiyyət unudub, MPLS routerdə qlobal miqyasda sökülüb, beş ədəd aparat konfiqurasiya edilib, lakin xəta baş vermədi. Altıncısında fərq edilən köhnə dəyişikliklər başqa bir şəxs tərəfindən edildi. Bir ton ssenari var.

Avtomatlaşdırma bizə daha az səhv etməyə imkan verəcək, lakin daha geniş miqyasda. Beləliklə, bir anda yalnız bir cihazı deyil, bütün şəbəkəni kərpic edə bilərsiniz.

Qədim dövrlərdən bəri babalarımız iti gözlə edilən dəyişikliklərin düzgünlüyünü, polad topları və şəbəkənin funksionallığını yuvarladıqdan sonra yoxlayırdılar.
İşi fasilələrə və fəlakətli itkilərə səbəb olan babalar daha az nəsil buraxdılar və zaman keçdikcə ölməlidirlər, lakin təkamül yavaş bir prosesdir və buna görə də hamı hələ də ilk növbədə dəyişiklikləri laboratoriyada sınaqdan keçirmir.
Bununla belə, tərəqqinin önündə konfiqurasiyanın sınaqdan keçirilməsi prosesini və onun şəbəkəyə sonrakı tətbiqini avtomatlaşdıranlar dayanır. Başqa sözlə, mən CI/CD prosedurunu götürmüşəm (Davamlı İnteqrasiya, Davamlı Yerləşdirmə) tərtibatçılardan.
Hissələrdən birində bunun versiyaya nəzarət sistemindən, ehtimal ki, Github-dan istifadə edərək necə həyata keçiriləcəyinə baxacağıq.

Şəbəkə CI/CD ideyasına öyrəşdikdən sonra bir gecədə konfiqurasiyanı istehsal şəbəkəsinə tətbiq etməklə yoxlamaq üsulu erkən orta əsrlərin cəhaləti kimi görünəcək. Bir növ döyüş başlığını çəkiclə vurmaq kimi.

haqqında fikirlərin üzvi davamı sistem şəbəkə idarəetməsi və CI/CD konfiqurasiyanın tam versiyasına çevrilir.

Versiyalaşdırma

Hər hansı bir dəyişikliklə, hətta ən kiçik dəyişikliklərlə, hətta bir görünməz cihazda belə, bütün şəbəkənin bir vəziyyətdən digərinə keçdiyini güman edəcəyik.
Və biz həmişə cihazda əmr yerinə yetirmirik, şəbəkənin vəziyyətini dəyişirik.
Beləliklə, bu dövlətləri versiyalar adlandıraq?

Deyək ki, cari versiya 1.0.0-dır.
ToR-lərdən birində Loopback interfeysinin IP ünvanı dəyişibmi? Bu kiçik versiyadır və 1.0.1 nömrələnəcək.
BGP-yə marşrutların idxalı siyasətlərinə yenidən baxdıq - bir az daha ciddi - artıq 1.1.0
Biz IGP-dən qurtulmaq və yalnız BGP-yə keçmək qərarına gəldik - bu, artıq dizaynda köklü dəyişiklikdir - 2.0.0.

Eyni zamanda, müxtəlif DC-lərin müxtəlif versiyaları ola bilər - şəbəkə inkişaf edir, yeni avadanlıq quraşdırılır, başqalarında yox, haradasa yeni səviyyəli onurğalar əlavə olunur və s.

haqqında semantik versiyalaşdırma ayrı bir məqalədə danışacağıq.

Təkrar edirəm - hər hansı bir dəyişiklik (sazlama əmrləri istisna olmaqla) bir versiya yeniləməsidir. Mövcud versiyadan hər hansı sapma barədə administratorlara məlumat verilməlidir.

Eyni şey dəyişikliklərin geri qaytarılmasına da aiddir - bu, son əmrləri ləğv etmir, bu cihazın əməliyyat sistemindən istifadə edərək geri qaytarma deyil - bu, bütün şəbəkəni yeni (köhnə) versiyaya gətirir.

Xidmətlərin monitorinqi və özünü sağalması

Bu öz-özünə aydın olan vəzifə müasir şəbəkələrdə yeni səviyyəyə çatmışdır.
Çox vaxt böyük xidmət təminatçıları nə baş verdiyini anlamaq əvəzinə, uğursuz bir xidmətin çox tez düzəldilməli və yenisini qaldırmalı olduğu yanaşmasını qəbul edirlər.
"Çox" o deməkdir ki, saniyələr ərzində normadan ən kiçik sapmaları aşkar edəcək monitorinqlə hər tərəfdən səxavətlə örtülməlisiniz.
Və burada interfeys yüklənməsi və ya node mövcudluğu kimi adi ölçülər artıq kifayət deyil. Növbətçinin onlara əllə nəzarət etməsi də kifayət etmir.
Çox şeylər üçün olmalıdır Özünü müalicə — monitorinq işıqları qırmızı oldu və biz gedib bağayarpağı ağrıyan yerə özümüz vurduq.

Və burada biz həm də təkcə fərdi cihazların deyil, həm də bütün şəbəkənin sağlamlığını, həm nisbətən başa düşülən ağ qutunun, həm də daha mürəkkəb olan qara qutunun sağlamlığını izləyirik.

Belə iddialı planları həyata keçirmək üçün bizə nə lazımdır?

• Şəbəkədəki bütün cihazların siyahısı, onların yeri, rolları, modelləri, proqram versiyaları var.
  kazan-leaf-1.lmu.net, Kazan, yarpaq, Juniper QFX 5120, R18.3.
• Şəbəkə xidmətlərini təsvir etmək üçün bir sistemə sahib olun.
  IGP, BGP, L2/3VPN, Siyasət, ACL, NTP, SSH.
• Cihazı işə salmağı bacarın.
  Host adı, Mgmt IP, Mgmt Route, İstifadəçilər, RSA-Keys, LLDP, NETCONF
• Cihazı konfiqurasiya edin və konfiqurasiyanı istədiyiniz (köhnə daxil olmaqla) versiyaya gətirin.
• Test konfiqurasiyası
• Dövri olaraq bütün cihazların vəziyyətini mövcud olanlardan sapmalara görə yoxlayın və kimə olması lazım olduğunu bildirin.
  Gecədə kimsə sakitcə ACL-ə bir qayda əlavə etdi.
• Performans monitorinqi.

Fondlar

Layihəni komponentlərə ayırmağa başlamaq üçün kifayət qədər mürəkkəb səslənir.

Və onlardan on olacaq:

1. İnventar sistemi
2. IP məkan idarəetmə sistemi
3. Şəbəkə xidmətinin təsviri sistemi
4. Cihazın işə salınması mexanizmi
5. Satıcı-aqnostik konfiqurasiya modeli
6. Satıcıya məxsus sürücü interfeysi
7. Konfiqurasiyanın cihaza çatdırılması mexanizmi
8. CI / CD
9. Yedəkləmə və sapmaların axtarışı mexanizmi
10. Monitorinq sistemi

Yeri gəlmişkən, bu, tsiklin məqsədlərinə baxışın necə dəyişdiyinə bir nümunədir - layihədə 4 komponent var idi.

Təsvirdə mən bütün komponentləri və cihazın özünü təsvir etdim.
Kesişən komponentlər bir-biri ilə qarşılıqlı əlaqədə olur.
Blok nə qədər böyükdürsə, bu komponentə daha çox diqqət yetirilməlidir.

Komponent 1: İnventar sistemi

Aydındır ki, hansı avadanlıqların harada yerləşdiyini, nəyə qoşulduğunu bilmək istəyirik.
İnventarlaşdırma sistemi istənilən müəssisənin ayrılmaz hissəsidir.
Çox vaxt müəssisənin şəbəkə cihazları üçün ayrıca inventar sistemi var ki, bu da daha konkret problemləri həll edir.
Bu məqalələr silsiləsinin bir hissəsi olaraq biz onu DCIM - Məlumat Mərkəzi İnfrastrukturunun İdarə edilməsi adlandıracağıq. Baxmayaraq ki, DCIM termini özü daha çox şeyi ehtiva edir.

Məqsədlərimiz üçün cihaz haqqında aşağıdakı məlumatları orada saxlayacağıq:

• Envanter nömrəsi
• Başlıq/Təsvir
• Model (Huawei CE12800, Juniper QFX5120 və s.)
• Xarakterik parametrlər (lövhələr, interfeyslər və s.)
• Rol (Leaf, Spine, Border Router və s.)
• Məkan (rayon, şəhər, məlumat mərkəzi, rəf, vahid)
• Cihazlar arasında qarşılıqlı əlaqə
• Şəbəkə topologiyası

Tamamilə aydındır ki, biz özümüz bütün bunları bilmək istəyirik.
Amma bu avtomatlaşdırma məqsədləri üçün kömək edəcəkmi?
Əlbəttə.
Məsələn, biz bilirik ki, Leaf açarlarında müəyyən bir məlumat mərkəzində, əgər Huawei-dirsə, müəyyən trafiki süzmək üçün ACL-lər VLAN-da, Juniper-dirsə, fiziki interfeysin 0 vahidində tətbiq edilməlidir.
Və ya regionun bütün sərhədlərinə yeni Syslog serverini yaymaq lazımdır.

Orada virtual şəbəkə cihazlarını, məsələn, virtual marşrutlaşdırıcılar və ya kök reflektorları saxlayacağıq. DNS serverləri, NTP, Syslog və ümumiyyətlə şəbəkəyə bu və ya digər şəkildə aid olan hər şeyi əlavə edə bilərik.

Komponent 2: IP məkanının idarə edilməsi sistemi

Bəli və bu gün Excel faylında prefiksləri və IP ünvanlarını izləyən insanlardan ibarət komandalar var. Lakin müasir yanaşma hələ də nginx/apache, API və IP ünvanlarını və VRF-lərə bölünmüş şəbəkələri qeyd etmək üçün geniş funksiyaları olan bir verilənlər bazasıdır.
IPAM - IP ünvanının idarə edilməsi.

Məqsədlərimiz üçün biz aşağıdakı məlumatları orada saxlayacağıq:

• VLAN
• VRF
• Şəbəkələr/Alt şəbəkələr
• IP ünvanları
• Ünvanları cihazlara, şəbəkələri yerlərə və VLAN nömrələrinə bağlamaq

Yenə də aydındır ki, biz ToR geri dönüşü üçün yeni bir IP ünvanı ayırdığımız zaman onun artıq kiməsə təyin olunduğuna görə büdrəməyəcəyimizə əmin olmaq istəyirik. Və ya şəbəkənin müxtəlif uclarında eyni prefiksi iki dəfə istifadə etdiyimizi.
Bəs bu avtomatlaşdırmaya necə kömək edir?
Bu asandır.
Biz sistemdə geriyə dönmə rolu ilə prefiks tələb edirik, burada bölüşdürülməsi üçün mövcud olan IP ünvanları var - əgər tapılarsa, biz ünvanı ayırırıq, yoxsa, yeni prefiksin yaradılmasını xahiş edirik.
Və ya cihaz konfiqurasiyasını yaratarkən, interfeysin VRF-nin yerləşdiyi eyni sistemdən öyrənə bilərik.
Və yeni bir server işə saldıqda, skript sistemə daxil olur, serverin hansı keçiddə olduğunu, hansı portun və hansı alt şəbəkənin interfeysə təyin edildiyini öyrənir və server ünvanını ondan ayıracaqdır.

Bu, funksiyaları təkrarlamamaq və iki oxşar quruma xidmət etməmək üçün DCIM və IPAM-ı bir sistemdə birləşdirmək istəyini göstərir.
Biz bunu edəcəyik.

Komponent 3. Şəbəkə xidmətlərinin təsviri sistemi

Əgər ilk iki sistem hələ də hansısa şəkildə istifadə edilməli olan dəyişənləri saxlayırsa, üçüncüsü hər bir cihaz rolu üçün onun necə konfiqurasiya edilməli olduğunu təsvir edir.
Şəbəkə xidmətlərinin iki müxtəlif növünü ayırmağa dəyər:

• İnfrastruktur
• Müştəri.

Birincilər əsas əlaqə və cihaz nəzarətini təmin etmək üçün nəzərdə tutulmuşdur. Bunlara VTY, SNMP, NTP, Syslog, AAA, marşrutlaşdırma protokolları, CoPP və s.
Sonuncu müştəri üçün xidməti təşkil edir: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP və s.
Əlbəttə ki, sərhəd halları da var - MPLS LDP, BGP hara daxil edilməlidir? Bəli və marşrutlaşdırma protokolları müştərilər üçün istifadə edilə bilər. Amma bu vacib deyil.

Hər iki xidmət növü konfiqurasiya primitivlərinə bölünür:

• fiziki və məntiqi interfeyslər (tag/anteg, mtu)
• IP ünvanları və VRF (IP, IPv6, VRF)
• ACL və trafik emal siyasətləri
• Protokollar (IGP, BGP, MPLS)
• Marşrutlaşdırma siyasətləri (prefiks siyahıları, icmalar, ASN filtrləri).
• Kommunal xidmətlər (SSH, NTP, LLDP, Syslog...)
• və s.

Bunu necə dəqiq edəcəyik, hələ ki, heç bir fikrim yoxdur. Biz bunu ayrı bir məqalədə nəzərdən keçirəcəyik.

Həyata bir az yaxın olsaq, bunu təsvir edə bilərik
Leaf keçidində bütün qoşulmuş Spine açarları ilə BGP seansları olmalıdır, qoşulmuş şəbəkələri prosesə idxal etməli və yalnız Spine açarlarından müəyyən bir prefiksdən olan şəbəkələri qəbul etməlidir. CoPP IPv6 ND-ni 10 pps ilə məhdudlaşdırın və s.
Öz növbəsində, onurğalar kök reflektorları kimi fəaliyyət göstərən bütün əlaqəli aparıcılarla seanslar keçirir və onlardan yalnız müəyyən uzunluqda və müəyyən bir icma ilə marşrutları qəbul edir.

Komponent 4: Cihazın işə salınması mexanizmi

Bu başlıq altında bir cihazın radarda görünməsi və uzaqdan əldə edilməsi üçün baş verməli olan bir çox hərəkətləri birləşdirirəm.

1. Cihazı inventar sisteminə daxil edin.
2. İdarəetmə IP ünvanını seçin.
3. Ona əsas girişi qurun:
   Host adı, idarəetmə IP ünvanı, idarəetmə şəbəkəsinə marşrut, istifadəçilər, SSH açarları, protokollar - telnet/SSH/NETCONF

Üç yanaşma var:

• Hər şey tamamilə manueldir. Cihaz stendə gətirilir, burada adi bir orqanik şəxs onu sistemlərə daxil edəcək, konsola qoşulacaq və konfiqurasiya edəcəkdir. Kiçik statik şəbəkələrdə işləyə bilər.
• ZTP - Zero Touch Provisioning. Aparat gəldi, ayağa qalxdı, DHCP vasitəsilə ünvan aldı, xüsusi serverə getdi və özünü konfiqurasiya etdi.
• İlkin konfiqurasiyanın avtomatik rejimdə konsol portu vasitəsilə baş verdiyi konsol serverlərinin infrastrukturu.

Hər üçü haqqında ayrı bir məqalədə danışacağıq.

Komponent 5: Satıcı-aqnostik konfiqurasiya modeli

İndiyə qədər bütün sistemlər dəyişənləri və şəbəkədə görmək istədiklərimizin deklarativ təsvirini təmin edən fərqli yamaqlardır. Ancaq gec və ya tez, konkret məqamlarla məşğul olmalı olacaqsınız.
Bu mərhələdə, hər bir xüsusi cihaz üçün primitivlər, xidmətlər və dəyişənlər, yalnız satıcı üçün neytral şəkildə, konkret cihazın tam konfiqurasiyasını əslində təsvir edən konfiqurasiya modelinə birləşdirilir.
Bu addım nə edir? Niyə dərhal yükləyə biləcəyiniz bir cihaz konfiqurasiyasını yaratmayasınız?
Əslində, bu üç problemi həll edir:

1. Cihazla qarşılıqlı əlaqə üçün xüsusi interfeysə uyğunlaşmayın. CLI, NETCONF, RESTCONF, SNMP olsun - model eyni olacaq.
2. Şablonların/skriptlərin sayını şəbəkədəki satıcıların sayına uyğun saxlamayın və dizayn dəyişərsə, eyni şeyi bir neçə yerdə dəyişdirin.
3. Konfiqurasiyanı cihazdan yükləyin (ehtiyat nüsxə), onu tam olaraq eyni modelə qoyun və deltanı hesablamaq üçün hədəf konfiqurasiyanı mövcud olanla birbaşa müqayisə edin və yalnız zəruri olan hissələri dəyişdirəcək və ya sapmaları müəyyən edəcək bir konfiqurasiya yaması hazırlayın.

Bu mərhələnin nəticəsi olaraq biz satıcıdan müstəqil konfiqurasiya əldə edirik.

Komponent 6. Satıcıya məxsus sürücü interfeysi

Bir gün ciska-nı Juniper kimi eyni şəkildə konfiqurasiya etmək, sadəcə olaraq onlara eyni zəngləri göndərməklə mümkün olacağına ümidlə özünüzü yaltaqlamamalısınız. Ağ qutuların artan populyarlığına və NETCONF, RESTCONF, OpenConfig dəstəyinin yaranmasına baxmayaraq, bu protokolların təqdim etdiyi spesifik məzmun satıcıdan satıcıya fərqlənir və bu, onların rəqabət fərqlərindən biridir ki, onlar asanlıqla imtina etməyəcəklər.
Bu, NorthBound interfeysi kimi RestAPI olan OpenContrail və OpenStack ilə təxminən eynidir, tamamilə fərqli zənglər gözləyir.

Beləliklə, beşinci addımda satıcıdan asılı olmayan model aparata keçəcəyi formanı almalıdır.
Və burada bütün vasitələr yaxşıdır (yox): CLI, NETCONF, RESTCONF, SNMP sadəcə.

Buna görə də, əvvəlki addımın nəticəsini müəyyən bir satıcının tələb olunan formatına köçürəcək bir sürücüyə ehtiyacımız olacaq: CLI əmrləri dəsti, XML strukturu.

Komponent 7. Konfiqurasiyanın cihaza çatdırılması mexanizmi

Konfiqurasiyanı yaratdıq, lakin hələ də cihazlara çatdırılmalıdır - və açıq şəkildə əl ilə deyil.
Əvvəla, hansı nəqliyyatdan istifadə edəcəyik sualı ilə qarşılaşırıq? Və bu gün seçim artıq kiçik deyil:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (baxmayaraq ki, bu, parametrləri deyil, FIB-ni çatdırmaq üçün bir yoldur, çünki bu, həddindən artıqdır)

Gəlin burada t hərfini qeyd edək. CLI mirasdır. SNMP... öskürək öskürək.
RESTCONF hələ də naməlum heyvandır; REST API demək olar ki, heç kim tərəfindən dəstəklənmir. Buna görə də seriyada NETCONF üzərində dayanacağıq.

Əslində, oxucunun artıq başa düşdüyü kimi, bu nöqtəyə qədər biz artıq interfeysə qərar vermişik - əvvəlki addımın nəticəsi artıq seçilmiş interfeys formatında təqdim olunur.

İkincisivə bunu hansı alətlərlə edəcəyik?
Burada da böyük seçim var:

• Öz-özünə yazılmış skript və ya platforma. Gəlin özümüzü ncclient və asyncIO ilə silahlandıraq və hər şeyi özümüz edək. Yerləşdirmə sistemini sıfırdan qurmaq bizə nəyə başa gəlir?
• Zəngin şəbəkə modulları kitabxanası ilə Ansible.
• Şəbəkə ilə cüzi işi və Napalm ilə əlaqəsi ilə duz.
• Əslində bir neçə satıcı tanıyan Napalm və bu qədər, əlvida.
• Nornir gələcəkdə parçalayacağımız başqa bir heyvandır.

Burada sevimli hələ seçilməyib - biz axtaracağıq.

Burada başqa nə vacibdir? Konfiqurasiyanın tətbiqinin nəticələri.
Uğurlu ya yox. Hələ də aparata giriş var, ya yox?
Görünür, commit cihaza endirilənlərin təsdiqi və təsdiqi ilə burada kömək edəcək.
Bu, NETCONF-in düzgün tətbiqi ilə birlikdə, uyğun cihazların çeşidini əhəmiyyətli dərəcədə daraldır - bir çox istehsalçı normal öhdəlikləri dəstəkləmir. Ancaq bu, ilkin şərtlərdən yalnız biridir RFP. Nəhayət, heç kim heç bir rus satıcısının 32*100GE interfeys şərtinə əməl etməyəcəyindən narahat deyil. Yoxsa narahatdır?

Komponent 8. CI/CD

Bu nöqtədə artıq bütün şəbəkə cihazları üçün konfiqurasiyamız hazırdır.
Mən “hər şey üçün” yazıram, çünki biz şəbəkə vəziyyətinin versiyalaşdırılmasından danışırıq. Yalnız bir keçidin parametrlərini dəyişdirmək lazım olsa belə, dəyişikliklər bütün şəbəkə üçün hesablanır. Aydındır ki, əksər qovşaqlar üçün onlar sıfır ola bilər.

Ancaq yuxarıda deyildiyi kimi, biz hər şeyi birbaşa istehsala çevirmək istəyən bir növ barbar deyilik.
Yaradılmış konfiqurasiya əvvəlcə Pipeline CI/CD-dən keçməlidir.

CI/CD Continuous Integration, Continuous Deployment deməkdir. Bu, komandanın nəinki hər altı aydan bir köhnəsini tamamilə əvəz edən yeni əsas buraxılışı buraxdığı, həm də mütəmadi olaraq kiçik hissələrdə yeni funksionallığı (Yerləşdirmə) təqdim etdiyi bir yanaşmadır, hər biri uyğunluq, təhlükəsizlik və təhlükəsizlik baxımından hərtərəfli sınaqdan keçirilir. performans (İnteqrasiya).

Bunun üçün konfiqurasiya dəyişikliklərinə nəzarət edən versiyaya nəzarət sistemimiz, müştəri xidmətinin pozulduğunu yoxlayan laboratoriyamız, bu faktı yoxlayan monitorinq sistemimiz var və son addım dəyişiklikləri istehsal şəbəkəsinə yaymaqdır.

Sazlama əmrləri istisna olmaqla, şəbəkədə tamamilə bütün dəyişikliklər CI/CD Boru Kəmərindən keçməlidir - bu, bizim sakit həyat və uzun, xoşbəxt karyera zəmanətimizdir.

Komponent 9. Ehtiyat və anomaliyaların aşkarlanması sistemi

Yenə də ehtiyat nüsxələri haqqında danışmağa ehtiyac yoxdur.
Biz onları sadəcə olaraq taca görə və ya konfiqurasiya dəyişikliyi faktına uyğun olaraq git-ə qoyacağıq.

Ancaq ikinci hissə daha maraqlıdır - kimsə bu ehtiyat nüsxələrə diqqət yetirməlidir. Və bəzi hallarda, bu kimsə gedib hər şeyi olduğu kimi döndərməlidir, bəzilərində isə kiməsə nəyinsə səhv olduğunu miyovlamalıdır.
Məsələn, dəyişənlərdə qeydiyyatdan keçməmiş yeni istifadəçi yaranıbsa, onu hackdən uzaqlaşdırmalısınız. Yeni bir firewall qaydasına toxunmamaq daha yaxşıdırsa, bəlkə kimsə sadəcə sazlamağı işə salıb və ya ola bilsin ki, yeni xidmət, quldur, qaydalara uyğun olaraq qeydiyyatdan keçməyib, amma insanlar artıq ona qoşulublar.

Hər hansı avtomatlaşdırma sistemlərinə və idarəetmənin polad əlinə baxmayaraq, biz hələ də bütün şəbəkə miqyasında bəzi kiçik deltalardan qaça bilməyəcəyik. Problemləri aradan qaldırmaq üçün heç kim sistemlərə konfiqurasiya əlavə etməyəcək. Üstəlik, onlar hətta konfiqurasiya modelinə daxil edilməyə də bilər.

Məsələn, problemi lokallaşdırmaq üçün xüsusi IP-yə düşən paketlərin sayını hesablamaq üçün təhlükəsizlik divarı qaydası tamamilə adi müvəqqəti konfiqurasiyadır.

Komponent 10. Monitorinq sistemi

Əvvəlcə monitorinq mövzusunu işıqlandırmaq fikrində deyildim - bu, hələ də həcmli, mübahisəli və mürəkkəb mövzudur. Lakin işlər irəlilədikcə məlum oldu ki, bu, avtomatlaşdırmanın ayrılmaz hissəsidir. Təcrübəsiz də ondan yan keçmək mümkün deyil.

İnkişaf edən Düşüncə CI/CD prosesinin üzvi hissəsidir. Konfiqurasiyanı şəbəkəyə köçürdükdən sonra hər şeyin onunla uyğun olub olmadığını müəyyən edə bilməliyik.
Və biz təkcə interfeysdən istifadə cədvəlləri və ya qovşaqların mövcudluğu haqqında deyil, həm də daha incə şeylər haqqında - lazımi marşrutların mövcudluğu, onlarda atributlar, BGP seanslarının sayı, OSPF qonşuları, End-to-End performansı haqqında danışırıq. üst-üstə düşən xidmətlər.
Xarici serverə sistem qeydləri əlavə etməyi dayandırdı, yoxsa SFlow agenti xarab oldu, yoxsa növbələrdə azalmalar artmağa başladı, yoxsa bəzi cüt prefikslər arasında əlaqə pozuldu?

Bu barədə ayrı bir məqalədə fikirləşəcəyik.

Nəticə

Əsas olaraq müasir məlumat mərkəzi şəbəkə dizaynlarından birini - marşrutlaşdırma protokolu kimi BGP ilə L3 Clos Fabric seçdim.
Bu dəfə biz şəbəkəni Juniper üzərində quracağıq, çünki indi JunOs interfeysi vanlove-dir.

Gəlin yalnız Açıq Mənbə alətləri və çoxlu təchizatçı şəbəkəsindən istifadə etməklə həyatımızı çətinləşdirək - ona görə də Juniper-ə əlavə olaraq, yol boyu daha bir şanslı insan seçəcəyəm.

Qarşıdakı nəşrlər üçün plan belədir:
Əvvəlcə virtual şəbəkələr haqqında danışacağam. Əvvəla, ona görə ki, mən istəyirəm, ikincisi, ona görə ki, bunsuz infrastruktur şəbəkəsinin dizaynı çox aydın olmayacaq.
Sonra şəbəkə dizaynının özü haqqında: topologiya, marşrutlaşdırma, siyasətlər.
Laboratoriya stendini yığaq.
Gəlin bu barədə düşünək və bəlkə də cihazı şəbəkədə işə salmağa məşq edək.
Və sonra hər bir komponent haqqında intim detallarla.

Bəli, hazır həll yolu ilə bu dövrü zərif şəkildə bitirəcəyimə söz vermirəm. 🙂

Faydalı linklər

• Seriala keçməzdən əvvəl Nataşa Samoilenkonun kitabını oxumağa dəyər Şəbəkə Mühəndisləri üçün Python. Və bəlkə də keçin kurs.
• Oxumaq da faydalı olacaq RFC Peter Lapuxov tərəfindən Facebook-dan məlumat mərkəzi fabriklərinin dizaynı haqqında.
• Memarlıq sənədləri sizə Overlay SDN-nin necə işlədiyi barədə fikir verəcəkdir. Volfram parça (əvvəllər Open Contrail).

təşəkkürlər

Roman dərəsi. Şərhlər və redaktələr üçün.
Artyom Çernobay. KDPV üçün.

Mənbə: www.habr.com