Piše: Tomislav Pongrac
Već dugo ne radim kao mrežni inženjer. Prije previše godina sam zadnji put konfigurirao ozbiljnije mreže. Danas inženjeri rade na puno moćnijim sustavima, ali proces upravljanja je vrlo sličan onome kakav je bio kad sam se ja time bavio.
Evo primjera iz tipičnog dana mrežaša.
Cilj: želim napraviti provjeru konfiguracije ili stanja na nekom nizu uređaja. Npr.
- Pregledati VLAN-ove na preklopnicima i njihovim sučeljima
- Uvjeriti se da je na nekom skupu routera uključen ispravni logging server
- Pregledati ima li više uređaja ispravno stanje OSPF susjeda
- Provjeriti jesu li svi interfacei u ispravnom admin i operativnom stanju
- Provjeriti sadrži li sigurnosna access lista jedan entry potreban za funkcioniranje servisa
Koraci do cilja bi izgledali otprilike ovako:
- Pregledam shemu ili tablicu uređaja na mreži (ili znam uređaje napamet) i na njoj vidim na kojim uređajima trebam napraviti provjeru
- Otvorim omiljeni SSH klijent i povezujem se na uređaj koji trebam
- Nakon logina upisujem naredbe koje rezultiraju ispisom koji meni pruža potrebne informacije. Često su to vrlo opsežni outputi. Koristeći svoje znanje i intuiciju iz šume podataka vadim nekoliko ključnih informacija.
- Postupak ponovim na koliko god uređaja treba
Po ovom uvodu i samom naslovu, pretpostavljam da slutite gdje to vodi. Odgovor je: da. To može bitno bolje i to može biti automatizirano. Primjeri koje sam naveo u mrežnoj automatizaciji se zovu “operational state validation” i “scoped configuration management”. Jako fancy nazivi za dobar dio posla kojeg svakodnevno rade mrežni inženjeri. Jedino – sve to automatizirati nije tako lako i jednostavno.
Problem
Primjeri su jednostavni, ali postoji razlog zašto se ti postupci nisu dovoljno automatizirali. Mrežu je teško automatizirati.
- Dosad dostupni alati su bili manjkavi – generirali su nepregledne konfiguracije kojima se nije moglo upravljati. Čak i ako su alati napravljeni od samih proizvođača
- Ako API nije konzistentan ili (još gore) ako se automatizira putem CLI naredbi – male razlike u verziji softvera mrežnog uređaja mogu predstavljati velik problem
- Broj funkcija koje se mogu dobiti iz alata je puno manji od onih koje se mogu dobiti kroz CLI.
- Upitno je zašto programski upravljati mrežom ako je svaki uređaj jedinstven pa svaki ima velik dio konfiguracije koji je specifičan samo za njega
- Kako testirati rezultate promjena? Što ako se automatskom promjenom konfiguracije odspojim i više ne mogu pristupiti uređajima?
Mrežaši su s razlogom skeptični. Vidjeli su puno promašaja. I kad je pravi problem nastupio, imali su puno slučajeva kad im je jedini prijatelj bio command line (CLI) i direktan pristup uređajima. Jedna od velikih pogrešaka koje sam vidio prilikom ovakvih inicijativa je postavljanje problema kao CLI vs. automatika. Nitko pri zdravoj pameti ne želi ukinuti pristup uređajima, pogotovo u slučaju havarije. Ono o čemu se priča je pojednostavljenje onog na što se troši najviše vremena: kontinuirano upravljanje mrežom. Ono što zovu operations i configuration management. A to se zaista može automatizirati.
Što se promijenilo da se sad mogu riješiti primjedbe mrežaša?
Sa strukturiranom automatizacijom mreže smo krenuli još prije dosta godina. Tu ne mislim na korištenje uobičajenih skripata. To se koristi oduvijek. Mislim na korištenje centraliziranih alata tipa Ansible i primjenu na većim okolinama.
U tim početcima bilo je bolno. I jednostavni primjeri upravljanja konfiguracijama su tražili mnoge prilagodbe ispod haube. Integracije su bile malobrojne i manjkave. To je sad značajno unaprijeđeno. Broj integracija, njihova kvaliteta i broj podržanih funkcija je značajno narastao.
Povećale su se i mogućnosti prezentacije konfiguracijskih podataka. Potpuno prilagođeno web sučelje s konfiguracijskim podacima se može kreirati bez osobitog znanja web programiranja.
Stigli su novi koncepti softverski upravljane mreže (SDN). S njima i konzistentniji načini pristupa opremi (API). Ta činjenica, naravno, olakšava automatizaciju. No bez obzira na koncept izvedbe mreže (klasični ili softverski definiran), pristup nam mora biti isti. Jako je vjerojatno da ćemo još poprilično dugo vremena živjeti i raditi u hibridnom svijetu u kojem će se ovi koncepti preklapati.
Kako pristupamo automatizaciji mreže i koja nam je vizija?
Već neko vrijeme štedimo značajne resurse koristeći automatizaciju. Automatiziramo dijelove konfiguracije mrežnih uređaja, upravljamo i arhiviramo konfiguracije, pratimo operativno stanje važnih dijelova mreže.
Kod pristupa automatizaciji generalno se vodimo sljedećim koracima, bez obzira je li riječ o novim ili postojećim korisnicima:
- Krenuti s quick winovima. Npr. kroz Ansible s mrežašima složimo dinamički kreirano web sučelje koje prikazuje real-time odgovore na pitanja s početka ovog posta.
- Nastaviti ili započeti proces u kojem će se prije svega mrežni inženjeri uvjeriti da je izvor istine (onaj famozni kod na Gitu) vjerodostojna reprezentacija konfiguracije mreže.
- Postupno povećavati udio konfiguracije koji je pod upravljanjem automatike (za početak opći dijelovi konfiguracije, kasnije i specifični protokoli i sučelja)
- Paralelno razvijati opseg praćenja operativnog stanja. Krenuti s jednostavnijim stanjima protokola prema kompleksnijim.
- Kad se ispune uvjeti, uklopiti upravljanje mrežom u automatizirane procese ostalih dijelova IT-a (kontejneri, virtualizacija, security …)
- Osigurati povjerenje u provjere konfiguracije i operativnog stanja. Nakon što mrežaši mogu povjerovati da rezultati automatske provjere i stanje na Git serveru znače 1/1 da njihova mreža radi, postigli smo puno. I tu možemo reći da smo bliže Svetom gralu mrežne automatizacije – punoj implementaciji NetOps koncepta gdje se automatski odvija proces konfiguracije, provjere i ažuriranja dokumentacije.
Post je već sad predugačak, pa neću dalje o NetOps konceptu. O tome ću drugom prilikom.
Ono što je najbitnije – i prvih nekoliko koraka na ovom putu će mrežnog inženjera učiniti sretnim jer se neće baviti dosadnim, jednoličnim poslovima, jer ima konzistentne konfiguracije po cijeloj mreži i jer spava mirno, znajući da mu je stanje mreže u potpunoj kontroli.
