NNM iSPI Performance for Quality Assurance (iSPI QA)

Når man har kontroll med oppetid og topologi for nettverket – noe NNMi gir deg – er det neste steget å få kontroll med kvaliteten. iSPI QA er en tilleggsmodul til HP Network Node Manager i (versjon 9.0 og høyere), som har som mål å bidra til økt stabilitet og kvalitet i nettverket ved å innsamle informasjon om, og rapportere på, nettverkskvalitet. iSPI QA omfatter bl.a. følgende funksjoner:

  • Oppdager eksisterende kvalitetstester i nettverket
  • Genererer rapporter over resultat av kvalitetstester, skedulert eller ved behov
  • Alarmerer når ”terskelverdier” overskrides

Automatisk oversikt over kvalitetstester

Den vanligste metoden for å teste kvalitet i nettverket er ved å simulere bruk. Dette gjøres ved å generere trafikk mellom to noder, basert på forskjellige protokoller (ICMP, TCP, UDP), og måle tid fra data sendes til svaret mottas (og eventuelle datatap som skjer). For at testingen skal dekke hele nettverket, er det normalt å konfigurere distribuerte enheter (som oftest rutere) til å utføre testene.

De testtypene som iSPI QA støtter er følgende:

  • ICMP Delay (tidsforsinkelse for ”ping” til en node)
  • ICMP Jitter (variasjon i tidsforsinkelsen)
  • ICMP Data loss (andel av ICMP pakker som mistes)
  • TCP Delay (tidsforsinkelse for oppkobling av en TCP-forbindelse)
  • TCP Jitter (variasjon i tidsforsinkelsen)
  • UDP Delay (tidsforsinkelse for sending av UDP pakker)
  • UDP Jitter (variasjon i tidsforsinkelsen)

Ciscos nettverksutstyr har mulighet for å teste dette, gjennom en funksjon i Cisco IOS som heter IPSLA (IP Service Level Agreement). Denne het tidligere SAA (Service Assurance Agent), og mange benytter fortsatt dette uttrykket. iSPI QA oppdager også tester basert på RFC 4560 (DISMAN Ping MIB) som tilsvarer IPSLA, men ikke er leverandørspesifikk.

Siden QA tester er konfigurert på den enkelte ruter eller svitsj i nettverket – for å teste forskjellige deler av nettverket – kan det være vanskelig å holde oversikt over hvor testene utføres, og hvilken del av nettverket de passerer gjennom. Med iSPI QA oppdager NNMi de nodene som tester nettverket, og bygger opp oversikten sentralt over hvilke tester som går hvor. Også tester som går mot deler av nettverket som ikke er direkte overvåket (f.eks. utstyr hos en service provider eller som er i et ”cloud” miljø) blir innhentet og er med på å danne totalbildet.

QA tester utføres etter en fast tidsplan, gjerne hvert 5. eller 10. minutt. Dermed genereres det mye data som ligger ute på den enkelte ruter eller svitsj til iSPI QA henter inn dette og legger det inn i sin database for rapportering. Med denne distribuerte metoden for datalagring, er man sikret å få tilgang til kvalitetsdata, også i tilfeller hvor linken mellom NNMi stasjonen og de enkelte rutere har vært ute av funksjon.

Skjermbildet nedenfor viser en oversikt over et antall QA tester:

 

Rapporter

En av de viktigste måtene å benytte kvalitetstestene på, er å studere utviklingen i kvalitet og stabilitet over tid. Derfor inneholder iSPI QA en rekke rapporter, som gir deg trender for kvalitetsparametre over tid. Rapportene kan kjøres ut etter forhåndsdefinerte tidsintervaller, eller de kan kjøres når man føler behov for det. Ikke minst hvis en kunde eller bruker klager over hvordan det var i går eller i forrige uke, kan det være greit å se hva som egentlig var tilstanden.

Skjermbildene nedenfor viser en rapport fra iSPI QA:

 

Alarmering

Brukeren kan konfigurere terskelverdier som de innsamlede data skal sjekkes mot, for å generere alarmer når kvaliteten synker under et visst nivå. Disse konfigurasjonene kan være bygget opp basert på et ”site” begrep, dvs. en lokasjon hvor det finnes en eller flere noder. Alle tester knyttet til en slik ”site” blir dermed gruppert, uansett hvor de utføres fra.

Integrasjon

iSPI QA er integrert med to andre iSPIs for å supplere disse med kvalitetsinformasjon. Dette gjelder iSPI for MPLS og iSPI for IP Telephony.  

Dato:10.02.2010

RTSM – oversikt over status i ditt operative driftsmiljø

RTSM – oversikt over status i ditt operative driftsmiljø RTSM er en ”sanntidsdatabase” som ligger i BSM Foundation fra og med versjon 9, og som oppdateres både med hensyn på status og topologi av alle produktene i BSM9-porteføljen.
Les mer her

Hvorfor Cloud er "Nå", ikke "Når"!

Hvorfor Cloud er "Nå", ikke "Når"! Hvorfor Cloud er "Nå", ikke "Når"! Cloud løsninger vil påvirke fremtiden vår og det er særdeles viktig at vi starter en orientering om dette nå.
Les mer her

Cloud Reference Architecture

Cloud Reference Architecture HP har utarbeidet en arkitektur som viser hvilke elementer en Cloud Computing arkitektur bør bestå av, og deres innbyrdes relasjoner, kalt HP Cloud Reference Architecture.
Les mer her
NESTE AKTIVITETER: