SDSM je gotov, ali ostaje nekontrolisana želja za pisanjem.

Naš brat je dugi niz godina patio od obavljanja rutinskih poslova, ukrštanja prstiju prije obaveza i nedostatka sna zbog noćnih vraćanja.
Ali mračna vremena se bliže kraju.

Ovim člankom ću započeti seriju o tome kako ja vidi se automatizacija.
Usput ćemo razumeti faze automatizacije, skladištenja varijabli, formalizovanja dizajna, RestAPI, NETCONF, YANG, YDK i uradićemo dosta programiranja.
Meni znači da a) nije objektivna istina, b) nije bezuslovno najbolji pristup, c) moje mišljenje, čak i tokom kretanja od prvog do poslednjeg članka, može da se promeni - da budem iskren, od faze nacrta do publikacije, dva puta sam sve potpuno prepisao.

Sadržaj

1. Ciljevi
   1. Mreža je kao jedan organizam
   2. Testiranje konfiguracije
   3. Versioniranje
   4. Praćenje i samoizlječenje usluga

2. Sredstva
   1. Sistem inventara
   2. IP sistem upravljanja prostorom
   3. Sistem opisa mrežnih usluga
   4. Mehanizam inicijalizacije uređaja
   5. Model konfiguracije bez obzira na dobavljač
   6. Interfejs drajvera specifičan za proizvođača
   7. Mehanizam za isporuku konfiguracije na uređaj
   8. CI / CD
   9. Mehanizam za backup i traženje odstupanja
   10. Nadzorni sistem

3. zaključak

Pokušat ću voditi ADSM u formatu malo drugačijem od SDSM-a. I dalje će se pojavljivati ​​veliki, detaljni, numerirani članci, a između njih ću objavljivati ​​male bilješke iz svakodnevnog iskustva. Pokušat ću se ovdje boriti protiv perfekcionizma i ne lizati svakog od njih.

Kako je smiješno da drugi put moraš proći istim putem.

U početku sam morao sam pisati članke o mrežama zbog činjenice da nisu bile na RuNetu.

Sada nisam mogao pronaći sveobuhvatan dokument koji bi sistematizovao pristupe automatizaciji i analizirao gore navedene tehnologije koristeći jednostavne praktične primjere.

Možda griješim, pa vas molim da dostavite linkove na korisne resurse. Međutim, to neće promijeniti moju odlučnost da pišem, jer je glavni cilj da i sam nešto naučim, a olakšati život drugima je ugodan bonus koji miluje gen za dijeljenje iskustva.

Pokušat ćemo uzeti LAN DC podatkovni centar srednje veličine i razraditi cijelu shemu automatizacije.
Radit ću neke stvari skoro prvi put s tobom.

Neću biti originalan u ovdje opisanim idejama i alatima. Dmitry Figol ima odličan kanal sa streamovima na ovu temu.
Članci će se preklapati s njima u mnogim aspektima.

LAN DC ima 4 DC-a, oko 250 svičeva, pola tuceta rutera i nekoliko zaštitnih zidova.
Nije Facebook, ali dovoljno da vas natjera da duboko razmislite o automatizaciji.
Postoji, međutim, mišljenje da ako imate više od 1 uređaja, automatizacija je već potrebna.
Zapravo, teško je zamisliti da iko sada može živjeti bez barem paketa scenarija za koljena.
Iako sam čuo da postoje kancelarije u kojima se IP adrese čuvaju u Excel-u, a svaki od hiljada mrežnih uređaja se konfiguriše ručno i ima svoju jedinstvenu konfiguraciju. Ovo se, naravno, može prenijeti kao moderna umjetnost, ali će osjećaji inženjera definitivno biti uvrijeđeni.

Ciljevi

Sada ćemo postaviti najapstraktnije ciljeve:

• Mreža je kao jedan organizam
• Testiranje konfiguracije
• Versioniranje stanja mreže
• Praćenje i samoizlječenje usluga

Kasnije u ovom članku ćemo pogledati koja sredstva ćemo koristiti, au sljedećem ćemo detaljno pogledati ciljeve i sredstva.

Mreža je kao jedan organizam

Definišuća fraza serije, iako na prvi pogled možda ne izgleda toliko značajno: mi ćemo konfigurisati mrežu, a ne pojedinačne uređaje.
Posljednjih godina vidjeli smo pomak u naglasku na tretiranje mreže kao jedinstvenog entiteta, stoga Definirani mrežni softver, Mreže vođene namjerom и Autonomne mreže.
Na kraju krajeva, šta aplikacijama treba globalno od mreže: povezanost između tačaka A i B (pa, ponekad +B-Z) i izolacija od drugih aplikacija i korisnika.

I tako je naš zadatak u ovoj seriji izgraditi sistem, održavajući trenutnu konfiguraciju cijelu mrežu, koji je već razložen u stvarnu konfiguraciju na svakom uređaju u skladu s njegovom ulogom i lokacijom.
sistem upravljanje mrežom podrazumijeva da ga kontaktiramo radi izmjena, a on zauzvrat izračunava željeno stanje za svaki uređaj i konfigurira ga.
Na ovaj način minimiziramo ručni pristup CLI-ju na gotovo nulu - sve promjene u postavkama uređaja ili dizajnu mreže moraju biti formalizirane i dokumentirane - i tek onda uvedene u potrebne mrežne elemente.

To jest, na primjer, ako smo odlučili da od sada rack switch-evi u Kazanju najavljuju dvije mreže umjesto jedne, mi

1. Prvo dokumentiramo promjene u sistemima
2. Generiranje ciljne konfiguracije svih mrežnih uređaja
3. Pokrećemo program za ažuriranje mrežne konfiguracije, koji izračunava šta treba ukloniti na svakom čvoru, šta dodati i dovodi čvorove u željeno stanje.

Istovremeno, mijenjamo ručno samo u prvom koraku.

Testiranje konfiguracije

Poznato jeda se 80% problema javlja prilikom promjene konfiguracije - indirektni dokaz za to je da je tokom novogodišnjih praznika sve obično mirno.
Lično sam bio svjedok na desetine globalnih zastoja zbog ljudske greške: pogrešna komanda, konfiguracija je izvršena u pogrešnoj grani, zajednica je zaboravila, MPLS je globalno demoliran na ruteru, pet komada hardvera je konfigurirano, ali greška nije bila uočeno šestog, izvršene su stare promjene koje je napravila druga osoba. Postoji tona scenarija.

Automatizacija će nam omogućiti da napravimo manje grešaka, ali u većem obimu. Na ovaj način možete podići ne samo jedan uređaj, već cijelu mrežu odjednom.

Naši djedovi su od pamtivijeka provjeravali ispravnost unesenih promjena oštrim okom, čeličnim kuglicama i funkcionalnost mreže nakon što su uvedene.
Oni djedovi čiji je rad doveo do zastoja i katastrofalnih gubitaka ostavili su manje potomaka i trebali bi izumrijeti s vremenom, ali evolucija je spor proces, pa stoga još uvijek svi prvo ne testiraju promjene u laboratoriji.
Međutim, prednjače oni koji su automatizirali proces testiranja konfiguracije i njene dalje primjene na mrežu. Drugim riječima, pozajmio sam CI/CD proceduru (Kontinuirana integracija, kontinuirana implementacija) od programera.
U jednom od dijelova ćemo pogledati kako to implementirati koristeći sistem kontrole verzija, vjerovatno Github.

Jednom kada se naviknete na ideju mrežnog CI/CD-a, preko noći će se metoda provjere konfiguracije primjenom na proizvodnu mrežu činiti kao ranosrednjovjekovno neznanje. Nešto kao udaranje bojne glave čekićem.

Organski nastavak ideja o sistem upravljanje mrežom i CI/CD postaje potpuna verzija konfiguracije.

Versioniranje

Pretpostavit ćemo da uz bilo kakve promjene, čak i one najsitnije, čak i na jednom neprimjetnom uređaju, cijela mreža prelazi iz jednog stanja u drugo.
I mi uvijek ne izvršavamo naredbu na uređaju, mi mijenjamo stanje mreže.
Nazovimo ove države verzijama?

Recimo da je trenutna verzija 1.0.0.
Da li se IP adresa Loopback interfejsa na jednom od zadataka promenila? Ovo je manja verzija i bit će označena brojem 1.0.1.
Revidirali smo politike za uvoz ruta u BGP - malo ozbiljnije - već 1.1.0
Odlučili smo da se riješimo IGP-a i pređemo samo na BGP - ovo je već radikalna promjena dizajna - 2.0.0.

Istovremeno, različiti DC-ovi mogu imati različite verzije - mreža se razvija, instalira se nova oprema, negdje se dodaju novi nivoi spinova, a ne u drugima, itd.

na semantičko verzioniranje pričaćemo u posebnom članku.

Ponavljam - svaka promjena (osim komandi za otklanjanje grešaka) je ažuriranje verzije. Administratori moraju biti obaviješteni o svim odstupanjima od trenutne verzije.

Isto se odnosi i na vraćanje promjena unazad - ovo ne poništava posljednje naredbe, ovo nije vraćanje na prethodni sistem pomoću operativnog sistema uređaja - ovo dovodi cijelu mrežu na novu (staru) verziju.

Praćenje i samoizlječenje usluga

Ovaj očigledan zadatak dostigao je novi nivo u modernim mrežama.
Često veliki provajderi usluga imaju pristup da neispravnu uslugu treba vrlo brzo popraviti i podići novu, umjesto da shvate šta se dogodilo.
“Vrlo” znači da morate biti obilno premazani sa svih strana nadzorom, koji će u roku od nekoliko sekundi otkriti i najmanja odstupanja od norme.
I ovdje uobičajene metrike, poput učitavanja interfejsa ili dostupnosti čvorova, više nisu dovoljne. Nije dovoljno ni njihovo ručno praćenje od strane dežurnog.
Za mnoge stvari bi trebalo da postoji Samoizlječenje — kontrolna svjetla su se upalila i mi smo otišli i sami nanijeli trputac tamo gdje je bolelo.

I ovdje također pratimo ne samo pojedinačne uređaje, već i zdravlje cijele mreže, kako whiteboxa, što je relativno razumljivo, tako i blackboxa, koji je složeniji.

Šta će nam biti potrebno da sprovedemo ovako ambiciozne planove?

• Imati popis svih uređaja na mreži, njihovu lokaciju, uloge, modele, verzije softvera.
  kazan-leaf-1.lmu.net, Kazan, list, Juniper QFX 5120, R18.3.
• Imati sistem za opisivanje mrežnih usluga.
  IGP, BGP, L2/3VPN, Policy, ACL, NTP, SSH.
• Biti u mogućnosti inicijalizirati uređaj.
  Ime hosta, Mgmt IP, Mgmt Route, Korisnici, RSA-ključevi, LLDP, NETCONF
• Konfigurirajte uređaj i dovedite konfiguraciju na željenu (uključujući staru) verziju.
• Testna konfiguracija
• Periodično provjeravajte status svih uređaja na odstupanja od trenutnih i javljajte kome bi trebao biti.
  Preko noći je neko tiho dodao pravilo u ACL.
• Monitor performansi.

Sredstva

Zvuči dovoljno komplikovano da počnete da rastavljate projekat na komponente.

A biće ih deset:

1. Sistem inventara
2. IP sistem upravljanja prostorom
3. Sistem opisa mrežnih usluga
4. Mehanizam inicijalizacije uređaja
5. Model konfiguracije bez obzira na dobavljač
6. Interfejs drajvera specifičan za proizvođača
7. Mehanizam za isporuku konfiguracije na uređaj
8. CI / CD
9. Mehanizam za backup i traženje odstupanja
10. Nadzorni sistem

Ovo je, inače, primjer kako se promijenio pogled na ciljeve ciklusa - u nacrtu su bile 4 komponente.

Na ilustraciji sam prikazao sve komponente i sam uređaj.
Komponente koje se seku međusobno djeluju.
Što je blok veći, više pažnje treba posvetiti ovoj komponenti.

Komponenta 1: Sistem inventara

Očigledno, želimo da znamo koja oprema se gde nalazi, na šta je povezana.
Sistem zaliha je sastavni dio svakog preduzeća.
Najčešće, preduzeće ima poseban sistem inventara za mrežne uređaje, koji rešava konkretnije probleme.
Kao dio ove serije članaka, nazvat ćemo ga DCIM - Data Center Infrastructure Management. Iako sam pojam DCIM, strogo govoreći, uključuje mnogo više.

Za naše potrebe, u njega ćemo pohraniti sljedeće informacije o uređaju:

• Inventarni broj
• Naslov/Opis
• model (Huawei CE12800, Juniper QFX5120, itd.)
• Karakteristični parametri (ploče, interfejsi itd.)
• Uloga (Leaf, Spine, Border Router, itd.)
• Lokacija (regija, grad, data centar, stalak, jedinica)
• Međusobne veze između uređaja
• Topologija mreže

Savršeno je jasno da mi sami želimo sve ovo da znamo.
Ali hoće li ovo pomoći u svrhe automatizacije?
Svakako.
Na primjer, znamo da u datom data centru na Leaf switchevima, ako je Huawei, ACL-ove za filtriranje određenog prometa treba primijeniti na VLAN, a ako je Juniper, onda na jedinicu 0 fizičkog interfejsa.
Ili trebate uvesti novi Syslog server na sve granice u regiji.

U njemu ćemo pohraniti virtuelne mrežne uređaje, na primjer virtualne rutere ili root reflektore. Možemo dodati DNS servere, NTP, Syslog i općenito sve što se na ovaj ili onaj način odnosi na mrežu.

Komponenta 2: IP sistem upravljanja prostorom

Da, i danas postoje timovi ljudi koji prate prefikse i IP adrese u Excel datoteci. Ali moderan pristup je i dalje baza podataka, sa front-endom na nginx/apache, API-jem i opsežnim funkcijama za snimanje IP adresa i mreža podijeljenih u VRF-ove.
IPAM - Upravljanje IP adresom.

Za naše potrebe, u njega ćemo pohraniti sljedeće informacije:

• VLAN
• VRF
• Mreže/Podmreže
• IP adrese
• Vezanje adresa za uređaje, mreže za lokacije i VLAN brojeva

Opet, jasno je da želimo biti sigurni da kada dodijelimo novu IP adresu za ToR loopback, nećemo se spotaknuti o činjenici da je već nekome dodijeljena. Ili da smo dva puta koristili isti prefiks na različitim krajevima mreže.
Ali kako ovo pomaže kod automatizacije?
Lako je.
Zahtevamo prefiks u sistemu sa ulogom Loopbacks, koji sadrži IP adrese dostupne za dodelu - ako se pronađe, dodeljujemo adresu, ako ne, zahtevamo kreiranje novog prefiksa.
Ili kada kreiramo konfiguraciju uređaja, možemo saznati iz istog sistema u kojem VRF bi trebalo biti lociran interfejs.
A prilikom pokretanja novog servera, skripta se prijavljuje u sistem, saznaje na kom prekidaču se server nalazi, koji port i koja podmreža je dodeljena interfejsu - i sa njega će dodeliti adresu servera.

Ovo sugerira želju da se DCIM i IPAM kombinuju u jedan sistem kako se ne bi duplicirale funkcije i ne bi služile dva slična entiteta.
To ćemo uraditi.

Komponenta 3. Sistem za opisivanje mrežnih usluga

Ako prva dva sistema pohranjuju varijable koje se i dalje moraju nekako koristiti, onda treći opisuje za svaku ulogu uređaja kako se treba konfigurirati.
Vrijedi razlikovati dvije različite vrste mrežnih usluga:

• Infrastruktura
• Klijent.

Prvi su dizajnirani da obezbede osnovnu povezanost i kontrolu uređaja. To uključuje VTY, SNMP, NTP, Syslog, AAA, protokole za rutiranje, CoPP, itd.
Potonji organiziraju uslugu za klijenta: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, itd.
Naravno, postoje i granični slučajevi - gde uključiti MPLS LDP, BGP? Da, i protokoli rutiranja se mogu koristiti za klijente. Ali ovo nije važno.

Obje vrste usluga su dekomponirane na konfiguracijske primitive:

• fizički i logički interfejsi (tag/anteg, mtu)
• IP adrese i VRF-ovi (IP, IPv6, VRF)
• ACL-ovi i politike obrade saobraćaja
• Protokoli (IGP, BGP, MPLS)
• Politika rutiranja (liste prefiksa, zajednice, ASN filteri).
• Komunalne usluge (SSH, NTP, LLDP, Syslog...)
• itd.

Kako ćemo to tačno uraditi, još nemam pojma. Razmotrit ćemo to u posebnom članku.

Ako malo bliže životu, onda bismo to mogli opisati
Leaf switch mora imati BGP sesije sa svim povezanim Spine prekidačima, uvoziti povezane mreže u proces i prihvatiti samo mreže iz određenog prefiksa sa Spine prekidača. Ograničite CoPP IPv6 ND na 10 pps, itd.
Zauzvrat, kičme održavaju sesije sa svim povezanim vodovima, djelujući kao korijenski reflektori, i prihvataju od njih samo rute određene dužine i sa određenom zajednicom.

Komponenta 4: Mehanizam inicijalizacije uređaja

Pod ovim naslovom kombinujem mnoge radnje koje se moraju dogoditi da bi se uređaj pojavio na radaru i da bi mu se pristupilo sa daljine.

1. Unesite uređaj u sistem inventara.
2. Odaberite IP adresu za upravljanje.
3. Postavite osnovni pristup tome:
   Ime hosta, IP adresa za upravljanje, ruta do upravljačke mreže, korisnici, SSH ključevi, protokoli - telnet/SSH/NETCONF

Postoje tri pristupa:

• Sve je potpuno ručno. Uređaj se dovodi na štand, gde će ga običan organski čovek uneti u sisteme, spojiti na konzolu i konfigurisati. Može raditi na malim statičkim mrežama.
• ZTP - Dodjela bez dodira. Hardver je stigao, ustao, dobio adresu preko DHCP-a, otišao na poseban server i sam se konfigurisao.
• Infrastruktura konzolnih servera, gdje se početna konfiguracija odvija preko konzolnog porta u automatskom načinu rada.

O sva tri ćemo govoriti u posebnom članku.

Komponenta 5: Konfiguracijski model koji ne zavisi od dobavljača

Do sada su svi sistemi bili različite zakrpe koje daju varijable i deklarativni opis onoga što bismo željeli vidjeti na mreži. Ali prije ili kasnije, morat ćete se pozabaviti pojedinostima.
U ovoj fazi, za svaki određeni uređaj, primitivi, usluge i varijable se kombinuju u konfiguracioni model koji zapravo opisuje kompletnu konfiguraciju određenog uređaja, samo na način koji je neutralan za dobavljača.
Šta radi ovaj korak? Zašto ne biste odmah kreirali konfiguraciju uređaja koju možete jednostavno prenijeti?
U stvari, ovo rješava tri problema:

1. Nemojte se prilagođavati određenom interfejsu za interakciju sa uređajem. Bilo da se radi o CLI, NETCONF, RESTCONF, SNMP - model će biti isti.
2. Ne držite broj šablona/skriptova prema broju dobavljača na mreži, a ako se dizajn promijeni, promijenite istu stvar na više mjesta.
3. Učitajte konfiguraciju sa uređaja (backup), stavite je u potpuno isti model i direktno uporedite ciljnu konfiguraciju sa postojećom kako biste izračunali deltu i pripremili zakrpu konfiguracije koja će promijeniti samo one dijelove koji su neophodni ili identificirati odstupanja.

Kao rezultat ove faze, dobijamo konfiguraciju nezavisnu od dobavljača.

Komponenta 6. Sučelje drajvera specifičnog za proizvođača

Ne biste se trebali laskati nadama da će jednog dana biti moguće konfigurirati cisku na potpuno isti način kao Juniper, jednostavno tako što ćete im poslati potpuno iste pozive. Unatoč sve većoj popularnosti bijelih kutija i pojavi podrške za NETCONF, RESTCONF, OpenConfig, specifičan sadržaj koji ovi protokoli isporučuju razlikuje se od dobavljača do dobavljača, a to je jedna od njihovih konkurentskih razlika od koje se neće tako lako odreći.
Ovo je otprilike isto kao što OpenContrail i OpenStack, koji imaju RestAPI kao NorthBound interfejs, očekuju potpuno različite pozive.

Dakle, u petom koraku, model nezavisan od proizvođača mora poprimiti oblik u kojem će ići na hardver.
I ovdje su sva sredstva dobra (ne): CLI, NETCONF, RESTCONF, SNMP jednostavno.

Stoga će nam trebati drajver koji će prenijeti rezultat prethodnog koraka u potreban format određenog dobavljača: skup CLI naredbi, XML struktura.

Komponenta 7. Mehanizam za isporuku konfiguracije na uređaj

Generirali smo konfiguraciju, ali je još uvijek treba isporučiti uređajima – i to, očito, ne ručno.
Prvo, suočeni smo sa pitanjem koji prevoz ćemo koristiti? I danas izbor više nije mali:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (iako je to izvanredno jer je to način da se isporuči FIB, a ne postavke)

Stavimo tačku na t ovdje. CLI je naslijeđe. SNMP... kašalj kašalj.
RESTCONF je još uvijek nepoznata životinja; REST API gotovo niko ne podržava. Stoga ćemo se u seriji fokusirati na NETCONF.

Zapravo, kao što je čitalac već shvatio, do ovog trenutka smo se već odlučili za interfejs - rezultat prethodnog koraka je već predstavljen u formatu interfejsa koji je izabran.

Drugo, i kojim alatima ćemo to uraditi?
Tu je i veliki izbor:

• Samonapisana skripta ili platforma. Naoružajmo se ncclientom i asyncIO i uradimo sve sami. Koliko nas košta da izgradimo sistem implementacije od nule?
• Ansible sa svojom bogatom bibliotekom mrežnih modula.
• Sol sa svojim oskudnim radom sa mrežom i vezom sa Napalmom.
• Zapravo Napalm, koji poznaje nekoliko dobavljača i to je to, doviđenja.
• Nornir je još jedna životinja koju ćemo secirati u budućnosti.

Ovdje favorit još nije izabran - tražit ćemo.

Šta je tu još važno? Posljedice primjene konfiguracije.
Uspješno ili ne. Postoji li još uvijek pristup hardveru ili ne?
Čini se da će urezivanje pomoći ovdje s potvrdom i validacijom onoga što je preuzeto na uređaj.
Ovo, u kombinaciji sa pravilnom implementacijom NETCONF-a, značajno sužava opseg odgovarajućih uređaja - malo proizvođača podržava normalna urezivanja. Ali ovo je samo jedan od preduslova u RFP. Na kraju, niko nije zabrinut da nijedan ruski proizvođač neće ispuniti uslove interfejsa 32*100GE. Ili je zabrinut?

Komponenta 8. CI/CD

U ovom trenutku već imamo spremnu konfiguraciju za sve mrežne uređaje.
Pišem “za sve” jer govorimo o verziji stanja mreže. Čak i ako trebate promijeniti postavke samo jednog prekidača, promjene se izračunavaju za cijelu mrežu. Očigledno, oni mogu biti nula za većinu čvorova.

Ali, kao što je već rečeno, mi nismo nekakvi barbari koji žele sve uvaljati direktno u proizvodnju.
Generirana konfiguracija prvo mora proći kroz Pipeline CI/CD.

CI/CD je skraćenica od Continuous Integration, Continuous Deployment. Ovo je pristup u kojem tim ne samo da objavljuje novo veliko izdanje svakih šest mjeseci, potpuno zamjenjujući staro, već redovno postepeno implementira (Deployment) nove funkcionalnosti u malim porcijama, od kojih je svaka sveobuhvatno testirana na kompatibilnost, sigurnost i performanse (Integracija).

Da bismo to uradili, imamo sistem kontrole verzija koji prati promene konfiguracije, laboratoriju koja proverava da li je klijentska usluga pokvarena, sistem za praćenje koji proverava ovu činjenicu, a poslednji korak je uvođenje promena u proizvodnu mrežu.

Sa izuzetkom komandi za otklanjanje grešaka, apsolutno sve promjene na mreži moraju proći kroz CI/CD Pipeline - ovo je naša garancija mirnog života i duge, sretne karijere.

Komponenta 9. Rezervni sistem i sistem za detekciju anomalija

Pa, nema potrebe ponovo govoriti o rezervnim kopijama.
Jednostavno ćemo ih dodati na krunu ili nakon promjene konfiguracije u git-u.

Ali drugi dio je zanimljiviji - neko bi trebao paziti na ove sigurnosne kopije. I u nekim slučajevima taj neko mora da ode i okrene sve kako je bilo, a u drugima nekome mjauče da nešto nije u redu.
Na primjer, ako se pojavio novi korisnik koji nije registriran u varijablama, morate ga ukloniti iz haka. A ako je bolje ne dirati novo pravilo firewall-a, možda je neko upravo uključio otklanjanje grešaka, ili možda nova usluga, bungler, nije registrovana po propisima, ali su joj se ljudi već priključili.

I dalje nećemo pobjeći od neke male delte na skali cijele mreže, unatoč bilo kakvim sistemima automatizacije i čeličnoj ruci upravljanja. Da bi se otklonili problemi, ionako niko neće dodati konfiguraciju sistemima. Štaviše, možda nisu ni uključeni u konfiguracijski model.

Na primjer, pravilo firewall-a za brojanje broja paketa po određenom IP-u radi lokalizacije problema je sasvim obična privremena konfiguracija.

Komponenta 10. Sistem nadzora

U početku nisam htela da obrađujem temu praćenja – to je još uvek obimna, kontroverzna i složena tema. Ali kako su stvari napredovale, pokazalo se da je to sastavni dio automatizacije. I nemoguće ga je zaobići, čak i bez vježbe.

Evoluirajuća misao je organski dio CI/CD procesa. Nakon što konfiguraciju prenesemo na mrežu, moramo biti u mogućnosti da utvrdimo da li je sada sve u redu s njom.
I ne govorimo samo i ne toliko o rasporedu korištenja interfejsa ili dostupnosti čvorova, već o suptilnijim stvarima - prisutnosti potrebnih ruta, atributa na njima, broja BGP sesija, OSPF susjeda, End-to-End performansi gornjih usluga.
Da li su syslogovi na eksternom serveru prestali da se zbrajaju, ili se SFlow agent pokvario, ili su padovi u redovima počeli da rastu, ili je došlo do prekida veze između nekog para prefiksa?

O tome ćemo razmišljati u posebnom članku.

zaključak

Kao osnovu, izabrao sam jedan od modernih dizajna mreže centara podataka - L3 Clos Fabric sa BGP kao protokolom za rutiranje.
Ovaj put ćemo graditi mrežu na Juniperu, jer je JunOs interfejs sada vanlove.

Otežajmo si život koristeći samo alate otvorenog koda i mrežu više dobavljača - pa ću pored Junipera izabrati još jednog sretnika na putu.

Plan za nadolazeće publikacije je otprilike ovako:
Prvo ću govoriti o virtuelnim mrežama. Prije svega, zato što to želim, a drugo, jer bez toga dizajn infrastrukturne mreže neće biti baš jasan.
Zatim o samom dizajnu mreže: topologija, usmjeravanje, politike.
Hajde da sastavimo laboratorijski stalak.
Razmislimo o tome i možda vježbamo inicijalizaciju uređaja na mreži.
A zatim o svakoj komponenti u intimnim detaljima.

I da, ne obećavam da ću graciozno završiti ovaj ciklus sa gotovim rješenjem. 🙂

korisni linkovi

• Prije nego što uđete u seriju, vrijedi pročitati knjigu Nataše Samoilenko Python za mrežne inženjere. I možda proći kurs.
• Također će biti korisno pročitati RFC o dizajnu fabrika data centara iz Facebooka Petra Lapuhova.
• Dokumentacija o arhitekturi će vam dati ideju o tome kako radi Overlay SDN. Tungsten Fabric (ranije Open Contrail).

Hvala ti

Roman Gorge. Za komentare i izmjene.
Artyom Chernobay. Za KDPV.

izvor: www.habr.com