SDSM je završio, ali nekontrolirana želja za pisanjem ostala je.

Dugi niz godina naš brat patio je zbog obavljanja rutinskog posla, prekrio je prste pred komitom i nije spavao zbog noćnih rollbacka.
Ali mračnim vremenima dolazi kraj.

Ovime započinjem seriju o tome kako meni izgleda automatizacija.
U nastavku ćemo razjasniti faze automatizacije, pohranu varijabli, formalizaciju dizajna, s RestAPI, NETCONF, YANG, YDK i mnogo ćemo programirati.
Meni znači da a) to nije objektivna istina, b) nije bezuvjetno najbolji pristup c) moj pogled može se čak promijeniti tijekom prijelaza iz prve u posljednju članku — iskreno, od faze nacrta do objavljivanja sve sam prepisao dva puta.

Sadržaj

Ciljevi
1. Mreža — kao jedinstven organizam
2. Testiranje konfiguracije
3. Verzionarstvo
4. Praćenje i samopopravljanje usluga
Sredstva
1. Sustav inventara
2. Sustav upravljanja IP prostorom
3. Sustav opisivanja mrežnih usluga
4. Mehanizam inicijalizacije uređaja
5. Vendor-agnostic konfiguracijski model
6. Vendor-specifični sučeljski upravljački program
7. Mehanizam dostave konfiguracije na uređaj
8. CI/CD
9. Mehanizam izrade sigurnosnih kopija i pronalaženja odstupanja
10. Sustav praćenja
Zaključak

ADSCom ću pokušati voditi u formatu malo drugačijem od SDMS. I dalje će se pojavljivati veliki, opsežni članci s brojevima, a između njih ću objavljivati male bilješke iz svakodnevnog iskustva. Potrudit ću se boriti protiv perfekcionizma i ne dorađivati ih svaku.

Kako je smiješno da drugi put moram prolaziti istim putem.
Isprva sam morao sam pisati članke o mrežama jer ih nije bilo na ruskom internetu.
Sada nisam mogao pronaći sveobuhvatan dokument koji bi sistematizirao pristupe automatizaciji i obrađivao prethodno navedene tehnologije kroz jednostavne praktične primjere.
Možda griješim, zato šaljite linkove na dobre resurse. Ipak, to neće promijeniti moju odlučnost da pišem, jer je osnovna svrha — naučiti nešto sam, a olakšati život bližnjima — ugodna pomagala koja miluje gen širenja iskustava.

Pokušat ćemo uzeti srednje veličine data centar LAN DC i obraditi cijelu shemu automatizacije.
Neke stvari ću raditi praktički po prvi put zajedno s vama.

U opisanim idejama i alatima neću biti originalan. Dmitrij Figolj ima odličan kanal sa streamovima na ovu temu.
Članci će se u mnogim aspektima preklapati s njima.

U LAN DC 4 su 4 data centra, oko 250 switch-eva, pola tuceta rutera i nekoliko vatrozida.
Nije Facebook, ali dovoljno da duboko razmislimo o automatizaciji.
Međutim, postoji mišljenje da ako imate više od 1 uređaja, automatizacija je već potrebna.
Zaista je teško zamisliti da netko sada može živjeti bez barem nekoliko skripti.
Iako sam čuo da postoje takve tvrtke gdje se praćenje IP adresa vodi u Excelu, a svaki od tisuća mrežnih uređaja se podešava ručno i ima svoju jedinstvenu konfiguraciju. Ovo se može smatrati modernom umjetnošću, ali osjećaji inženjera sigurno će biti povrijeđeni.

Ciljevi

Sada ćemo postaviti maksimalno apstraktne ciljeve:

Mreža — kao jedinstven organizam
Testiranje konfiguracije
Verzioniranje stanja mreže
Praćenje i samopopravljanje usluga

Kasnije u ovom članku razmotrićemo koje alate ćemo koristiti, a u sljedećima i ciljeve i sredstva detaljno.

Mreža — kao jedinstven organizam

Određujuća fraza ciklusa, iako na prvi pogled može izgledati beznačajno: mi ćemo podešavati mrežu, a ne pojedinačne uređaje.
Sve posljednje godine svjedoci smo pomaka prema tome da s mrežom postupamo kao s jedinstvenom cjelinom, otuda i dolaze u našu život Softverski definirana mreža, Mreže vođene namjerom i Autonomne mreže.
Jer što aplikacijama globalno treba od mreže: povezanost između točaka A i B (pa ponekad +B-J) i izolaciju od drugih aplikacija i korisnika.

A tako, naš zadatak u ovoj seriji je izgraditi sustav, koji podržava trenutnu konfiguraciju cijele mreže, koja se već dekontekstualizira na trenutnu konfiguraciju na svakom uređaju u skladu s njegovom ulogom i lokacijom.
Sustav upravljačke mreže podrazumijeva da se za promjene obraćamo njemu, a on u svom obrtu izračunava potrebno stanje za svaki uređaj i podešava ga.
Tako minimiziramo gotovo do nule odlazak u CLI ručno — sve promjene u postavkama uređaja ili dizajnu mreže moraju biti formalizirane i dokumentirane — a tek potom se primjenjuju na potrebne elemente mreže.

Dakle, na primjer, ako smo odlučili da od sada rack switchevi u Kazanju trebaju najavljivati dvije mreže umjesto jedne, mi

Prvo dokumentiramo promjene u sustavima

Generiramo ciljnu konfiguraciju svih uređaja u mreži

Pokrećemo program za ažuriranje mrežne konfiguracije, koji izračunava što treba ukloniti na svakom čvoru, što dodati, i dovodi čvorove u željeno stanje.
Pri tome ručno unosimo promjene samo u prvom koraku.

Testiranje konfiguracije

Poznato je, da 80% problema nastaje tijekom promjene konfiguracije — neizravni dokaz tome je što tijekom novogodišnjih praznika obično sve bude mirno.
Osobno sam bio svjedokom desetaka globalnih opustjela zbog ljudske pogreške: pogrešna komanda, izvršena u pogrešnoj grani konfiguracije, zaboravljena zajednica, globalno obrisan MPLS na ruteru, postavljene su četiri sprave, a na petoj greška nije primijećena, stari su se podaci od strane druge osobe doveli u komitet. Postoji bezbroj scenarija.

Automatika će nam omogućiti da činimo manje grešaka, ali u većem opsegu. Tako možemo upropastiti ne jedan uređaj, već cijelu mrežu odjednom.

Od davnina su naši djedovi provjeravali ispravnost unesenih promjena oštrim okom, čeličnim jajima i funkcionalnošću mreže nakon njihovog uvođenja.
Oni djedovi čije su akcije uzrokovale zastoje i katastrofalne gubitke ostavljali su manje potomstva i trebali bi s vremenom izumrijeti, ali evolucija je spor proces, i stoga još uvijek ne svi unaprijed provjeravaju promjene u laboratoriju.
Međutim, na rubu napretka su oni koji su automatizirali proces testiranja konfiguracije, i njene daljnje primjene na mreži. Drugim riječima — posudili su postupak CI/CD (Continuous Integration, Continuous Deployment) od programera.
U jednom od dijelova razmotrit ćemo kako to implementirati uz pomoć sustava za kontrolu verzija, vjerojatno GitHub-a.

Čim se pomirite s idejom o mrežnom CI/CD, metoda provjere konfiguracije primjenom na radnu mrežu učinit će vam se kao ranosrednjovjekovno neznanje. Otprilike kao udaranje čekićem po bojevoj glavi.

Organsko nastavak ideja o sustavu upravljanja mrežom i CI/CD postaje potpuno verzioniranje konfiguracije.

Verzionarstvo

Pretpostavljamo da svaki, i najmanji, čak i neprimjetni uređaj, uzrokuje promjenu cijele mreže iz jednog stanja u drugo.
I nikada ne izvršavamo komandu na uređaju, već mijenjamo stanje mreže.
Pa hajde da ta stanja zovemo verzijama?

Recimo da je trenutna verzija — 1.0.0.
Promijenila se IP adresa Loopback sučelja na jednom od ToR-ova? To je manjinska verzija — dobit će broj 1.0.1.
Revidirane su politike za uvoz ruta u BGP — nešto ozbiljnije — već 1.1.0.
Odlučili smo se riješiti IGP i preći samo na BGP — to je radikalna promjena dizajna — 2.0.0.

Pri tome različiti DC-evi mogu imati različite verzije — mreža se razvija, postavlja se nova oprema, negdje se dodaju novi nivoi spine, negdje — ne, itd.

O semantičkom verzioniranju pričat ćemo u posebnom članku.

Ponovit ću — svaka promjena (osim dijagnostičkih komandi) predstavlja ažuriranje verzije. O svim odstupanjima od aktualne verzije moraju biti obaviješteni administratori.

Isto se odnosi na povratak promjena — to nije ukidanje posljednjih komandi, to nije rollback uz pomoć operativnog sustava uređaja — to je vraćanje cijele mreže na novu (staru) verziju.

Praćenje i samopopravljanje usluga

Ovo je očigledan zadatak u modernim mrežama koji prelazi na novi nivo.
Često se kod velikih pružatelja usluga prakticira pristup prema kojem se pao servis mora vrlo brzo popraviti i podići novi, umjesto da se istražuje što se dogodilo.
„Vrlo“ znači da sa svih strana treba biti obilato pokriveno nadzorima, koji će unutar sekundi otkriti bilo kakva odstupanja od norme.
A ovdje već nisu dovoljne uobičajene metrike, poput opterećenja sučelja ili dostupnosti čvora. Nije dovoljna ni ručna kontrola dežurnog nadzora nad njima.
Za mnoge stvari trebali bi imati Self-Healing — nadzori su se upalili crveno i sami su se otišli brinuti, gdje boli.

I ovdje ne nadziremo samo pojedinačne uređaje, već i zdravlje cijele mreže, i to kako bijeli kut, što je relativno jasno, tako i crni kut, što je već složenije.

Što će nam trebati za realizaciju ovih ambicioznih planova?

Imati popis svih uređaja u mreži, njihovo postavljanje, uloge, modele, verzije softvera.
kazan-leaf-1.lmu.net, Kazan, leaf, Juniper QFX 5120, R18.3.
Imati sustav opisivanja mrežnih usluga.
IGP, BGP, L2/3VPN, Politika, ACL, NTP, SSH.
Moći inicijalizirati uređaj.
Hostname, Mgmt IP, Mgmt Route, Korisnici, RSA-Ključevima, LLDP, NETCONF
Postavljati uređaj i vraćati konfiguraciju na potrebnu (uključujući stariju) verziju.
Testirati konfiguraciju
Periodično provjeravati stanje svih uređaja u pogledu odstupanja od aktualnog i obavijestiti koga treba.
Noću je netko tiho dodao pravilo u ACL.
Pratiti funkcionalnost.

Sredstva

Zvuči dovoljno složeno da bi se započelo dekomponiranje projekta na komponente.

I bit će ih deset:

Sustav inventara
Sustav upravljanja IP prostorom
Sustav opisivanja mrežnih usluga
Mehanizam inicijalizacije uređaja
Vendor-agnostic konfiguracijski model
Vendor-specifični sučeljski upravljački program
Mehanizam dostave konfiguracije na uređaj
CI/CD
Mehanizam izrade sigurnosnih kopija i pronalaženja odstupanja
Sustav praćenja

To, moram napomenuti, je primjer kako se promijenio pogled na ciljeve ciklusa — u nacrtima komponenti bilo je 4.

Na ilustraciji sam prikazao sve komponente i samo uređaj.
Preklapajući se komponente međusobno komuniciraju.
Što je veći blok, više pažnje treba posvetiti toj komponenti.

Komponenta 1. Sustav inventara

Očigledno, želimo znati koji je uređaj gdje, na što je povezan.
Sustav inventara je neodvojiv dio svake tvrtke.
Najčešće, za mrežne uređaje, tvrtka ima poseban sustav inventara koji rješava specifičnije zadatke.
U okviru ovog ciklusa članaka nazivaćemo to DCIM — Upravljanje infrastrukturom podatkovnog centra. Iako sam pojam DCIM, strogo govoreći, uključuje mnogo više.

Za naše potrebe u njemu ćemo pohranjivati sljedeće informacije o uređaju:

Inventarni broj
Naziv/opis
Model (Huawei CE12800, Juniper QFX5120 itd.)
Karakteristični parametri (ploče, sučelja itd.)
Uloga (Leaf, Spine, Border Router itd.)
Lokacija (regija, grad, podatkovni centar, ormar, jedinica)
Međusobni povezivanje uređaja
Topologija mreže

Savršeno je jasno da i sami želimo znati sve to.
No, hoće li to pomoći u svrhu automatizacije?
Bez sumnje.
Na primjer, znamo da u ovom podatkovnom centru na Leaf preklopnicima, ako je to Huawei, ACL za filtriranje određenog prometa treba primijeniti na VLAN, a ako je to Juniper — onda na jedinici 0 fizičkog sučelja.
Ili je potrebno implementirati novi Syslog poslužitelj na sve granice regije.

U njemu ćemo pohraniti virtualne mrežne uređaje, na primjer virtualne usmjerivače ili rut-odraznike. Možemo dodati DNS poslužitelje, NTP, Syslog i uopće sve što se nekako odnosi na mrežu.

Komponenta 2. Sustav upravljanja IP prostorom

Da, i u naše vrijeme postoje kolektivi ljudi koji vode evidenciju prefiksa i IP adresa u Excel datoteci. No, suvremeni pristup je ipak baza podataka, s frontend-om na nginx/apache, API-jem i širokim funkcijama za evidenciju IP adresa i mreža s podjelom na VRF.
IPAM — Upravljanje IP adresama.

Za naše zadatke u njemu ćemo pohranjivati sljedeće informacije:

VLAN
VRF
Mreže/Podmreže
IP adrese
Veza adresa s uređajima, mreža s lokacijama i brojevima VLAN

Opet, jasno je da želimo biti sigurni da, dodjeljujući novu IP adresu za loopback ToR-a, nećemo naići na to da je već nekome dodijeljena. Ili da smo isti prefiks koristili dva puta na različitim krajevima mreže.
Ali kako će to pomoći u automatizaciji?
Lako.
Pitajmo u sustavu za prefiks s rolom Loopbacks, u kojem su dostupne IP adrese za dodjelu — ako se pronađe, dodjeljujemo adresu, ako ne, tražimo kreiranje novog prefiksa.
Ili prilikom kreiranja konfiguracije uređaja možemo iz tog istog sustava saznati u kojem VRF-u bi trebao biti sučelje.
A prilikom pokretanja novog servera, skripta će otići u sustav, saznati u kojem server switcheu, u kojem portu i koja podmreža je dodijeljena sučelju — iz njega će se dodijeliti adresa servera.

Postoji želja da se DCIM i IPAM spoje u jedan sustav kako se ne bi duplicirale funkcije i ne bi se upravljalo dvjema sličnim entitetima.
Tako ćemo i učiniti.

Komponenta 3. Sustav opisivanja mrežnih usluga

Ako prva dva sustava pohranjuju varijable koje se još moraju nekako iskoristiti, treći opisuje za svaku ulogu uređaja kako bi trebao biti konfiguriran.
Ističemo dva različita tipa mrežnih usluga:

Infrastrukturne
Klijentske.

Prve su namijenjene osiguravanju osnovne povezanosti i upravljanju uređajem. Ovdje možemo uključiti VTY, SNMP, NTP, Syslog, AAA, protokole usmjeravanja, CoPP itd.
Druge organiziraju uslugu za klijenta: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP itd.
Naravno, postoje i granični slučajevi — kako svrstati MPLS LDP, BGP? Svega je toga korišteno za klijente. No, to nije presudno.

Oba tipa usluga raspoređuju se na konfiguracijske primitivi:

fizički i logički sučelja (tag/untag, mtu)
IP adrese i VRF (IP, IPv6, VRF)
ACL i politike obrade prometa
Protokoli (IGP, BGP, MPLS)
Politike usmjeravanja (popisi prefiksa, zajednice, ASN filteri).
Upravljačke usluge (SSH, NTP, LLDP, Syslog…)
ItD.

Kako ćemo to točno napraviti, još nemam pojma. Razjasnit ćemo u posebnom članku.

Ako se malo više približimo realnosti, mogli bismo opisati što
Leaf prekidač treba imati BGP sesije sa svim povezanim Spine prekidačima, uvesti spojene mreže u proces, primati od Spine prekidača samo mreže iz određenog prefiksa. Ograničiti CoPP IPv6 ND na 10 pps itd.
S druge strane, spajdovi drže sesije sa svim povezanim listovima, djelujući kao rut reflektori, i primaju od njih samo rute određene duljine i s određenom zajednicom.

Komponenta 4. Mehanizam inicijalizacije uređaja

Pod ovim naslovom objedinjujem brojne radnje koje trebaju biti obavljene kako bi uređaj postao prepoznatljiv i mogao biti udaljeno pristupljen.

Registrirati uređaj u inventarnom sustavu.
Dodijeliti IP adresu upravljanja.
Postaviti osnovni pristup na njega:
Hostname, IP adresa upravljanja, ruta u mrežu upravljanja, korisnici, SSH ključevi, protokoli — telnet/SSH/NETCONF

Ovdje postoje tri pristupa:

Sve ručno. Uređaj se doveze na stend gdje ga obična osoba unosi u sustave, poveže se konzolom i postavlja. Može funkcionirati na malim statičkim mrežama.
ZTP — Zero Touch Provisioning. Oprema je stigla, postavila se, dobila adresu putem DHCP-a, otišla na posebni server, samonastavila se.
Infrastruktura konzolnih servera gdje se primarna konfiguracija provodi putem konzolnog porta automatski.

O sve tri ćemo razgovarati u posebnom članku.

Komponenta 5. Vendo-agnostik konfiguracijski model

Dotad su svi sustavi bili raštrkani komadići, dajući promjenljive i deklarativne opise onoga što bismo željeli vidjeti u mreži. No, prije ili kasnije, morat ćemo se suočiti s konkretnim stvarima.
U ovoj fazi za svaki konkretni uređaj, primitivni elementi, usluge i varijable kombiniraju se u konfiguracijski model, koji zapravo opisuje punu konfiguraciju konkretnog uređaja, samo u vendor-independent načinu.
Što ovaj korak donosi? Zašto ne formirati konfiguraciju uređaja odmah, koju jednostavno možemo učitati?
U stvari, to omogućava rješavanje tri zadatka:

Ne prilagoditi se specifičnom sučelju za interakciju s uređajem. Bilo da se radi o CLI, NETCONF, RESTCONF, SNMP — model će biti isti.
Ne zadržavati broj predložaka/skripti prema broju dobavljača u mreži, a u slučaju promjene dizajna, mijenjati isto na više mjesta.
Učitajte konfiguraciju s uređaja (rezervne kopije), rasporedite je u točno isti model i izravno usporedite ciljanju konfiguraciju i onu koja već postoji kako biste izračunali razliku i pripremili konfiguracijski paket koji će promijeniti samo one dijelove koji su potrebni ili za otkrivanje odstupanja.

Kao rezultat ovog koraka dobivamo konfiguraciju neovisnu o dobavljaču.

Komponenta 6. Dobavljač-specifični sučeljski vozač

Ne treba se zavaravati da će se Cisco ikad moći konfigurirati točno kao Juniper, jednostavno šaljući potpuno iste pozive. Unatoč rastućoj popularnosti whitebox-a i pojavama podrške za NETCONF, RESTCONF, OpenConfig, specifičan sadržaj koji se ovim protokolima isporučuje razlikuje se od dobavljača do dobavljača, i to je jedna od njihovih konkurentskih prednosti koju neće lako odustati.
To je otprilike isto kao i OpenContrail i OpenStack, koji imaju RestAPI kao svoje NorthBound sučelje, očekuju potpuno različite pozive.

Dakle, u petom koraku, model neovisan o dobavljaču trebao bi preuzeti oblik u kojem će se implementirati na hardver.
I ovdje su svi načini dobri (ne): CLI, NETCONF, RESTCONF, SNMP, jednostavno cijenite.

Stoga će nam trebati vozač koji će rezultat prethodnog koraka prevesti u pravilni format specifičan za dobavljača: set CLI komandi, struktura XML.

Komponenta 7. Mehanizam isporuke konfiguracije na uređaj

Mi smo generirali konfiguraciju, ali je još treba dostaviti uređajima — i, očito, ne ručno.
Prvo, postavlja se pitanje koji transport ćemo koristiti? A izbor je danas već prilično velik:

CLI (telnet, ssh)
SNMP
NETCONF
RESTCONF
REST API
OpenFlow (iako je izvan liste jer je to način isporuke FIB-a, a ne postavki)

Hajde da ovdje stavimo točke na i. CLI — to je staro. SNMP… eh-em.
RESTCONF — još uvijek nepoznato čudovište, REST API gotovo nitko ne podržava. Stoga ćemo se u ciklusu fokusirati na NETCONF.

Zapravo, kao što je čitatelj već shvatio, s sučeljem smo se do ovog trenutka već dogovorili — rezultat prethodnog koraka već je predstavljen u formatu onog sučelja koje je odabrano.

Drugo, kojim alatima ćemo to raditi?
Ovdje je izbor također velik:

Skripta napisana od strane nas ili platforma. Naoružat ćemo se ncclient i asyncIO i sami ćemo sve učiniti. Što nas košta, izgraditi sustav implementacije od nule?
Ansible sa svojom bogatom bibliotekom mrežnih modula.
Salt sa svojim skromnim radom s mrežom i povezanosti s Napalmom.
Sami Napalm, koji poznaje nekoliko dobavljača i to je sve, doviđenja.
Nornir — još jedna mačka koju ćemo terminirati u budućnosti.

Ovdje još nije odabran favorit — istraživat ćemo.

Što je ovdje još važno? Posljedice primjene konfiguracije.
Uspješno ili ne. Je li ostao pristup opremi ili ne.
Čini se da će ovdje pomoći commit s potvrdom i validacijom onoga što je učitano u uređaj.
Ovo u kombinaciji s pravilnom implementacijom NETCONF značajno sužava krug odgovarajućih uređaja — normalni commit ne podržavaju tako mnogi proizvođači. No, to je samo jedan od obaveznih uvjeta u RFP. Na kraju krajeva, nitko ne brine što nijedan ruski dobavljač neće proći pod uvjetom od 32*100GE sučelja. Ili brine?

Komponenta 8. CI/CD

U ovom trenutku već imamo konfiguraciju za sve uređaje u mreži.
Pišem "za sve", jer govorimo o verzioniranju stanja mreže. I čak i ako je potrebno promijeniti postavke samo jednog switcha, izračunavaju se promjene za cijelu mrežu. Očito, one mogu biti u tom slučaju nulte za većinu čvorova.

Ali, kao što je već rečeno, ne ponašamo se kao divljaci da sve odjednom gurnemo u produkciju.
Generirana konfiguracija prvo mora proći kroz CI/CD cjevovod.

CI/CD znači kontinuirana integracija, kontinuirana implementacija. To je pristup u kojem ekipa ne objavljuje novu glavnu verziju jednom u pola godine, potpuno zamjenjujući staru, već redovito inkrementalno uvodi (implementaciju) novu funkcionalnost u malim dijelovima, od kojih se svaki temeljito testira na kompatibilnost, sigurnost i funkcioniranje (integracija).

Za to imamo sustav kontrole verzija koji prati promjene konfiguracije, laboratorij u kojem se provjerava ne pokvari li se klijentska usluga, sustav nadzora koji provjerava taj aspekt, i posljednji korak — implementaciju promjena u radnu mrežu.

Osim odvojbenih naredbi, apsolutno sve promjene u mreži moraju proći kroz CI/CD Pipeline — to je naš jamac mirnog života i duge sretne karijere.

Komponenta 9. Sustav izrade sigurnosnih kopija i traženja odstupanja

Pa, o sigurnosnim kopijama ne treba posebno govoriti.
Samo ćemo ih po zakazivanju ili po zaprimanju promjene konfiguracije u git dodavati.

A sada druga, zanimljivija strana — netko bi trebao paziti na te sigurnosne kopije. U nekim slučajevima, taj netko bi trebao ići i vratiti sve kako je bilo, a u drugim, obavijestiti nekoga da nešto nije u redu.
Na primjer, ako se pojavi neki novi korisnik koji nije naveden u varijablama, treba ga ukloniti daleko od hakiranja. A ako je pravilo o vatrozidu novo — bolje ga ne dirati, možda je netko jednostavno uključio debugging, a možda je novi servis, nespretni korisnik, nije ga prema pravilima naveo, a već su svi počeli ulaziti.

Od neke male delta u mjerilu čitave mreže, ipak ne možemo pobjeći, unatoč svim sustavima automatizacije i čeličnoj ruci uprave. Za otklanjanje problema, nitko neće unositi konfiguraciju u sustave. Tim više što model konfiguracije možda čak ni ne predviđa.

Na primjer, pravilo vatrozida za brojanje paketa na određeni IP, radi lociranja problema — prilično uobičajena privremena konfiguracija.

Komponenta 10. Sustav nadzora

Isprva nisam imao namjeru raspraviti temu nadzora — to je ipak opširna, sporna i složena tema. No, tijekom procesa je ispalo da je to sastavni dio automatizacije. I ne možemo ga zaobići, čak i bez prakse.

Razvijajući misao — to je organski dio procesa CI/CD. Nakon što se konfiguracija implementira u mrežu, trebamo biti u stanju odrediti je li sve u redu.
I nije riječ samo o grafikonima korištenja sučelja ili dostupnosti čvorova, već i o suptilnijim stvarima — prisutnosti potrebnih ruta, atributima na njima, broju BGP sesija, OSPF susjeda, End-to-End funkcionalnosti viših usluga.
Jesmo li prestali prikupljati syslogove na vanjskom serveru, ili se SFlow agent pokvario, ili su se povećali gubici u redovima, ili je prekinuta povezanost između nekog para prefiksa?

U posebnom članku razmotrit ćemo i to.

Zaključak

Kao osnovu izabrao sam jedan od suvremenih dizajna data centar mreže — L3 Clos Fabric s BGP-om kao protokolom usmjeravanja.
Mrežu ćemo ovaj put graditi na Juniperu, jer je sada JunOs sučelje — savršeno.

Otežat ćemo si život koristeći samo open source alate i multivendor mrežu — stoga ću osim Junipera u međuvremenu izabrati još jednog sretnika.

Plan nadolazećih publikacija otprilike je ovakav:
Prvo ću govoriti o virtualnim mrežama. Prvo, jer to želim, a drugo, jer bez toga dizajn infrastrukturne mreže neće biti dovoljno jasan.
Potom ću se osvrnuti na dizajn mreže: topologiju, usmjeravanje, politike.
Sastavit ćemo laboratorijski postav.
Razmislit ćemo i, možda, vježbati u inicijalizaciji uređaja u mreži.
A zatim o svakom komponentu u intimnim detaljima.

I da, ne obećajem da ću ovaj ciklus elegantno završiti gotovim rješenjem. 🙂

Koristitne veze

Prije nego što se dublje upustimo u seriju, vrijedi pročitati knjigu Natashe Samoilenko Python za mrežne inženjere. A možda i proći tečaj.
Bit će korisno također pročitati RFC o dizajnu data centarskih fabrika od Facebooka, autora Petra Lapuhova.
O tome kako radi Overlay SDN daje vam uvid dokumentacija o arhitekturi Tungsten Fabric (ranije Open Contrail).