vis skrlj vasilij 1968 93492497 · aix advanced interactive executive bac business availability...

Vasilij Škrlj

UPRAVLJANJE IN NADZOR SISTEMA ZA

ELEKTRONSKO PREDLOŽITEV CARINSKIH

DEKLARACIJ (NCTS) CARINSKE UPRAVE RS

Diplomsko delo

Maribor, julij 2009

I

Diplomsko delo visokošolskega strokovnega študijskega programa

UPRAVLJANJE IN NADZOR SISTEMA ZA ELEKTRONSKO

PREDLOŽITEV CARINSKIH DEKLARACIJ (NCTS) CARINSKE

UPRAVE RS

Študent: Vasilij Škrlj

Študijski program: VS ŠP Računalništvo in informatika

Smer: Logika in sistemi

Mentor: viš. pred. dr. Andrej Šoštarič, visokošolski sodelavec asistent

za računalništvo

Somentor: red. prof. dr. Damjan Zazula, visokošolski učitelj uni za

računalništvo

Maribor, julij 2009

IV

ZAHVALA

Predvsem se zahvaljujem ženi Damijani, za

njeno podporo in zaupanje v smiselnost mojega

početja.

Zahvala gre tudi dr. Šoštariču, ker mi je

omogočil in pomagal izpeljati nalogo in za vso

pomoč pri njenem nastajanju ter sodelavcema

Edu in Dejanu, ki sta soustvarjalca Nadzornega

sistema Nagios.

V

UPRAVLJANJE IN NADZOR SISTEMA ZA ELEKTRONSKO

PREDLOŽITEV CARINSKIH DEKLARACIJ (NCTS) CARINSKE

UPRAVE RS

Klju čne besede: nadzor, ITIL, porazdeljeni sistem, nadzor nad sistemom,

procesiranje transakcij BEA Tuxedo, aplikativne rešitve, tranzitni sistem NCTS

UDK: 004.774.6:336.247(043.2)

Povzetek

Diplomska naloga uvodoma predstavi problem velikih in kompleksnih informacijskih

sistemov. Ena pomembnih nalog je nadzor nad delovanjem takih sistemov, kar rešujemo

s pomočjo priporočil ITIL, kot dobre prakse in z različnimi orodji, ki so dosegljiva na

trgu. V nadaljevanju so predstavljena orodja, ki so trenutno na voljo: tako komercialna

kot odprtokodna. Podrobneje je predstavljeno nadzorno orodje Nagios. Jedro naloge je

spoznavanje porazdeljenega transakcijskega sistema NCTS (New Computerized Transit

System), ki ga uporabljajo v šestnajstih državah članicah Evropske skupnosti in služi

carinskim upravam pri spremljanju tranzita blaga. V nadaljevanju naloge se seznanite

tudi s pripravo in vpeljavo nadzornega sistema v carinski informacijski sistem.

VI

MANAGEMENT AND MONITORING OF THE NCTS SYSTEM OF

CARINSKA UPRAVA RS

Key words: monitoring, ITIL, distributed system, system monitoring, BEA Tuxedo transaction processing, application solutions, transit system NCTS

UDK: 004.774.6:336.247(043.2)

Abstract

In diploma thesis handling of big and complex information systems is introduced. One

of the important tasks is systems operation supervision and monitoring, which can be

solved with ITIL assistance as a good practice and with different tools, which are

available on the market. These tools, being commercial or open–source, are promoted

in continuation of the thesis. Supervision tool Nagios is presented more exactly. Core

of the thesis is recognition of the division transaction system NTCS (New Computerized

Transit System), which is used in 16 EU member states and serves to the customs

control of the goods transit. Finally, a practical example of the customs information

control system is introduced and presented.

VII

VSEBINA

1 UVOD..................................................................................................................... 1

2 UPRAVLJANJE IN NADZOR RA ČUNALNIŠKIH SISTEMOV IN

OMREŽIJ .............................................................................................................. 4

3 OPIS UPRAVLJALSKIH IN NADZORNIH SISTEMOV........... .................... 7

3.1 KOMERCIALNI SISTEMI......................................................................................... 8

3.2 ODPRTOKODNI SISTEMI........................................................................................ 9

3.3 SISTEM NAGIOS.................................................................................................. 11

4 IMPLEMENTACIJA IN NADGRADNJE ZA POTREBE SISTEMA NCT S

............................................................................................................................... 20

4.1 KRATEK OPIS SISTEMA/OMREŽJA CURS IN NCTS ............................................. 20

4.2 VHODNE, IZHODNE IN VMESNE ČAKALNE VRSTE ................................................ 23

4.2.1 Vrstni vmesnik ECN TUXEDO.................................................................... 24

4.2.2 Vhodne vrste ECN ........................................................................................ 24

4.2.3 Izhodne vrste ECN........................................................................................ 26

4.2.4 ECN Kodna stran in UNICODE konverzija ................................................. 27

4.2.5 Translacija in validacija sporočil .................................................................. 27

4.2.6 Aplikacija MCC (Minimal Common Core) ..................................................28

4.2.7 Aplikacija GMS (Guarantee Management System)...................................... 28

4.2.8 Sistem Most (BRIDGE) ................................................................................ 29

5 REALIZACIJA REŠITVE NA OSNOVI NAGIOS ............... ......................... 30

5.1 ANALIZA NAPAK ................................................................................................ 30

5.1.1 Strojni viri ..................................................................................................... 30

5.1.1.1 Nadzor ................................................................................................ 30

5.1.1.2 Detekcija............................................................................................. 31

5.1.1.3 Odprava napake .................................................................................. 31

5.1.1.4 Seznam strojnih virov:........................................................................31

5.1.2 Programska oprema....................................................................................... 32

5.1.2.1 Nadzor ................................................................................................ 32

5.1.2.2 Detekcija............................................................................................. 32

VIII

5.1.2.3 Odprava napake .................................................................................. 33

5.1.2.4 Seznam programskih virov:................................................................ 33

5.1.3 Izmenjava sporočil z zunanjo domeno.......................................................... 34

5.1.3.1 Nadzor ................................................................................................ 34

5.1.3.2 Detekcija............................................................................................. 35

5.1.3.3 Odprava napake .................................................................................. 35

5.1.3.4 Seznam točk, ki jih moramo nadzorovati: ......................................... 35

5.1.4 Izmenjava sporočil s skupno domeno (CD).................................................. 35

5.1.4.1 Nadzor ................................................................................................ 36

5.1.4.2 Detekcija............................................................................................. 36

5.1.4.3 Odprava napake .................................................................................. 36

5.1.4.4 Seznam točk, ki se morajo nadzorovati:............................................. 36

5.1.5 Programi MCC/ECN/GMS........................................................................... 37

5.1.5.1 Nadzor ................................................................................................ 37

5.1.5.2 Detekcija............................................................................................. 37

5.1.5.3 Odprava napake .................................................................................. 38

5.1.5.4 Seznam točk, ki jih moramo nadzorovati ........................................... 38

5.1.6 Programi TARIC/TQM/SCI/SEED .............................................................. 39

5.1.6.1 Nadzor ................................................................................................ 40

5.1.6.2 Detekcija............................................................................................. 40

5.1.6.3 Odprava napak.................................................................................... 40

5.1.6.4 Seznam točk, ki jih moramo nadzorovati: .......................................... 41

5.1.7 Analize sporočil IE917, IE916, IE906, IE907 .............................................. 41

5.1.7.1 Nadzor ................................................................................................ 41

5.1.7.2 Detekcija............................................................................................. 41

5.1.7.3 Odprava napak.................................................................................... 42


5.1.8 Varnostne kopije ........................................................................................... 42

5.1.8.1 Nadzor ................................................................................................ 42

5.1.8.2 Detekcija............................................................................................. 42

5.1.8.3 Odprava napake .................................................................................. 43


IX

5.1.9 Ponovna vzpostavitev sistema ...................................................................... 43

5.1.10 Sisitem Most........................................................................................... 43

5.1.10.1 Nadzor ............................................................................................ 43

5.1.10.2 Detekcija......................................................................................... 44

5.1.10.3 Odprava napake .............................................................................. 44

5.1.10.4 Seznam točk, ki jih moramo nadzorovati: ...................................... 44

5.2 NAMESTITEV NADZORNEGA SISTEMA - NAGIOS................................. 45

5.2.1 Nastavitev nadzornega sistema NAGIOS ..................................................... 46

5.2.2 Namestitev nrpe (Daemon and plugin for executing plugins on remote hosts)

na Ncts1 in Ncts2 .......................................................................................... 49

5.3 POSEBNOSTI REŠITVE......................................................................................... 50

6 ZAKLJU ČEK...................................................................................................... 52

PRILOGE...................................................................................................................... 54

6.1 SEZNAM SLIK ..................................................................................................... 54

6.2 SEZNAM TABEL .................................................................................................. 54

6.3 NASLOV ŠTUDENTA............................................................................................ 55

6.4 KRATEK ŽIVLJENJEPIS........................................................................................ 55

X

UPORABLJENE KRATICE

AIX Advanced Interactive Executive

BAC Business Availability Center

BBL Bulletin Board Liaison

CCN Common Communications Network

CD Common Domain

CDCM Common Domain Communications Module

CGI Common Gateway Interface

CPU Central Processing Unit

CSI Common Systems Interface

CS/RD Central Services/Reference Data

CURS Carinska Uprava Republike Slovenije

CVI Center Vlade RS za Informatiko

DLT Digital Linear Tape

ED External Domain

ECN EDI CSI Node

EDI Electronic Data Interchange

EDIFACT Electronic Data Interchange For Administration, Commerce and Transport

EU Evropska Unija

FC Fiber-optic Connector

GMS Guarantee Management System

GUI Graphical User Interface

HD Help Desk

HKOM Hitro Komunikacijsko Omrežje

HTTPS Hyper Text Transfer Protocol Secure

XI

IE Information Exchanges

IKT Informacijska in Komunikacijska Tehnologija

IPC Inter-Process Communications

IT Information Tehnology

ITIL Information Tehnology Infrastructure Library

IS Informacijski Sistem

J2EE Java 2 Platform Enterprise Edition

MCC Minimal Common Core

MJU Ministrstvu za Javno Upravo

MQ Message Queue

ND National Domain

NDTA Nationally Developed Transit Application

NCTS New Computerised Transit System

NRPE Daemon and plugin for executing plugins on remote hosts

OGC Office of Government Comerce

OS Operacijski Sistem

PAC Proactive Analysis Components

RAM Risk Analysis Module

RAP Remote API Proxy

SICIS Slovenski Carinski Informacijski Sistem

SSL Secure Sockets Layer

SMS Short Message Service

SNMP Simple Network Management Protocol

SSH Secure SHell

TSM Tivoli Storage Manager

XII

TUXEDO Transactions for Unix,, Extended for Distributed Operations

WSH Work Station Listener

XML Extensible Markup Language

Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS

Stran 1

1 UVOD

Informacijska tehnologija nas v vsakdanjem življenju spremlja praktično na vsakem

koraku, saj smo potrošniki raznih storitev v zdravstvu, javni upravi, bančništvu, zabavni

industriji in še marsikje. Ne zavedamo pa se logističnih operacij, ki potekajo ob našem

plačevanju s kreditno ali plačilno kartico v trgovini ali pri zdravniku, ko nam predpisujejo

zdravila, ko podaljšujemo prometno dovoljenje, ali zgolj zahtevamo izpisek iz zemljiške

knjige, celo pri rezervaciji letalske karte in še bi lahko naštevali. Pri vseh postopkih smo

zelo odvisni od pravilnega in hitrega delovanja informacijskih sistemov. Glede na potrebe

se med seboj povezujejo razne bančne ustanove, borznoposredniške hiše, velike trgovske

mreže, turistične agencije in mnoge druge ustanove. Z vstopom Slovenije v Evropsko unijo

(EU) so se zahteve po informatizaciji in izmenjavi podatkov z ostalimi članicami EU

prenesle tudi na javno upravo, kot sta policija in carina. Zahteve, ki jih predpiše EU, so

enotne za vse države in jih morajo upoštevati vse članice EU. V primeru nespoštovanja

predpisanih zahtev se posamezno članico finančno kaznuje z globo. Ob morebitnem

neupoštevanju predpisov so torej kršeni zakoni na nivoju EU in ne samo v članici, ki

predpisa ni upoštevala. Predpisi ne zajemajo samo izmenjave podatkov in upoštevanja

novih predpisov in zakonov, temveč tudi dosegljivost in razpoložljivost informacijskega

sistema. Informacijski sistem posamezne upravne enote deluje na različni strojni opremi,

na različnih operacijskih sistemih, uporabljajo se različne aplikacije, podatki se shranjujejo

v različnih podatkovnih skladiščih in se povezujejo na različnih nivojih in protokolih.

Nadzorovanje in analiza delovanja tako raznolikega in kompleksnega informacijskega

sistema sta zelo zamudni opravili. Za pregledovanje delovanja posameznih delov

informacijskega sistema se moramo prijaviti na različne konzole, poganjati različne

kliente, pridobivati podatke iz klientov in pregledovati podatke ter jih primerjati z

referenčnimi podatki. Za vse te naloge potrošimo zelo veliko časa. Odkrivanje ozkih grl je

zamudno in dolgotrajno. Preiskovanje vzroka je v primeru izpada dela informacijskega

sistema časovno zelo zahtevno.

V svetu informatike so problem zaznali že zelo zgodaj in ga začeli reševati na različne

načine. Ponudniki programske in strojne opreme ponujajo dodatno opremo, ki je

namenjena nadzoru informacijskih sistemov. Poleg dodatne programske opreme je zelo

pomembno, da k problemu pristopimo celovito.


Stran 2

Za vodilo organiziranosti našega informacijskega sistema si pomagamo z zbirko najboljših

praks in priporočil ITIL ( IT Infrastructure Library). ITIL pomaga razčleniti naš

informacijski sistem na procese in nas vodi pri organizaciji in nadgradnji kompleksnega

informacijskega sistema. Priporočila nas usmerjajo pri tem, kako in na kakšen način

moramo organizirati naš IT, da bo delovanje informacijskega sistema čim manj moteno in

bo nadzorovanje učinkovito. Priporočila ITIL nas usmerjajo v izdelavo dokumentacije za

celoten IT. Mi smo sledili tistemu delu priporočila ITIL, ki je namenjen upravljanju in

nadziranju informacijskega sistema. Priporočila nas vodijo v popis posamezne

računalniške strojne ali programske komponente, kot so posamezne aplikacije, podatkovna

skladišča, sklopljenost posameznih aplikacij, operacijskega sistema, diskovne enote,

procesorjev in vrste komunikacijskih povezav. V postopku nadzorovanja moramo za vsako

komponento predvideti način nadzorovanja, zaznavanje napake, postopek odpravljanja

napake in eskalacijo problema.

Različni proizvajalci, kot sta na primer IBM in HP, nam ponujajo svoje komercialne

nadzorne rešitve, medtem ko lahko na svetovnem spletu najdemo tudi različne

odprtokodne sisteme.

V nalogi bomo predstavili Tranzitni carinski sistem Republike Slovenije in informacijsko

podporo za nadzor tega sistema. Nemoteno delovanje omenjenega sistema je zelo

pomembno, saj že kratka nekajminutna prekinitev delovanja posameznega modula

povzroči zastoj na mejnih prehodih, letališčih, zastoj v železniškem in ladijskem prometu.

Nedelovanje izmenjave podatkov o uvoznih kvotah, tarifah in trošarinah povzroči v

podjetjih izpad dela dohodka ali kršenje pravil EU. Posledice so lahko zelo drastične, od

izgube dobička pri uvozu, do mandatnih kazni ali izgube zaupanja za začasni uvoz blaga.

Carinska uprava Republike Slovenije vrši carinski in trošarinski nadzor nad prometom

blaga, ki gre v ali iz Republike Slovenije, odkriva nepravilnosti in odstopanja pri tranzitu

blaga, ki prihaja iz EU in zapušča meje EU.

Sistem, ki ga bomo nadzirali, je namenjen izmenjavi sporočil z EU. Sporočila so

namenjena kontroli blaga pri izvozu in uvozu v Slovenijo in EU.

Diplomska naloga je razdeljena na pet poglavij. Po uvodu v drugem poglavju predstavimo

pomembnost uvedbe nadzornega sistema v sektorju za informacijsko in komunikacijsko

tehnologijo (IKT) in pristop k uvedbi. Nadalje so predstavljeni osnovni moduli priporočil

ITIL in njihov pomen. V tretjem poglavju se seznanimo z nadzornimi sistemi, ki so na


Stran 3

voljo na tržišču. V predstavitvi bomo ločili komercialne in nekomercialne modele, s

poudarkom na nadzornem sistemu Nagios, ki ga kasneje uporabimo za nadzor

informacijskih sistemov (IS). V četrtem poglavju je opisano delovanje tranzitnih aplikacij s

poudarkom na sistemu ECN (EDI (Electronic Data Interchange) CSI (Common Systems

Interface) Node), ki je ključen za delovanje celega sistema, saj vse aplikacije izmenjujejo

sporočila preko sistema ECN. V petem poglavju so glede na priporočila ITIL opisane

točke, ki jih bomo nadzirali s pomočjo nadzornega sistema Nagios. V šestem poglavju

poudarimo naše izkušnje, ki smo jih pridobili z uvajanjem nadzornega sistema Nagios.


Stran 4

2 UPRAVLJANJE IN NADZOR RA ČUNALNIŠKIH SISTEMOV IN

OMREŽIJ

Povsod, tako tudi v gospodarstvu in javni upravi, se srečujemo z različnimi

informacijskimi sistemi, ki delujejo na različnih operacijskih sistemih. Programi so

namenjeni različnim sektorjem in se izvajajo po različnih protokolih ter na različni strojni

opremi, med seboj pa so povezani v različna omrežja. V primeru prekinitve delovanja ene

od povezav ali le dela strojne ali programske opreme nam odpoved le-te lahko povzroči

finančni izpad ali pa celo ogrozi človeška življenja. Informacija, ki zaostaja in je stara

nekaj ur ali celo dni, ni več uporabna in je nepomembna. Poslovno okolje, ki se zaveda

pomembnosti hitrih in popolnih informacij, vlaga v posodobitev informacijskega sistema

in sledi priporočilom ITIL na vseh področjih.

Na podlagi dobrih izkušenj strokovnjakov iz različnih področij so nastala priporočila dobre

prakse ITIL. Priporočila so podlaga za dobro organizirano delo v ustanovah in podjetjih,

kjer se zavedajo pomena povezanosti sektorja za IKT z ostalimi akterji v ustanovah ali

podjetjih. Priporočila ITIL vsebujejo obširna navodila za ravnanje s storitvami, saj

obsegajo širok spekter procesov in produktov. Priporočila ITIL so prvič predstavili v 80.

letih in sicer v Veliki Britaniji za upravne ustanove OGC (Office of Government

Commerce) [7]. Od leta 1980 so priporočila rastla in se dopolnjevala z novimi spoznanji.

Priporočila ITIL so bila med drugim uvrščena tudi med standarde, kot je mednarodni

standard ISO/IEC 2000. Z novimi spoznanji in širitvijo so priporočila postala preobsežna

in nepregledna. S prenovo priporočila ITIL sta nastali različici ITIL V2 in ITIL V3.

Priporočila ITIL pokrivajo naslednja področja: izdelavo zahtev naročnikov, načrtovanje

rešitve, implementacijo rešitve, nadziranje delovanja rešitve ter optimizacijo in

odpravljanje napak na rešitvi.

Različica priporočil ITIL V3 je razdeljena na naslednja področja: storitvena strategija

(Service Strategy), storitveni koncept (Service Design), storitveni prehod (Service

Transition), ter storitveno obratovanje in spremljanje izboljšav (Service Operation and

Continual Service Improvement - CSI) (sl.2.1).


Stran 5

Slika 2.1: Struktura priporočil ITIL V3.

Storitvena strategija je jedro priporočil ITIL V3 in je namenjena odkrivanju tržnih

priložnosti za razvijalce in pravilnemu oblikovanju zahtev notranjih in zunanjih

naročnikov. Storitvena strategija obsega ogrodje za gradnjo postopkov v razvijajočih se

odnosih. Hkrati nudi strateške smernice za zasnovo, realizacijo, vzdrževanje in nenehno

izboljševanje storitev ter sposobnost pridobivanja novih izboljšav, ki jih nudimo naročniku.

Storitveni koncept zasnuje načrt in upošteva vse vidike in predloge servisnih služb, ki jih

želi podpreti in predstavi opravilo kot storitev. Storitveni prehod spremlja napredek od

zajemanja zahtev do cilja, ki je bil definiran v fazi Storitvene strategije in Storitvenega

koncepta, meri napredek in spremlja, če se približujemo cilju. V nadaljevanju skrbi za

realizacijo izvedbe in postavitev izdelka v produkcijsko okolje [8].

Storitveno obratovanje in spremljanje izboljšav je storitev, namenjena (kot že ime pove)

obratovanju storitev in možnosti optimizacije procesa. Ta del zajema tudi področje uvedbe

nadzora nad informacijskim sistemom in odpravljanja napak.

V praksi je velikokrat drugače kot velevajo priporočila ITIL, saj se razvoj in

implementacija programske in strojne opreme zaključita z zaključkom projekta.

Nadzorovanje, nadgradnja in optimizacija informacijskega sistema so velikokrat prezrti,

saj to predstavlja dodaten strošek in je tako investicijo zelo težko upravičiti zaradi

pomanjkanja direktnih rezultatov, ki se pojavijo z zamikom. Danes je velik izziv prepričati


Stran 6

vodstvo za investicijo v dober kompleksen sistem za nadzor strojne in programske opreme

ter skrbeti za kontinuirano izboljševanje in nadgradnjo tako produkcijske kot nadzorne

strojne in programske opreme.

Podpora za storitve (Service Support), ki je del priporočil ITIL, je razdeljena na šest

modulov.

Prvi modul je Storitveni center (Service Desk) in je vitalnega pomena za nadzorovanje ter

upravljanje IS. Storitveni center predstavlja stično točko med upravitelji in uporabniki IS.

Na nivoju Storitvenega centra se izvajajo: registracija, klasifikacija incidentov in

komunikacija z uporabniki.

Zabeležen incident prevzame v upravljanje in nadzor modul Upravljanje incidentov

(Incident Management). Funkciji Upravljanje incidentov in Storitveni center sta običajno

združeni v eni organizacijski enoti ali oddelku. Upravljanje incidentov skrbi za začetek

reševanja, eskalacijo (vključevanje specialistov v reševanje problema za posamezni del

računalniške opreme), sledenje poteku ter zapiranje incidenta.

Modul Upravljanje problemov (Problem Management) je namenjen identifikaciji,

klasifikaciji in ugotavljanju vzrokov za podobne ali enake incidente, zmanjšanju njihovega

negativnega učinka na poslovne procese ter preprečevanju ponovitev le-teh.

Upravljanje sprememb (Change Management) skrbi za vrednotenje in implementacijo

sprememb v infrastrukturi ter sistematični pristop k nadgradnji strojne ali programske

opreme.

Upravljanje konfiguracij (Configuration Management) skrbi za nadzor nad sredstvi in

njihovo konfiguracijo, zagotovi stabilne temelje za upravljanje z incidenti, problemi in

spremembami.

Modul Nadzor programske opreme (Release Management) je namenjen natančnemu in

strukturiranemu popisu strojne in programske opreme ter uvedbi sprememb pri kontroli

skladnosti tako strojne kot programske opreme.


Stran 7

3 OPIS UPRAVLJALSKIH IN NADZORNIH SISTEMOV

Ob upoštevanju priporočil ITIL oblikujemo in načrtujemo storitev, oblikovano za

posamezen primer. Po končanem načrtovanju naše storitve, v našem primeru bo to nadzor

carinskega informacijskega sistema, je treba izbrati primerno orodje, ki bo izpolnilo vse

naše zahteve. Dodatna programska oprema mora omogočati storitvenemu centru in centru

za upravljanje incidentov nadzor nad delovanjem informacijskega sistema na enem mestu.

Nadzor sroritev na enem mestu omogoča hiter in pravilen odziv na napake in po potrebi

eskalacijo problema. Orodja za nadzor IS nas lahko opozorijo na kritične momente, ki

nastajajo v IS in so potencialni povzročitelji izpada IS. V kolikor IS nadzorujemo z

orodjem, napake in izpade beležimo v bazo ali datoteko tako, da je časovno zelo natančno

določeno, kdaj je do izpada prišlo, katere storitve so bile v času izpada v kritičnem stanju

in čas odprave napake. Pri komercialnih orodjih se beležijo tudi vsi posegi v IS in

spremljanje verzij posameznih komponent. S tem je nadzor nad različnimi različicami

programske opreme olajšan in zagotavljanje stabilnosti IS lažje ter zanesljivejše.

Načrtovanje in usklajevanje nadgradenj IS je mnogo bolj nadzorovano in ekonomično pri

uporabi orodja za nadzorovanje IS, saj imamo na voljo tudi podatke o obremenitvah

sistema v posameznih delih dneva, tedna ali meseca.

Nadzorni sistem preverja delovanje IS in preko mrežnih povezav zbira informacije o stanju

posameznih komponent IS, tako strojnih kot programskih. Zbrane informacije beleži in

nas, v primeru odstopanja od predhodno nastavljenih mej, opozori preko elektronske pošte

ali SMS (Short Message Service) sporočila na mobilni telefon (sl. 3.1).


Stran 8

Slika 3.1: Nadzorni sistem

3.1 Komercialni sistemi

Na trgu ponujajo različni ponudniki strojne in programske opreme različne plačljive

rešitve za nadzor in upravljanje. Nekaj rešitev je tudi takih, ki so delno brezplačne in so

uporabne tudi za nadzor kompleksnih sistemov. Med seboj se razlikujejo predvsem v

prijaznosti do uporabnikov, kot so to npr. preglednost na monitorju, načini nastavitev

delovanja orodij, cena, tehnična podpora, ki je na voljo na spletu, obširnost navodil, ki so

dostopna prek spleta in številni moduli, ki so že napisani za nadzor posameznih delov IS.

Na trgu se srečamo s komercialnimi ponudniki, kot so IBM, HP, CA in BMC. To so

največji komercialni ponudniki, ki so z nakupom podjetij, ki so razvila orodja, prevzeli

pravico nad produktom, ga integrirali in ga sedaj prodajajo pod lastno znamko.

IBM ponuja za nadzor sistemov komercialno rešitev z imenom IBM Tivoli Monitoring .

Orodje je namenjeno spremljanju sistemskih sredstev, zaznavanju ozkih grl in morebitnih


Stran 9

težav ter samodejni obnovi v kritičnih okoliščinah. Tivoli Monitoring je osnova za dodatne

nadgradnje. Z dodatnimi komponentami PAC (Proactive Analysis Components) razširimo

funkcionalnost osnovnega paketa za upravljanje strojne in programske opreme. Rešitev je

večplastna in nam omogoča vizualni prikaz delovanja sistema strojne opreme, kot so

zasedenost procesorja, zasedenost diskovnega prostora, zasedenost delovnega pomnilnika,

hitrost delovanja komunikacijske opreme in nekaterih drugih parametrov. Dodatni paketi

omogočajo nadzor in upravljanje programske opreme, kot so delovanje posameznih

storitev, zasedenost storitev, število sporočil v čakalnih vrstah (queue), spremljanje verzij

programske in strojne opreme, nadzor nad varnostno politiko in drugo [6].

HP ponuja podobne rešitve pod imenom HP Business Availability Center (BAC). Orodje

se tako kot pri IBM-u integrira z dodatnimi rešitvami, kot so HP Aplication Security

Center, HP Client Automation Center, HP Network Management Center. Z nadgradnjo

dodatnih orodij izboljšamo nadzor na področju pristopa, določanja različic aplikacij in

možnost avtomatske odprave napak pri morebitnih izpadih določenih strojnih ali

programskih komponent.

Podjetje BMC ponuja svoje storitve pod imenom BMC Service Level Management. Tudi

pri tem produktu je mogoče dokupiti nadgradnje, s katerimi lahko povečamo zmogljivost

osnovnega orodja [1].

CA ponuja svoje rešitve pod imenom CA Unicenter Network and System Management

(Unicenter NSM). Unicenter Network and System Management nadzira in upravlja stanje

in razpoložljivost operacijskih sistemov ter opravlja osnovno upravljanje s statusi vseh

infrastrukturnih elementov, poslovnih aplikacij in podatkovnih skladišč. Obstajajo tudi

opcije za aspekte varnosti, varovanja podatkov in poganjanje časovno tempiranih opravil

[2].

3.2 Odprtokodni sistemi

Na spletu najdemo tudi odprtokodne nadzorne sisteme. Za razliko od komercialnih rešitev

so odprtokodni sistemi namenjeni pretežno samo za nadzor in obveščanje. Nadgradnje za

nadzor določanja različic programskih in strojnih komponent, avtomatsko obnavljanje in

varnostni nadzor običajno ne obstajajo. Na tržišču so zelo razširjeni odprtokodni sistemi

OpenNMS, Zenoss in Nagios.


Stran 10

OpenNMS je namenjen nadzoru sistemov in mreže. Preko spletnega brskalnika lahko

nadzorujemo razpoložljivost sistema in aplikacij. Vse nastavitve za delovanje OpenNMS

se nahajajo v datotekah formata XML (Extensible Markup Language). Omogoča tudi

nadzor naprav, ki podpirajo protokol SNMP (Simple Network Management Protocol). Za

nastavitve parametrov obstaja GUI (Graphical User Interface), s katerim nastavljamo

delovanje sistema OpenNMS tako, da nam ni potrebno poznavanje podrobnosti XML.

Tudi iskanje aplikacij, ki ne podpirajo SNMP ali iskanje preko vrat (port-sniffing), je

enostavno. Zelo dobro je podprto zbiranje in prikazovanje podatkov o IS. Sistem

OpenNMS je napisan v Javi in bi ga bilo mogoče teoretično izvajati na vseh operacijskih

sistemih, ki podpirajo Javo 1.5 SDK (Software Development Kit). Preizkušeno deluje na

naslednjih operacijski sistemih: Linux, Solaris, Mac OS X in Microsoft Windows.

OpenNMS ima slabo formalno dokumentacijo in slab grafični prikaz načrta nadzorovanih

sistemov, prav tako moramo biti pazljivi tudi pri nastavitvenih datotekah XML, saj v

primeru nepravilnega popravka v nastavitveni datoteki, OpenNMS ne deluje več. Slabost

sistema OpenNMS je tudi, da povezanost med stanji posameznih storitev, ki jih

nadzorujemo in alarmi, ki se prožijo ter obveščanjem nadzornikov preko elektronske pošte,

ni rešena hierarhično. Obveščanje poteka vsled stanja storitve in ne sled alarma [12].

Sistem Zenoss je zelo dobro orodje za nadzorovanje velikih IS in mrežnih povezav.

Zadosti večini zahtev, ki jih potrebujemo za nadzorovanje kompleksnih IS. Objektno

orientirana arhitektura samega orodja je zelo prilagodljiva in ne zahteva predhodnih

nastavitev. Zelo močno je podprto iskanje in risanje načrta infrastrukture povezav IS. V

svoje delovanje lahko vključi tudi sistema Nagios in Cacti, ima pa tudi možnost

prikazovanja predlog orodja ZenPacks. Podatke o strojni opremi pridobiva s pomočjo

protokola SNMP. V primerih, kjer protokol SNMP ni podprt, Zenoss uporablja varno

povezavo ssh (secure shell) in telnet. Zenoss je dobro dokumentiran, obstajata dva

priročnika - Quick Start Guide in Admin Guide. Obstaja tudi knjiga z naslovom Zenoss

Core Network and System Monitoring, ki jo je mogoče dobiti tudi v elektronski obliki.

Morda edina resna pomanjkljivost orodja Zenoss je dejstvo, da je orodje mlado in zato ne

deluje brezhibno in skriva še obilo napak, ki pa jih razvojni inženirji sproti odpravljajo.


Stran 11

3.3 Sistem Nagios

Sistem Nagios bom predstavil bolj podrobno, ker smo ga izbrali za nadzorno orodje, s

katerim smo implementirali rešitev nadzora pri naročniku. Orodjr Nagios je za uporabo

dokaj preprosto, saj je celotni uporabniški vmesnik zgrajen na spletnem strežniku. Na

sistem Nagios se povežemo s pomočjo varne povezave HTTPS (Hyper Text Transfer

Protocol Secure), ki uporablja kriptiran protokol SSL (Secure Sockets Layer). Uporabnik

preko spletnega brskalnika dostopa do nadzorne strani, kjer se najprej prijavi v aplikacijo

in potem spremlja celoten nadzorni sistem preko tega vmesnika. Z drugimi besedami -

aplikacija ne potrebuje nobene namestitve na lokalnem računalniku. Nagios za svoje

delovanje potrebuje še odprtokodni aplikacijski in spletni strežnik Apache ter določene

dodatne odprtokodne grafične knjižnice. Podatki, ki jih sistem Nagios zbira, lahko

shranjujemo v bazo ali pa kar v datoteči sistem [11]. Slednjo izbiro smo uporabili v naši

nalogi.

Nadzorni sistem Nagios je nastal leta 2002. Razvili so ga na osnovi projekta, imenovanega

NetSaint, ki je z enako vsebino deloval od leta 1990. V začetku je bil načrtovan bolj kot

sistemski nadzorni sistem in ni bil usmerjen v nadzor v omrežjih. Na začetku razvoja je bil

bolj podoben Linux-u in Unix-u. Začetne instalacije produkta Nagios so bile zapletene in z

razvojem produkta so poenostavili tudi instalacijo. Navodila Nagios Quickstart so obsežna,

tako da smo za instalacijo na strežniku z operacijskim sistemom AIX (Advanced

Interactive Executive) ver. 5.3 porabili približno dva dneva. S spletnim brskalnikom se

povežemo v Nagios prek spletnega naslova https://nagios3/nagios. Za vzpostavitev

povezave moramo imeti ustrezno uporabniško ime in geslo. V navodilih Nagios Quickstart

je opisan postopek kreiranja novih uporabnikov in gesel, tako da lahko do spletnega

vmesnika dostopamo z različnimi pravicami vpogleda. V naši rešitvi smo uporabili kar

administrativnega uporabnika, katerega smo določili pri instalaciji orodja. Za naše potrebe

se prijavljamo z varno povezavo prek spletnega naslova https://xxx.xxx.xxx.xxx/nagios/,

kjer je xxx.xxx.xxx.xxx IP-naslov strežnika, na katerem je instaliran sistem Nagios.

Uporabnik preko spletnega brskalnika dostopa do nadzorne strani, kjer se najprej prijavi v

aplikacijo in potem spremlja celoten nadzorni sistem preko tega vmesnika. Po prijavi v

nadzorni sistem Nagios nas pričaka naslednji uporabniški vmesnik (sl. 3.2).


Stran 12

Slika 3.2: Nagios - prva stran.

Ekran je razdeljen na dva dela. Na levi strani se na črni podlagi nahaja meni, ki je vedno na

voljo, osrednji večji del, pa vsebuje tudi osnovne informacije o instalaciji orodja Nagios.

Meni je razdeljen na štiri sklope: osnovni (General), nadzorni (Monitoring), poročila

(Reporting) in nastavitve (Configuration).

Osnovni sklop ima dve možnosti: preklop na prvo stran (Home) in dostop do

dokumentacije (Documentation).

V nadzornem delu menija lahko izbiramo med različnimi pogledi našega sistema, ki ga

nadzorujemo. Izbiramo med pogledi: Tactical Overview, Service Detail, Host Detail,

Hostgroup Overview, Hostgroup Summary, Hostgroup Grid, Servicegroup Overview,

Servicegroup Summary, Servicegroup Grid, Status Map, 3-D Status Map, Service

Problems, Host Problems in Network Outages.

Izbiramo lahko med različnimi pogledi IS, ki ga nadzorujemo. Kako grupiramo strežnike

in storitve je odvisno od nastavitev, ki smo jih podali v nastavitvenih datotekah. Na sliki

3.3 vidimo taktičen pogled (Tactical Overview), ki nam prikazije grobo stanje

nadzorovanega IS.


Stran 13

Slika 3.3: Nagios – taktični pregled.

Slika 3.4 prikazuje primer delovanja storitev, razdeljenih v skupine. Podobno sliko bi

dobili ob pregledu strežnikov. S klikom na eno od skupin si lahko lastnosti in stanje

storitev ogledamo bolj podrobno.

Slika 3.4: Nagios – skupine, urejene po storitvah.

Na sliki 3.5 se nahajajo vse storitve, ki jih uporabljamo za nadzorovanje našega IS.

Storitve so obarvane v tri različne barve, glede na njihov trenutni status. Zeleno obarvane


Stran 14

storitve predstavljajo delovanje v mejah normale, rumeno obarvane storitve predstavljajo

moteno delovanje. Pri preverjanju delovanja strojne ali programske opreme so namreč

zaznali njihovo moteno delovanje in prekoračitev prve meje in so v stanju opozorila

(warning). Rdeče obarvan servis za nadzor pa pomeni, da je delovanje opreme zelo

moteno. V tem primeru se sproži alarm – npr. pošiljanje elektronske pošte, če imamo

izbrano takšno opcijo v nastavitvenih datotekah.

Slika 3.5: Nagios – storitve.

Lahko se omejimo samo na storitve, katere določeni parametri odstopajo od vnaprej

nastavljenih mej, ki smo jih nastavili v nastavitvenih datotekah. To nam omogoča zelo

hitro detekcijo napake ali ozkih grla, ki nastajajo pri obremenitvah. V primeru, da storitev

zazna, da je oprema začela delovati v mejah normale, se status spremeni in storitev iz

ekranskega seznama izgine (sl. 3.6).


Stran 15

Slika 3.6: Nagios – filter.

Različni pogledi in vnaprej nastavljeni filtri nam omogočijo, da pregledujemo samo želene

storitev ali strežnike. Tako lahko hitreje določimo, kje v opazovanemu sistemu je prišlo do

napake, oziroma kje prihaja do kritične situacije.

Naslednji sklop poročila je namenjen prikazovanju stanja našega sistema v določenem

obdobju. Zgodovino delovanja lahko prikažemo tabelarno in grafično, kar nam omogočajo

zgodovinski podatki, ki jih hranimo v datotekah ali v bazi. Pri hranjenju podatkov o

delovanju IS se omejimo na določeno obdobje. Podatke, namenjene prikazu moramo

izbirati razumno, saj preobsežne izbira podatkov ne omogoča preglednih tabel.

Na sliki 3.7 je prikazano sedemdnevno delovanje ene od izbranih storitev.


Stran 16

Slika 3.7: Nagios – zgodovina.

Slika 9 prikazuje delovanje storitve za obdobje enega meseca.

Slika 3.8: Nagios – zgodovina.

Zgodovino delovanja določenih strežnikov ali servisov lahko prikažemo tudi v tabeli (sl.

3.9).


Stran 17

Slika 3.9: Nagios - statistika storitev.

Poročilo lahko razširimo tudi na pregled obveščanja in sicer lahko izvemo, katere storitve

so bile vzrok obvestil preko elektronske pošte in kdo je bil obveščen. Rdeče obarvane

storitve prikazujejo, kdo in kdaj je bil obveščen o prekoračitvi kriti čne meje. Zeleno

obarvani deli pa nas obveščajo, kdaj je neka storitev začela delovati normalno (sl. 3.10).

Slika 3.10: Nagios – obveščanje.


Stran 18

V razdelku nastavitve (Configuration) imamo možnost pregledovanja nastavljenih storitev,

ki pregledujejo naš IS (sl. 3.11).

Slika 3.11: Nagios - nastavitve.

Z izbiro povezave (modro obarvanega teksta) se pomaknemo v globino in se nam prikažejo

vse nastavitve za določeno storitev. Omenjena nastavitve lahko spreminjamo samo ročno v

nastavitvenih datotekah.

Glavna nastavitvena datoteka je nagios.cfg, v kateri nastavimo poti do ostalih nastavitvenih

datotek, kot so checkcommands.cfg, misccommands.cfg, contactgroups.cfg, contacts.cfg,

hostgroups.cfg, hosts.cfg, servicegroups.cfg, resource.cfg, poti do arhivskih datotek in

logov.

V nadaljevanju podajamo primerjavo treh odprtokodnih nadzornih sistemov - Nagios,

OpenNMS in Zenoss.

Nagios OpenNMS Zenoss

Iskanje vozlišč Potrebno nastaviti v

nastavitvenih

datotekah za vsako

vozlišče posebej

Nastavitvena

datoteka z

vključenimi /

izključenimi

GUI, CLI in

možnost nastavitve

iz tekstovne ali

XML datoteke


Stran 19

območji

Avtomatsko iskanje Ne Da Da

SQL baza Ne (Z nakupom

licence Da)

PostgreSQL mySQL in Zope

ZEO

Iskanje aplikacij Da- nastavljene

storitve

Ne brez dodatnega

agenta (NRPE)

Da – s pomočjo ssh,

zenPacks in

avtomatsko

Podpira NRPE/

NSClient

Da Da Možno

Podpira SNMP V1,V2 in V3 V1,V2 in V3 V1,V2 in V3

Nastavitev prikaza

dogodkov na

konzoli

Ne Da Da

Tabela 3.1: Primerjalna tabela odprtokodnih sistemov.

Za nastavitev nadzora vozlišč je orodje Nagios bolj okoreno od orodij OpenNMS in

Zenoss, saj je potrebno nastavitve izvesti v nastavitvenih datoteka. Za hranjevanje

zgodovine delovanja IS, pa se podatki lahko shranjujejo v datoteko, kar je bila v našem

primeru prednost, ker nismo imeli na voljo podatkovne baze, kamor bi lahko v primeru

orodij OpenNMS ali Zenoss shranjevali podatke o delovanju IS. Nadzorna sistem

OpenNMS in Zenoss imata avtomatsko iskanje aplikacij, katere želimo nadzirati. V našem

primeru, bi bili s tem lahko omejeni, saj bi lahko izbirali samo med možnostmi, ki bi bile

na voljo. Želeli smo nadzirati tudi vsebinsko delovanje IS:

• preverjati pošiljanje določenih sporočil,

• obveščanje o opozorilih in napakah v logih od posameznih aplikacij in

• nadzirati stanje v čakalnih vrstah.

Glede na zahteve in izkušne iz prejšnjih projektov , smo za nadzor IS, ki ga želimo

nadzorovati izbrali orodje Nagios.


Stran 20

4 IMPLEMENTACIJA IN NADGRADNJE ZA POTREBE SISTEMA

NCTS

4.1 Kratek opis sistema/omrežja CURS in NCTS

Pri rešitvi smo sledili priporočilom ITIL in najprej podrobno preučili delovanje aplikacij

računalniško podprtega tranzitnega sistema NCTS (New Computerised Transit System).

Naredili smo analizo, kaj bomo nadzorovali, kako bomo zaznavali napake, definirali smo

postopke odprave napak in eskalacije problemov v primeru, če napak ne moremo sami

odpraviti.

IS, ki ga bomo nadzirali, se nahaja na različnih lokacijah in ga upravljajo različna podjetja.

Sistem smo temeljito analizirali, popisali in je sestavljen iz naslednjih komponent:

• V Evropo se povežemo preko strežnika, na katerem sta prehoda CCN/CSI -

Gateway (CCN (Common Communications Network ) / CSI (Common Systems

Interface)-), ki ga administrirajo in vzdržujejo iz centrale v Bruslju. Do določenih

opravil lahko dostopajo lokalno administratorji, ki so registrirani na Ministrstvu za

javno upravo (MJU) in Carinski upravi Republike Slovenije (CURS). Izmenjava

sporočil poteka preko čakalnih vrst, ki so nastavljene na tem strežniku. Strežnik je

znotraj hitrega komunikacijskega omrežja (HKOM) in je preko usmerjevalnika

povezan s strežnikom, na katerem se izvajajo aplikacija NCTS za izmenjavo

podatkov.

• Na usmerjevalniku Evropa se IP naslovi prenaslavljajo v naslove strežnikov Ncts1

in Ncts2.

• Na strežniku Ncts1 je instalirana aplikacija Oracle in pripadajoče baze aplikacij za

ECN, MCC (Minimal Common Core) in GMS (Guarantee Management System).

• Na strežniku Ncts2 delujejo naslednji programi, ki jih želimo nadzorovati: ECN,

MCC, GMS in Websphere, na katerem se izvajajo programi za okolje J2EE (Java 2

Platform Enterprise Edition), ki omogočajo povezavo med transakcijskima

sistemoma TUXEDO (Transactions for Unix, Extended for Distributed Operations)

in MQ (IBM Message Queue). Povezava MQ se uporablja za izmenjavo sporočil z

SICIS (Slovenski Carinski Informacijski Sistem). Na strežniku Ncts2 poteka tudi


Stran 21

prenos podatkov za pravila (TARIC), kvote (QUOTA2), nadzorstvo

(SURVEILLANCE) in trošarine (SEED). Izmenjava podatkov s SICIS poteka s

pomočjo protokola FTP. Izmenjava podatkov z EU pa poteka preko čakalnih vrst.

Pretvorba iz datoteke v sporočilo in obratno opravljajo programi, ki so napisani v

C-ju, in uporabljajo posebne knjižnice za povezovanje s prehodi in čakalnimi

vrstami, katere določa EU.

ECN je komunikacijsko/sporočilno/prevajalni modul. ECN povezuje aplikacije različnih

domen tranzitnega sistema, npr. nacionalne domene (ND National Domain), skupne

domene (CD Common Domain), podjetja ali zunanje domene (ED External Domain) in

centralno storitev za izmenjavo referenčnih podatkov CS/RD (Central Services/Reference

Data). Povezave različnih domen prek ECN so predstavljene v tabeli 4.1.

To

From

ND CD ED CS/RD

ND � � �

CD �

ED �

CS/RD � �

Tabela 4.1: Povezave domen na ECN.

Vsako vozlišče ECN v sistemu NCTS mora biti postavljeno z lastnim prehodom CCN/CSI.

Prehod se uporablja za povezavo ECN s splošno domeno prek omrežja CCN. To je

ponazorjeno na sliki 4.1 .


Stran 22

LAN

CCN/[email protected]

CS/RD

LAN

CCN/CSIGateway@domain C

NDTA @ domain C

LANLAN

ECN @domain A

CCN/CSICCN/CSI

Gateway@domain A

ECN @domain B

CCN/CSIGateway@domain B64 Kbps

max

64 Kbpsmax

MCC@ domain A

Trader application@ domain A

NDTA@ domain B

64 K

bps

max

64 Kbps max

Slika 4.1: ECN znotraj NCTS.

ECN znotraj sistema NCTS ponuja tranzitnim aplikacijam okolje za medsebojno

komunikacijo [3].

Te aplikacije so lahko:

• osnovna podpora tranzita MCC ali nacionalna tranzitna aplikacija NDTA

(Nationally Developed Transit Application),

• centralna storitev za izmenjavo referenčnih podatkov CS/RD,

• aplikacije podjetij (Trader Application).

Komunikacija med temi aplikacijami je sporočilno orientirana (message-oriented). Sistem

NCTS specifikacij določa več tipov sporočil, imenovanih IE (Information Exchanges), ki

se lahko izmenjujejo med tranzitnimi aplikacijami v času njihovega delovanja. ECN

ponuja tranzitnim aplikacijam različne načine za izmenjavo sporočil IE v dveh različnih

vmesnikih.

Vrstni del zunanjega vmesnika ECN oskrbuje lokalne (local) vrste, dostopne

povezovalnim aplikacijam. Te so razdeljene na vhodne čakalne vrste (input queues) in

izhodne čakalne vrste (output queues). V vhodne čakalne vrste odlagajo sporočila zunanje

aplikacija. ECN pregleduje te čakalne vrste, prebere sporočila v njih in jih obdela.


Stran 23

Izhodne čakalne vrste so vrste, kjer ECN posreduje sporočila. Zunanja aplikacija pregleda

takšne vrste za sprejem sporočil. Ko je ECN povezan z aplikacijo MCC ali aplikacijo za

nadzor garancij GMS, lahko z uporabo komunikacijske tehnologije TUXEDO

(Transactions for Unix,, Extended for Distributed Operations), ECN prav tako posreduje

sporočila aplikacijama MCC ali GMS.

Vse čakalne vrste ECN, ki so vidne tranzitni aplikaciji, so v bistvu čakalne vrste

TUXEDO. Pripadajo aplikaciji ECN, ki jih ustvari tekom instalacije. Za dostop do teh vrst

mora biti tranzitna aplikacija po naravi aplikacija vrste TUXEDO – npr. biti mora bodisi

TUXEDO-odjemalec ali TUXEDO-strežnik. V primeru povezave aplikacije ECN z

aplikacijama MCC ali GMS je komunikacija (branje iz vrste/pisanje v vrsto) izvršena s

klicem ustreznih storitev. Aplikacija MCC mora poklicati storitve ECN v primeru, da želi

poslati sporočilo ECN in ECN mora poklicati storitve MCC v kolikor želi poslati sporočilo

MCC ali GMS.

4.2 Vhodne, izhodne in vmesne čakalne vrste

V nadaljevanju bomo opisali prostore (queue space) ECN, kjer se nahajajo vhodne,

izhodne in vmesne čakalne vrste. V vsakem prostoru so vrste, ki se uporabljajo za

izmenjavo sporočil. Določene vrste so namenjene tudi obdelavi sporočil znotraj ECN-ja.

Naloge, ki jih izvaja ECN so:

• pretvorba iz EDIFACT (Electronic Data Interchange For Administration,

Commerce and Transport) v XML ali obratno,

• preverjanje strukture sporočila (določen tip sporočila (IE) mora vsebovati določena

polja XML) in preverjanje vsebine sporočila (določena polja v zapisu XML lahko

vsebujejo samo določeno vrednost).

Med vsako nalogo se sporočilo shrani v določeno vrsto. Notranje vrste ne bomo posebej

predstavili, saj ECN v primeru napake pošiljatelju napačnega sporočila sam posreduje

sporočilo v formatu IE906 ali IE907, v katerem je napaka opisana. Obstajajo štirje načini

delovanja ECN in glede na način delovanja pripada posameznemu načinu tudi prostor, kjer

se nahajajo čakalne vrste. Normalen način delovanja (NORMAL) je delovanje ECN v

produkcijskem načinu. Prostor, ki se uporablja za čakalne vrste, ima ime NORMAL. V

nadaljevanju bom predstavil posamezne vrste, ki se nahajajo znotraj tega prostora. Za


Stran 24

lokalno testiranje se uporablja način nacionalni test (NAT_TEST). V času uvajanja novih

funkcionalnosti se lahko uporablja tudi način usposabljanja (TRAINING). Za celoten test

pa se uporablja način za mednarodno testiranje (INT_TEST). Za vse načine velja, da

uporabljajo svoj prostor, v katerem so nastavljene posamezne vrste.

4.2.1 Vrstni vmesnik ECN TUXEDO

Naslednja slika predstavlja ECN vhodne in izhodne čakalne vrste TUXEDO za MCC (sl.

4.2). Zaradi boljše preglednosti smo čakalne vrste za GMS in modul za analizo tveganja

RAM (Risk Analysis Modul) izpustili. Podobno kot za MCC so postavljene vrste tudi za

GMS, RAM in SICIS.

ECN

ECN_CORE_Q

ECN_ADMIN_Q

ECN_TRAD_Q *

EC

N_E

D_Q

* ED

_EC

N_Q

*

NTA_CORE_Q

NTA_ADMIN_Q

NTA_TRAD_Q *

NTA_REPLY_Q

TRADERS(External Domain)

NTA(National Domain)

CCN/CSI(Common Domain)

* Not in INT_TEST and TRAINING

Slika 4.2: Vhodne in izhodne vrste ECN.

4.2.2 Vhodne vrste ECN

Spodnji seznam čakalnih vrst vsebuje vhodne čakalne vrste ECN in pripadajoča sporočila,

ki se trenutno lahko izmenjujejo preko teh vrst (ta. 4.3).


Stran 25

Ime vrste Način delovanja Dovoljena

sporočila

Uporaba za

ECN_CORE_Q NORMAL IE001, IE002,

IE003, IE006,

IE010, IE018,

IE020, IE024,

IE027, IE038,

IE050, IE114,

IE115, IE118,

IE901

NTA (NDTA ali

MCC) posreduje

sporočila CORE o

poslovnih procesih

oddaljeni NTA

ECN_ADMIN_Q NORMAL IE411, IE904,

IE905, IE906

NTA (NDTA ali

MCC) posreduje

tehnična sporočila

oddaljeni NTA

ECN_TRAD_Q NORMAL IE008, IE009,

IE016, IE025,

IE028, IE029,

IE043, IE051,

IE058, IE060,

IE062

NTA (NDTA ali

MCC) posreduje

sporočila

podjetjem

ECN_ED_Q NORMAL IE007, IE014,

IE015, IE044,

IE054

Podjetja

posredujejo

sporočila lokalni

aplikaciji NTA

Tabela 4.2: Seznam vhodnih čakalnih vrst.

Upoštevati je treba, da je ECN v celoti nastavljiv, razen prostora za vrste in imen vrst, ki

jih uporablja. Zato se tabela, opisana zgoraj, ujema s privzetimi nastavitvenimi datotekami,

ki jih dobimo skupaj z instalacijo ECN. V kolikor lokalni administrator ECN te


Stran 26

nastavitvene datoteke spremeni, lahko ustrezne informacije pridobimo iz nastavitvenih

datotek samih.

4.2.3 Izhodne vrste ECN

Spodnja tabela 4.4 vsebuje izhodne čakalne vrste ECN in pripadajoča sporočila, ki se

trenutno lahko izmenjujejo preko teh vrst.

Ime vrste Način delovanja Dovoljena sporočila Uporaba za

NTA_CORE_Q NORMAL IE001, IE002, IE003,

IE006, IE010, IE018,

IE020, IE024, IE027,

IE038, IE050, IE114,

IE115, IE118, IE901

Oddaljena NTA

(NDTA ali MCC)

posreduje sporočila

CORE o poslovnih

procesih lokalni

NTA

NTA_ADMIN_Q NORMAL IE904, IE905, IE906,

IE031, IE032

Oddaljena NTA

(NDTA ali MCC)

posreduje tehnična

sporočila lokalni

NTA

NTA_TRAD_Q NORMAL IE007, IE014, IE015,

IE044, IE054

Sporočila podjetij

lokalni NTA

ED_ECN_Q NORMAL IE008, IE009, IE016,

IE025, IE028, IE029,

IE043, IE051, IE058,

IE060, IE062, IE907,

Translation&Sending

Report

Sporočila lokalne

NTA podjetjem ali

poročilu prevajanja

in pošiljanja prej

posredovanega

sporočila

Tabela 4.3: Seznam izhodnih vrst


Stran 27

Opcije nastavljanja so iste kot pri vhodnih vrstah.

4.2.4 ECN Kodna stran in UNICODE konverzija

Aplikacija ECN obvladuje Unicode (UTF8) in 8-bitne znake. EDIFACT 96B standard je

8-bitni, in se uporablja za izmenjavo sporočil z skupno domeno. ECN vmesnik za

nacionalno domeno je lahko 8-bitni (LATIN-1) ali Unicode (UTF8).

ECN vsebuje dva filtra, ki zagotavljata prevod znakov iz UTF8 v standard ISO in obratno.

Prvi filter ima naslednje parametre delovanja:

• bere UTF8 XML niz,

• spreminja vse znake v zapisu UTF8 LATIN-1 znake v njihove ustrezne znake

ISO8859-1,

• spreminja vse ne-LATIN-1 UTF8 znake v ubežne znake ‘_’.

Pri pretvarjanju filter predvideva, da so vsa prihajajoča sporočila EDIFACT dešifrirana v

ISO8859-1 (LATIN-1). Aplikacija ECN vsebuje filter za procesiranje niza XML,

dešifriranega v IS08859-1, kar je rezultat prevoda iz prihajajočega sporočila EDIFACT.

Zato ta filter:

• bere 8-bitni niz XML,

• spreminja vse znake v nizu XML v format UTF8. Pri tem predvideva, da so vsi

znaki v formatu ISO8859-1 (LATIN-1).

4.2.5 Translacija in validacija sporočil

Za translacijo in validacijo sporočil se uporablja aplikacija REDIX, ki jo kliče aplikacija

ECN. Nastavitve za REDIX so shranjene v posebni datoteki in se po potrebi posodabljajo.

Posodabljanje poteka s sporočili IE032, IE950 in IE932. Sporočilo IE032 pride iz skupne

domene po potrebi. Vse države, ki so vključene v tranzitni sistem, o spremembah v

delovanju svojih uradov s sporočili IE031 ali preko elektronske pošte obveščajo oddelek

CS/RD, ki je zadolžen za distribucijo referenčnih podatkov v EU. Ob spremembi v bazi

podatkov oddelka CS/RD, se tvori sporočilo IE032 in se pošlje vsem članicam EU, ki

uporabljajo sistem NCTS. Sporočilo IE950 vsebuje le šifrante, ki so nacionalnega značaja

in so vezani na določeno državo, v kateri ta ECN deluje. To pomeni, da sporočilo IE950

pošlje nacjonalna domena, kar je v našem primeru Slovenija. Sporočilo IE932 naročimo v


Stran 28

CS/RD preko spletnega vmesnika in ročno prenesemo preko varne povezave v mapo, kjer

se shranjujejo tudi IE032. To sporočilo lahko po potrebi preko konzolne aplikacije

uvozimo v ECN [4].

4.2.6 Aplikacija MCC ( Minimal Common Core)

Aplikacija MCC teče na stežniku Ncts2. Namenjena je za izvajanju tranzitnega postopka.

Aplikacija podpira celoten tranzitni postopek od najave tranzitne deklaracije do zaključka

tranzita in sproščanja rezerviranih denarnih sredstev, ki so namenjena zavarovanju tranzita.

V podrobnosti postopka se ne bomo spuščali, ker le-ta ni predmet nadzora. Za pravilnost

postopka skrbi sama aplikacija MCC. Carinske izpostave se na aplikacijo povezujejo preko

odjemalca MCC in izvajajo posamezne akcije kot so:

• odpiranje nove tranzitne deklaracije,

• vnašanje posameznih opomb pri odstopanju tovora s tranzitno deklaracijo,

• prepuščanje tranzitnih deklaracij v tranzit

• prevzemanje in zaključevanje tranzita,

• vnašanje opomb pri odstopanju,

• sprožanje poizvedb o posameznem tranzitu,

• sproščanje garancij idr.

Odjemalec MCC je na osebnih računalnikih carinskih izpostav nameščen lokalno.

Izmenjava sporočil med odjemalcem MCC in strežniško aplikacijo MCC, ki teče na

strežniku, prav tako poteka preko transakcijskih vrst TUXEDO. Vsa sporočila, ki jih

izmenja aplikacija MCC, se shranjujejo v bazi Oracle, ki teče na strežniku Ncts1 [10].

4.2.7 Aplikacija GMS ( Guarantee Management System)

Aplikacija GMS teče na strežniku Ncts2. Namenjena ja nadzoru garancij tranzitnih

deklaracij. Vsak tranzit je treba zavarovati za primer nesreče pri prevozu. Za olajšanje

postopka zavarovanja posameznega prevoza tovora določena banka jamči z večjim

zneskom za posamezni tranzitni urad. Posamezni prevoz tovora rezervira le del celotne

vsote, glede na občutljivost tovora pri prevozu. Ob zaključku tranzita je potrebno ta

sredstva sprostiti in jih ponovno dati na voljo za nove tranzite. Do aplikacije GMS, ki se

izvaja na strežniku, lahko cariniki dostopajo preko odjemalca, ki je nastavljen lokalno na


Stran 29

osebnem računalniku. Odjemalec GMS uporabljamo za vnašanje in popravljanje seznama

tranzitnih uradov in garancijskih zneskov ter druge akcije, ki so povezane z garancijskimi

sredstvi. Izmenjava sporočil med odjemalcem GMS in aplikacijo GMS, ki se izvaja na

strežniku, prav tako poteka preko transakcijskih vrst TUXEDO [5].

4.2.8 Sistem Most (BRIDGE)

Osnovna funkcija sistema Mosta je izmenjava sporočil med sistemom NCTS z ostalimi

sistemi znotraj CURS-a. S pomočjo povezave med transakcijskim sistemom TUXEDO in

sistemom IBM WebSphere MQ uporabljamo strežnik WebLogic Server 8.1 SP5, na

katerem se izvaja konektor WTC (Weblogic Tuxedo Connector), ki skrbi za izmenjavo

sporočil med sistemom SICIS in aplikacijo ECN.

Poleg tega ima Most več sekundarnih funkcij, kot so generiranje in pošiljanje sporočil

SI025, SI029 in SI118 iz NCTS-a v SICIS. Poleg tega se strežnik WebLogic uporablja kot

platforma za digitalno podpisovanje in preverjanje sporočil, kot tudi za spletne storitve, ki

predstavljajo vmesnik do storitev TUXDO aplikacij MCC, ECN in GMS.

Most temelji na strežniku BEA Weblogic, ki je nameščen poleg ECN in ostalih strežnikov

TUXEDO na strežniku Ncts2. Zaradi zagotavljanja kakovosti prenosa po principu

»natanko enkrat« so potrebne posebne transakcije, ki zahtevajo, da je poleg strežnika

Weblogica lokalno nameščen še sistem IBM Websphere MQ. Ta je s posebnim kanalom

MQ povezan z oddaljenim sporočilnim sistemom MQ, preko katerega se izmenjujejo

sporočola v SICIS.


Stran 30

5 REALIZACIJA REŠITVE NA OSNOVI NAGIOS

Glede na priporočila ITIL smo opisali napake, do katerih lahko pride, postopke reševanja

in v primeru, da napake v določenem času ne odpravimo, tudi način in osebe za eskalacijo.

Napake, ki se lahko pojavljajo, smo v grobem razdelili na določene sklope, kjer je

postopek odprave napak zelo podoben. Protokol sam lahko razdelimo v sledeče operacije:

• nadzor,

• detekcijo napake,

• odpravo napak oziroma eskalacijo v primeru večjih problemov in

• seznam elementov, ki jih bomo nadzirali.

Sistem Nagios smo uporabili za nadzor in detekcijo napak. V nadaljevanju ga bomo

poimenovali kar nadzorni sistem. Osebne podatke, kot so imena, telefonske številke in

naslovi IP, smo zaradi varovanja podatkov zakrili.

5.1 Analiza napak

5.1.1 Strojni viri

V ta sklop napak sodijo napake, ki so posledica odpovedi strojne opreme. Sam sistem

aplikacij NCTS (MCC/ECN/GMS) in baza Oracle so postavljeni redundantno tako, da

imamo v primeru napake na strojni opremi vedno na voljo dodatno opremo, že pripravljeno

za delovanje. Tako imamo na primer podvojene vse pomembnejše dele v strežnikih (diski,

mrežne kartice, kartice FC (Fiber-optic Connector)), pa tudi sama strežnika sta v

redundantni povezavi (cluster).

5.1.1.1 Nadzor

Sam nadzor strojne opreme poteka preko nadzornega sistema, ki redno preverja sistemske

dnevnike na obeh strežnikih ter na diskovnem polju in generira opozorila v primeru

odpovedi strojne opreme.

V primeru odpovedi nadzornega sistema ima dežurni inženir tudi možnost ročnega

preverjanje sistemskih dnevnikov.

Nadzorni sistem preverja naslednje dele strojne opreme: mrežne kartice, kartice FC, diske,

pomnilnik, računalnik kot celoto in napajanje.


Stran 31

5.1.1.2 Detekcija

Nadzorni sistem sproži v primeru odpovedi strojne opreme posebno akcijo, ki o odpovedi

določenega strojnega dela obvesti dežurnega delavca preko elektronske pošte ali SMS-a.

5.1.1.3 Odprava napake

Dežurni delavec mora ob dospetju alarma preveriti sistem in locirati napako tako, da se

preko povezave VPN poveže v HKOM in prijavi na sistem. Po preverbi in potrditvi

odpovedi strojnega dela se glede na vrsto odpovedi obvesti naslednje odgovorne:

• v primeru odpovedi strojne opreme na strežnikih NCTS (Ncts1 in Ncts2),

diskovnega polja ECM, in stikala za diskovno polje je pristojno za reševanje

nastalih problemov podjetje BULL Slovenija,

• v primeru odpovedi mrežnih stikal se obvesti podjetje ASTEC,

• v primeru odpovedi tračne enote DLT (Digital Linear Tape) se obvesti podjetje

S&T.

5.1.1.4 Seznam strojnih virov:

• strežnika Ncts1 in Ncts2 (napajanje, CPU (Central Processing Unit)) – BULL

Escala 240,

• mrežne kartice (delovanje mreže) – dve za produkcijo/strežnik, ena za

rezervni/strežnik,

• mrežne optične kartice FC (povezava z diskovnim poljem) – dva na vsak strežnik,

• pomnilnik – 16 Gb,

• lokalni diski (/swap, /tmp, /, /orasys) – 72 Gb konfiguracija v sistem RAID 1,

• diskovno polje,

• mrežna stikala,

• tračna enota DLT (SCSI),

• napajanje (dva/strežnik).


Stran 32

5.1.2 Programska oprema

V ta sklop napak sodijo napake, ki so posledica odpovedi ali pomanjkanja določene

programske opreme. To so na primer prostor na datotečnih sistemih, zasedenost

pomnilnika, ostali infrastruktuni viri, ki omogočajo delovanje aplikacije (operacijski

sistem, baza Oracle, transakcijski sistem TUXEDO ipd.).

5.1.2.1 Nadzor

Sam nadzor programskih virov se izvaja preko nadzornega sistema, ki redno preverja

sistemske in aplikacijske dnevnike na obeh strežnikih in v primeru odpovedi programskih

virov obvesti dežurnega delavca v podjetju S&T preko elektronske pošte ali sporočila

SMS.


preverjanje sistemskih in programskih dnevnikov.

Nadzorni sistem preverja naslednje vire:

• nivo operacijskega sistema:

� prostor na diskih,

� dosegljivost mreže (na produkcijski in na nadomestni lokaciji),

� dosegljivost vrat (ports),

• nivo baze Oracle:

� delovanje baze,

� prijavljanje (logging),

� izdelava varnostne kopije (backup) ,

• nivo transakcijskega sistema TUXEDO:

� viri za medprocesno komunikacijo (IPC Inter-Process Communications),

� zasedenost vrst.

5.1.2.2 Detekcija

V primeru odpovedi programske opreme sproži sistem posebno akcijo, ki o odpovedi

določenega strojnega dela preko elektronske pošte ali sporočil SMS obvesti dežurnega

delavca v podjetju S&T.


Stran 33


Dežurni inženir je dolžan preveriti sistem in locirati napako tako, da se preko povezave

VPN poveže v HKOM in prijavi na sistem.

Po preverbi in potrditvi odpovedi programskega vira se obvesti naslednje odgovorne:

• v primeru odpovedi na nivoju operacijskega sistema se obvesti dežurnega inženirja

iz podjetja S&T, ki skrbi za operacijski sistem AIX,

• v primeru odpovedi na nivoju baze se obvesti dežurnega inženirja iz podjetja S&T,

ki skrbi za bazo Oracle,

• tudi v primeru odpovedi na nivoju transakcijskega sistema TUXEDO odpravlja

težavo za to usposobljen dežurni inženir iz podjetja S&T.

5.1.2.4 Seznam programskih virov:

• nivo operacijskega sistema:

� prostor na logičnih diskih: /app, /, /swp, /tmp, /oradata, /oraredo1,

/oraredo2, /oraundotemp, /orasys,

� dosegljivost mreže: vmesnika en0 in en1 strežnikov Ncts1 in Ncts2 v

produkciji medtem, ko vmesnik en2 služi tudi za nadzor rezervnega sistema,

� v sklopu dosegljivosti mreže moramo preverjati tudi vrata, ki morajo biti

dosegljiva od zunaj. Najpomembnejši naslovi vrat so 11000, 10000 in

15000, ki se uporabljajo za aplikacije MCC, GMS in ECN. Pomembni so

tudi naslovi 21,23,1521 in 7001, ki se uporabljajo za nadzor. Ne smemo

pozabiti tudi na specifične naslove vrat, ki se uporabljajo za komunikacijo s

CCN/CSI-GW, ECN, TARIC-RECV, TQM-RECV, SCI-RECV, TARIC-

SEND, TQM-SEND, SCI-SEND,

� preverjanje izvajanja izdelave varnostnih kopij s programskim paketom

TSM (Tivoli Storage Manager),

� število sistemskih virov na uporabnika. Predvsem moramo paziti na število

procesov in maksimalno velikost datoteke. To je predvsem važno pri novi

postavitvi operacijskega sistema AIX ,


Stran 34

� nadzor sistemskih dogodkov.

• Nivo beze Oracle:

� nadzor delovanje baze,

� nadzor izdelave varnostnih kopij z odjemavcem TSM,

� nadzor skripte, ki skrbi za čiščenje arhivskih sledi na diskih /oraredo1 in

/oraredo2,

� nadzor alarmne sledi (alert log).

• Nivo transakcijskega sistema TUXEDO:

� nadzor virov IPC (delovni pomnilnik, semaforji, vrste),

� nadzor vrst za MCC/ECN/GMS,

� nadzor napak v vrstah ERROR,

� nadzor komunikacij med domenami TUXEDO (ECNDOM, MCCDOM,

GMSDOM),

� nadzor samih storitev TUXEDO.

5.1.3 Izmenjava sporočil z zunanjo domeno

V ta sklop napak sodijo napake, zaradi katerih se ne morejo izmenjevati sporočila z

zunanjo domeno. To so na primer napake na sistemih, ki zagotavljajo komunikacijo z

zunanjo domeno (traders).

Sama izmenjava sporočil poteka preko različnih strežnikov, sistem NCTS pa mora

zagotavljati prenos sporočil iz in v strežnik EPKO, ki ga nadzoruje podjetje ZZI.

5.1.3.1 Nadzor

Sam nadzor izmenjave sporočil z zunanjo domeno poteka preko nadzornega sistema, ki

redno preverja aplikacijske dnevnike na strežnikih in ki, v primeru odpovedi izmenjave

sporočil, obvesti dežurnega delavca v podjetju S&T preko elektronske pošte ali sporočil

SMS.

V primeru odpovedi nadzornega sistema ima dežurni iženir tudi možnost ročnega

preverjanje sistemskih in aplikacijskih dnevnikov. Tudi sami uporabniki sistema zelo hitro

opazijo tovrstne napake.


Stran 35

5.1.3.2 Detekcija

Sistem v primeru odpovedi izmenjave sporočil sproži posebno akcijo, ki o odpovedi

izmenjave sporočil z zunanjo domeno obvesti dežurnega delavca v podjetju S&T. Dežurni

inženir mora preveriti sistem in napako ter raziskati, kje dejansko se je napaka zgodila.

Iženir mora preveriti ali sporočila sploh prihajajo v sistem in ali ga zapuščajo (npr.

Sporočila IE015, IE028, IE016, IE045 idr.). V primeru, da izmenjave sporočil ni, mora

preveriti aplikaciji ECN in Most ter stržnik EPKO, ki se nahaja v podjetju ZZI. Za potrebe

nadzora strežnika v podjetju ZZI bi potrebovali dovoljenje za nadzor, ki jo mora zagotoviti

CURS.


Po preverbi in potrditvi odpovedi izmenjave sporočil se obvešča naslednje ljudi:

• v primeru odpovedi izmenjave sporočil na samem strežniku odpravlja težavo

dežurni inženir iz podjetja S&T,

• v primeru odpovedi izmenjave sporočil na strežniku EP se obvesti podjetje ZZI,

• v primeru odpovedi izmenjave sporočil drugje, se obvesti ponudnika storitev.

5.1.3.4 Seznam točk, ki jih moramo nadzorovati:

• strežnik EPKO, ki skrbi za komunikacijo med sistemom NCTS sistemom in

zunanjo domeno,

• sistem Most,

• storitve ECN TUXEDO, namenjene izmenjavi sporočil z zunanjo domeno.

5.1.4 Izmenjava sporočil s skupno domeno (CD)

V ta sklop napak sodijo napake, zaradi katerih se ne morejo izmenjevati sporočila s skupno

domeno (CD). To so na primer napake na sistemih, ki zagotavljajo komunikacijo s skupno

domeno.


Stran 36

Sama izmenjava sporočil poteka preko strežnika CCN/CSI, ki je pod nadzorom EU.

Komunikacija ni direktna, temveč poteka preko požarne pregrade z imenom Europa, ki je

pod nadzorom podjetja ASTEC.

5.1.4.1 Nadzor

Sam nadzor izmenjave sporočil s skupno domeno nadziramo preko nadzornega sistema, ki

redno preverja aplikacijske dnevnike na strežnikih in ki v primeru odpovedi izmenjave

sporočil preko elektronske pošte ali sporočila SMS obvesti dežurnega inženirja v podjetju

S&T. V primeru odpovedi nadzornega sistema ima dežurni inženir tudi možnost ročnega

preverjanja sistemskih in aplikacijskih dnevnikov. Uporabniki sistema tudi sami zelo hitro

opazijo to napako.

5.1.4.2 Detekcija

Sistem v primeru odpovedi izmenjave sporočil sproži posebno akcijo, ki o odpovedi

izmenjave sporočil z zunanjo domeno obvesti dežurnega inženirja v podjetju S&T. Dežurni

inženir mora preveriti sistem in napako ter ugotoviti, kje se je napaka dejansko zgodila.

Inženir mora preveriti, ali sporočila sploh prihajajo v sistem (npr. IE001, IE002, ...) in ali

sistem tudi zapuščajo. V primeru, da izmenjave sporočil ni, mora preveriti komunikacijo s

sistemom CCN/CSI in tudi z aplikacijo ECN.


Ko preverimo in potrdimo odpoved izmenjave sporočil, obvestimo naslednje ljudi:

• V primeru odpovedi izmenjave sporočil na samem strežniku odpravlja težavo

idežurni nženir iz podjetja S&T,

• V primeru odpovedi izmenjave sporočil na sistemu CCN/CSI obvestimo CVI

(Center Vlade RS za informatiko - trenutno je problem, da EU, ki je drugi nivo za

podporo (second-level support), zagotavlja podporo samo v delovnih urah) in

ASTEC.

5.1.4.4 Seznam točk, ki se morajo nadzorovati:

• sistem CCN/CSI-GW – delovanje,

• požarni zid (firewall) na usmerjevalniku Europa, ki omogoča komunikacijo med

sistemi CCN/CSI-GW in NCTS,


Stran 37

• storitvi ECN TUXEDO cdcm_l in cdcm_h, ki skrbita za komunikacijo s sistemom

CCN/CSI-GW na ravni sistema NCTS,

• odjemalec ECN CDCM (Common Domain Communications Module - v konzoli

aplikacije ECN-admin dodatno vklopimo in izklopimo to komunikacijo).

5.1.5 Programi MCC/ECN/GMS

V ta sklop napak sodijo napake, ki se pojavijo na programih NCTS in jih v sklopu rednega

nadzora in dežurstva ni mogoče preprečiti. Tipični primeri napak so hrošči v programu

(bugs) ali pa, da se kakšno sporočilo zatakne v vrsti ali pade del aplikacije ( npr. storitev

TUXEDO) preprosto ne deluje pravilno.

To so aplikacije, ki so napisane posebej za projekt NCTS, razvili pa so jih v podjetju v

Intrasoft iz Grčije. Drugi nivo podpore je organiziran v okviru ustreznih služb EU.

Teh napak se ne da preprečiti vnaprej, saj jih praktično ni mogoče predvideti. Potrebno jih

je kakovostno ročno nadzorovati, kar je naloga dežurnega inženirja iz podjetja S&T.

5.1.5.1 Nadzor

Sam nadzor izmenjave sporočil s skupno domeno se izvaja preverja preko nadzornega

sistema, ki redno preverja programske dnevnike na strežnikih. V primeru napake na

programih se preko elektronske pošte ali sporočila SMS obvesti dežurnega inženirja iz

podjetja S&T.


preverjanje sistemskih in programskih dnevnikov.

Ročni nadzor, ki ga lahko opravlja dežurni inženir je iz podjetja S&T, je zelo pomemben in

obvezen del nadzora.

5.1.5.2 Detekcija

Napake oziroma hrošči v programih so zelo nepredvidljivi. Pojave nekaterih je mogoče

detektirati relativno preprosto (npr. ustavitev programa), druge pa odkrijemo zelo pozno

(ustavitev posameznega servisa). V primeru detekcije napake je treba čimprej obvestiti

dežurnega inženirja iz podjetja S&T. Dežurni inženir mora napako identificirati in jo po


Stran 38

možnosti tudi odpraviti. V kolikor to ni mogoče, mora napako prijaviti v ustrezni sistem za

javljanje napak na nivoju EU.


Potem, ko je dežurni inženir preveril in potrdil odpoved delovanja aplikacij

MCC/ECN/GMS, vendar napak ni uspel odpraviti, glede na tip napake le-to prijavi

ustreznim službam in sicer:

• v primeru, da je napaka v samem programu (bug), prijavi napako v ustrezen sistem

za sporočanje napak na nivoju EU,

• v primeru, da je za napako kriv postopek, obvesti oddelek HD(Help Desk) v Gorici,

• v kolikor le določena skupina uporabnikov ne more uporabljati aplikacije (kar je

zelo redek pojav), lahko obvesti tudi podjetje ASTEC (v tem primeru

predvidevamo, da je prišlo do napake v omrežju).

5.1.5.4 Seznam točk, ki jih moramo nadzorovati

• Program MCC:

� delovanje programa (vse storitve),

� dnevniki v mapi /app/64/projects/MCCPHASE32/log,

� glavni proces BBL(Bulletin Board Liaison) ,

� prekomerno naraščanje zasedenosti pomnilnika (memory leak),

� upravljalci za odjemalce WSH (Work Station Listener ),

� vrsti z napakami (errqdep, errqdes),

� število sporočil v posameznih vrstah,

� komunikacija do sistema ECN (domena ECNDOM),

� posodobitev šifrantov (IE932, IE931, IE032, IE031 ).

• Program GMS:


� dnevniki v mapi /app/64/projects/GMS/log ,


Stran 39

� glavni proces BBL,

� prekomerno naraščanje zasedenosti pomnilnika ,

� upravljalci za odjemalce WSH,

� vrsta z napakami (ERROR_GMS_Q),


� komunikacija do sistema ECN (doomena ECNDOM),

� posodobitev šifrantov (IE932, IE931, IE032, IE031),

� zapiranje garancij.

• Program ECN:


� dnevniki v mapi /app/64/ecn (ULOG*),

� vtsta z napakami (ERRQUE),


� povezava do sistemov MCC in GMS (domena MCCDOM in GMSDOM),

� translacijske napake (če pride do napake, se sporočilo ne obdela),

� posodobitev šifrantov (IE932, IE032, IE950).

5.1.6 Programi TARIC/TQM/SCI/SEED

V ta sklop napak sodijo napake, zaradi katerih se ne morejo izmenjevati sporočila s skupno

domeno (CD), ki pa ne sodijo v sistem NCTS. To so na primer sporočila za aplikacije

TARIC, TQM, SCI in SEED.

Sama izmenjava sporočil poteka preko strežnika CCN/CSI, ki je pod nadzorom EU.

Komunikacija ni direktna, temveč poteka preko požarne pregrade z imenom Europa, ki je

pod nadzorom podjetja ASTEC.

Sporočila se na koncu posredujejo naprej v obdelavo različnim aplikacijam tako, da je

treba nadzorovati tudi prenos sporočil v te aplikacije.


Stran 40

5.1.6.1 Nadzor

Nadzor izmenjave sporočil s skupno domeno poteka preko nadzornega sistema, ki redno

preverja programske dnevnike na strežnikih in v primeru odpovedi izmenjave sporočil

preko elektronske pošte ali sporočila SMS obvesti dežurnega inženirja iz podjetja S&T.

V primeru odpovedi nadzornega sistema ima dežurni delavec tudi možnost ročnega

preverjanja sistemskih in programskih dnevnikov. Tudi sami uporabniki sistema zelo hitro

opazijo tovrstne napaka (predvsem v sistemu TARIC, kjer je zelo pomembno, da se

sporočila obdelajo še isti dan).

5.1.6.2 Detekcija

Sistem v primeru odpovedi izmenjave sporočil sproži posebno akcijo, ki obvesti preko

elektronske pošte dežurnega inženirja iz podjetja S&T, da je odpovedala izmenjava

sporočil z zunanjo domeno. Dežurni inženir mora preveriti sistem in napako ter preveriti,

kje dejansko se je napaka zgodila. Inženir mora preveriti, ali sporočila sploh prihajajo v

sistem (npr. IE001, IE002 idr) in ali ga zapuščajo. V kolikor izmenjave sporočil ni, mora

inženir preveriti delovanja aplikacije ECN in komunikacijo s sistemom CCN/CSI.

5.1.6.3 Odprava napak

Ko preverimo in potrdimo odpoved aplikacij TARIC/TQM/SCI/SEED, obvestimo

naslednje ljudi:

• v primeru odpovedi izmenjave sporočil na samem strežniku odpravlja težavo

dežurni inženir iz podjetja S&T,

• v primeru odpovedi izmenjave sporočil na CCN/CSI se hkrati obvesti MJU

(administrator sistema CCN/CSI preveri stanje v vrstah in zažene določene storitve

( npr. RAP (Remote API Proxy)) in prijavimo napako v ustrezni sistem za javljanje

napak na nivoju EU

• v primeru, da pade prenos do končnih aplikacij zaradi napake na drugi strani, se

obvesti:

� podjetje 3GEN in ASTEC v primeru, da ne deluje prenos datotek,

� podjetje ZZI v primeru, da se datoteke ne obdelajo (to lahko preveri dežurni

center TARIC).


Stran 41


• sistem CCN/CSI – delovanje,

• požarni zid na usmerjevalniku Europa, ki omogoča komunikacijo med sistemome

CCN/CSI in NCTS,

• same aplikacijske dnevnike (csistack.log in csistack.trc za posamezni program v

mapi /lib),

• komunikacija do ciljnih sistemov (scp, ftp).

5.1.7 Analize sporočil IE917, IE916, IE906, IE907

Napake se lahko pojavijo tudi zaradi samih napak v strukturi ali vsebini sporočil. Programi

sami nadzorujejo (predvsem aplikacija ECN) strukturo in vsebino vsakega sporočila. V

kolikor pride do napake v sami strukturi, programi ustvarujo sporočilo IE917 ali IE907 z

vsebino o napakah. Če pride do napake v vsebini (npr. nepravilne šifre), ki jih lahko

aplikacija sama ugotovi, se z vsebino o napaki ustvari sporočila IE916 ali IE906. Dolžnost

dežurnega inženirja je, da analizira vsa ta sporočila in preverja, ali morda ne prihaja do

napak zaradi napačnih nastavitev sistema. Sporočila so lahko naša ali tuja, analizirati pa je

treba oboja.

5.1.7.1 Nadzor

Samodejni nadzor v teh primerih ni primeren, saj se ne pojavljajo vedno iste napake,

ampak moramo predvsem odkrivati nove. Ključni element je torej ročni nadzor, ki ga

opravlja dežurni inženir iz podjetja S&T. Nadzorni sistem bo nadzoroval samo število

posameznih sporočil IE917, IE916, IE906 in IE907, ki se izmenjujejo preko sistema ECN

in v primeru večjega števila teh napak obvesti dežurnega inženirja iz podjetja S&T preko

elektronske pošte ali sporočila SMS.

5.1.7.2 Detekcija

Dežurni inženir mora vsako novo napako podrobno analizirati in po možnosti ugotoviti

njen vzrok.


Stran 42

5.1.7.3 Odprava napak

Odprava napake je specifična od primera do primera, dežurni inženir pa se mora odločiti

koga v določenem primeru obvesti.


• dnevniki aplikacije ECN (app/64/ecn/ULOG*) ali baza ECN, tabela TRACE,

• sled sporočila (ecn-admin).

5.1.8 Varnostne kopije

Tudi v sistemu NCTS posvečamo skrb rednemu izdelovanju varnostnih kopij. Popolna

varnostna kopija baze se izvaja vsak dan ob polnoči. Na vsakih 15 minut se generira tudi

delna varnostna kopija (inkremental backup). Varnostne kopije sistema strežnikov Ncts1 in

Ncts2 izvedemo vsak dan ob 20:00 uri. Tudi pri tem postopku lahko pride do napak, ki pa

jih je treba čim prej odpraviti, saj potrebujemo v primeru razpada sistema njegove

varnostne kopije.

5.1.8.1 Nadzor

Sam nadzor izdelave varnostnih kopij se izvaja preko nadzornega sistema, ki redno

preverja aplikacijske dnevnike na strežnikih in v primeru zastoja procesa izdelave

varnostnih kopij o tem obvesti dežurnega inženirja iz podjetja S&T preko elektronske

pošte ali sporočil SMS.

Dežurni delavec ima v primeru odpovedi nadzornega sistema možnost ročnega preverjanja

sistemskih in aplikacijskih dnevnikov. Ker uporabniki sistema NCTS te napake načeloma

sploh ne morejo opaziti, mora dežurni inženir še posebej paziti na pravilno izvajanje

izdelave varnostnih kopij.

5.1.8.2 Detekcija

Dežurni inženir mora vsako novo napako podrobno analizirati in po možnosti ugotoviti

vzrok zanjo.


Stran 43


V primeru odpovedi same izvedbe varnostne kopije je treba obvestiti dežurnega inženirja,

ki je zadolžen za sistem TSM.


Nadzor izvajanja izdelave varnostnih kopij preko odjemalca TSM s poizvedbami (query)

5.1.9 Ponovna vzpostavitev sistema

V primeru razpada sistema je treba postaviti sistem na novo. Primer ponovne vzpostavitve

sistema je opisan v posebnem dokumentu Disaster recovery sistema NCTS.

5.1.10 Sisitem Most

V ta sklop napak sodijo napake, ki se zgodijo pri izmenjavi podatkov med sistemoma

NCSTS in EU CIS ali sistemom NCTS in strežnikom EPKO (ZZI). Tipični primeri so npr.

nedelovanje storitve za izmenjavo sporočil o zaključku tranzita (SI025 in SI029) in

sporočil iz sistema EU CIS.

Teh napak običajno ne moremo preprečiti, in jih je tudi težko zaznati. Te vrste napake

mora dežurni inženir iz podjetja S&T s pomočjo nadzornega sistema ročno kakovostno

nadzirati.

5.1.10.1 Nadzor

Sam nadzor izmenjave sporočil s skupno domeno izvajamo preko nadzornega sistema, ki

redno preverja programske dnevnike na strežnikih in v primeru napake na Mostu obvesti

dežurnega inženirja iz podjetja S&T preko elektronske pošte ali sporočila SMS.


preverjanje sistemskih in aplikacijskih dnevnikov.

Ročni nadzor, ki ga opravlja dežurni inženir je pomemben in obvezen del nadzora.


Stran 44

5.1.10.2 Detekcija

Napake na sistemu Mostu so zelo nepredvidljive. Nekatere odkrijemo dokaj hitro

(nedelovanje sistema), druge pa zelo pozno (nedelovanje določene storitve). V primeru

detekcije napake je o tem trebno čim prej obvestiti dežurnega inženirja, ki mora

identificirati napako in jo po možnosti odpraviti.


Potem, ko je dežurni inženir preveril in potrdil odpoved delovanja sistema Most, vendar

napake sam ne more odpraviti, obvesti dežurnega inženirja iz podjetja S&T, ki je za sistem

Most odgovoren.


• delovanje sistema Mosta (storitev za pošiljanje sporočil – SI025 in SI209,

izmenjava z zunanjo domeno),

• programski dnevnik (/app/bea/domains/brgdom/nohup.out),

• nadzor preko ustreznega IP-naslova in vrat 7001 (prijava v konzolo in preverjanje

delovanje samega aplikacijskega strežnika WebLogica),

• nadzor odjemalca IBM MQ za prenos sporočil do SICIS (SI025, SI029, zunanja

domena),

• nadzor vrst TUXEDO (za izmenjavo z zunanjo domeno).


Stran 45

5.2 NAMESTITEV NADZORNEGA SISTEMA - NAGIOS

Sistem Nagios paket je odprtokodni sistem, ki je v osnovi namenjen za namestitev na

operacijskem sistemu Linux. Ker je strežnik, na katerega smo želeli instalirali paket

Nagios, vrste Bull z operacijskim sistemom AIX ver. 5.3, smo morali izvorno kodo za

Nagios prenesti na ta sistem in smo jo potem prevedli kar na strežniku MCC05.

5.1: Povezava strežnikov.

Nagios za svoje delovanje zahteva še aplikacijski in spletni strežnik Apache , ki je prav

tako odprtokodni sistem ter določene grafične knjižnice. Podatki, ki jih nadzorni sistem

Nagios zbira, se lahko hranijo v bazi (za kar bi potrebovali licence) ali pa kar na samem

datotečnem sistemu. Slednjo rešitev smo, kot sem že uvodoma povedal uporabili tudi sami.

Ker smo se odločili uporabljati varno komunikacijo med testnim strežnikom MCC05 in

delovno postajo, kjer se izvaja spletni odjemalec sistema Nagios, smo morali omogočiti

tudi povezavo SSL, ki pa jo sam MCC05 strežnik že uporablja.


Stran 46

5.2.1 Nastavitev nadzornega sistema NAGIOS

Nadzorni sistem Nagios se nastavljamo s pomočjo nastavitvenih datotekah. Slednje so

urejene hierarhično/piramidno, pri čemer se določene nastavitve dedujejo v globino. Vsaka

nastavitvena datoteka ima na začetku sekcijo, v kateri se nahaja primer in opis nastavitev,

ki jih s pomočjo določene datoteke nastavljamo. V našem primeru smo uporabili privzete

nastavitve. Vse datoteke so shranjene v mapi /etc aplikacije Nagios na strežniku MCC05

(/app/nagios/etc). Pri instalaciji sistema Nagios se generirajo tudi vse ustrezne nastavitvene

datoteke. Pravilnost vnesenih sprememb v nastavitvenih datotekah preverjamo s pomočjo

ukaza nagios –v.

Osnovna nastavitvena datoteka je nagios.cfg, v kateri imamo 94 različnih nastavitev.

Mednje sodijo poti do ostalih nastavitvenih datotek, ki jih Nagios uporablja za svoje

delovanje, nastavitev za administratorja, uporabnike in skupine, različne časovne

komponente itd. Te datoteke ne uporablja samo Nagios, ampak tudi spletni vmestnik CGI

(Common Gateway Interface) za prikazovanje stanja sistema Nagios. Vse nastavitvene

datoteke ( torej tudi osnovna nastavitvena daatoteka nagios.cfg) se nahajajo na priloženem

CD-ju, in sicer v mapi /etc.

Naslednja nastavitvena datoteka je definicija strežniških skupin (groups), ki se nahaja v

datoteki hostgroups.cfg.

V nastavitveni datoteki hosts.cfg nastavimo nastavitve za posamezni strežnik, katerega

želimo nadzorovati.

Naštejmo nekaj najpomembnejših nastavitev iz datoteke hosts.cfg:

host_name je ime strežnika, kakor se potem sklicujemo na njega v nastavitvenih datotekah,

address je IP-naslov strežnika,

check_command je ukaz, ki preverja ta strežnik (običajno je to ukaz ping, ki preverja, če se

strežnik v omrežju odziva),

contact_groups je skupina naslovnikov, ki jih sistem obvešča o dogodkih v zvezi s tem

strežnikom.

V našem primeru imamo ustrezne nastavitve za dva strežnika in sicer za Ncts1 in za Ncts2

znotraj skupine NCTS.


Stran 47

V datoteki servicegroups.cfg nastavljamo skupine storitev. Tu smo v začetku upoštevali

našo razdelitev napak po skupinah, vendar smo v času implementacije nadzornega sistema

Nagios iz izkušenj ročnega nadziranja ugotovili, da je boljša porazdelitev na naslednje

skupine:

SYSTEM – napake na nivoju operacijskega sistema,

TUXEDO – vrste TUXEDO,

APPLICATIONS – programi ECN, MCC, GMS,

CCNCSI – programi za izmenjavo sporočil TARIC, TQM, SCI, SEED,

EXCH_NCTS - izmenjava sporočil z domeno NCTS,

LOG_FILES – pregled dnevnikov,

TUX_SYSTEM - storitve TUXEDO,

CHECK_IE906 – preverjanje sporočil IE906.

Skupine se spreminjamo glede na potrebe uporabnikov nadzornega sistema Nagios, tako

smo naknadno dodali skupino CHECH_IE906.

Trenutno imamo veljavnih preko 240 različnih servisov, nastavitve pa se nahajajo v

datoteki services.cfg. Nastavitve posamezne storitve imajo naslednjo obliko:

define service{ use generic-service ; Name of service template to use host_name ncts2 service_description mcc_numb_clients_tuxedo servicegroups TUX_SYSTEM is_volatile 0 check_period 24x7 max_check_attempts 3 normal_check_interval 3 retry_check_interval 1 contact_groups nagios_admins notification_interval 120 notification_period 24x7 notification_options w,u,c,r check_command check_nrpe_mcc_numb_clients_tuxedo!120!140 }


Stran 48

Pomembnejše nastavitve so:

• host_name je ime strežnika, na katerem se izvede storitev, nastavljena v datoteki

host.cfg,

• service_description je opis storitve, kakor je prikazano v grafičnem vmestniku in

obveščanju preko elektronske pošte,

• servicegroups je skupina storitev, ki ji določena storitev pripada,

• normal_check_interval je čas v minutah med izvajanjem posamezne storitve,

namenjene preverjanju,

• check_command – s tem ukazom kličemo storitev,

• contact_groups je skupina naslovnikov, ki jih sistem obvešča o dogodkih, ko so

mejne vrednosti prekoračene,

vse ostale nastavitve lahko pogledamo v dokumentaciji za Nagios.

Naslednja nastavitvena datoteka je timeperiods.cfg, v kateri nastavimo časovna obdobja, ki

se uporabljajo za delovanje storitev. Storitve razdelimo v skupine v skladu s potrebami

delovanja našega IS glede na dan v tednu ali uro v dnevu. Pri določenih storitvah se je

pojavil problem, ko je sistem v nočnem času zaradi premajhnega obsega prometa javljal

napako. Zato smo kasneje razdelili delovanje storitev na dva dela: prva storitev nadzira

delovanje IS preko dneva, druga storitev pa nadzira delovanje IS preko noči ter v soboto in

v nedeljo.

V datoteki contactgroups.cfg nastavimo različne skupine, ki bodo v primeru prekoračitve

vrednosti posamezne storitve obveščene po elektronski pošti. Prvotno smo razdelili

obveščanje na štiri skupine in kasneje pa smo dodali še skupino nagios_gms.

Za vsakega, ki ga želimo obveščati preko elektronske pošte, vpišemo ustrezne nastavitve in

kontaktne podatke v datoteki contacts.cfg.

Storitve, ki nadzorujejo posamezen strežnik Ncts1 in Ncts2, so nameščene lokalno na

vsakem strežniku. Do posamezne storitve na strežniku dostopamo na način, ki je zapisan v

datoteki checkcommands.cfg. Kot smo videli že v definiciji storitev, nam delovanje

storitev omogoča določen ukaz (command), ki se izvaja periodično. Konfiguracije vseh

ukazov so v datoteki checkcommands.cfg.


Stran 49

Kot vidimo, je vsak ukaz definiran z dvema parametroma – z imenom in z dejanskim

ukazom, ki se zvede(command_line).

5.2.2 Namestitev nrpe (Daemon and plugin for executing plugins on remote hosts) na

Ncts1 in Ncts2

Na strežnikih Ncts1 in Ncts2 smo namestili program nrpe, ki teče v ozadju in ob klicu

ukaza iz sistema Nagiosa sproži nadzorno storitev (tudi na oddaljenih strežnikih). Program

nrpe vsebuje veliko nadzornih storitev. Storitve, ki so specifične za naš IS, smo napisali

sami in njihove nastavitve se nahajajo v datoteki nrpe.cfg.

5.2: Povezava Nagios – NRPE.

Kot smo že omenili, s pomočjo nastavitvenih datotek definiramo ukaza za posamezene

storitve, ki se periodično izvajajo ob točno določenem času in prožijo programe, ki

preverjajo točno določene parametre (npr. število sporočil v vrsti TUXEDO, prost prostor

na diskih strežnikov, dostop do strežnikov ipd.). V posameznem programu določimo mejne

vrednosti, ko veljajo za prehoh določene storitve iz normalnega stanja (NORMAL) v

opozorilno stanje (WARNING) ali celo v kritično stanje (CRITICAL). Kritično stanje

seveda ne pomeni, da sistem ne deluje, temveč posamezne vrednosti parametrov kažejo, da

lahko sistem preneha z delovanjem ali da bo kmalu deloval moteno. Različna stanja so na

spletnem vmesniku obarvana zeleno, rumeno ali rdeče.


Stran 50

5.3 POSEBNOSTI REŠITVE

Za preverjanje smo bili napisali storitve, ki jih kliče nadzorni sistem Nagios. V primeru, ki

sledi, je prikazano preprosto preverjanje sporočil, ki so bila posredovana iz baze. Glede na

nastavitve, ki smo jih nastavili v nastavitvenih datotekah, se izvede ukaz, ki preko

programa nrpe proži lupinski skript (shell script). Ta skript naredi v bazi poizvedbo s

skriptom sql. Skript select_last_SI029.sh (vsi omenjeni skripti se nahajajo na priloženem

CD-ju) nam posreduje informacijo o tem, kdaj je bilo poslano zadnje sporočilo iz sistema

NCTS v sistem SICIS. Glede na predhodno nastavljeno vrednost, (opozorilo (WARNING)

300, kritično (CRITICAL) 1800, nujno (URGENTLY) 1), dobi nadzorni sistem Nagios

stanje izmenjave sporočil. Kot smo omenili, vsaka od storitev vrača tri stanja. V zgornjem

primeru smo uporabili dva stanja, ki se na spletnem vmesniku izpišeta in obarvata rdeče

(CRITICAL in URGENTLY). Če je poslano samo eno sporočilo, se nam v grafičnem

prikazovalniku in v elektronskem sporočilu izpiše URGENTLY. Na spodnji sliki vidimo

prikaz našega nadzornega sistema Nagios.


Stran 51

5.3: Nadzorni sistem Nagios.

Možnost obveščanja s pomočjo sporočil SMS smo realizirali s pomočjo storitve, ki jo

ponuja mobilni operater Mobitel v okviru svoje standardne ponudbe Planet, ko omogoča

odprtje poštnega predala na Planetu in pošiljanje sporočil SMS v primeru, ko dobimo

elektronsko pošto. V sistemu Nagiosu smo nastavili kritične storitve tako, da pošiljajo

elektronska sporočila tudi na elektronski naslov na Planetu.


Stran 52

6 ZAKLJU ČEK

Informacijski sistemi postajajo vsak dan bolj zapleteni. Vzdrževanje in nadzorovanje takih

sistemov je zelo težavno, zamudno in kompleksno. Na trgu je veliko nadzornih rešitev, ki

so med drugim lahko vodilo primere, s katerimi se srečujemo v praksi. K celotnemo

reševanju nadzora računalniških sistemov in omrežij nam veliko pomagajo priporočila in

smernice, ki nam jih podaja ITIL. Za nadzorovanje sistemov je pomembno poznavanje

strojne in programske opreme, ki jo nadzorujemo ter poznavanje poslovnih procesov, ki se

na programski opremi izvajajo. Procesi, ki so dobro opisani in definirani, nam pomagajo

pri analizi napak, ki se lahko pojavijo pri delovanju IS. Pri razvoju nadzornega sistema se

opiramo na priporočila ITIL razdelamo IS, kjer lahko pride do napak, na manjše skupine,

jih opišemo, opišemo postopke reševanja in eskalacije pri dolgotrajnem odpravljanju

posameznega problema. Zelo pomembno je, da se po postavitvi nadzornega sistema izvede

šolanje za bodoče uporabnike nadzornega sistema. Uporaba sistema za nadziranje je lahko,

v primeru, da je izvedena profesionalno in pregledno, zelo preprosta in je namenjena tudi

uporabnikom, ki niso vešči rokovanja z računalniško opremo, imajo pa vsebinsko znanje.

Najbolj pomembno je, da se nadzorni sistem nenehno dopolnjuje in vodi dokumentacija o

posodabljanju nadzornega sistema. Pri nadgradnjah in dopolnitvah tako strojne kot

programske opreme našega IS je treba dopolnjevati tudi nadzorni sistem. Ne smemo se

zadovoljiti s storitvami, ki smo jih implementirali. Slediti je treba spremembam v IS in

predlogom, ki jih podajajo uporabniki nadzornega sistema. Predloge pretehtamo in po

potrebi dodamo nove nadzorne storitve, ali popravimo že obstoječe. V primeru, ko mejne

vrednosti niso najbolje postavljene, pride do prevelikega obsega obvestil, tako da

uporabniki postanejo imuni na sporočila iz našega nadzornega sistema.

Pri dobro uglašenem in vzdrževanem nadzornem sistemu smo o napakah opozorjeni, še

preden do večjih izpadov IS. V primeru, da do napak pride, je lociranje zelo preprosto in

aktiviranje servisnih služb, ki so odgovorne za posamezne sklope strojne ali programske

opreme, je enostavno in natančno.

Vloženega časa in denarja v nadzorni sistem nam ne sme biti žal, saj lahko z njegovo

pomočjo zmanjšamo izpade našega IS, povečamo zadovoljstvo uporabnikov, zmanjšamo

stroške odprave napak, posledica tega pa je na koncu tudi manjši izpad dohodka zaradi

nedelovanja našega informacijskega sistema.


Stran 53

Literatura:

[1] BMC SOFTWARE, http://www.bmc.com/

[2] CA Transforming IT Mnagement, http://www.ca.com/us/service-desk-

management.aspx

[3] DDNTA Main document for NCTS Phase 3.2 and ECS (TCE-L1-DDNTA-P32),

Taxation and Customs Union DG, European Comission, Bruselj, 2006

[4] ECN Phase 3.2: Detailed Design Document (TCE-DTD-L1ECN-P32-v2.60-

EN.doc), Taxation and Customs Union DG, European Comission, Bruselj, 2006

[5] GMS Phase 3.2: Detailed Design Document (TCE-DTD-L1GMS-P32-v2.60-


[6] IBM Tivoli Composite Application Manager for Applications helps IT

http://www-01.ibm.com/common/ssi/cgi-

bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=877&lettern

um=ENUSZP08-0260#Header_8

[7] OGC – about ITIL, http://www.ogc.gov.uk/index.asp?id=2261

[8] Itil Books IT SERVICE MANAGMENT ZONE, http://www.itil.org.uk/

[9] ITIL, http://www.itil-officialsite.com/home/home.asp

[10] MCC Phase 3.2: Detailed Design Document (TCE-DTD-L1MCC-P32-v2.60-


[11] Nagios, http://www.nagios.org/

[12] OpenNMS, http://www.opennms.org/index.php/Main_Page


Stran 54

PRILOGE

Diplomski nalogi je priložena zgoščenka (CD - Compact Disc), na kateri so zapisane

nastavitvene datoteke od Nagiosa. Poleg tega vsebuje še elektronsko verzijo diplomske

naloge v formatu PDF ter predstavitev zagovora v formatu Powerpoint.

6.1 Seznam slik

Slika 2.1: Struktura priporočil ITIL V3. ............................................................................... 5

Slika 3.1: Nadzorni sistem .................................................................................................... 8

Slika 3.2: Nagios - prva stran. ............................................................................................. 12

Slika 3.3: Nagios – taktični pregled. ................................................................................... 13

Slika 3.4: Nagios – skupine, urejene po storitvah. .............................................................. 13

Slika 3.5: Nagios – storitve. ................................................................................................ 14

Slika 3.6: Nagios – filter. .................................................................................................... 15

Slika 3.7: Nagios – zgodovina............................................................................................. 16

Slika 3.8Nagios – zgodovina............................................................................................... 16

Slika 3.9: Nagios - statistika storitev................................................................................... 17

Slika 3.10: Nagios – obveščanje. ........................................................................................ 17

Slika 3.11: Nagios - nastavitve............................................................................................ 18

Slika 4.1: ECN znotraj NCTS. ............................................................................................ 22

Slika 4.2: Vhodne in izhodne vrste ECN. ........................................................................... 24

6.2 Seznam tabel

Tabela 3.1: Primerjalna tabela odprtokodnih sistemov....................................................... 19

Tabela 4.1: Povezave domen na ECN................................................................................. 21

Tabela 4.3: Seznam vhodnih čakalnih vrst.......................................................................... 25


Stran 55

Tabela 4.4: Seznam izhodnih vrst ....................................................................................... 26

6.3 Naslov študenta

Vasilij Škrlj

Begunje 131

1382 Begunje pri Cerknici

Tel: (01) 7056-327

e-mail: [email protected]

6.4 Kratek življenjepis

Rodil sem se 22.1.1968 v Postojni. Po končanem trilrtnem programu na Srednji šoli za

elektroniko in naravoslovje v Ljubljani Prušnikova 98, sem se zaposlil v Iskri Delti.

Šolanje sem nadaljeval izredno in dve leti kasneje končal V. stopnjo Srednje

elektrotehniške šole na Vegovi 4. Delavne izkušnje in znanje sem si nabiral tudi v delovnih

organizacijah EI BULL in Plasis.

Od leta 2005 sem zaposlen v računalniškem podjetju S&T d.o.o., kjer delam na projektu

NCTS in sem odgovoren za delovanje sistema za elektronsko izmenjavo tranzitnih

deklaracij.

vis skrlj vasilij 1968 93492497 · aix advanced interactive executive bac business availability...

Documents