Prosjektrapport. Atea. Overvåkningssystem for et plattformuavhengig miljø

Transkript

1 Prosjektrapport Atea Overvåkningssystem for et plattformuavhengig miljø

2 PROSJEKT NR Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Overvåkningssystem for et plattformuavhengig miljø DATO 29. mai 2009 ANTALL SIDER / BILAG 68/12 PROSJEKTDELTAKERE Arne Otterbeck Carl Fredrik Halgard Stephan Bjoraa INTERN VEILEDER Torunn Gjester OPPDRAGSGIVER ATEA AS KONTAKTPERSON Tore Stensrud SAMMENDRAG I denne prosjektrapporten har vi sammenliknet tre store overvåkningsverktøy, HP Business Availability Center, IBM Tivoli Monitoring og Microsoft SystemCenter Operation Manager, for å finne det beste verktøyet for vår oppdragsgiver. Oppdragsgiveren krevde et verktøy som kunne overvåke deres demomiljø bestående av flere forskjellige plattformer. I tillegg har vi sammenliknet HP Discovery and Dependency Manager, IBM Tivoli Application Discovery Dependency Manager og discoveryfunksjonen til Microsoft SystemCenter Operation Manager for å finne det beste verktøyet for å generere inventardatabase. Resultatene vi har kommet frem til gjennom vår testing av verktøyene er at IBM Tivoli tilbyr det verktøyet som passer best i henhold til bedriftens krav. 3 STIKKORD Overvåkning Inventardatabase Testing Side 2 av 68

3 Forord Denne rapporten er resultatet av det arbeid og den prosess vi i gruppen har utført som et team igjennom det siste halve året i hovedprosjektet Overvåkningssystem for et plattformuavhengig miljø. Resultatet har blitt et utfyllende dokument om hvordan det er å teste, evaluere og implementere et omfattende overvåkningsverktøy i et eksisterende plattformuavhengig miljø. Vi har sammenliknet tre konkurrerende overvåkningsverktøy opp mot hverandre. Rapporten kan brukes som veiledning for brukere som er ute etter slike overvåkningsløsninger. Dette fordi vi har dokumentert hele installasjonsprosessen med konfigureringer og de mest brukte funksjonene. Vi har jobbet aktivt med å formulere oss på best mulig måte slik at rapporten appellerer til personer med og uten teknisk innsikt. Vi vil takke vår veileder, Torunn Gjester, for god oppfølging gjennom hele perioden som har kommet med tips og råd til prosjektarbeidet. Og en takk til Kyrre Begnum for fyldig tilbakemelding på prosjektrapporten. Vi vil også takke vår oppdragsgiver, Atea AS, for kontorplass, nødvendig utstyr, oppfølging og utømmelige mengder med god kaffe. Oslo, mai 2009 Arne Otterbeck s Carl F. Halgard s Stephan Bjoraa s Side 3 av 68

4 Innholdsfortegnelse F O R O RD PR ESE N T ASJO N INN L E DNIN G OM BEDRIFTEN BAKGRUNN FOR PROSJEKTET MOTIVASJON Bedriftens motivasjon Elevenes motivasjon PROBLEMSTILLING M E T O D E R PROSJEKTSTYRING TESTLAB B A K G RUNN OVERVÅKNINGSVERKTØYENE IBM Tivoli HP Busines Availability Center Microsoft Operations Manager INSTALLASJON AV OPERATIVSYSTEM OG OVERVÅKNINGSVERKTØY Systemkrav for verktøyene Installasjon av operativsystem Microsoft Windows Server Microsoft Windows Server Installasjon av overvåkningsverktøy FORBEREDELSER TIL TESTING IBM Tivoli HP Business Availability Center Microsoft Operations Manager O V E R V Å K NIN G TING SOM SKAL TESTES TESTSKJEMA FOR OVERVÅKNING TESTRESULTAT AV OVERVÅKNING Testmatrise Statistikk og kommentarer Kommentarer til testene DISC O V E R Y O G IN V E N T A RD A T A B ASE TEST AV INVENTARDATABASE OG DISCOVERY TESTRESULTAT AV INVENTARDATABASE OG DISCOVERY IBM discovery og inventardabase HP discovery og inventardatabase Microsoft discovery og inventardatabase Statistikk og kommentarer Side 4 av 68

5 7. E V A L U E RIN G O G V A L G A V V E R K T Ø Y EVALUERING AV OVERVÅKNING IBM overvåkning HP overvåkning Microsoft overvåkning EVALUERING AV DISCOVERY OG INVENTARDATABASE IBM discovery og inventardatabase HP discovery og inventardatabase Microsoft discovery og inventardatabase DR Ø F T IN G O G V A L G A V V E R K T Ø Y TESTRESULTATENES BETYDNING FOR VALG AV VERKTØY SAMMENLIKNING AV EGENSKAPER DRØFTING VALG AV VERKTØY Oppsummering I M PL E M E N T E RIN G PLANLEGGING HVA BLE IMPLEMENTERT K O N K L USJO N PROBLEMSTILLING VIDERE ARBEID A RB E IDSM E T O D E R O G PR O B L E M E R UND E R V E IS EVALUERING AV ARBEIDSMETODER Evaluering av testlab Evaluering av testskjema Evaluering av test av discovery og inventardatabase GENERELLE VERKTØY OG METODER HVA GIKK GALT K I L D E R D A T A O RDB O K Side 5 av 68

6 1. Presentasjon Vi er tre studenter fra Høgskolen i Oslo som har fått i oppgave av Atea å evaluere tre store overvåkningsverktøy opp mot hverandre. Vi skal velge det verktøyet som passer best i henhold til bedriftens krav og ønsker, som fremkommer i kravspesifikasjonen (se vedlegg A), og deretter implementere dette verktøyet. Atea har et eget presentasjonsrom hvor de viser frem løsninger for kunder. Før de kan vise disse løsningene for kundene, er de nødt til å sette opp demoer for å teste at de fungerer. Dette gjør de i en egen demolab 1, det er denne demolaben de ønsker å få overvåket ved hjelp av det overvåkningsverktøyet vi skal velge. Prosjektperiode: Januar 2009 Juni 2009 G ruppemedlemmer: Arne Otterbeck (s141809), Stephan Bjoraa (s141799), Carl Fredrik Halgard (s141802) Veileder: Torunn Gjester, tlf: , e-post: Torunn.Gjester@iu.hio.no Oppdragsgiver: Atea ( Kontaktperson: Tore Stensrud, tlf: , e-post: tore.stensrud@atea.no Side 6 av 68

7 2. Innledning 2.1 O M BEDRIFTEN Atea er en av de ledende leverandørene av IT-infrastruktur. De leverer hovedsakelig maskin- og programvareprodukter, konsulenttjenester og serviceavtaler. Selskapet har over 4300 ansatte fordelt på kontorer i 72 byer i Norge, Sverige, Danmark, Finland, Litauen, Latvia og Estland. I Norge har Atea kontorer i Oslo, Hamar, Larvik, Kongsberg, Drammen, Arendal, Kristiansand, Stavanger, Haugesund, Bergen, Ålesund, Trondheim, Bodø og Tromsø. 2.2 BA KGRUNN FOR PR O SJEK T ET Atea har et stort demomiljø hvor de setter opp og tester løsninger før de viser disse løsningene for kunder. Dette miljøet har etter hvert blitt veldig stort og uoversiktlig. I denne sammenheng ønsker de å implementere et overvåkningsverktøy for å overvåke maskinene i miljøet, både fysiske og virtuelle, samt nettverksutstyr 2. De ønsker også en inventardatabase med oversikt over alt utstyr i demomiljøet. Med demomiljø mener vi laben hvor konsulentene og selgerne setter opp løsninger som skal testes før de vises til kunder. Denne laben består av en rekke servere og maskiner i tillegg til et stort virtuelt miljø samt nettverksutstyr. Som eksempler på demoer som er satt opp kan det nevnes Cisco IP-telefoni løsninger og Unified Communication MOTIVASJON Bedriftens motivasjon Atea ønsker først og fremst å få et overvåkningssystem som gir bedre oversikt over miljøet og som håndterer feil på en god måte. Dette vil igjen gjøre det enklere for driftssjefen i demomiljøet å holde miljøet ved like. De ønsker også kunne vise frem og selge disse overvåkningsverktøyene videre Elevenes motivasjon Vi søkte bevisst etter en oppgave som omhandlet sikkerhet, virtualisering 4 og serverteknologi. Vi kunne ikke fått en bedre oppgave enn den vi fikk fra Atea. Vi ønsker å tilegne oss kunnskap og ferdigheter innen disse feltene. Side 7 av 68

8 2.4 PROBLEMST ILLING Atea har per i dag ingen løsning for å overvåke demomiljøet sitt, og vil se på forskjellige løsninger for å implementere i deres allerede konfigurerte demomiljø. Det bedriften er ute etter er en løsning som er lett å implementere i demomiljøet de allerede har, og som kan overvåke maskiner (virtuelle og fysiske) og nettverksenheter, samt lage en inventardatabase som gir bedre oversikt over enheter og relasjonene mellom disse. Vi skal sammenligne og teste tre slike løsninger. De tre overvåkningsløsningene som Atea ønsket at vi skulle teste og evaluere er IBM Tivoli, HP Business Availability Center og Microsoft System Center Operations Manager. Disse verktøyene ble valgt siden disse produsentene er salgspartnere med Atea. Det er viktig å påpeke at verktøyene fra de forskjellige produsentene ikke kan kombineres. Derfor må både overvåkningsverktøy og discovery og inventardatabaseverktøy være fra samme produsent. Etter ønske fra driftssjef demomiljø skal hovedfokus ligge på overvåkning. Problemstillingene er derfor satt i prioritert rekkefølge. Problemstillingene: I forhold til bedriftens krav, 1. Hvilket overvåkningsverktøy passer best å implementere i henhold til bedriftens krav: IBM Tivoli Monitoring, HP Business Availability Center eller Microsoft System Center Operation Manager? 2. Hvilket verktøy genererer den mest fullstendige inventardatabasen på bakgrunn av en discoveryfunksjon: HP Discovery and Dependency Mapping, IBM Tivoli Application Discovery Dependency Manager eller Microsoft System Center Operation Manager? 3. Når verktøy er valgt, skal vi implementere disse verktøyene i demomiljøet. Vi vil gjerne presisere de viktigste begrepene fra problemstillingen: Bedriftens krav: Bedriftens krav ut ifra det som kommer frem i kravspesifikasjonen (vedlegg A Kravspesifikasjon). Inventardatabase: Database som lagrer informasjon om enheter som blir funnet i nettverket på bakgrunn av en discovery. Discoveryfunksjon: Nettverksoppdagelse som finner maskiner og enheter i et nettverk. IB M Tivoli : Består av to forskjellige verktøy, ett for overvåkning og ett for discovery og inventardatabase. Side 8 av 68

9 HP Business Availability Center: Består av to forskjellige verktøy, ett for overvåkning og ett for discovery og inventardatabase. Microsoft System Center Operation Manager: Kun ett verktøy for både overvåkning og discovery og inventardatabase. Side 9 av 68

10 3. Metoder 3.1 PROSJEKT ST YRING For å få en god oversikt over prosjektet satte vi opp en prosjektplan som inneholder mål for prosjektet, intern organisering, valgt prosessmodell, fremdriftsplan i form av et GANTT diagram 5, milepælsplan, ansvarskart og risikostyring. I tillegg til dette har vi ført prosjektdagbok og timeregnskap. Målet med å ha en slik prosjektstyringsplan er at det skal fordele våre ressurser i form av timer på en god måte. I tillegg vil det være bra å ha en oversikt over hvem som har ansvaret for de enkelte aktivitetene. Vi lagde denne prosjektplanen for å få struktur i arbeidet vårt og for få en oversikt over de ulike tidsfristene i prosjektet vårt. Denne prosjektplanen vil hjelpe oss å overholde frister og krav slik at vi leverer et godt produkt ved slutten av prosjektperioden. (Se vedlegg B Prosjektplan) Side 10 av 68

11 Milepæl Dato Beslutning/godkjenning Webside opprettet 5/12 09 Nettsiden er laget Statusrapport levert på nett 5/12 09 Statusrapporten er lagt ut på nettsiden Forprosjektrapport levert på nett 30/1 09 Forprosjektrapporten er lagt ut på nettsiden Kravspesifikasjon godkjent 22/1 09 Kravspesifikasjon godkjent av oppdragsgiver og prosjektleder Testskjema godkjent 11/2 09 Testskjema er godkjent av oppdragsgiver og prosjektleder Forberedende del er ferdig 13/2 09 Kravspesifikasjon og testskjema er godkjent og VLAN 6 og virtuelle maskiner maskiner er ferdig installert med demoverktøy Testing av verktøy er ferdig 6/3 09 Ferdig med å utføre forskjellige testscenarioer på de forskjellige demoverktøyene Evalueringsdel er ferdig 20/3 09 Ferdig med evaluering av verktøy. Verktøy som skal brukes er også valgt Planleggingsdel er ferdig 3/4 09 Har laget løsningsdesign og satt opp plan for implementering som er godkjent av oppdragsgiver og prosjektleder Implementasjonsdel er ferdig 11/5 09 Ferdig med å installere, konfigurere overvåkningsverktøy. Har også utført akseptansetest. Prosjektrapport er levert på nett og på HiO 29/5 09 Prosjektrapporten er lagt ut på nettsiden og levert i ekspedisjonen. Framføring på HiO 15 17/6 09 Framføring for sensor og medstudenter på HiO Dette er milepælsplanen vi har forholdt oss til i dette prosjektet. Side 11 av 68

12 3.2 T EST LAB For å installere og teste de tre forskjellige overvåkningsverktøyene valgte vi å bruke en testlab. Atea har allerede et virtuelt demomiljø, derfor valgte vi å installere og teste de forskjellige overvåkningsverktøyene i dette virtuelle miljøet. Dette mener vi er den beste måten å få kjennskap til verktøyene på, både gjennom installasjonsprosessen og bruk. Alternativet ville være å installere og teste på fysiske maskiner, men dette hadde tatt lenger tid enn det gjorde å sette opp de virtuelle maskinene og virtuelle nettverkene. I tillegg ville det koste mye penger og det ville være upraktisk i den forstand at det ville tatt mye plass. Et annet alternativ vi vurderte var virtuelle testlaber som Microsoft tilbyr over nett, men disse labene var tidsbegrenset og produsentene av de andre verktøyene vi skulle teste tilbyr ikke denne tjenesten, derfor valgte vi å gå bort fra dette alternativet. Figur 1:Ateas demomiljø Side 12 av 68

13 Dette er en oversikt over Atea sitt allerede eksisterende demomiljø. De virtuelle maskinene vi satt opp og installerte de forskjellige verktøyene på ligger på virtuelle nettverk. Disse virtuelle nettverkene og maskinene ligger på et IBM Bladecenter. Et IBM Bladecenter er en boks hvor man kan sette inn flere små server. Disse små serverne er på størrelse med et skjermkort. Selve opprettelsen av virtuelle maskiner og nettverk foregår gjennom et grafisk brukergrensesnitt på Virtual Center 7 serveren. All lagring og backup av de virtuelle maskinene ligger på et SAN 8 som består av en rekke harddisker fordelt på forskjellige servere. All trafikk mellom de virtuelle maskinene og lagringsmiljøet (SAN) går gjennom switchen i IBM Bladecenteret. Side 13 av 68

14 4. Bakgrunn 4.1 O VER VÅ KNING SV ER KT Ø YE NE Så lenge det har eksistert store datamiljøer har det vært etterspørsel etter verktøy for å overvåke maskinpark og nettverksutstyr. Overvåkningsverktøy kan overvåke hardware, software, applikasjoner, transaksjoner og nettverk. Verktøyene kan være veldig avanserte og omfattende, derfor har de fleste store verktøyene fyldige manualer som er tilgjengelige på internett. Verktøyene kan settes opp til å foreta målinger på for eksempel ytelse og man kan selv sette terskelen for når man vil ha en melding om for høy bruk. Det kan måle responstid på nettsider eller hvor lang tid det tar å gjennomføre en transaksjon for eksempel i en nettbank. Man kan sette egne regler for hva som skal skje når forskjellige terskler nåes, det kan kjøres scripts, sendes varsler på e-post eller SMS eller det kan ganske enkelt vise hendelser i et konsoll 9. Verktøy som dette er utrolig viktige i større miljøer da man raskere, enklere og mer effektivt kan rette opp i feil som påvirker systemet i større eller mindre grad. Det meste kan også automatiseres ved hjelp av script hvis dette er ønskelig. Det er ikke alt som bør automatiseres, men trivielle feil som forekommer ofte er det greit å fikse ved hjelp av script. Dermed kan ansatte som før brukte hele sin arbeidsdag på feilsøking og retting bruke mer av tiden sin på andre viktige jobber og dermed øke omsetningen i bedriften. I tillegg til overvåking har de fleste av disse verktøyene også en discoveryfunksjon med en inventardatabase. Dette er nyttig hvis man utnytter funksjonene dette gir til det fulle. Med det menes at man setter discoveryen til å kjøre med gitte intervaller slik at man finner nye enheter som måtte ha kommet til siden sist og man finner ut om noe skulle være fjernet. Disse verktøyene tilbyr også endringshistorikk, det vil si hvilke endringer som er gjort på de forskjellige enhetene som er oppdaget siden sist gang man kjørte discovery IBM Tivoli IBM Tivoli er en portefølje med en rekke forskjellige verktøy. Av disse skal vi teste ut et verktøy for overvåkning og et verktøy for discovery og inventardatabase. Disse verktøyene er utviklet med tanke på veldig store bedrifter, som eksempler kan det nevnes IBM, Komplett, Universitetet i Oslo og Norsk Tipping. Overvåkningsverktøyet i IBM Tivoli er et agentbasert 10 overvåkningsverktøy. Det vil si at for å kunne overvåke en maskin er man nødt til å installere en agent som ligger som en bakgrunnstjeneste og sjekker systemet, det agenten finner sender den til en database som deretter viser informasjonen i et konsoll. Side 14 av 68

15 Figur 2: Situation Event Console i IBM Tivoli Når man installerer dette overvåkningsverktøyet finnes det en hel rekke med regler innebygget. Disse reglene vil gi advarsler av forskjellig grad i dette konsollet hvis advarslene skulle oppstå. Man trenger derfor ikke sette alle regler selv. Hvis det er ønskelig er det også mulig å forandre terskelen på de forskjellige innebygde reglene slik at det passer for miljøet som skal overvåkes. I tillegg til dette konsollet finnes det et webgrensesnitt, fra dette grensesnittet kan man gjøre alt det man kan gjøre i produktkonsollet. I tillegg til Situation Event Console kan man lage forskjellige GUI (Grafisk brukergrensesnitt) som man kan sette opp akkurat slik man selv ønsker. Under er et GUI vi har laget som overvåker Bladecenteret i Atea sitt demomiljø. Side 15 av 68

16 Figur 3: Egendefinert brukergrensesnitt i IBM Tivoli Discoveryverktøy blir brukt for å finne maskiner og enheter i eget nettverk. Discoveryverktøyet i IBM Tivoli porteføljen fungerer på den måten at man først definerer et område, det være seg subnett 11, IP-range eller lignende. Deretter sender verktøyet ping til alle IP-adresser i dette området, får den svar vil den prøve å logge seg inn på enheten for å finne ut mer om den. Alt som blir funnet under en discovery blir lagret i en inventardatabase med navn, IPadresse, hva slags operativsystem enheten har og evt. hva slags hardware enheten har. Side 16 av 68

17 Figur 4: TADDMs brukergrensesnitt HP Business Availability Center HP BAC står for Business Availability Center og er en portefølje av en rekke verktøy for bruk innen overvåkning, drift og administrering. I denne porteføljen skal vi ta for oss verktøy for monitoring og i tillegg verktøy for discovery og inventardatabase. Verktøyet som tar for seg monitorering heter SiteScope og verktøyet for discovery og inventardatabase heter ucmdb. SiteScope er et agentløst monitoreringsverktøy som brukes til å overvåke maskiner, servere, enheter og alt annet som måtte befinne seg i en bedrifts IT infrastruktur. Det at det er agentløst betyr at verktøyet samler inn den informasjonen den trenger fra målmaskiner 12 uten å måtte legge inn noe på disse. Skjermbildet under viser SiteScope sitt brukergrensesnitt med liste over aktive monitorer 13 på noen maskiner. Side 17 av 68

18 Figur 5: SiteScope brukergrensesnitt Side 18 av 68

19 ucmdb er en inventardatabase som ved hjelp av en discovery funksjon oppdager og samler inn informasjon over det som befinner seg i bedriftens IT infrastruktur. I tillegg til dette danner den seg et topologikart 14 over infrastrukturen og beskriver relasjoner og avhengigheter mellom maskiner og enheter. Skjermbildet under viser ucmdb og discovery funksjonen. Figur 6: ucmdb og discovery Microsoft Operations Manager Operations Manager er en del System Center porteføljen. Denne porteføljen består av programmer som kan overvåke, konfigurere, ta backup av, ta recovery av og administrere virtuelle maskiner. Disse produktene er designet for å kunne brukes i store miljøer med rundt 5000 maskiner som kan overvåkes med agenter og kan overvåkes med agentløs 15 overvåking. Operations Manager er det verktøyet som brukes til overvåking. Det Side 19 av 68

20 baserer seg på bruk av agenter på de maskinene som overvåkes. Det er mulig å overvåke uten agenter, men dette er ikke anbefalt. Agentene vil kjøre som en bakgrunnsprosess og vil motta instrukser fra Operations Manager om hva den skal overvåke og rapportere tilbake. Operations Manager har også en discovery funksjon. Denne lister de maskinene man kan overvåke. Disse maskinene må være medlem av domenet som Operations Manager ligger i. Dermed vil alle maskinene som blir listet opp også kunne finnes i Active Directory 16. Dette gjør at discoveryfunksjonen i Operations Manager ikke fungerer som i de andre verktøyene. Den har ikke mulighet for å finne andre enheter enn de den har i Active Directory eller har en SNMP 17 communitystring 18. Figur 7: Microsoft Operations Manager 2007 Side 20 av 68

21 4.2 INST ALL ASJON AV O PER AT IVS YST EM OG OVER V ÅKNINGS VERKT Ø Y Systemkrav for verktøyene Systemkravene for å kunne installere og kjøre de forskjellige verktøyene vi har testet ligger i vedlegg C.1. Det skal presiseres at alle disse maskinene er virtuelle Installasjon av operativsystem Før vi kunne installere verktøyene var vi nødt til å installere operativsystem på de virtuelle maskinene vi opprettet. Dette gjorde vi ved å laste ned en klone av en installasjons-cd i form av en.iso fil. Denne filen la vi deretter i den virtuelle maskinens virtuelle Cd-rom. Da vi startet den virtuelle maskinen startet installasjonen Microsoft Windows Server 2003 På de virtuelle maskinene vi skulle installere HP og IBM verktøyene på valgte vi å bruke Windows Server Dette fordi Windows Server 2008 er veldig nytt og av den grunn var vi ikke sikre på hvilke uforutsette problemer vi ville støte borti. Det er også veldig store plattformforskjeller fra Windows Server 2003 og 2008 som kunne skape problemer. Da installasjon av operativsystem var ferdig la vi inn Vmware Tools 19 på alle de virtuelle maskinene, dette gjorde vi fordi det øker den grafiske ytelsen og gir bedre støtte for delte mapper. (Se Vedlegg C.2 Installasjon av Microsoft Windows Server 2003) Microsoft Windows Server 2008 På den virtuelle maskinen vi skulle installere Microsoft verktøyet på valgte vi å installere Windows Server Dette fordi det var støttet i Microsoft verktøyet. Det var også dette vi fikk anbefalt fra Microsoft sin side. (Se Vedlegg C.3 Installasjon av Microsoft Windows Server 2008) Installasjon av overvåkningsverktøy Da operativsystem var installert var vi klare for å installere selve overvåkningsverktøyet. Med unntak av Microsoft fikk vi installasjonsfilene for overvåkningsverktøyene fra konsulentene fra IBM og HP. HP B A C Vi fikk installasjonsfilene fra konsulenten fra HP. Deretter flyttet vi disse filene over til den virtuelle maskinen vi skulle installere verktøyet på. Installasjonen startet vi ved å åpne en setup.exe fil og fulgte deretter instruksjonene på skjermen. I tillegg til å installere selve overvåkningsverktøyet måtte vi legge inn Microsoft Internet Information Services 20 og Java Runtime Environment 21. Vi måtte også på en av maskinene installere Microsoft SQL (Se Vedlegg C.5 Installasjon av HP verktøy) Side 21 av 68

22 IB M Tivoli Vi fikk installasjonsfilene fra konsulenten fra IBM. Deretter flyttet vi disse filene over til den virtuelle maskinen vi skulle installere verktøyet på. Før vi kunne installere overvåkningsverktøyet måtte vi for IBM produktene installere en databasemotor i bunn. Denne databasemoteren heter DB2 22 og er laget av IBM. Da DB2 var installert kunne vi installere overvåkningsverktøyet og discoveryverktøyet. (Se Vedlegg C.4 Installasjon av IBM verktøy) Microsoft Operations Manager Vi lastet ned en setup.exe fil fra Microsoft sine nettsider. Før vi kunne installere overvåkningsverktøyet måtte vi installere Microsoft SQL 2005 og Microsoft IIS. Da dette var gjort startet vi installasjonen fra setup.exe filen og fulgte instruksjonene på skjermen. (Se Vedlegg C.6 Installasjon av Microsoft verktøy) Side 22 av 68

23 4.3 FORBER ED EL SER T IL T EST ING Før vi kunne begynne å bruke verktøyene måtte vi gjøre noen forberedelser IBM Tivoli Siden IBM verktøyet bruker agenter for å overvåke enheter var vi nødt til å utplassere operativsystemagenter til de maskinene vi ville overvåke. Dette gjorde vi ved å skrive et par linjer i kommandovinduet på maskinen som kjørte IBM Tivoli Monitoring verktøyet. Med i kommandoen måtte vi ha med lokal administratorbruker og passord for maskinen vi ville installere agent på. Da operativsystemagenten var installert kunne vi installere andre agenter på den samme maskinen, men dette kunne vi gjøre gjennom konsollet til overvåkningsverktøyet. For å overvåke de fire fysiske vertsmaskinene for det virtuelle miljøet måtte vi kopiere et sertifikat fra Virtual Center serveren over til maskinen hvor overvåkningsverktøyet kjørte og deretter skrive inn en linje i kommandovinduet. Figur 8: kommando for å aktivere Virtual Center sertifikat i IBM ITM HP Business Availability Center SiteScope som er overvåkningsdelen av HP Business Availability Center krevde at man hadde lokal administrator tilgang til målmaskinen som skulle overvåkes, dette er fordi SiteScope er agentløst. For å kunne overvåke en maskin måtte man legge til brukerrettigheter til maskinen som skal overvåkes i SiteScope. I tillegg til dette måtte SiteScope tjenesten kjøres som administrator på den virtuelle SiteScope maskinen. Det var heller ikke anbefalt å ha en fysisk firewall mellom SiteScope maskinen og målmaskinen. For å få full tilgang til de fire fysiske serverne for det virtuelle miljøet måtte vi kopiere et sertifikat fra de fire serverne over til SiteScope maskinen. Side 23 av 68

24 4.3.3 Microsoft Operations Manager Microsoft Operation Manager bruker agenter for å overvåke enheter. Før man kan distribuere disse agentene må man kjøre en nettverksoppdagelse (discovery) for å finne maskiner i nettverket. Når man har funnet maskinene kan man velge å installere agent på disse gjennom konsollet til overvåkningsverktøyet. Til motsetning fra HP og IBM verktøyene har man i Microsoft verktøyet allerede lokal administratortilgang via Active Directory, man slipper derfor å legge til ekstra tilganger. Side 24 av 68

25 5. Overvåkning 5.1 T ING SOM SK AL T E S T ES I kravspesifikasjonen (vedlegg A) er det definert en rekke krav over hva som skal overvåkes, i henhold til dette har vi satt opp en liste over ting vi skal teste i de forskjellige verktøyene. Dette er hva vi skal teste: CPU o Forbruk o Nedetid o Temperatur Disk o Forbruk o Nedetid Minne o Forbruk o Nedetid PDU 23 o Kapasitet o Nedetid Miljø o Temperatur Switch o Kapasitet o Nedetid Database o Latency 24 o Nedetid Webserver o Latency o Nedetid o Trendanalyse 25 Side 25 av 68

26 5.2 T EST SKJEMA FOR OVER V ÅKNING For å kunne teste verktøyene på den mest strukturerte, praktiske og objektive måten velger vi å bruke testskjema. Vi bruker samme testskjema for å teste alle verktøyene. For å komme frem til det endelige testskjema har vi diskutert frem og tilbake om hvordan det skulle se ut for at vi skulle få best mulig oversikt for senere sammenlikning. Selve utformingen på skjemaet har kommet frem etter lange diskusjoner og mye drøfting. Vi har hatt mye diskusjon om hvorvidt vi skulle ha en karakterskala for de forskjellige testene. Vi hadde i starten planer om å ha en skala fra 1-10 hvor 1 var lett og 10 var vanskelig, men etter mer diskusjon fant vi ut at det ville bli vanskelig å rangere testene på denne måten. Vi kom til et kompromiss hvor vi fant ut at vi kunne bruke en skala fra 1-3 der 1 var lett, 2 var middels og 3 var vanskelig, men etter ytterligere diskusjon ble vi enige om at en slik karakterskala ville bli for subjektiv i lengden. Til slutt ble vi enige om å ikke bruke denne karakterskalaen. I og med at disse verktøyene er utviklet med tanke på at det er IT-utdannede personer som skal bruke de vil det ikke gjøre så mye om de er vanskelige å forstå med en gang så lenge de er effektive og får jobben gjort. For å få et endelig sammenlikningsgrunnlag ble vi enig om å oppsummere hvert testskjema med bestått, delvis bestått eller ikke bestått. Disse karakterene gis i henhold til kravene for hvert testskjema. Hvert testskjema har sine egne krav som beskrives i feltet for hva og hvordan det skal testes. Testene er ikke satt i en prioritert rekkefølge og hver test teller like mye. Se eksempel lengre ned. Bestått: Dette betyr at testen ble godkjent og fullført i henhold til testskjemaets krav. Delvis bestått: Testen er mulig å bestå, men under vår testing var ikke resultatet godt nok får å få graden bestått. Ikke bestått: Dette betyr at testen ikke ble bestått i henhold til testens krav. Side 26 av 68

27 Nedenfor er testskjema malen vi satt opp og en forklaring på de forskjellige feltene i skjemaet. Vi mener at det endelige testskjemaet tydelig viser hvordan testene har blitt satt opp, utført og hvilke resultater testen ga. Dette testskjemaet er godkjent av oppdragsgiver. 1.1 Tittel Test på Utføres av: Hvor skal det utføres: Hva skal testes? Hvordan skal det testes? Fremgangsmåte Hva skjedde under testen? Ble testen bestått? Tidsbruk Kommentar Tittel: Tittelen på testskjema, tallkoden i tittelen sier noe om hvilket verktøy og hva slags tester som er utført. Det første tallet henviser til verktøy der 1 er IBM, 2 er HP og 3 er Microsoft. Det siste tallet henviser til hva som er testet. Test på: Beskriver enhet/maskin/applikasjon etc. som det skal testes på. Feltet skal inneholde klar informasjon om hva og hvor testen skal utføres. Utføres av: Person i prosjektgruppen som har hovedansvaret for dette testskjemaet. Hvor skal det testes? Navn på overvåkningsverktøy Hva skal testes? Her skal det beskrives hvilke punkter som skal testes. Eksempler på dette kan være CPU forbruk, temperatur eller CPU nedetid. Hvordan skal det testes? Hvordan skal vi teste de enkelte reglene. Inneholder en kort forklaring på hva testen og regelen går ut på. Dette er også kravet til testen og det vi gir karakter utifra. F remgangsmåte Beskrivelse av oppsettet til testen. Dette feltet forklarer stegene man må igjennom for å sette opp testen. Hva skjedde under testen? Hendelsesforløp hele veien fra testen startet til den ble fullført/avbrutt. Side 27 av 68

28 Ble testen bestått? Ble testen bestått i henhold til testens formål og kriterier? Tidsbruk Hvor lang tid det tok å sette opp og utføre testen. Inkludert konsultering av dokumentasjon og feilhåndteringer. Kommentar Dette feltet brukes til å forklare problemer som dukker opp under testingen, feil, avvik, spesielle merknader og andre ting som måtte være av interesse. På neste side er det et eksempel på et ferdig utfylt testskjema. Side 28 av 68

29 1.1.1 Test av fysisk CPU forbruk Hva skal testes? Hvordan skal det testes? Fremgangsm åte Hva skjedde under testen? Ble testen bestått? Tidsbruk Kommentar Test på <hardware: cpu> Forbruk Utføres av: Carl Forbruk på over 90 % i 30min skal gi advarsel. Hvor skal det utføres: Ibmbc01.demobryn.local 1. Bla frem til VMware VI agenten på VC01 i Physical View 2. Høyreklikk på VMware VI agent og velg Situations 3. Trykk på ikonet for ny Situation 4. Skriv inn navnet på Situation (CPU_forbruk_high) 5. Velg attributt fra lista (KVM Clustered Servers) og attributt (Server CPU utilization) 6. I Forumla vinduet: trykk på første linje i tabellen, velg >= og skriv inn 90, trykk Enter 7. Velg ønsket state (Critical i dette tilfellet) 8. På Distribution taben; velg *VMWARE_VI_AGENT fra Available Managed Systems Lists 9. (På Expert Advice tab kan du skrive inn dine egne råd for hva man burde gjøre hvis man får denne advarselen, dette steget er opsjonelt) 10. (Take Action tab: her kan du stille på hva som skal skje når situasjonen oppstår, hvis du ikke setter noe vil du bare få en advarsel i Physical viewet i ITM. Dette steget er også opsjonelt med mindre du har veldig klare ønsker om hva som skal skje når situasjonen slår til) 11. På Until taben: velg Interval Expires og skriv inn 30min 12. Når alt er gjort, trykke Ok og situasjonen er laget, hvis situasjonen slår til vil det komme en advarsel i Physical viewet i ITM. Etter jeg trykket Ok ble situasjonen aktiv og lå og venta på at den skulle bli true. Det er allerede en situasjon innebygd i ITM for dette, som gir advarsel når CPU bruken er 90 % eller over. Jeg satt terskelen til 30 %. Jeg satt også Interval Expires til 30sekunder slik at situasjonen skulle gi feilmelding i konsollet. Det kom da en advarsel i konsollet med en gang. Bestått 2 timer For å kunne overvåke fysisk CPU må man ha en OS agent på maskinen man skal teste på. Det går an å kjøre agentløs overvåkning også, men da får man ikke like mye informasjon om systemet. Å sette opp regler i ITM er ikke særlig intuitivt, men hvis du har gjort det en gang så har du skjønt det og kan sette opp de neste lettere. Det er mange forskjellige attributter man kan velge og det gjelder å holde tunga rett i munnen for å finne den riktige for den enkelte regelen. I ITM ligger det mange ferdiglagde situasjoner som gir advarsel og critical advarsler om alt mulig om CPU, minne, disk og alt mulig annet. Jeg har derfor under testing opprettet mine egne situasjoner som i praksis gjør akkurat det samme som de ferdiglagde. Side 29 av 68

30 5.3 T EST RESULT AT AV O VER VÅ KNING Under følger en matrise hvor resultatene av de forskjellige testene i de forskjellige verktøyene blir vist. I tillegg til denne matrisen vil vi presentere resultatene i ulike diagrammer for hvert verktøy. For å sammenligne de tre diagrammene vil vi sette opp et stolpediagram og kommentere forskjeller i fordelingen av beståtte, delvis beståtte og ikke beståtte tester. Hvis det er ønskelig å se kommentar på testene som har fått bestått henviser vi til vedlegg D.1 Testbok Testmatrise Test IB M HP M icrosoft 1. Fysisk CPU 1.1 Forbruk Bestått Ikke bestått Bestått 1.2 Nedetid Ikke bestått Ikke bestått Bestått 1.3 Temperatur Ikke bestått Ikke bestått Ikke bestått 2. Fysisk Disk 2.1 Forbruk Bestått Bestått Bestått 2.2 Ikke bestått Ikke bestått Delvis bestått Oppetid/nedetid 3. Fysisk M inne 3.1 Forbruk Bestått Bestått Bestått 3.2 Nedetid Ikke bestått Ikke bestått Delvis bestått 4. PDU 4.1 Forbruk Bestått Ikke bestått Ikke bestått 4.2 Nedetid Delvis bestått Ikke bestått Ikke bestått 5. Temperatur 5.1 Miljøtemperatur Delvis bestått Delvis bestått Ikke bestått 6. Switch 6.1 Forbruk Delvis bestått Bestått Ikke bestått 6.2 Delvis bestått Delvis bestått Delvis bestått Oppetid/nedetid 7. Database 7.1 Bestått Bestått Bestått Oppetid/nedetid 7.2 Latency Bestått Bestått Ikke bestått 8. Webserver 8.1 Ikke bestått Bestått Bestått Oppetid/nedetid 8.2 Latency Ikke bestått Bestått Ikke bestått 8.3 Trendanalyse på punkt 8.1 Ikke bestått Ikke bestått Ikke bestått Side 30 av 68

31 5.3.2 Statistikk og kommentarer Figur 9: IBM Bestått: 6, Delvis bestått: 4, Ikke bestått: 7 I dette diagrammet ser vi at IBM verktøyet har flere ikke beståtte tester. Hverfall 3 av disse ville blitt bestått hvis vi hadde hatt korrekt plugin til overvåkningsverktøyet. Dette gjelder spesielt webservertestene. Figur 10: HP Bestått: 7, Delvis bestått: 2, Ikke bestått: 8 HP har hele 8 ikke beståtte tester og dette er fordi de blant annet fikk ikke bestått på samtlige CPU tester. I tillegg fikk HP ikke bestått på PDU testene også. Begge de 2 delvise beståtte testene gjaldt SNMP spørringer. Side 31 av 68

32 Figur 11: Microsoft Bestått: 6, Delvis bestått: 3, Ikke bestått: 8 Microsoft sine ikke beståtte tester gikk på SNMP målinger og webservertester. Alle de 3 delvise testene testene gikk på nedetidstester. Figur 12: Sammenlikning av overvåkningsverktøy Her er et stolpediagram som viser fordeling av bestått, delvis bestått og ikke bestått for de tre overvåkningsproduktene. Utifra dette diagrammet ser vi at alle produktene kommer veldig jevnt ut, men det er alikvel forskjeller. Når det gjelder IBM ser vi at de kommer best ut med tanke på antall bestått og delvis bestått. De har også lavest antall ikke beståtte tester. Side 32 av 68

33 Microsoft sine resultater ligger ved første øyekast tett opp imot IBM og HP, men det må påpekes er at Microsoft er et produkt som ikke er plattformuavhengig 26. Se kap for utdypning av dette Kommentarer til testene Under har vi kommentert testene på CPU som ble delvis- eller ikke bestått i de forskjellige verktøyene. De andre kommentarene til tester som bare ble delvis- eller ikke bestått finnes i vedlegg D.2 Tester som ble delvis- eller ikke bestått. CPU-tester på IB M Tivoli CPU nedetid (test 1.2) IBM Tivoli har fått ikke bestått på denne testen på det grunnlag at verktøyet ikke vet at det er CPU som går ned. Hvis en maskin skrus av eller av en annen grunn går ned vil den bli listet som Offline. Formålet med nedetidstesten var at verktøyet skulle sende en mail hvis maskinen som blir overvåket gikk ned grunnet feil på CPU. I og med at IBM verktøyet ikke har en innebygget varslingsfunksjon og siden det ikke vet om maskinen går ned pga CPU feil eller om den blir skrudd av manuelt får den ikke bestått på denne testen. CPU temperatur (test 1.3) Grunnen til at IBM-verktøyet ikke får bestått eller delvis bestått på denne testen er at det ikke finnes en innebygget funksjon i operativsystemet som kan vise temperaturverdier. Dermed har overvåkningsverktøyet ingen steder å hente/lese/overvåke temperaturverdien fra. CPU-tester på HP B A C CPU forbruk (test 1.1) Denne testen ble ikke bestått av den grunn at det ikke var mulig å få til en trendanalyse over CPU forbruk. Testen gikk ut på å at man skulle bli varslet om det var unormalt høy CPU forbruk over en lengre tid og i dette tilfellet var dette på 30minutter. Utifra dokumentasjon og en del prøving måtte vi konkludere med at det ikke gikk ann å få gjennomført denne testen. Å måle generell CPU forbruk var ikke noe problem i seg selv, men siden vi valgte å teste CPU på en av de fysiske vertsmaskinene i bladecenteret så måtte vi bruke SiteScopes monitor for Vmware 27 og da fikk vi ikke ut et resultat i form av prosent, men i antall MHz. CPU nedetid (test 1.2) Testen vil melde ifra om den ikke får kontakt med maskinen, men det er ingenting som tilsier om det er maskinen som er skrudd av eller om det er CPUen som har gått ned på grunn av feil. Derfor blir ikke denne testen bestått. Side 33 av 68

34 CPU temperatur (test 1.3) Det var ingen monitor i SiteScope for å sjekke temperatur for en CPU. Vi prøvde å finne ut om kanskje Windows selv rapporterte temperatur i sine egne logger og overvåkningsverktøy, men det var ikke tilfelle. Det samme gjaldt også Unix-baserte operativsystem. Denne testen ble derfor ikke godkjent. Alternativet ville kanskje vært å finne tredjeparts programmer som overvåker maskintemperaturer og deretter overvåket de via SiteScope, men det ville vært tidkrevende. Den korrekte metoden er at SiteScope selv hadde hatt mulighet til det. CPU-tester på M icrosoft Operation M anager CPU temperatur (test 1.3) Det var ikke mulig å sette opp en måling for temperatur. Av samme grunn som for IBM og HP. Side 34 av 68

35 6. Discovery og inventardatabase 6.1 T EST AV INVENT ARDAT A BA SE OG DISCOVER Y Testing av discovery funksjonen vil bli gjennomført likt for de enkelte overvåkningsløsningene. Dette innebærer at vi gir discovery verktøyene like tilganger og at de søker på samme nett. Tilganger er brukernavn, passord og koder man trenger for å få tilgang til maskiner og enheter. Selve discoveryverktøyet bruker forskjellige protokoller når den prøver å koble seg til oppdagede maskiner og enheter på nettet. Av tilganger har vi lagt til følgende protokoller WMI (For å logge seg på Windows systemer) SNMP (For å logge seg på feks nettverksenheter) SSH (For å koble seg til feks Unix systemer) SQL (For å koble seg til Microsoft SQL databaser) DB2 (For å koble seg til IBM DB2 databaser) Telnet (For å koble seg til feks nettverkenheter) Det vil være veldig tidkrevende å få samlet sammen tilganger til absolutt alt som befinner seg på nettet, derfor vi har holdt oss til standardtilgangene. Det skal også bare utforskes på nettet til demomiljøet slik at ikke vi oppdager ting som ikke tilhører demomiljøet. Det vi ønsker å se er hvor mye som blir oppdaget i nettet og hvor mye informasjon som blir hentet ut om de enkelte enhetene. I tillegg vil vi legge vekt på hva kravspesifikasjonen til prosjektet krever av den endelige inventardatabasen. Det er ikke sikkert at discovery funksjonen til de enkelte verktøyene vil finne alt det som ønskes å ha i inventardatabasen, derfor vil det være ønskelig å kunne legge inn eventuelle ekstra enheter på manuelt vis. Av kravspesifikasjonen skal det være endringshåndtering i inventardatabasen og det vil derfor være interessant å finne ut hva slags funksjonalitet som tilbys av overvåkningsverktøyene i forhold til dette. Endringshåndtering innebærer at man skal få oversikt over forandringer i inventardatabasen. Hvis det for eksempel legges til nye maskiner i nettverket skal dette oppdages av verktøyet og lagres i databasen automatisk. Dette gjelder også hvis enheter blir fjernet fra nettverket. For å kunne sammenlikne discoveryfunksjonene til de forskjellige verktøyene planlegger vi å lage en tabell med hvor mange maskiner, programvare, tjenester og enheter av forskjellige typer overvåkningsverktøyene finner. Side 35 av 68

36 6.2 T EST RESULT AT AV I NVE NT ARDAT AB AS E OG DISC O V ER Y For å få best mulig sammenlikningsgrunnlag av discoveryverktøyene har vi valgt å kjøre discoveryen out-of-the-box, det vil si at vi ikke vil gjøre noen andre konfigurasjoner enn å sette tilganger til enheter vi vil finne. Det finnes på dette tidspunkt ingen fullstendig liste over hva som finnes i demomiljøet, derfor vi har ingen mulighet til å sjekke de enhetene verktøyene finner mot en fasit. Dokumentasjon av discovery testingen ligger som vedlegg E. Her vil det står hvordan vi satte opp og konfigurerte discoveryverktøyene IBM discovery og inventardabase Under ser vi et bilde av et fullført discovery i IBM hvor det grønne feltet viser status på tilkoblingen mot det den har oppdaget og undersøkt. Hvis det er tilkoblingsfeil vil man få gule og røde felter i stedet avhengig av feilens grad. I tillegg til fargekode får man en unik feilkode som man kan bruke for å identifisere og løse tilkoblingsfeilen ved hjelp av dokumentasjonen. De tilkoblingsfeilene som gjentok seg oftest var manglende angitte tilganger i form av brukernavn og passord, men også passord for å koble seg til nettverksenheter. Andre typer feil som utmerket seg var såkalte timeout feil som gjorde at forbindelsen mellom IBM og den enheten den prøver å utforske brytes etter en viss tid. Tilsammen var det totalt rundt 500 feilmeldinger. Figur 13: IBM Taddm godkjente tilkoblinger Side 36 av 68

37 Skjermbildet under viser det som er oppdaget av IBM. Alt som blir funnet blir kategorisert under logiske navn. Det som ikke blir identifisert havner i en egen gruppe for ukjente enheter. Figur 14: Oppdagete enheter i IBM Taddm Stolpediagrammet under viser et lite utdrag av det som er funnet i IBM discovery. Figur 15:oppdagede enheter etter IBM discovery Side 37 av 68

38 6.2.2 HP discovery og inventardatabase Skjermbildet under viser statistikk over det som er funnet av HP i sin discovery. Tabellen til høyre viser antall enheter og maskiner som er funnet, mens listen til venstre viser det som HP leter etter. Øverst til venstre så får man statistikk over antall tilkoblingsfeil og hvilke tilkoblinger som ble fullført. I kolonnen for det som HP leter etter så ser man de modulene som er aktivert markert med grønt ikon. Der hvor det er tilkoblingsfeil så vil man få et lite rødt utropstegn. For å få en nærmere forklaring på feilen så må man klikke seg videre inn på feilmeldingene i kolonnen øverst til høyre. Tabellen over det som er funnet i discovery legger det som er funnet inn i forskjellige logiske kategorier og man kan dobbeltklikke seg videre inn for å få mer utdypende informasjon. Figur 16: Resultat discovery HP Side 38 av 68

39 Skjermbildet under viser et lite utdrag av det som er funnet i HP discovery. Figur 17: Oppdagede enheter etter HP discovery Side 39 av 68

40 6.2.3 Microsoft discovery og inventardatabase Skjermbildet under viser hva discovery funksjonen i Microsoft fant. Siden Microsoft bare finner maskiner og enheter som befinner seg i sitt eget active directory ble det ikke noen stor liste. I tillegg var det ikke mange medlemmer av dette active directoriet og derfor fant ikke Microsoft flere enn de 3 maskinene som er listet opp i skjermbildet. Figur 18: Microsoft discovery resultat Side 40 av 68

41 6.2.4 Statistikk og kommentarer Etter å ha kjørt discovery med de forskjellige verktøyene så vi at resultatene av Microsoft discovery ikke var som forventet. Microsoft verktøyet finner kun enheter som ligger i dets eget Active Directory hierarki. Derfor har vi ikke kunnet sammenlikne discoverydelen av Microsoft verktøyet mot discovery med IBM og HP. Figur 19: Oppdagede enheter i IBM og HP Oppdagede enheter IBM HP Switch Router 5 7 DB2 (databasemotor) 2 2 Microsoft SQL 12 5 Microsoft IIS Unix Windows VLAN Rack PDU VMware ESX servere 4 0 DNS På grunn av forskjellig presentasjon av oppdagede enheter i de to verktøyene har vi valgt å kun vise det som er mest interessant å finne ved hjelp av discovery. Disse utvalgte enhetene dekker også hovedpunktene i kravspesifikasjonen. Som det kommer frem i stolpediagrammet og tabellen ser vi at HP verktøyet har funnet langt færre Windowsmaskiner, SQL servere, VLAN og ESX 28 servere enn IBM verktøyet, dette er på grunn av tilkoblingsfeil og manglende drivere. Side 41 av 68

42 7. Evaluering og valg av verktøy 7.1 EV ALU ERING AV O V ERVÅKNING IBM overvåkning IBM bruker primært agenter for å overvåke maskiner og servere, det være seg virtuelle eller fysiske. Det finnes også et utall andre agenter for å overvåke forskjellige applikasjoner og tjenester. For å overvåke en maskin er det viktig at man først starter med operativsystem agenten, denne må utplasseres ved hjelp av kommandolinjen hvor man først logger seg på som en ITM 29 bruker og deretter angir IP-adresse og administratorbrukernavn og passord til serveren man vil utplassere agenten på. Når operativsystemagenten er installert på maskinen vil man i ITM konsollet se den aktuelle maskinen man har installert agent på og hvilke agenter som er installert på maskinen. Når operativsystemagenten først er installert vil man kunne utplassere andre typer agenter på denne maskinen via konsollet, det være seg en VMware VI agent, Microsoft SQL agent med mer. IBM støtter de aller fleste operativsystem, blant annet; Windows og unixbaserte operativsystemer. Når agenter er installert på en maskin vil man, så snart noe trigger sitasjonene som er innebygget i ITM, få en melding om dette i Situation Event Console 30 vinduet. Det er veldig mange innebygde situasjoner og regler innebygget i ITM fra før, noe som gjør at det er enkelt å komme i gang med overvåkningen av demomiljøet. Situasjonene som oppstår blir delt inn i 7 forskjellige alvorlighetsgrader med forskjellige fargekoder: Unknown (grå), Informational (lys blå), Healthy (grønn), Warning (gul), Minor (oransje), Critical (rød) og Fatal (svart). Man kan også, skulle det være ønskelig, sette sine egne regler og situasjoner som også vil gi melding i Situation Event Console. En annen funksjon i overvåkningsverktøyet er muligheten for å sette opp egne grafiske brukergrensesnitt med målinger. Det er nesten ikke begrensninger på ulike måter du kan presentere data på, det er tabeller, søylediagram, kakediagram, grafer, områdekart, speedometer, lineært speedometer, du kan sette opp eget Situation Event Console (det er et innebygget et fra før), grafisk fremstilling, topologikart og web-browser med mer. Det er også relativt enkelt å sette opp ditt eget grafisk brukergrensesnitt, har du først satt opp et grensesnitt er det enkelt å sette opp nye. I tillegg til disse funksjonene som ITM gir finnes det forskjellige plug-ins til verktøyet som gir flere funksjonaliteter. Under testing benyttet vi oss kun av Internet Service Monitoring 31 som gjorde at vi kunne sjekke DHCP 32, HTTP 33, DNS 34 og andre tjenester. Det mest trøblete med ITM er overvåking av nettverksenheter ved hjelp av SNMP, det finnes to måter dette kan gjøres på. Enten ved å få enhetene til å sende SNMP traps som deretter mottas av ITM eller ved å bruke en Universal Agent 35 som sjekker SNMP oppslagsfiler og henter informasjon utifra disse. Side 42 av 68

43 7.1.2 HP overvåkning Etter en del testing av HP sitt overvåkningsverktøy sitter vi igjen med det inntrykket av at det er et meget bra produkt, men dog altfor stort og omfattende for Ateas demomiljø. Overvåkningsverktøyet til HP hadde et godt oversiktelig brukergrensesnitt og god dokumentasjon så det var ikke noe problem å starte testingen med å sette opp enkle målinger. Siden HP overvåkningsverktøyet er agentløst måtte vi legge til de maskinene som skal overvåkes inn i en liste over maskiner med godkjente tilganger. Når man skal feks overvåke en maskin med en SQL database må man først ha administratortilgang til den maskinen for å få lov til å overvåke databasen. Å legge til disse maskinene var ikke noe problem siden vi på forhånd hadde administratorpassord. Man vil også få en bekreftelse på om tilkoblingen mellom overvåkningsverktøyet og målmaskinen er korrekt. Dette er veldig praktisk om en monitor skulle feile og man slipper derfor å måtte tenke på om det er tilkoblingsfeil eller ikke. HP kommer med en lang rekke innebygde monitorer som tar for seg forskjellige målinger. Disse målingene varierer fra enkle pingverktøy til feks mere avanserte databasemonitorer. For å sette opp en ny monitor så må man igjen om disse tre stegene: 1. Finn hva som skal overvåkes. Hvilken maskin skal du overvåke og har du tilgang til denne maskinen? 2. Hva skal måles? Her må du velge hva som skal måles på denne maskinen. 3. Hva skal rapporteres? Hva skal det rapporteres utifra de tersklene du har satt for målingen? De 3 tersklene er Error If, Warning If og Good IF. I vår testing av HP har det ikke vært noe problem med punkt 1 i denne listen som omhandler tilkobling mellom SiteScope og målmaskinen. Dette fordi laben ikke har brannmurer og andre enheter som vil hindre tilkoblingen. I andre miljøer kan dette bli et kjedelig problem siden man må ta hensyn til at SiteScope sine monitorer bruker forskjellige spesielle porter i sin overvåkning. Man må også ta hensyn til hvilken protokoll monitoren bruker for å koble seg til målmaskinen. Når tilkobling mellom SiteScope og målmaskin er i orden kan man endelig ta for seg hva man ønsker å måle og hva som skal rapporteres. Hvis man på forhånd vet nøyaktig hva som skal måles og hvor man skal finne det er det veldig behjelpelig. De forskjellige monitorene kan hente ut veldig mye forskjellig informasjon og det er opp til brukeren av SiteScope og luke ut det som er relevant og interessant. Under vår testing ble det brukt mye tid på å lete seg igjennom informasjonen som kommer ut av monitoren og dette var tidkrevende arbeid. Enkle monitorer for feks hardware som CPU er enkle og forstå, men når det gjaldt monitorer for databaser og nettverksutstyr så ble det fort uoversiktelig. Å sette rapportering for monitorene var greit nok og man hadde 3 terskler som beskrev rød, gul og grønn tilstand. Hver av disse tersklene kunne settes til ønskede verdier og tilstander for målingene. I tillegg til dette kunne man også beregne en baseline for en allerede eksisterende monitor for å regne ut typiske nivåer som man deretter kunne tilpasse Side 43 av 68