Из техничких разлога садржај читалишта можете пратити искључиво на латиници.

Arhitektura mrežnog upravljanja (2.)

3 Model upravljanja mrežom

Postoje tri različita pristupa implementacije upravljačkog rešenja:

  • izolovani pristup;
  • koordinisani pristup;
  • integrativni pristup.

Arhitektura

Slika 2: Model upravljanja mrežom

Kod izolovanog pristupa, izolovani alati kreiraju se za svaki upravljački problem. Alati rade nezavisno jedan od drugog na osnovu nezavisnih podataka i s nezavisnim korisničkim interfejsima.

Kod koordinisanog pristupa, alati su i dalje nezavisni ali oni obezbeđuju funkcije koje su koordinisane. To, na primer, znači da se rezultati koje dobija jedan alat upotrebljavaju kao ulaz za drugi alat. Skriptovi se koriste za programiranje interakcije različitih alata.

Ako se komponentama upravlja u jednom heterogenom okruženju i ako je omogućen pristup informacijama na jedan nezavisan način, onda govorimo o integrativnom pristupu menadžmenta. Tim informacijama pristupa se preko dobro definisanih intrfejsa i protokola.

Ako se upravljačka platforma koristi za integrativni menadžment u heterogenom okruženju, tada moraju biti specifikovani sledeći aspekti:

  • opis upravljanih objekata (informacioni model);
  • tretiranje i podrška organizacionom aspektu, ulogama i koorporacijskoj formi (organizacioni model);
  • opis komunikacionog procesa u upravljačke svrhe (komunikacioni model);
  • strukturisanje menadžment funkcionalnosti (funkcionalni model).

3.1 Informacioni model

Kod heterogenih sistema ne postoji a priori saznanje koje informacije je potrebno razmeniti da bi se rešio posao upravljanja.

Upravljani objekat predstavlja karakteristike resursa na kojima se izvodi upravljanje. Informacioni model mora da obezbedi mogućnosti i da specifikuje:

  • kako se objekat može identifikovati;
  • od čega se sastoji;
  • kako se ponaša;
  • kako se njime može manipulisati;
  • koje relacije postoje s drugim upravljanim objektima.

Upravljanje u sklopu menadžment arhitekture označava pristup upravljanom objektu zahvaljujući upotrebi upravljačkih komandi koje se prenose pomoću upravljačkog protokola do upravljanog entiteta (agent) koji je odgovoran za upravljani objekat.

Informacioni model menadžment arhitekture definiše pristup modelovanju (relacija između entiteta, tipova podataka, ...) i jedinstvenoj notaciji za opis upravljačkih informacija. ISO i OMG su definisali objektno orijentisani pristup modelovanja, IAB (Internet Architecture Board) pristup zasnovan na tipu podataka. ISO i IAB/IETF (Internet Engineering Task Force) koriste podskup jezika za opis ASN.1 (Abstract Syntax Notation One), OMG (Object Management Group) koristi IDL (Interface Definition Language) i tipove podataka programskih jezika pomoću CORBA-e (Common Object Request Broker Architecture).

Izbor modelovanih karakteristika resursa neizbežno utiče na delokrug funkcionisanja upravljačke aplikacije. Tip modelovanja i stepen apstrakcije takođe ima uticaja na kompleksnost aplikacije. Način na koji se specifikuju upravljačke informacije u formi upravljačkih objekata i odgovarajućih atributa, operacija i poruka, ima centralnu važnost za menadžment.

Slika 3: Informacioni model

Upravljačke informacije specifikuju se iz različitih perspektiva:

  • resursa;
  • procedura;
  • proizvođača;
  • operatera;
  • korisnika.

Pristup od dna ka vrhu dovodi do toga da se izvode upravljački relavantne apstrakcije iz propisanih protokola, komponenata i produkata. Pristup od vrha ka dnu pokušava da izvede upravljačke informacije iz zahteva za upravljačku aplikaciju, korisnika ili operatera.

3.2 Organizacioni model

Menadžment arhitektura ne bi trebalo da ima prejudicirajući uticaj na organizacionu i operativnu strukturu mrežnog sistema, ali ona mora da podrži razumljivu formu koja karakteriše organizaciju I obezbedi odgovarajuću opciju za adaptaciju.

Na slici su prikazani različiti topološki i funkcionalni aranžmani koji postoje za upravljačke sisteme. Kod centralizovanog menadžmenta jedan NMS je odgovoran za sve zadatke. Kod multipoint kontrole resursi se kombinuju u grupe (domene) prema nekim aspektima (topologija, funkcionalnost, organizacija) i menadžer je dodeljen svakoj grupi. Ako želite da koordinirate menadžerima u pristupu multipoint, tada, u zavisnosti od koorporacijske šeme, to proizvodi ili multicentar kontrolu ili hijerarhijski menadžment.

Publication1

Slika 4: Topološki i funkcionalni aranžmani upravljačkih sistema

Kompleksnije forme su mreže menadžera gde ne postoji jasna alokacija resursa upravljačkom sistemu. Tip alokacije zavisi od mnogo faktora. Tako, na primer, isti resurs može biti alociran na više menadžera ako je jedan menadžer odgovoran za upravljanje bezbednošću, a drugi za upravljanje performansama.

Organizacioni model menadžment arhitekture definiše učesnike, njihove uloge i fundamentalne principe njihove koordinacije. Postoje dve različite forme kooperacije u menadžmentu.

Menadžment-agent model sa svojom asimetrično-hijerarhijskom kooperativnom formom koja podrazumeva relaciju tipa korisnik–dobavljač za njihovu kooperaciju, što je slično s poznatim modelom klijent–server. Menadžer (klijent) upućuje zahtev agentu (server) da izvrši određenu operaciju ili da pribavi informaciju. Agent odgovara rezultatom operacije ili zahtevanom informacijom. To reprezentuje relaciju tipa m:n jer menadžer može da uposli više agenata, a svaki agent može da usluži više menadžera. Ovo je najpopularnija forma kooperacije koja se trenutno koristi u oblasti menadžmenta. OSI menadžment i Internet menadžment koriste ovu formu.

Trenutno je aktuelna pojava simetrične koorporacijske forme koja proizlazi iz komunikacije i kooperacije u osnovi istih objekata. Ova forma podrazumeva razmenu informacija u oba smera i poznata je kao pear-to-pear pristup. CORBA koristi ovu vrstu kooperaivnog modela. Često je potrebno okarakterisati podskup pojedinačnih resursa u grupe, na primer domene, zbog organizacionih razloga. Ako organizacioni model obezbeđuje koncept domena, on mora da specifikuje kako se oni formiraju, kako se dodeljuju odgovornosti domenima i kako se one mogu modifikovati dinamički.

S konceptom domena blisko je povezan koncept politike. Politika je propisani kurs akcija izveden iz korporativnog cilja ili IT procesa. Primer politike uključuje na primer:

  • backup će biti startovan u ponedeljak uveče;
  • password će biti promenjen najkasnije na svake četiri nedelje
  • svi podaci koji se prenose između departmana biće kodirani.

3.3 Komunikacioni model

Menadžment predstavlja monitoring i kontrolu fizički rasturenih resursa. Bitan deo tog posla jeste razmena upravljačkih informacija. Komunikacioni model menadžment arhitekture definiše koncept razmene informacija između entiteta.

Komunikacija se ostvaruje:

  • kroz razmenu kontrolnih informacija koje treba da imaju uticaja na resurs ili upravljani objekat koji predstavlja resurs;
  • kroz zahtev za očitavanje statusa (monitoring);
  • kroz asinhronu razmenu poruka koju inicira sistem u kojem se resurs nalazi.

Konsekventno komunikacioni model bavi se sledećim aspektima:

· specifikuje komunikacione partnere;

· specifikuje komunikacione mehanizme, servise i protokole za razmenu upravljačkih informacija;

· definiše sintaksu i semantiku i strukturu podataka koji se razmenjuju;

· ugrađuje menadžment protokole unutar arhitekture servisa ili hijerarhije protokola.

3.4 Funkcionalni model

Funkcionalni model pokušava da specifikuje opšte menadžment funkcije i deli čitav kompleks menadžmenta u funkcionalne oblasti kao što su menadžment konfigurisanja, menadžment grešaka, menadžmenta naloga... Očekivane funkcionalnosti i servisi koje upravljani objekat zahteva da bi implementirao određene funkcionalnosti moraju prethodno biti definisane u funkcionalnom modelu za individualne funkcionalne oblasti.

Na slici su prikazani moduli aktivnosti vezani za korisnički nalog.

Slika 5: Moduli aktivnosti korisničkog nalog

Ako se funkcionalni model koristi za opis iskoristivosti resursa u upravljanju performansama, tada tri nivoa modela predstavljaju:

· iskoristivost resursa;

· učestalost zahteva za resursom i

· učestalost odbitaka (reject).

Za svaki nivo treba definisati maksimalnu vrednost i nekoliko upozoravajućih stanja, kao i njihovu rezoluciju. Tada je moguće napisati menadžment aplikaciju koja bi korstila tu funkciju iskoristivosti i u zavisnosti od vršnih vrednosti inicirati događaje ili okidače korektivnih akcija.