Oppetid

Tema: Spar penge på dit IT budget

2012-01-17T08:52:00.004+01:00

I denne blog finder du inspiration til emner, løsninger og metoder som kan spare dig for penge, tid og ressourcer og således få et IT budget til at strække længere

#1 AD Management

Hvordan administrerer du dit AD og hvordan kontrollerer du ændringer i AD?
Kan du spore hvem der har lavet hvilke ændringer og hvornår?
Bruger servicedesken for meget tid på trivielle henvendelser fra brugerne om ændring / oplysning af adgangskoder og brungerkonti?
Bruger IT afdelingen for meget tid på at vedligeholde generelle oplysninger om brugerne i AD?
Bruger du eksterne konsulenter til at lave rapporter til IT revisionen?
Hvordan rydder du op i AD hvad angår brugere og computere som er inaktive eller som ikke har logge på i længere tid?

Hvis du "bare" bruger de indbyggede MS værktøjer til at klare disse opgaver så er der stor sandsynlighed for at du kan spare både tid, penge og ressourcer ved at løse en eller flere af ovenstående opgave med nogle af løsningerne i vores AD management suite fra ManageEngine.

Hvad får du ud af at bruge AD management suiten?

Bedre samarbejde: Er I flere om at administrere AD så sikrer rollefordelingen at I kan arbejde optimalt sammen og bruge mindre tid på administration og rapportering.
Mindre pres på servicedesken: Lad brugerne selv nulstille adgangskoder og opdatere kontkatinformation så der kommer færre trivielle henvendelser om dette i servicedesken.
Mindre / ingen ekstern konsulentassistance: Alle rapporter ligger færdige i systemet uanset om det er interne rapporter eller rapporter til revisionen (compliance).
Prisvenlig software på subscription: Vores løsninger er prisvenlige subscription licenser så der er stor sandsynlighed for at du kommer til at betale mindre end du gør du din nuværende løsning. Og fordi det er subscriptions bliver softwaren til en driftsomkostning i stedet for en investering som skal afskrives.

Hvilke løsninger finder du AD management suiten?

ADManager Plus Professional: En nem og brugervenlig løsning til Windows AD administration og rapportering, som hjælper AD administratorer og teknikere i deres daglige arbejde. Med et centrali-seret og intuitivt webgrænsesnit håndterer ADManager Plus Professional en række komplekse opgaver som fx. masseændringer af brugerkonti og andre AD objekter, delegering af rollebaseret adgang til helpdesk teknikere og udarbejdelse af rapporter til brug for intern afrappor-tering og revision / compliance.

>>Med ADManager Plus Professional kan du foretage ændringer i AD, enten på enkelte AD objekter eller i bulk. Du kan desuden nemt rapportere på status af disse objekter, så du kan få ryddet op i brugere og computere som er inaktive eller brugerkonti med ”never expire” adgangskoder o.lign. [Se YouTube video]

ADSelfService Plus Professional: En sikker webbaseret løsning, som muliggør, at brugerne selv kan åbne deres låste brugerkonti, nulstille / forny deres adgangskoder og opdatere deres kontaktinformationer (kaldet ”Egenopdatering”). Administratorerne kan selv bestemme sikkerhedsniveauet og rammerne for nulstilling af adgangskoder og den samlede løsning aflaster helpdesken for trivielle opkald fra brugere, som har glemt eller skal have nulstillet deres adgangskode.

>> Med ADSelfService Plus Professional kan du sikre nem selvbetjening af brugernes adgangskoder, åbne låste brugerkonti og lade brugerne opdatere deres egne kontaktin-formationer, så du letter presset på servicedesken. [Se YouTube video]

ADAudit Plus Standard: En løsning, der opdager stort set alle ændringer på AD og kan rapportere og alarmere på disse ændringer. Funktionerne imødekommer de fleste revisionskrav / compliancekrav og giver samtidigt AD administratorer et værktøj til at højne sikkerheden og sporbarheden omkring ændringer i AD. Kort sagt så ved du altid hvem, der opdaterede AD med hvilke ændringer, hvor og hvornår.

>> Med ADAudit Plus Standard kan du auditere ændringer i AD så du nemt får compliance rapporter (fx logon/logoff) og auditere tilgang til andre servere og fileshares. Så bliver revisionen tilfredse. [Se YouTube video]

Har du brug for en ServiceDesk?

2011-05-29T08:45:00.002+02:00

I min tid som IT-supporter brugte vi ofte sætningen ”når du har gjort 1 ting dårligt, skal du gøre 10 ting rigtigt godt, før det dårlige er glemt”. Der er formentligt et gram af sandhed i. Dårlige oplevelser har en tendens til at hænge fast i hukommelsen og gode oplevelser bliver glemt hurtigt.

Det er IT-supportens lod at skulle arbejde op ad bakke hele tiden. Meget ofte hører man utilfredshed på gangene og det er de færreste IT-chefer der rent faktisk har mod på at lave en tilfredshedsundersøgelse. Har jeg ret?

Har du også oplevet at der bliver sat spørgsmålstegn ved it-supportens effektivitet og dygtighed?

For mig at se er tiden kommet til at tage næste trin ad servicedesk-stigen hvis I f.eks. kan nikke genkendende til en eller flere af disse ting:

I er mere end 3 personer i afdelingen som laver support
Der er mere end 50 personer eller 100 arbejdsstationer/servere/printere m.v.
I afkræves dokumentation for løste opgaver og forbrugt tid
I ønsker at brugerne kan søge efter eksisterende løsninger på deres problem
I ønsker at brugerne selv kan oprette sager

Der kan være rigtigt mange andre mulige indgangsvinkler til dette. Det kan f.eks. være at I allerede har investeret i en servicedesk, men løsningen opleves som alt for dyr. Det kan også være at I mangler funktioner.

Servicedesk-programmer kan give jer en dokumentation for hvordan I løser sagerne. Er det godt eller er det skidt? Hvis det er skidt, hvornår begyndte det så? Hvordan kan vi gøre det bedre?

Løsningen er brug af Service Level Agreements (SLA), hvilket kan betegnes som en rammeaftale for levering af en vare. I det her tilfælde er der tale om support-sager, så det er oplagt at aftale et tidsforløb for hvornår behandlingsprocessen skal begynde og hvornår sagen kan lukkes fordi den er løst. Med brugen af SLA opstår muligheden for at kunne sende sagen videre til en kollega eller chef, hvis SLA ikke overholdes.

Når antallet af IT-supportere øges kommer kravet om om at viden skal fra hovedet til databasen med kendte løsninger. Samtidig opstår behovet fra brugernes side for at kunne se forløbet i egne sager og kunne give sit besyv med hvis problemstillingen ændres eller løses.

Kort sagt; Servicedesk handler om gennemsigtighed, historik, effektivitet og.... penge!

Når IT-afdelingen løser opståede problemer hurtigt og effektivt, kommer brugeren hurtigst muligt videre uden at spilde unødvendig tid. Det sparer penge.
Når brugeren er forbundet med en eller flere arbejdsstationer og andet udstyr som automatisk findes i servicedesk-programmet, så kan supporten hurtigere behandle problemet. Det sparer penge.
Når IT-afdelingen skal have implementeret et nyt virtuelt miljø, dokumenteres planlægningen, udrulningsplanen og ikke mindst backout planen i servicedesk-programmet. Det sparer i den grad penge!

Jeg vil opfordre dig til at bruge 5 minutter på at se på en servicedesk som kan opfylde jeres krav uden at tømme jeres pengepung. Se mere om emnet på vores ServiceDesk side

- Steffen Kjeldsen, Draware A/S

Sådan bruger du logs aktivt

2011-05-29T08:29:00.002+02:00

Spørger du dig selv hvordan I bruger logs i din IT-drift, så er det overvejende sandsynligt at det sker efter "strudsemetoden"... Med strudsemetoden forbinder jeg følgende: (Se også vores Youtube videoer om LogManagement)

Du ser ikke aktivt i dine hver dag
Når der opstår et problem forsøger du at finde nålen i høstakken ved at gå til den node som du tror har problemet og gennemsøge loggen for ofte at finde ingenting eller se at loggen er overskrevet og data er tabt (næsten alle logs er cykliske og overskriver sig selv når de er fulde.)
Logs er for nørder med god tid, så derfor ser du ikke i dem

Men logs er fingeraftrykket på hvad der sker med bl.a. dine noder, applikationer, brugere, sikkerhed så de inderholder meget værdifuld information som kan hjælpe dig til at klare følgende fire opgaver nemmere og hurtigere:

Hardware og software fejl. Fx problemer med diske, ram, varme, fugt og crashede applikationer eller uønsket software.
Hvad har en bestemt bruger gjort på et bestemt tidspunkt. Hvilke noder, applikationer og hjemmesider har en bruger arbejdet med på et givet tidspunkt. Hvilke filer er kopierede eller slettede og hvornår / hvor længe har en bruger været logget ind på forskellige systemer.
Sikkerhedsbrister. Er der nogen som har brugt virksomhedens ressourcer på en uretmæssig måde, forsøgt at få adgang til fortrolig information eller foretaget destruktive handlinger. Er der nogen som udefra (eller måske vigtigere indefra) har tilegnet sig rettigheder som administrator og derved har uretmæssig adgang til dine systemer / noder.
Compliance. Kan du bevise overfor revisionen at du indsamler, vurderer og arkiverer logs så sporbarheden i din IT-drift er sikret.

For at få det fulde udbytte af dine logs er det derfor nødvendigt med følgende simple actions:

Arkivering: Opsæt et centralt og gerne intelligent log-indsamlingspunkt (se fx Correlog) (Se YouTube video om Correlog) som står for den samlede arkivering af alle dine logs og traps.
Konfigurering: Konfigurer dine netværksenheder (switches, routere, firewalls, access punkter, prober, SAN m.fl.) til at sende syslogs til (IP-adressen på) din centrale log-server.
Agenter: Installer en agent på alle dine servere og workstations som omdanne Windows eventlogs og applikationslogs til syslogs som sendes til den centrale log-server.
Datamængder: Sørg for at der er styr på arkiveringen af logs og dan dig et overblik over mængden af logs (både antallet fra minut og mængden i Gb af dine logs over fx en måned). Det er vigtigt at din log-server kan håndtere mængden af logs på en hensigtsmæssig måde.
Korrelering: Opsæt filtre som både proaktivt og reaktivt (via rapporter) kan fortælle dig hvad du skal være opmærksom på dine logs fortæller dig.
Alarmering: Opsæt e-mail alarmer som fortæller dig / din servicedesk når log-serveren finder en alvorlig fejl (fx et hardware crash eller en sikkerhedsbrist)

Du er nu i stand til følgende på baggrund af dine logs:

Søge i alle dine logs fra ét sted på tværs af noder, brugere og applikationer (lidt som i Google). Det gør arbejdet med logs fantastisk meget nemmere, hurtigere og mere effektivt.
Proaktivt alarmere på fejl og sikkerhedsbrister så de får mindst mulig indvirkning på IT-driften. Derved sikrer du en højere oppetid for dine IT systemer.
Rapportere på logs (mængder, hændelser og korrelationer) så du kan vurdere hvilket udstyr der er mest udsat, fejlbehæftet eller skal efterses. Du gør revisionen "glad" og sikrer proaktivt en højere oppetid.
Korrelere logs så du opdager sikkerhedsbrister, der kan føre til datatab og nede tid.
Øge sporbarheden ved historisk analyse af fejl, nedbrud, (bruger)adfærd. Fordi du har indsamlet dine logs aktivt er du sikker på at kunne gå tilbage i tiden og se præcist hvem der gjorde hvad på et bestemt tidspunkt. Der giver dig en bedre mulighed for at analysere en historisk fejl og på den måde forstå hvordan du kan forhindre at den samme fejl sker igen.

- Christian Schmidt, Draware A/S

Ønsker du bedre performance på VMware?

2011-04-29T11:22:00.000+02:00

Dit VMware miljø startede med at have masser af ressourcer men efter du har tilføjet en række nye servere så kører det ikke helt optimalt mere. Du har ikke et værktøj ti specifik overvågning af det virtuelle miljø og ved ikke helt hvilke parametre du bør kigge på for at løse performanceproblemerne. Men fortvivl ikke. I nedenstående artikel finder du en gennemgang af de vigtigste målepunkter inden for det delte virtuelle objekter så som CPU, MEM, DISK og NET. Det er muligvis lidt teknisk men det er det virtuelle miljø jo også, så god læselyst!

CPU Metrikker:

CPU orienterede målinger er de mest almindelige målinger, der analyseres. De er også de mest misforståede i virtuelle miljøer.

cpu.extra.summation

cpu.extra.summation metrikken måles på VM niveau og den indikerer , om der er uoverensstemmelse imellem I/O traffik og CPU proceshastighed. Denne uoverensstemmelse forårsager tidsforsinkelser kendt som I/O Wait på VM processer – og dette opfattes som et performance problem.

Hvis denne metrik er analyseret alene, vil man ikke få særlig meget nyttigt information; og VMWare har oplyst at cpu.extra.summation metrikken er upålidelig , da oplysningerne kan være misvisende.

VMware har derfor fjernet cpu.extra.summation fra vSphere 4.0. Dér hvor man tidligere kunne vælge metrikken, er der nu en blankt rubrik med teksten ”n/a”.

Metrikken er derimod stadig nyttig, når man vil finde performance problemer. Cpu.extra.summation er en indikator af mulige CPU Ready problemer og den kan give viden, når den bruges som en relativt værdi under fejlfinding blandt flere virtuelle objekter.

Høje cpu.extra.summation værdier i et bestemt område af en virtuel infrastruktur opstår, når en VM ikke har nok processorkraft allokeret, eller fordi der er CPU Ready problemer.

VMs, som lider af CPU flaskehalse, kan adresseres ved at allokere flere CPU ressourcer eller ved at løse CPU Ready problemerne.

cpu.ready.summation

Bemærk: En værdi i denne metrik indikerer, at der findes en flaskehals i det virtuelle miljø.
cpu.ready.summation metrikkern måles på VM niveau i real-time, og den vurderer, om en VM har CPU Ready problemer. CPU Ready problemer er et resultat af overudnyttelse og dette sker, når VMs er i strid med hinanden om brugen af et begrænset antal fysiske kerner. Denne strid skaber ventetid.

Ventetiden opstår, når en VM venter på, at transaktionen hos den en anden VM afsluttes, så den selv kan fuldføre sin egen transaktion. Ventetiden, som er et resultat af, at CPU Ready forårsager langsommelige transaktioner, hvilket opfattes som et performance problem.

Den bedste praksis på VM niveau siger, at en CPU Ready flaskehals opstår, når mere end 5 % af tiden brugt i en CPU transaktion er ventetid på ledige fysiske CPU ressourcer.

Selvom VMware forsøger at skedulere en VM til at bruge en fysisk kerne – på en måde hvor belastningerne balanceres - så kan denne skedulering distribueres for bredt og tyndt, hvis (alt)for mange virtuelle kerner er provisioneret pr. antal fysiske kerner.

For at undgå tynd distribution af CPU ressourcer, vil mange organisationer forsøge at rationere 3 virtuelle CPUer til en fysisk CPU som maksimum ressourcetildeling.

CPU Ready problemer kan være svære at opdage og dette er årsagen til mange performance problemer. Løsningen på CPU Ready problemer er at re-balancere VM belastninger ved at sprede brugen af fysisk CPU eller ved at ”right-size” en VMs CPU ressource allokering. CPU Ready problemer kan undgås ved at monitorere CPU forbruget med cpu.usagemhz.average og cpu.extra.summation.

cpu.usagemhz.average

cpu.usagemhz.average metrikken viser det fysiske CPU forbrug og dette er målt på VM niveau. En høj måling i cpu.usagemhz.average metrikken viser, at CPU forbruget for en fysisk CPU ressource nærmer sig, eller har nået - fuld udnyttelse. Det er muligt, at VMs med en høj værdi i denne metrik oplever ventetider i performance, da overudnyttelse af CPU kan føre til CPU Ready problemer. Her venter kommandoer på tilgængelige ressourcer.

Selvom en høj cpu.usagemhz.average metrik alene ikke er ensbetydende med, at en flaskehals finder sted, så kan det være en indikator for, at værdierne skal følges nøje. Denne metrik kan hjælpe en systemadministrator med proaktivt at undgå performance problemer. Denne metrik kan også bruges til at isolere årsagen til flaskehalsen på CPU ressourcen.

Nogle VMs vil lejlighedsvis bruge 100 % af de allokerede ressourcer, baseret på deres behandlingskrav, som kan føre til problemer med andre VMs, som skal dele disse ressourcer. VMs med høje cpu.usagemhz.average værdier bør undersøges i en længere periode, for at vurdere hvordan CPU forbruget udvikler sig gennem VMens aktive perioder. Den eneste måde at løse CPU relaterede flaskehalse er at allokere flere CPU ressourcer til VMs, som oplever problemer, der opstår som følge af CPU overudnyttelse.

Disk Metrikker:

disk.busResets.summation

Bemærk: En værdi i denne metrik indikerer, at der findes en flaskehals i det virtuelle miljø.
En disk bus reset er, når alle kommandoer, som har ventet i en kø i en HBA eller Disk Bus, er blevet slettet. disk.busResets.summation metrikken måler, hvornår en disk bus reset har fundet sted. Denne metrik er målt på VM niveau i real time.

Hvis disk.busReset.summation metrikken har en værdi på en VM, kan det indikere, at der er et alvorligt diskrelateret problem. Det er muligt at:

· en disk er blevet overbelastet af for megen trafik fra:

- For mange VMs som tilgår denne disk

- For mange instrukser, der stammer fra de VMs, som tilgår disken

· der er andre overførselsrelaterede problemer

· der er sket en hardware fejl

VMs med en disk.busResets.summation værdi vil lide af træghed og kan fryse eller crashe.
Systemadministratorer kan forsøge at fejlfinde dette problem ved at kigge på VM trafik på disken for at se, om der er et overførselsproblem fra de VMs, som tilgår disken. Det kan være nødvendigt med assistance fra en storage-administrator for at identificere kerneproblemet. Løsningen på problemet, som er identificeret ved brug af disk.busResets.summation metrikken, kan muligvis kræve et hardware fix eller typisk en re-balancering af VM trafikken ved at flytte VMs over til en anden datastore med mere kapacitet.

disk.commandsAborted.summation

Bemærk: En værdi i denne metrik indikerer, at der findes en flaskehals i det virtuelle miljø.
disk.commandsAborted.summation metrikken er en metrik, som viser antallet af mislykkede forespørgsler, der blev sendt til en disk. Denne metrik er målt på VM niveau i real time. Værdierne for denne metrik for hvert VM burde være 0. Hvis værdien er alt andet end 0, er det en indikation på, at der er et alvorligt disk relateret problem, som straks skal undersøges. VMs med en disk.busResets.summation værdi vil lide af træghed og kan fryse eller crashe. Årsagerne til at denne metriks værdi er alt andet end 0 er:

· en disk er blevet overbelastet af for meget trafik fra:

- For mange VMs som tilgår denne disk

- For mange instrukser, der stammer fra de VMs, som tilgår disken

· Der er andre overførselsrelaterede problemer

· Der er sket en hardware fejl

En systemadministrator kan fejlsøge dette problem ved at kigge på VM trafikken ned til disken og på denne måde se, om der er en gennemløbsfejl. Typisk vil det være nødvendigt med assistance fra en storage administrator for at identificere det problem, der skaber en værdi under disk.commandsAborted.summation metrikken. Løsningen til dette problem kræver typisk en re-balancering af VM trafikken ved at (her mangler vist et ord??) VMs til andre datastores med mere tilgængelig kapacitet eller et hardware fix.

disk.totalLatency.average

Bemærk: En værdi i denne metrik indikerer, at der findes en flaskehals i det virtuelle miljø.
disk.totalLatency.average metrikken viser hvor meget disk latency/latenstid, der forekommer på en disk.
Denne metrik er målt på host niveau i real time. Disk latenstid er den tid det tager at generere et svar, efter en besked er blevet leveret til disken. Denne metrik kan hjælpe med at vurdere, om et storage miljø oplever performance problemer, for hvis latenstiden er høj, så må der være et problem - men eftersom mange problemer kan skabe disk latenstid, er disk.totalLatency.average metrikken ikke præcis og yderligere fejlfinding er nødvendig for at lokalisere det problem, der skaber disk latency.
Disse problemer kan opstå som følge af problemer med hukommelsen eller disk gennemløbet. VMs, som lider af disk latenstid, vil reagere trægt under brug. Disk.totalLatency.average problemer kan løses ved at lave load balancing – find de mest ressourcekrævende VMs og right-size deres ressourcer og/eller flytte disse VMs til andre datastores.
disk.queueLatency.average

Bemærk: En værdi i denne metrik indikerer, at der findes en flaskehals i det virtuelle miljø.
disk.queueLatency.average metrikken angiver den tid en forespørgsel venter i en kø for at blive behandlet af disken. Metrikken er målt på host niveau i real time. Mens tiden hvori en forespørgsel venter i kø stiger, så vil VM performance falde. En høj disk.queueLatency.average værdi opstår som regel samtidigt med disk.totalLatency.average, eftersom forespørgsler venter i kø på grund af den øgede tid det tager disken at behandle dem. Hvis disk.queueLatency.average metrikken viser en høj værdi, skal man også kontrollere disk.totalLatency.average metrikken. Hvis disk latency er et reel problem som nævnt i disk.totalLatency.average sektionen, er der andre performance flaskehalse, som skaber dette problem, og en fuld fejlfinding i hukommelse og gennemløb metrikker skal udføres.

Ligesom problemer med disk latency, kan disk.queueLatency.average problemer løses ved at lave load balancing - altså finde de mest ressource krævende VMs og right-size deres ressourcer og/eller flytte disse VMs til andre datastores eller i sidste ende ved at skifte hardware, hvis der er hardware fejl.

Gennemløb: Et gennemsnit af disk.read.average og disk.write.average
disk.read.average metrikken referer til mængden af trafik, der genereres af at læse forespørgsler mens disk.write.average metrikken refererer til mængden af trafik, som genereres ved at skrive forespørgsler til disken. Disse metrikker er målt på VM niveau i real time. Gennemsnittet af de to metrikker tilsammen bliver måleenheden for gennemløbet. Diskgenneløbet refererer til den gennemsnitlige trafikkapacitet som en VM har i sin forbindelse til disken. Ved at kigge på gennemløbet på tværs af alle VMs kan man identificere hvilke VMs, der genererer den største mængde trafik til disken.

Throughput kan afbildes over tid for at, se om en VM har haft performance problemer på forskellige tidspunkter og aktivitetsniveauer, og hvis denne forøgelse af aktivitet har skabt performance problemer for andre VMs ved at optage alt gennemløb til disken. VMs som lider af gennemløbsproblemer, eller på hosts hvor gennemløbet er begrænset, vil virke træge ved brug. Høje gennemløbsværdier vil pege på disk latenstidsproblemer samt andre disk-problemer som Commands Aborted og Bus Resets. Gennemløbsproblemer kan løses ved at re-balancere belastninger og/eller flytte VMs til andre steder, hvor de vil have nok kapacitet, eller hvor de ikke vil optage kapaciteten som andre VMs kræver.

Memory Metrikker:

mem.active.average

mem.active.average metrikken indsamles på VM niveau, og den måler antallet af hukommelsessider (memory pages), som bruges aktivt af en VM på et givent tidspunkt. Typisk vil en VM ikke bruge al sin allokerede hukommelse på et givent tidspunkt. En del af allokeringen indeholder andre data, som har været brugt for nyligt, men som ikke/ikke længere er aktivt i brug. Eftersom en VM har mere hukommelse allokeret end det, som er i brug på et givent tidspunkt, vil mem.active.average metrikken ikke repræsentere hvor meget hukommelse, en VM har brugt. I virkeligheden er mem.active.average metrikken mere nøjagtig, når et indblik i det samlede hukommelsesforbrug skal dannes. Men man burde stadig evaluere mem.active.average for at få et indblik i, hvor meget aktiv hukommelse, der bliver brugt af en VM på et givent tidspunkt. Ved at evaluere denne metrik sammen med mem.consumed.averagevil kan man vurdere, om en VM har fået allokeret en tilstrækkelig mængde hukommelse. Det eneste måde at løse problemer, som relaterer til mem.active.average, er at allokere mere hukommelse til VM’et eller flytte VM’et til en host, som har mere hukommelse.

mem.consumed.average

mem.consumed.average metrikken indsamles på VM niveau, og den måler mængden af hukommelse, der ialt bliver brugt af en VM. En VM bruger mere end blot den aktive hukommelse, som findes i VM’ets hukommelsessider. En del af den brugte hukommelse indeholder hukommelse, som er blevet brugt for nyligt, men som ikke er aktivt i brug på det nuværende tidspunkt. Den aktive hukommelse og ”tilbageholdt hukommelse” udgør tilsammen det samlede hukommelsesforbrug af en VM – og dette er hvad mem.consumed.average måler.

Evaluering af mem.consumed.average værdier kan være værdigfuld (pun intended), når man vurderer indvirkningen af hukommelsesmangel på performance i en VM. Det er vigigt at vurdere mem.active.average samtidigt for at se, om en VM virkelig lider af hukommelsesmangel. Ved nøje undersøgelse af denne metrik i ressourceforbruget mens en VM arbejder på højt plan, kan man danne et sig et indblik i, hvor meget hukommelse VM’en skal have allokeret. Vigtigst er forståelsen for, at visse VMs vil bruge al den hukommelse, der er til rådighed, og hvis en VM viser høje mem.consumed.average værdier, vil det være nødvendigt at undersøge, om det er en af ”memory hog” applikationerne, som er skyld i problemt. For disse typer VMs vil brug af mem.consumed.average metrikken som en tærskel til fremtrædende hukommelsesmangel ikke virke. Den eneste måde at løse hukommelsesmangel som mem.consumed.average og mem.active.average på er ved at tilføje eller allokere mere hukommelse til VM’en eller ved at flytte den til en host, som har mere hukommelse.

mem.overhead.average

mem.overhead.average metrikken måler mængden af hukommelse, som bruges til at administrere allokeret hukommelse og som indsamles på VM niveau pr. host. På grund af måden VMs – og computere generelt – bruger deres hukommelse, skal en del af hukommelsen bruges til at administrere sig selv. Denne process er den måde, en computer holder styr på, hvad dens egne ressourcer laver. En vigtig bemærkning til denne adfærd er, at det supplerende overhead tilføjer et krav til mere hukommelsesbrug af en VM end det, som er allokeret af systemadministratoren. Jo større mængde hukommelse, der allokeres til en VM, jo mere hukommelse skal bruges til overhead. Tabellen nedenfor fremstillet af VMware viser en akkurat læsning for hvor meget overhead, der er behov for – pr. VM - baseret på hukommelse og antal CPUer for en given VM. Eftersom hukommelse er den mest begrænsende ressource, er iagttagelse af mem.overhead.average metrikken afgørende for at undgå noget, der kan føre til hukommelsesmangler, der ikke fremgår tydeligt.

Kilde: vmware.com [Link]

Memory Swapping: mem.swapin.average, mem.swapout.average og mem.swapped.average

Bemærk: Værdier i disse metrikker indikerer, at der findes en flaskehals i det virtuelle miljø.
mem.swapin.average, mem.swapout.average og mem.swapped.average metrikkerne evalueres samtidigt for at måle, om der opstår memory swapping flaskehalse. Disse metrikker måles på VM niveau, og det samlede gennemsnit bruges til at danne en procent værdi. Memory swapping er en handling, som computere gennemfører for at administrere deres hukommelse. Hvis en computer’s hukommelse er fuld og der er ikke yderligere kapacitet for at forvalte informationer, vil computeren tage noget af indholdet i sin hukommelse og ”swappe” det ned i storage på en disk, for at den så kan tage imod nye informationer i den nu ledige hukommelsesplads. Hvis noget af den hukommelse, som er blevet swappet skal bruges, vil VMen forespørge i den gamle hukommelse fra disken og swappe den ind igen, så den kan bearbejdes. Denne process er ekstremt tidskrævende og kan forårsage meget lange (læs:meget lange) proces tider, da informationen skal bevæge sig igennem netværket til disk systemet og derefter skal behandles af disken(e). Ligeledes vil denne meget lange proces opstå, når informationen skal swappes tilbage til hukommelsen fra disken. Som følge af de massive ventetider vil performance niveauet synke drastisk, hvis VMer swapper hukommelse. Memory swapping kan tilgengæld skabe andre flaskehalse, da swapping af store data blokke kan tilstoppe gennemløbet. Forøget gennemløb vil have en negativ effekt på disken, og dette vil resultere i disk latenstid samt andre disk problemer.

Memory swap er i det hele taget en indikator på, at der ikke er allokeret nok hukommelse til VMen, eller der kan opstå ballooning, og dette nedskærer hukommelsen til en VM på en host. For at løse en memory swapping flaskehals skal man tildele mere hukommelse til VMen og udføre yderligere fejlsøgning for at finde ud af, om swapping sker som følge af ballooning.

mem.vmmemctl.average (balloon)

Bemærk: En værdi i denne metrik indikerer, at en flaskehals forekommer i det virtuelle miljø.
En værdi i mem.vmmemctl.average metrikken er en indikator på, at der foregår ballooning. Ballooning opstår, når VMer bruger flere hukommelsesressourcer og begynder at nå grænsen, enten fysisk eller defineret i ressource grænsen i VMware. VMware vil, som følge af forøget aktivitet i en VM, administrere og bevilge hukommelse til den VM, der har mest brug for det. Ballooning er af afgørende betydning, da den er direkte forbundet til memory swapping, som er en væsentlig årsag til performance problemer. VMware skaber ballooning for at forhindre hukommelsesmangel, men denne process vil skade ”uskyldige tilskuer” VMs. Problemerne opstår, når en VM er blevet frataget sine hukommelsesressourcer og begynder at forøge bruget af hukommelse. VMen vil herefter begynde at swappe hukommelse ned til disken for at gøre plads til flere informationer, som den skal behandle. Denne handling fører til de tidligere nævnte memory swapping problemer. Som før nævnt, kan memory swapping herefter skabe gennemløbs- og disk-problemer. Disse forekommende flaskehalse vil sænke en VMs performance gevaldigt! Værdier i mem.vmmemctl.average metrikken skal undersøges omgående. Endvidere er det muligt, at ballooning sker, fordi VMware har lavet begrænsninger – begrænsninger som systemadministratoren ikke har kendskab til.

Måden at løse flaskehalse, der opstår som følge af ballooning, på er ved at right-size hukommelse for alle VMs, om nødvendigt tilføje mere hukommelse, flytte VMs for at balancere ressource forbuget og vigtigst, se om der er sat begrænsninger i Vmware, som ikke passer til de VMs, der administreres.

Netværksmetrikker:

net.received.average, net.transmitted.average og net.usage.average

net.received.average, net.transmitted.average og net.usage.average metrikker måler VM forespørgsler, netværkstrafik og forbrug. Disse metrikker måles på VM niveau og ligner den information, som opfanges i disk gennemløbet, men disk gennemløbet er direkte relateret til den trafik, der kommer fra en datastore til serveren. Denne metrik kan give indblik i, om iSCSI eller NFS storage er i brug, da kommunikationen for datastore trafikken måles i netværkstrafikken.

Disse metrikker rapporterer på områder, som hvad flaskehalse angår er så små, at store værdier i en mærkbar mængde kun vil blive set på cluster eller datacenterniveau. Selv på disse niveauer repræsenterer net.received.average, net.transmit.average og net.usage.average minimale mængder trafik, hvis de sammenlignes med andre metrikker. Netværksmetrikker er meget sjældent – hvis nogensinde – årsagen til performance flaskehalse.

At finde og løse problemer med analyser fra disse målinger:

For at finde problemer i data leveret af disse metrikker skal et datacenter kunne trække rådata ud og behandle dem med avancerede analyser for at sammenligne værdier og afvigende værdier og se om problemer opstår på specifikke tidspunkter. Derudover skal visse metrikker analyseres på VM niveau samt host, cluster og ressourcepool niveau. Endnu vigtigere er det, at et problem i en metrik for en VM kan være forårsaget af hændelser, som sker på et andet VM. Disse beregninger kan være komplicerede at sætte op og kræver store mængder proceskapacitet for, at de kan fuldføres. Mens ressourcer deles, skal analysen vurdere, hvordan VMs interagerer med hinanden og samtidigt analysere enkelte VMs, hosts, clusters og ressourcepools.

Løsning af eksisterende problemer gennem analyse af de to metrikker:

Løsningen til problemer, som de 20 metrikker afslører gennem analyse af data fra vCenter, omfatter normalt konfiguration af indstillinger for miljøet, right-sizing af ressource allokeringer for en VM, rebalancering af VMs på tværs af udstyret for at distribuere belastninger bedre eller undersøgelse af hardware, hvis en flaskehals muligvis opstår som følge af et hardware problem. Efter man har opdaget en flaskehals, er yderligere analyse af data nødvendigt for at finde ud af, hvad den begræsnende ressource er eller for at undersøge et mønster, som kan give dig et hint om, hvad problemet er.

Konklusion:

Deling af ressourcer i et datacenter gør det mere komplekst at sikre, at en VM har de ressourcer, den har brug for for at kunne fungere, som den skal. De 20 metrikker beskrevet ovenfor bør monitoreres aktivt, når man skal administrere et miljø og sikre høj performance af alle VMs. På grund af de store mængder oplysninger, der genereres i real-time, skal data fra disse 20 metrikker analyseres rettidigt for ikke blot at identificere en flaskehals, men for at forhindre flaskehalse i at opstå, når tidlige varslingsindikatorer identificeres.

Bemærk: Værdier i disse metrikker indikerer, at der er en flaskehals i det virtuelle miljø.

Af Thor-Bjørn Tramp (tat@draware.dk)

Overvågning - men hvordan og af hvad?

2011-04-29T10:28:00.000+02:00

Efter et alvorligt nedbrud har du indset nødvendigheden af at overvåge din infrastruktur, men hvordan griber du sagen ad og hvad skal du overvåge?

Det er en problemstilling mange kan nikke genkendende til og den umiddelbare reaktion er at skrive overvågning som søgeord i Google. Det giver imidlertid 2,39 millioner hits! Finder du egentlig frem til nogle forskellige alternativer så står der ofte af pågældende løsning klarer præcist det samme uanset em den koster kr. 10.000 eller en million.

Samtidigt hører du brugerne og din IT organisation klage over fx:

Det går for langsomt
Det er "nok" serverne / netværket / SANet osv...
Patch Management systemet har installeret opdateringer og nu virker applikationen ikke
Virtualiseringen har gjort alt uoverskueligt og langsomt
Varmen fik serverne til at gå ned
Vi mistede strømmen pga fejl i UPSen

Der er jo tusinder fejlkilder og du står i dag med ingenting, en lille løsning som er for simpel (fx. en gratis løsning baseret på Ping) eller en kompliceret enterpriseløsning som ingen rigtigt kan betjene (foruden leverandøren som skal on-site til kr. 1.500 i timen). I har kort sagt prøvet at finde en løsning før men det har vist sig at være en tidskrævende, dyr og besværlig øvelse uden et garanteret brugbart resultat.

Fortvivl ikke for går du lidt struktureret tilværks er der gode chancer for at få en successful oplevelse. Du kunne som en god start læse min BLOG om valg af den "rigtige løsning". Når du har været igennem disse vurderinger, så tænk på hvilke af følgende elementer, der udgør dine "main pains". Det er næppe sandsynligt at du vil investere i en løsning som på én gang klarer dem alle eller har tid til at vente på en implementering, som kan tage måneder (eller år):

#1: Netværket (LAN/WAN/WiFi)
#2: Serverne (fysiske såvel som virtuelle)
#3: SAN og storage
#4: Applikationerne - både interne og eksterne
#5: Det virtuelle miljø
#6: Log Management
#7: Prober og særligt udstyr (temp, batteri, fugt, lys, luft m.fl)

Når du har afgjort hvilke elementer der er vigtigste at måle på (prioriter dem eventuelt fra 1 til 7) og vurder så hvilke af følgende målepunkter, der kan give jeres drift relevant information om status og tendenser:

Netværk: (Impact på #1, #3 & #5)
A) Tilgængelighed ("Availability") baseret på ping hvis det er netværksnoder eller servere
B) Trafikmængden (antallet af pakker, mængde og båndbreddeforbrug)
C) Trafiktypen (porte, protokoller og applikationer) typisk baseret på sFlow/NetFlow
D) Opsamling af hardware fejl (syslogs / traps)
E) Environment status og særlige målepunkter
F) Evt. topologisk info som hjælper med mapning og alarmhåndtering
Servere: (Impact på #2 #4 & #5) A) Tilgængelighed ("Availability") helst baseret på noget andet end ping (fx WMI forespørgsler til OS)
B) Båndbreddeforbrug på netkortet
C) Throughput til SAN
D) Opsamling af hardwarefejl (syslogs / traps / fra HW agenter som fx HP SIM)
E) Særlige metrics for virtuelle servere relateret til deling af CPU, MEM & Disk.
SAN & Storage: (Impact på #2, #3, #4 & #5)
A) Målepunkter for IOPS
B) Throughput
C) Read/Write operationer til storage
D) Båndbreddeforbrug på interfaces på SAN
E) Evt. topologisk info som hjælper med mapning og alarmhåndtering
Applikationerne: (Impact på #4)
A) Tilgængelighed på applikationer / komponenter (typisk baseret på WMI, Perfmon eller på en lokal agent som rulles ud fra overvågningssystemet)
B) Svartid på applikationer og URLs
C) Synthetiske transaktioner med applikationer
D) End-2-End performance målinger
E) Transaktionsmålinger på fx web transaktioner
Det virtuelle miljø: (Impact på #2, #3 & #5)
A) Nuværende problemer (flaskehalse, CPU/MEM/DISK*)
B) Hvor opstår de fremtidige problemer
C) Rightsizing - genvinding af ressourcer som er over/under fordelt
D) Eventuelt rapportering på prisen for de udnyttede ressourcer (Chargeback)
Log Management: (Impact på #1 - #7)A) Opsamling, konsolidering og indexering af logs fra servere (Fx Windows, Unix, Linux og ESX), applikationer (Fx SQL, Mail og Web), Netværksnoder (Fx switches, routere, AP/WLC & Firewalls)
B) Mulighed for søgning på tværs af alle logs på bestemte tidspunkter efter en bestemt type af data (fx IP adresse, brugerkonto, event ID, severity, facility mm)
C) Event log korrelering hvilket vil sige sammenstilling af forskellige logs baseret på type og frekvens til brug for alarmering og rapportering
D) Alarmering på basis af automatisk genkendte dele af logs (fx eventid eller bestemte logs fra hardware leverendører som feks. Cisco og HP)
Prober og særligt udstyr: (Impact på #1 - #7)
A) Custom SNMP baseret polling af værdier fra prober som giver alarmer (Fx temperatur, fugt, lys, luft, åben/lukket, spænding mv)
B) Overvågning af UPS og alarmer om batteritilstand

Når du har valgt hvad der er vigtigst for din infrastruktur så er det en god idé at kende faldgrupperne så du forhåbentlig kan undgå de værste og få en hurtig og smidig implementering af overvågningen. Derfor har jeg listet nogle af de problemer som vi oftets ser ved overvågningsystemer og implementering / brug:

Den forkromede løsning: I din "iver" for at vælge et system som kan alt hvad I gerne vil er det endt med et framework system fra en af de store leverandører. Disse systemer er ofte komplicerede, store meget funktionsrige. Det kan betyde følgende for jer:

A) En meget lang implementeringstid (måneder til år)
B) Afhængighed af få specialister i egen organisation (eller endnu værre hos en ekstern kilde)
C) Manglende fleksibilitet i systemet gør det til en supertanker (svær at manøvrere)
D) Meget kostbart både i indkøb, vedligehold og interna/eksterne ressourcer til at implementere og vedligeholde systemet.
Fejlalarmer: Du vælger et system hvor alle alarmer er slået til så hele implementeringen går ud på at slå de unødvendige alarmer fra. Eller du får sat en række alarme op der ikke er specifikke nok så IT driften drukner i alarmer. Derfor sletter du/I bare alle alarmer hver morgen... inklusive den vigtige om at exchangeserveren er ved at løbe tør for diskplads.

Alarmer skal deles op i tilghængelighed og performance og være meget specifikke. Det er vigtigt at de i alarmteksten som minimum fortæller følgende:
A) Hvor alarmen kommer fra
B) Hvad der har udløst alarmen
C) Hvordan fejlen rettes
Afstemning af forventninger: Det nye IT overvågningssystem kan kun betjenes af en eller to personer i afdelingen og passer godt til hvad de ønsker. Men systemet passer ikke til hvad alle andre forventede af udbytte, inklusive chefen som har betalt for systemet eller brugerne som burde få inddirekte glæde af en højere oppetid eller en hurtigere problemløsning. Husk at vælge successkriterierne for systemet før det vælges, indkøbes og implementeres!
Vi vil have alt i ét system: Du ønsker en fælles platform eller ét system der kan udbygges til at klare alle opgaver. Det er besnærende at forestille sig at du kun skal kigge i et overvågningssystem for at se alle problemer i driften, men det fører næsten altid til valg af "den forkromede løsning" og det har som tidligere beskrevet ofte nogle uheldige konsekvenser. Prøv i stedet at vælge nogle specialistløsninger som kan rapportere ind til et fælles system som fx ServiceDesken som samler alle trådene. Det er alligevel specialister som kigger på netop deres område i systemet som fx Serverne, netværket, applikationerne, storage osv.
Brugerne:Husk at vælge en system som ret faktisk giver brugerne noget værdi i form af nedenstående punkter. Disse punkter bør være en del af successkriterierne for valg af et system.

A) Hurtigere fejlretning
B) Bedre information om problemer
C) Højere oppetid
D) Hurtigere svartid
E) Bedre performance

For at få inspiration til flere af de nævnte udfordringer og, emner og teknikker kan du fx se på følgende links: [Emner] [Metoder] [Problemer]

* Se vores blog om vigtige performance parametre i det virtuelle miljø.

Af Christian Schmidt (chr@draware.dk)

Kan du kode dig ud af rutineopgaver?

2011-04-29T10:06:00.000+02:00

Muligheder og trængsler når du er træt af at gøre tingene manuelt igen og igen.

Der kommer et tidspunkt i enhver teknikers liv, hvor man bare er så træt af hele tiden at lave de samme kedelige ting gang på gang. Huske at flytte filer, huske at lave backup af databaser, checke logbiblioteket, læse fejlmeddelelser, fjerne gamle filer der er mere end 100 dage. Listen er uendelig og enten bliver det ikke gjort eller også tager det laaaang tid og bliver bare endnu en brandslukningsopgave blandt de mange andre hastesager.

Når opgaver skal udføres manuelt, er det ting, der ofte bliver glemt, når det hele brænder på. Så opdager man konsekvenserne på den hårde måde, når systemerne ikke længere virker, og så er rutineopgaverne lige pludseligt noget, der røver dagevis af tid. De manuelle rutineopgaver tager også ofte tid fra de virkelige problemer og opgaver, så hverdagen bliver en hektisk jonglering mellem opgaver og tid.

Er løsningen så ikke bare at få automatiseret så mange af rutinerne som muligt, så afdelingen kan glemme opgaverne i tryg forvisning om, at der bliver taget hånd om det?

En måde, der både umiddelbart er gratis og ligger lige for, er at lave en række scripts, som kan eksekveres gennem Windows Task Manager. Fordelen ved denne løsning er, at den ikke kræver investeringer i nyt hardware og software, og den bruger standard komponenter, der allerede findes i alle Windows servere.

Er afdelingen helding med at have en eller flere medarbejdere, der synes det er en sjov udfordring, så kan du komme et godt stykke af vejen med scripts. Det kræver så bare, at der er god tid til det, og at man har den viden, der skal til for at få det til at fungere. Når scriptet lige er blevet færdig og den stolte ejer præsenterer løsningen, er der i reglen ikke et øje tørt. Det kører bare, og man kan bruge sin energi på andre opgaver.

Men over tid fejler scripts fra tid til anden. Det kan være fordi task manager ikke rigtigt fik startet det efter en genstart eller placeringen blev ændret. Du opdager ikke, at scriptet ikke kører og lever i uvidenhed om konsekvenserne, indtil databasen bryder sammen pga for lidt harddisk plads eller fordi jeres kunde system ikke kan sende data.

Er løsningen så bare at resignere og vende tilbage til de manuelle rutiner?

Egentlig ikke. Scripting vil fungere OK i stabile miljøer, hvor man sørger for at vedligeholde scripts regelmæssigt og får dem tilpasset lige så snart, der er ændringer i det miljø, de skal virke i. Det er også meget vigtigt, at man har sat et log system op, så man kan få besked, når de automatiske rutiner svigter.

I den virkelige verden er det bare ofte sådan, at de medarbejdere, der kunne lave ændringer i jeres scripts, enten ikke er der mere, eller de er på ferie eller har barn syg, når det brænder på. De logs I skulle checke for at vide, at scriptene ikke kører længere, bliver heller ikke checket – det er jo et manuelt job, som man glemmer.

Så der er ikke noget galt med automatisering, hvis bare det kan gør livet lettere i stedet for mere besværligt. Jeg synes derfor, at automatisering som minimum skal kunne:

Være nemt at tilpasse og ændre uden kode
Skal kunne tage hensyn til undtagelser og til, at miljøet kan ændre sig.
Jeg vil vide, når automatiseringen virke,r som den skal
Jeg vil især også gerne vide, når det IKKE virker

Det er muligt at få en automatisering på plads, der opfylder de krav og mere til, men så skal man have et system, der kan levere varen. Se mere om emnet på [Automatisering]

Af Steffen Kjeldsen (stk@draware.dk)

Hvordan vælger du IT drift værktøjer?

2011-04-24T10:19:00.000+02:00

Så du har et problem i driften der sikkert kræver hjælp fra en af de millioner af løsninger. som findes på markedet men hvordan finder du "den rigtige løsning" på netop dine udfordringer?

Det er ikke nogen triviel sag og en proces, du kan lære at mestre, hvis du har klarlagt nogle kriterier først. Nedenstående er baseret på mange års observation af forskellige strategier og deres resultater hos vores kunder.

Selv om du måske ikke umiddelbart gør dig det klart, så findes der en række faktorer, der er afgørende for valget af løsning uden umiddelbart at havde noget med løsningen at gøre. De 3 vigtigste eksterne faktorer er:

Økonomi: Løsningen du vælger koster penge! Både i indkøb, vedligehold, implementering og uddannelse. Det gælder også selvom løsningen er gratis eller meget billig i indkøb / vedligehold. Det er afgørende, at du har en idé om de mulige økonomiske rammer for en løsning, før du prøver at vælge en. Skal den koste 10K, 100K, 500K eller 1M?
Brugervenlighed: Kan du og dine kollegaer bruge løsningen i løbet af kort tid uden at skulle bruge urealistisk lang tid på uddannelse? Du ved sikkert selv at det at tage meget mere end ½ - 1 dag fri fra arbejde er svært. Findes der portaler, videoer eller andet hvor I kan lære produktet selv eller skal I på et eksternt kursus? Hvor meget tid skal der løbende bruges på formel uddannelse versus selvtræning?
Leverandøren: Typen af leverandør kan blive afgørende for successen af dit valg, fordi forskellige leverandører betragter deres kunder helt anderledes end du gør dig klart. Herunder finder du 3 forskellige slags leverandørtyper:

A) Enterprise: Stor multinational spiller med ubegrænsede ressourcer, mange produkter, meget viden og mange kunder. Det bliver dyrt (fordi producenten skal have betaling for hele den store organisation som står bag), du bliver underlagt producentens regler og processer så alting tager meget lang tid og det bliver ofte kompliceret, fordi producentens løsninger er beregnet til meget store (amerikanske) kunder. Producentens lydhørhed overfor dine ideer og ønsker er stort set nul. Skal du have den mindste smule hjælp, koster det penge og helpdesken et typisk outsorcet til et helt tredie land, hvor der ikke er garanti for, at du kan komme til at tale med en ekspert.

B) Entreprenøren: Mindre producent ofte med udenlandsk repræsentation, som har færre ressourcer, færre produkter og færre kunder - specielt kunder i din region. Du vil opleve en stor grad af fleksibilitet hvad angår licenser, priser, support og fejlrettelser. Producenten har support i en anden tidszone, men supporten er normalt kompetent og svarer på både e-mail og telefon. Producentens lydhørhed overfor dine kommentarer og ideer er normalt ret stor. Der er en fare for at producenten ikke findes om nogle år eller bliver opkøbt af et andet firma med en anden strategi.

C) Den lokale: Du vælger en løsning, hvor din lokale partner står på mål for at løsningen er den "rigtige". Partneren klarer kontakten til producenten og hjælper dig med både implementeing, uddannelse og support. Er den lokale partner god, får du alle fordelene. Hvis den lokale partner er dårlig, får du alle ulemperne. Husk at sikre dig, at du hvis det bliver nødvendigt har mulighed for at kontakte leverandøren direkte.

Så nu har du noget at kigge på, før du går ud og prøver at finde den rigtige løsning og er klar til at vælge bladt de mange kandidater, men hvordan finder du løsningen og hvad skal du se på under valget af løsningen?

Du er nu klar til at definere hvad løsningen skal udvirke i dit miljø / organisation og hvorfor du har brug for den (Eng: "compelling event"). Det er af afgørende betydning, at du kan svare på, hvorfor du vil have en ny løsning og hvilke problemer/udfordringer, det nye værktøj skal løse. Meget vigtigere end specifikke funktioner. Jeg har set utallige lister med kravsspecifikationer, der groft sagt repræsenterer "reservedele der flyver i formation". Da mange løsninger stort set kan det samme (dog ofte på forskellig måde) bliver det vigtigere at definere krav til brugervenlighed og hastighed end om produktet understøtter SNMP og WMI. Herunder kommer nogle eksempler på hvad du skal se efter i et produkt:

Spot on: Kan løsningen nogenlunde det du har brug for eller væsenligt meget mere eller mindre? Finder du en løsning, som nogenlunde kan det du har brug for, så er der stor sandsynlighed for, at den har det rigtige mix af økonomi og brugervenlighed til dit behov. Det er nemt at forelske sig i en masse funktioner, men det har tit et uheldig indvirkning på brugervenligheden, økonomien og implementeringstiden.
Best IT fit: Passer løsningen ind i virksomhedens IT strategi? Det spørgsmål er vigtigt at få besvaret og kan rumme mange "vejbump" af politisk og faglig karaker. Hvis du vælger en løsning, som er i uoverensstemmelse med virksomhedens IT strategi, får du næppe IT afdelingens udelte support og opbakning.
I like it: Når du får en præsentation af løsningen, har du så umiddelbart en god mavefornemelse? Det er måske den vigtigste parameter for valg af en løsning. Har du fornemmelsen af, at det en en løsning, som er nem, overskuelig, velfungerende og som løser dine opgaver, så er det stor sandsynlighed for, at du har fundet "den rigtige løsning".

For at kunne vælge den rigtige løsning skal du formodentlig se på nogle alternativer og her kan det være en uvurderlig hjælp, hvis du kan få en uvildig lokal parner med på råd. Der findes så mange forskellige muligheder, at noget rådgivning vil spare dig for rigtigt meget tid, energi, natlige telefonsamtaler mv. Hvis du har afklaret de foregående punkter og går til en lokal partner med dine ønsker, skulle du kunne vælge den rigtige løsning på meget kort tid (typisk 1-3 måneder).

Søger du inspiration til at finde "den rigtige løsning", som kan hjælpe dig med at støtte din IT drift, så kan du fx:

Starte med Adam og Eva foran Google. Her er mulighederne ubegrænsede, men netop mængden af valgmuligheder er så overvældende, at det måske ikke er en god option for den utrænede løsningshunter.
Spørge leverandøren af den tilsvarende hardware. De vil ofte pege på en løsning, som specifikt understøtter deres produkter og er det, hvad du søger, så er det jo fint. Men forvent ikke et uvildigt råd eller en løsning som er bred, nem eller hurtig at implementere.
Hente inspiration hos din lokale partner. Hos Draware har vi inddelt vore løsninger efter Emner, Metoder og Problemer for at du bedst muligt kan søge målrettet inspiration på nettet. Her kan du i ro og mag hvis du har tid læse om mulighederne, uden at blive "overfaldet" af en ivrig sælger.
Bruge en livline ved at ringe til en kollega eller til en lokal partner du stoler på. Det er ofte den hurtigste vej til at sikre, at valget falder på "den rigtige løsning".