Načela digitalne arhitekture v IT-infrastrukturnih rešitvah

Načela digitalne arhitekture v IT-infrastrukturnih rešitvah
26. 10. 2017 Adam Sabljakovic

JANEZ GRUDEN

2.del

Načela digitalne arhitekture
v IT-infrastrukturnih
rešitvah

V infrastrukturni portfelj rešitev prodirajo koncepti programabilnosti (»machine-to-machine« kot nadgradnja načina konfiguriranja naprav prek vmesnikov »command line/ web-GU I«) in orkestracije delovnih tokov (»workflows«) s cilji avtomatizacije ponavljajočih se opravil, omejitve človeškega faktorja (napake) in ureditve (strukturirani pristop). S poslovnega vidika je avtomatizacija sinonim za klic po ureditvi in poenostavitvi načina dela: priporočeno je začeti z manjšimi sklopi avtomatiziranih rešitev v okoljih, kjer obvladujemo procesno in tehnološko plat.

Avtomatizacija in orkestracija postajata nova infrastrukturna gradnika upravljanja IT-sistemov. Veliki proizvajalci, ponudniki storitev, standardizacijske in odprtokodne iniciative razvijajo idejo korak dalje ter oglašujejo zasnovo digitalne arhitekture v infrastrukturi na temeljih odprte, razširljive in programsko krmiljene platforme, zmožne zadostiti novejšim zahtevam aplikacij.

 

Zveni znano? »Software defined« definicije so se malce izpele in so iznašli novo, kar ni ničnovega za IT-industrijo. Ker neformalne delovne skupine in standardizacijske entitete še niso dosegle soglasja, opisi ter definicije nove arhitekture ne presežejo marketinške namembnosti, če jih ne podkrepimo z razlago. Za izhodišče vzemimo omrežno arhitekturo.

Pri avtomatizaciji se spreminja način upravljanja (»management plane«), ki preko orkestracijskih mehanizmov programsko komunicira s »control« in posledično »data plane« ravnmi na usmerjevalnikih in stikalih. »Control« in »data plane« ostajata v obstoječih vlogah z vsemi mehanizmi (»protocols/ control« in »forwarding/data«).

Bistvo digitalne arhitekture se skriva v razumevanju vlog (»roles«): infrastruktura ni več množica naprav, ki jih upravljamo po sistemu samostojne naprave, ampak skupek elementov,interpretiranih v podatkovnih sistemih. Namesto »network – collection of devices« govorimo o »network as a model«. Nivo upravljanja (»management plane«) se razmejuje na servisni nivo (»services«) in nivo krmilnika (»controller«), ki upravljata programsko nastavljive elemente (»elements«) v infrastrukturi. Funkcionalno imamo opraviti s servisi (»Services: Policy in Orchestration«).

Tabela1

Tabela 1: Nivoji digitalne arhitekture v infrastrukturi

Ukazne vrstice so za ljudi, avtomatizacija potrebuje programabilne vmesnike in podatkovne modele

Za razumevanje »software-defined« konceptov je pomemben odmik od rabe ukaznih vrstic preko vmesnika, prirejenega človeku (»command line interface – CLI«), in prevajalnika (»parser«) na napravah. Ideja se vrti okoli pravilne ugotovitve, da v digitalni arhitekturi servisni nivo in kontrolerji ne potrebujejo nepotrebnega vmesnega člena. Način komunikacije preko vmesnikov, prirejenih za človekovo rabo („human-to-machine command lines« – CLI), ne zadostuje več. API (»application programmatic interface”) v različicah REST/NETCONF/ RESTCON kot transportni »machine-to-machine« vmesnik s podatkovnim formatom tipa XML ali JSON standardizira komunikacijo, ne pa tudi interpretacije.

Prenesti ukazno vrstico v API seji XML/JSON ne omogoča polne avtomatizacije, kajti proizvajalci podpirajo različne formate. Prav tako niso standardizirani odzivi upravljanih sistemov.

Po pravilu, da za vsak tehnološki problem obstaja rešitev v obliki dodatnega nivoja interpretacije, digitalna arhitektura prinaša nivo abstrakcije v obliki modeliranih storitev.

V primeru nastavitve BGP-usmerjanja je status zapisan v znani podatkovni strukturi na usmerjevalniku in krmilniku ter dostopen servisnemu nivoju.

Ukaz CLI/SSH vrne odziv v obliki teksta, API-klic v formatu XML/
JSON – v obeh primerih ni konsistence, vrnjeni zapis je odvisen od programske
opreme in proizvajalca. Rešitev je zapis storitve v podatkovni
strukturi (»data modeling«), ki jo razumejo krmilniki in naprave.
Pot, od konfiguracije posameznih naprav do obdelave podatkov,je
tlakovana z idejo modeliranih storitev (»data models«) na napravah in
krmilnikih, neodvisno od proizvajalca.
Nič povsem novega, SNMP je gojil podobno zasnovo,
kakopak z manjšimi ambicijami.

Nekonsistentnost in avtomatizacija stojita na različnih bregovih. Konsistenten način rabe mehanizmov neodvisno od proizvajalcev opreme je temeljna podlaga za »open automation«. Prednost »machnine-to-machine API« pristopa je v servisnih programabilnih vmesnikih in v podatkovnih modelih zapisanih storitev s konfiguracijskimi ter statusnimi podatki (»OpenConfig/IETF data models, Yang language for data modeling«) z možnostjo obdelave transakcij (»Datastores«). Skupaj z virtualizacijo predstavlja možnost izbire: katerakoli storitev kjerkoli (tabela 2).

Za vse s spominom na zgodnje dni tehnologije MPLS (l. 1999–2000): v tistem času za mnoge nepotreben dodatni nivo odločanja, namesto IP-naslova labela (oz. »tag«) skupaj z virtualnimi usmerjevalnimi tabelami (»VRF«) ni nič drugega kot nivo abstrakcije pri usmerjanju prometa.

Tabela2

Tabela 2: Koncepti in protokoli digitalne arhitekture v infrastrukturi

Digitalna arhitekturav praksi – pristop k avtomatizaciji procesno/tehnološko obvladljivih sklopo

V IT-oddelke bi bilo nespametno prenašati pristope velikih preskokov. Nepremišljenost v praksi trči na nepremostljive ovire lastnih sposobnosti in obstoječih postavitev. Na SRC-u se digitalizacije v infrastrukturi lotevamo s postopno uvedbo avtomatizacije. Pri tehtanju smiselnosti si postavljamo vprašanje, kaj rešujemo, oz. opravilo, ki ga poenostavljamo/ standardiziramo (nekaj primerov v tabeli 3). Ne moremo še govoriti o uveljavitvi pristopa upravljanja modeliranih storitev v praksi. Bistvo ni v arhitekturi, ampak v osredotočenosti na nov način dela.

tabela3_1
tabela3_2
tabela3_3

Tabela 3: Primeri rabe avtomatizacije

V avtomatizacijo analize delovanja omrežnih naprav načrtno uvajamo programski jezik Python, prav tako v postopke posegov v obliki zapisov »rollback« procedur:

  • avtomatizirana datoteka CLI-ukazov za izvajanje rednega preventivnega vzdrževanja (analiza podatkov s korelacijo dogodkov, točnost in ponovljivost),
  • grafična prezentacija (orodje NeXt UI) statusa prometa.

Z orkestratorjem Ansible, krmiljenim preko Cisco Spark »bot«-ov, orkestriramo aktiven nadzor nad spremembami v omrežju:

  • Cisco Spark za poganjanje programov in izvajanje procedur Ansible (interpretacija za neprogramerje, prevajanje vrealnem času),
  • avtomatska primerjava konfiguracij in shranjevanje na MS-datotečni sistem SharePoint.

Kontroler Cisco APIC-EM z elementi krmiljenja in servisov pregleda omrežja:

  • preverjanje verodostojnosti in identitete omrežnih naprav v omrežju,
  • spremljanje veljavnosti zagonskega procesa, avtentičnosti opreme in konfiguracij.

Cisco UCS Director za orkestracijo delovnih tokov pri nastavitvah virtualnih strežnikov, podatkovnih platform in omrežnega prometa v podatkovnih centrih:

  • uporabnikom je na voljo samopostrežna nastavitev virtualnih okolij iz nabora sistemov Windows in Linux,
  • proces je integriran v ITIL-sistem, omogočena je kontrola nad dejansko rabo virov.

ZAKLJUČEK

Odveč je bojazen, da infrastrukturni inženirji postajajo programerji. Verjeten domet bi bil povprečnost, kajti mojstrstvo se ne doseže s polovičnim pristopom k programiranju. Enako odsvetujem pretiran odpor do sprememb. Poznavanje konceptov in nekaj rutinskega programerskega znanja zadostuje za implementacije. Popotovanje v »software defined« svet, kot bi zapisali načrtovalci.

Če uživate v člankih, jih delite s prijatelji. Lepe stvari je lepo deliti.