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

Mnogo je godina naš brat patio od obavljanja rutinskih poslova, stiskanja palčeva prije nego što se posveti i nedostatka sna zbog noćnih vraćanja.
Ali mračna vremena se bliže kraju.

Ovim ću člankom započeti niz o tome kako mene vidi se automatizacija.
Usput ćemo razumjeti faze automatizacije, pohranjivanje varijabli, formaliziranje dizajna, RestAPI, NETCONF, YANG, YDK i puno ćemo programirati.
Mene znači da a) to nije objektivna istina, b) to nije bezuvjetno najbolji pristup, c) moje se mišljenje, čak i tijekom kretanja od prvog do zadnjeg članka, može promijeniti - da budem iskren, od faze nacrta do publikaciji, sve sam potpuno prepisao dva puta.

sadržaj

1. ciljevi
   1. Mreža je kao jedan organizam
   2. Testiranje konfiguracije
   3. Verziranje
   4. Praćenje i samoozdravljenje usluga

2. fondovi
   1. Sustav inventara
   2. Sustav upravljanja IP prostorom
   3. Sustav opisa mrežnih usluga
   4. Mehanizam inicijalizacije uređaja
   5. Model konfiguracije neovisno o dobavljaču
   6. Sučelje upravljačkog programa specifičnog za dobavljača
   7. Mehanizam za isporuku konfiguracije na uređaj
   8. CI / CD
   9. Mehanizam za backup i traženje odstupanja
   10. Sustav nadzora

3. Zaključak

Pokušat ću provesti ADSM u malo drugačijem formatu od SDSM-a. I dalje će izlaziti 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 ulizivati ​​se svakom od njih.

Kako je smiješno da drugi put morate 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 opsežan dokument koji bi sistematizirao pristupe automatizaciji i analizirao gore navedene tehnologije koristeći jednostavne praktične primjere.

Možda griješim, stoga navedite poveznice na korisne resurse. No, to neće promijeniti moju odlučnost da pišem, jer glavni cilj je i sam nešto naučiti, 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.
Neke stvari ću raditi gotovo 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 preklopnika, pola tuceta usmjerivača i nekoliko vatrozida.
Nije Facebook, ali dovoljno 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 itko sada može živjeti bez barem paketa skripti za koljeno.
Iako sam čuo da postoje uredi u kojima se IP adrese čuvaju u Excelu, a svaki od tisuća mrežnih uređaja konfigurira se ručno i ima svoju jedinstvenu konfiguraciju. To se, naravno, može protumačiti kao moderna umjetnost, ali će osjećaji inženjera svakako biti uvrijeđeni.

ciljevi

Sada ćemo postaviti najapstraktnije ciljeve:

• Mreža je kao jedan organizam
• Testiranje konfiguracije
• Verzija stanja mreže
• Praćenje i samoozdravljenje usluga

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

Mreža je kao jedan organizam

Definirajuća fraza serije, iako se na prvi pogled možda ne čini toliko značajnom: mi ćemo konfigurirati mrežu, a ne pojedinačne uređaje.
Posljednjih godina vidjeli smo pomak u naglasku prema tretiranju mreže kao jedinstvene cjeline, stoga Softver definirano umrežavanje, Mreže vođene namjerom и Autonomne mreže.
Uostalom, što aplikacijama treba globalno od mreže: povezanost između točaka A i B (dobro, ponekad +B-Z) i izolacija od drugih aplikacija i korisnika.

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

To je, na primjer, ako smo odlučili da od sada rack switchevi u Kazanu trebaju najavljivati ​​dvije mreže umjesto jedne,

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

Pritom, izmjene vršimo ručno samo u prvom koraku.

Testiranje konfiguracije

Poznato jeda se 80% problema javlja tijekom promjena konfiguracije - neizravni dokaz tome je da je tijekom novogodišnjih praznika obično sve mirno.
Osobno sam svjedočio desecima globalnih prekida rada zbog ljudske pogreške: pogrešna naredba, konfiguracija je izvršena u pogrešnoj grani, zajednica je zaboravila, MPLS je globalno uništen na usmjerivaču, pet dijelova hardvera je konfigurirano, ali pogreška nije primijećeno šestog, počinjene su stare promjene koje je napravila druga osoba. Postoji gomila scenarija.

Automatizacija će nam omogućiti da činimo manje pogrešaka, ali u većoj mjeri. Na ovaj način možete blokirati ne samo jedan uređaj, već cijelu mrežu odjednom.

Od pamtivijeka su naši djedovi provjeravali ispravnost učinjenih promjena oštrim okom, čeličnim kuglama i funkcionalnost mreže nakon što su bile izbačene.
Oni djedovi čiji je rad doveo do zastoja i katastrofalnih gubitaka ostavili su manje potomaka i trebali bi s vremenom izumrijeti, ali evolucija je spor proces, pa stoga ne testiraju svi promjene prvo u laboratoriju.
No, prednjače oni koji su automatizirali proces testiranja konfiguracije i njezine daljnje primjene na mrežu. Drugim riječima, posudio sam CI/CD proceduru (Kontinuirana integracija, kontinuirana implementacija) od programera.
U jednom od dijelova ćemo pogledati kako to implementirati pomoću sustava za kontrolu verzija, vjerojatno Githuba.

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

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

Verziranje

Pretpostavit ćemo da s bilo kakvim promjenama, čak i onim najsitnijim, čak i na jednom neprimjetnom uređaju, cijela mreža prelazi iz jednog stanja u drugo.
I uvijek ne izvršavamo naredbu na uređaju, mi mijenjamo stanje mreže.
Pa nazovimo ova stanja verzijama?

Recimo da je trenutna verzija 1.0.0.
Je li se promijenila IP adresa Loopback sučelja na jednom od ToR-ova? Ovo je manja verzija i nosit će broj 1.0.1.
Revidirali smo pravila za uvoz ruta u BGP - malo ozbiljnije - već 1.1.0
Odlučili smo se riješiti IGP-a i prebaciti samo na BGP - ovo je već radikalna promjena dizajna - 2.0.0.

U isto vrijeme, različiti DC-ovi mogu imati različite verzije - mreža se razvija, nova oprema se instalira, nove razine kralježaka se dodaju negdje, ne u drugima, itd.

na semantička verzija govorit ćemo u posebnom članku.

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

Isto vrijedi i za vraćanje promjena - ovo nije poništavanje zadnjih naredbi, ovo nije vraćanje pomoću operativnog sustava uređaja - ovo je dovođenje cijele mreže na novu (staru) verziju.

Praćenje i samoozdravljenje usluga

Ovaj samorazumljivi zadatak dosegao je novu razinu u modernim mrežama.
Često veliki pružatelji usluga imaju pristup da neispravnu uslugu treba vrlo brzo popraviti i pokrenuti novu, umjesto da utvrde što se dogodilo.
"Vrlo" znači da morate biti velikodušno obloženi 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 sučelja ili dostupnosti čvora, više nisu dovoljne. Nije dovoljno ni ručno praćenje od strane dežurnog.
Za mnoge stvari treba postojati Samoizlječenje — zapalile su se lampice za nadzor i sami smo otišli namazati trputac tamo gdje nas je boljelo.

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, što je kompliciranije.

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

• Imajte 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 sustav za opisivanje mrežnih usluga.
  IGP, BGP, L2/3VPN, Politika, ACL, NTP, SSH.
• Biti u mogućnosti inicijalizirati uređaj.
  Ime glavnog računala, Mgmt IP, Mgmt ruta, korisnici, RSA ključevi, LLDP, NETCONF
• Konfigurirajte uređaj i dovedite konfiguraciju na željenu (uključujući i staru) verziju.
• Konfiguracija testa
• Povremeno provjeravati stanje svih uređaja radi odstupanja od trenutnih i javljati kome treba.
  Preko noći je netko tiho dodao pravilo u ACL.
• Pratite performanse.

fondovi

Zvuči dovoljno komplicirano za početak rastavljanja projekta na komponente.

A bit će ih deset:

1. Sustav inventara
2. Sustav upravljanja IP prostorom
3. Sustav opisa mrežnih usluga
4. Mehanizam inicijalizacije uređaja
5. Model konfiguracije neovisno o dobavljaču
6. Sučelje upravljačkog programa specifičnog za dobavljača
7. Mehanizam za isporuku konfiguracije na uređaj
8. CI / CD
9. Mehanizam za backup i traženje odstupanja
10. Sustav nadzora

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

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

Komponenta 1: Sustav inventara

Očito želimo znati koja se oprema gdje nalazi, na što je povezana.
Sustav inventara sastavni je dio svakog poduzeća.
Poduzeće najčešće ima zaseban sustav inventara za mrežne uređaje, koji rješava specifičnije probleme.
U sklopu ove serije članaka nazvat ćemo je DCIM – Data Center Infrastructure Management. Iako sam pojam DCIM, strogo govoreći, uključuje puno više.

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

• Inventarni broj
• Naslov/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, stalak, jedinica)
• Međusobne veze između uređaja
• Topologija mreže

Savršeno je jasno da sve to želimo znati i sami.
Ali hoće li to pomoći u svrhu automatizacije?
Svakako.
Na primjer, znamo da u određenom podatkovnom centru na Leaf preklopnicima, ako je u pitanju Huawei, ACL-ove za filtriranje određenog prometa treba primijeniti na VLAN, a ako je u pitanju Juniper, onda na jedinici 0 fizičkog sučelja.
Ili trebate postaviti novi Syslog poslužitelj na sve granice u regiji.

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

Komponenta 2: Sustav upravljanja IP prostorom

Da, i danas postoje timovi ljudi koji prate prefikse i IP adrese u Excel datoteci. Ali moderni pristup još uvijek je baza podataka, s front-endom na nginx/apacheu, API-jem i opsežnim funkcijama za snimanje IP adresa i mreža podijeljenih u VRF-ove.
IPAM - Upravljanje IP adresama.

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

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

Opet, jasno je da želimo biti sigurni da kada dodijelimo novu IP adresu za ToR povratnu petlju, nećemo naići na činjenicu da je već nekome dodijeljena. Ili da smo upotrijebili isti prefiks dva puta na različitim krajevima mreže.
Ali kako to pomaže kod automatizacije?
Lako je.
Zahtijevamo prefiks u sustavu s ulogom Loopbacks, koji sadrži IP adrese dostupne za dodjelu - ako se pronađe, dodjeljujemo adresu, ako ne, tražimo kreiranje novog prefiksa.
Ili prilikom izrade konfiguracije uređaja iz istog sustava možemo saznati u kojem VRF-u sučelje treba biti smješteno.
A prilikom pokretanja novog poslužitelja, skripta se prijavljuje u sustav, pronalazi na kojem se prekidaču nalazi poslužitelj, koji je port i koja je podmreža dodijeljena sučelju - i iz toga će dodijeliti adresu poslužitelja.

Ovo sugerira želju da se kombiniraju DCIM i IPAM u jedan sustav kako se ne bi duplirale funkcije i kako ne bi služila dva slična entiteta.
To ćemo i učiniti.

Komponenta 3. Sustav za opisivanje mrežnih usluga

Ako prva dva sustava pohranjuju varijable koje se ipak trebaju nekako koristiti, onda treći opisuje za svaku ulogu uređaja kako treba biti konfigurirana.
Vrijedno je razlikovati dvije različite vrste mrežnih usluga:

• Infrastruktura
• Klijent.

Prvi su dizajnirani za pružanje osnovne povezivosti i kontrole uređaja. To uključuje VTY, SNMP, NTP, Syslog, AAA, protokole usmjeravanja, CoPP itd.
Potonji organiziraju uslugu za klijenta: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP itd.
Naravno, ima i graničnih slučajeva - gdje uključiti MPLS LDP, BGP? Da, i protokoli usmjeravanja mogu se koristiti za klijente. Ali ovo nije važno.

Obje vrste usluga rastavljene su u konfiguracijske primitive:

• fizička i logička sučelja (tag/anteg, mtu)
• IP adrese i VRF-ovi (IP, IPv6, VRF)
• ACL-ovi i pravila obrade prometa
• Protokoli (IGP, BGP, MPLS)
• Pravila usmjeravanja (popisi prefiksa, zajednice, ASN filteri).
• Pomoćne usluge (SSH, NTP, LLDP, Syslog...)
• itd.

Kako ćemo to točno izvesti, još nemam pojma. Razmotrit ćemo to u zasebnom članku.

Ako malo bliže životu, onda bismo to mogli opisati
Preklopnik Leaf mora imati BGP sesije sa svim povezanim preklopnicima Spine, uvesti povezane mreže u proces i prihvatiti samo mreže s određenog prefiksa od preklopnika Spine. Ograničite CoPP IPv6 ND na 10 pps, itd.
Zauzvrat, bodlje održavaju sesije sa svim povezanim vodovima, djelujući kao reflektori korijena, i prihvaćaju od njih samo rute određene duljine i s određenom zajednicom.

Komponenta 4: Mehanizam inicijalizacije uređaja

Pod ovim naslovom kombiniram mnoge radnje koje se moraju dogoditi kako bi se uređaj pojavio na radaru i kako bi mu se pristupilo na daljinu.

1. Unesite uređaj u sustav inventara.
2. Odaberite IP adresu za upravljanje.
3. Postavite osnovni pristup njemu:
   Ime glavnog računala, IP adresa upravljanja, ruta do mreže upravljanja, korisnici, SSH ključevi, protokoli - telnet/SSH/NETCONF

Postoje tri pristupa:

• Sve je potpuno ručno. Uređaj se donosi na postolje, gdje će ga obični organski čovjek unijeti u sustave, spojiti na konzolu i konfigurirati. Može raditi na malim statičkim mrežama.
• ZTP - Zero Touch Provisioning. Hardver je stigao, ustao, primio adresu preko DHCP-a, otišao na poseban server i sam se konfigurirao.
• Infrastruktura konzolnih poslužitelja, gdje se početna konfiguracija odvija kroz konzolni port u automatskom načinu rada.

O sva tri ćemo govoriti u zasebnom članku.

Komponenta 5: Model konfiguracije neovisno o dobavljaču

Do sada su svi sustavi bili različite zakrpe koje su davale varijable i deklarativni opis onoga što želimo vidjeti na mreži. Ali prije ili kasnije, morat ćete se suočiti s pojedinostima.
U ovoj fazi, za svaki određeni uređaj, primitive, usluge i varijable se kombiniraju u konfiguracijski model koji zapravo opisuje potpunu konfiguraciju određenog uređaja, samo na način neutralan prema dobavljaču.
Što ovaj korak radi? Zašto ne biste odmah izradili konfiguraciju uređaja koju možete jednostavno učitati?
Zapravo, ovo rješava tri problema:

1. Nemojte se prilagođavati određenom sučelju za interakciju s uređajem. Bio to CLI, NETCONF, RESTCONF, SNMP - model će biti isti.
2. Nemojte držati broj predložaka/skripti prema broju dobavljača na mreži, a ako se dizajn promijeni, promijenite istu stvar na više mjesta.
3. Učitajte konfiguraciju s uređaja (backup), stavite je u potpuno isti model i izravno usporedite ciljnu konfiguraciju s postojećom kako biste izračunali delta i pripremili konfiguracijski patch koji će promijeniti samo one dijelove koji su potrebni ili identificirati odstupanja.

Kao rezultat ove faze dobivamo konfiguraciju neovisnu o dobavljaču.

Komponenta 6. Sučelje upravljačkog programa specifičnog za dobavljača

Ne biste se trebali laskati nadama da će jednog dana biti moguće konfigurirati cisku na potpuno isti način kao Juniper, jednostavno slanjem potpuno istih poziva njima. Unatoč sve većoj popularnosti whiteboxova i pojavi podrške za NETCONF, RESTCONF, OpenConfig, specifični sadržaji koje ovi protokoli isporučuju razlikuju se od dobavljača do dobavljača, a to je jedna od njihovih konkurentskih razlika koje se neće tako lako odreći.
Ovo je otprilike isto kao što OpenContrail i OpenStack, koji imaju RestAPI kao NorthBound sučelje, očekuju potpuno različite pozive.

Dakle, u petom koraku, model neovisan o dobavljaču 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 upravljački program koji će prenijeti rezultat prethodnog koraka u traženi format određenog dobavljača: skup CLI naredbi, XML strukturu.

Komponenta 7. Mehanizam za isporuku konfiguracije na uređaj

Generirali smo konfiguraciju, ali je još treba dostaviti na uređaje - i to, očito, ne ručno.
Prvo, postavljamo pitanje kojim prijevozom ćemo se služiti? A danas izbor više nije mali:

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

Stavimo točku na t ovdje. CLI je nasljeđe. SNMP... kašalj kašalj.
RESTCONF je još uvijek nepoznata životinja; REST API ne podržava gotovo nitko. Stoga ćemo se u seriji usredotočiti na NETCONF.

Zapravo, kao što je čitatelj već shvatio, do ove točke već smo odlučili o sučelju - rezultat prethodnog koraka već je predstavljen u formatu sučelja koje je odabrano.

drugo, i kojim alatima ćemo to učiniti?
Ovdje također postoji veliki izbor:

• Skripta ili platforma koju sam napisao. Naoružajmo se ncclientom i asyncIO i napravimo sve sami. Koliko nas košta izgradnja sustava za implementaciju od nule?
• Ansible sa svojom bogatom bibliotekom mrežnih modula.
• Sol svojim oskudnim radom s mrežom i vezom s Napalmom.
• Zapravo Napalm, koji poznaje par prodavača i to je to, doviđenja.
• Nornir je još jedna životinja koju ćemo secirati u budućnosti.

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

Što je tu još važno? Posljedice primjene konfiguracije.
Uspješno ili ne. Postoji li još uvijek pristup hardveru ili ne?
Čini se da će commit ovdje pomoći s potvrdom i provjerom valjanosti onoga što je preuzeto na uređaj.
To, u kombinaciji s ispravnom implementacijom NETCONF-a, značajno sužava raspon prikladnih uređaja - malo proizvođača podržava normalne obveze. Ali ovo je samo jedan od preduvjeta u RFP. Na kraju, nitko se ne brine da niti jedan ruski dobavljač neće ispuniti uvjet 32*100GE sučelja. 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čito, oni mogu biti nula za većinu čvorova.

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

CI/CD je kratica za 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ć redovito postupno implementira (uvođenje) nove funkcionalnosti u malim dijelovima, od kojih je svaka opsežno testirana na kompatibilnost, sigurnost i izvedba (Integracija).

Da bismo to učinili, imamo sustav za kontrolu verzija koji prati promjene konfiguracije, laboratorij koji provjerava je li klijentska usluga pokvarena, sustav za praćenje koji provjerava tu činjenicu, a posljednji korak je uvođenje promjena u proizvodnu mrežu.

S izuzetkom naredbi za otklanjanje pogrešaka, apsolutno sve promjene na mreži moraju proći kroz CI/CD cjevovod - to je naše jamstvo za miran život i dugu, sretnu karijeru.

Komponenta 9. Sigurnosni sustav i sustav za otkrivanje anomalija

Pa, nema potrebe ponovno govoriti o sigurnosnim kopijama.
Jednostavno ćemo ih staviti u git prema kruni ili prema činjenici promjene konfiguracije.

Ali drugi dio je zanimljiviji - netko bi trebao pripaziti na ove sigurnosne kopije. I u nekim slučajevima taj netko mora otići i okrenuti sve kako je bilo, a u drugim mjauknuti nekome da nešto nije u redu.
Na primjer, ako se pojavio novi korisnik koji nije registriran u varijablama, trebate ga ukloniti dalje od hacka. A ako je bolje ne dirati novo pravilo vatrozida, možda je netko samo uključio otklanjanje pogrešaka ili možda nova usluga, bungler, nije registrirana prema propisima, ali su joj se ljudi već pridružili.

Još uvijek nećemo pobjeći od neke male delte na razini cijele mreže, unatoč bilo kakvim sustavima automatizacije i čeličnoj ruci menadžmenta. Kako bi se otklonili problemi, nitko ionako neće dodati konfiguraciju sustavima. Štoviše, možda čak i nisu uključeni u konfiguracijski model.

Na primjer, pravilo vatrozida za brojanje broja paketa po određenoj IP adresi za lokaliziranje problema sasvim je obična privremena konfiguracija.

Komponenta 10. Sustav nadzora

Isprva nisam namjeravao govoriti o temi monitoringa - to je još uvijek opsežna, 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 prakse.

Evolucija misli organski je dio procesa CI/CD. Nakon postavljanja konfiguracije na mrežu, moramo moći utvrditi je li sada sve u redu s njom.
I ne govorimo samo i ne toliko o rasporedima korištenja sučelja ili dostupnosti čvorova, već o suptilnijim stvarima - prisutnosti potrebnih ruta, atributa na njima, broja BGP sesija, OSPF susjeda, performansi End-to-End gornjih usluga.
Jesu li se syslogovi prema vanjskom poslužitelju prestali zbrajati, ili se SFlow agent pokvario, ili su padovi u redovima čekanja počeli rasti, ili se pokvarila povezanost između nekih par prefiksa?

O tome ćemo razmisliti u zasebnom članku.

Zaključak

Kao osnovu odabrao sam jedan od modernih dizajna mreže podatkovnih centara - L3 Clos Fabric s BGP kao protokolom usmjeravanja.
Ovaj put ćemo izgraditi mrežu na Juniperu, jer sada je JunOs sučelje omiljeno.

Zagorčajmo si život koristeći samo Open Source alate i mrežu s više dobavljača - pa ću uz Juniper usput odabrati još jednog sretnika.

Plan za nadolazeće publikacije je otprilike ovakav:
Prvo ću govoriti o virtualnim mrežama. Prije svega zato što to želim, a drugo zato što bez toga projekt infrastrukturne mreže neće biti baš jasan.
Zatim o samom dizajnu mreže: topologija, usmjeravanje, politike.
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ćajem da ću elegantno završiti ovaj ciklus s gotovim rješenjem. 🙂

korisni linkovi

• Prije nego što se upustite u seriju, vrijedi pročitati knjigu Natashe Samoilenko Python za mrežne inženjere. A možda i prođe tečaj.
• Također će biti korisno pročitati RFC o dizajnu tvornica podatkovnih centara s Facebooka Petera Lapukhova.
• Dokumentacija o arhitekturi će vam dati ideju o tome kako Overlay SDN funkcionira. Tkanina od volframa (bivši Open Contrail).

Hvala vam

Rimski klanac. Za komentare i izmjene.
Artjom Černobaj. Za KDPV.

Izvor: www.habr.com