Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
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.7.4 Seznam točk, ki jih moramo nadzorovati: .......................................... 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
5.1.8.4 Seznam točk, ki jih moramo nadzorovati: .......................................... 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.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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).
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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).
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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).
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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).
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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).
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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 .
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
Stran 22
LAN
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.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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).
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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).
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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.
V primeru odpovedi nadzornega sistema ima dežurni inženir tudi možnost ročnega
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.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
Stran 33
5.1.2.3 Odprava napake
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 ,
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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.
5.1.3.3 Odprava napake
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.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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.
5.1.4.3 Odprava napake
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,
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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.
V primeru odpovedi nadzornega sistema ima dežurni inženir tudi možnost ročnega
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
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
Stran 38
možnosti tudi odpraviti. V kolikor to ni mogoče, mora napako prijaviti v ustrezni sistem za
javljanje napak na nivoju EU.
5.1.5.3 Odprava napake
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:
� delovanje programa (vse storitve),
� dnevniki v mapi /app/64/projects/GMS/log ,
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
Stran 39
� glavni proces BBL,
� prekomerno naraščanje zasedenosti pomnilnika ,
� upravljalci za odjemalce WSH,
� vrsta z napakami (ERROR_GMS_Q),
� število sporočil v posameznih vrstah,
� komunikacija do sistema ECN (doomena ECNDOM),
� posodobitev šifrantov (IE932, IE931, IE032, IE031),
� zapiranje garancij.
• Program ECN:
� delovanje programa (vse storitve),
� dnevniki v mapi /app/64/ecn (ULOG*),
� vtsta z napakami (ERRQUE),
� število sporočil v posameznih vrstah,
� 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.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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).
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
Stran 41
5.1.6.4 Seznam točk, ki jih moramo nadzorovati:
• 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.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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.
5.1.7.4 Seznam točk, ki jih moramo nadzorovati:
• 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.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
Stran 43
5.1.8.3 Odprava napake
V primeru odpovedi same izvedbe varnostne kopije je treba obvestiti dežurnega inženirja,
ki je zadolžen za sistem TSM.
5.1.8.4 Seznam točk, ki jih moramo nadzorovati:
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.
V primeru odpovedi nadzornega sistema ima dežurni inženir tudi možnost ročnega
preverjanje sistemskih in aplikacijskih dnevnikov.
Ročni nadzor, ki ga opravlja dežurni inženir je pomemben in obvezen del nadzora.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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.
5.1.10.3 Odprava napake
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.
5.1.10.4 Seznam točk, ki jih moramo nadzorovati:
• 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).
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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 }
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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.
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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-
EN.doc), Taxation and Customs Union DG, European Comission, Bruselj, 2006
[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-
EN.doc), Taxation and Customs Union DG, European Comission, Bruselj, 2006
[11] Nagios, http://www.nagios.org/
[12] OpenNMS, http://www.opennms.org/index.php/Main_Page
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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
Upravljanje in nadzor sistema za elektronsko predložitev carinskih deklaracij (NCTS) Carinske uprave RS
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.