Prestatiemanagement: witboek over best practices

Inleiding

Prestatiebeheer omvat optimalisatie van de responstijd van netwerkservices en beheer van de consistentie en kwaliteit van afzonderlijke en algemene netwerkservices. De belangrijkste service is de noodzaak om de responstijd van gebruiker/toepassing te meten. Voor de meeste gebruikers is de responstijd een kritische succesfactor voor prestaties. Deze variabele geeft vorm aan de perceptie van netwerksucces door zowel uw gebruikers als toepassingsbeheerders.

Achtergrondinformatie

Capaciteitsplanning is het proces waarmee u de vereisten voor toekomstige netwerkbronnen bepaalt om een impact op de prestaties of beschikbaarheid van bedrijfskritieke toepassingen te voorkomen. Op het gebied van capaciteitsplanning kan de basislijn van het netwerk (CPU, geheugen, buffers, in/uit-octetten, enz.) de responstijd beïnvloeden. Houd er daarom rekening mee dat prestatieproblemen vaak correleren met capaciteit. In netwerken is dit meestal bandbreedte en gegevens die in wachtrijen moeten wachten voordat ze via het netwerk kunnen worden verzonden. In spraaktoepassingen heeft deze wachttijd vrijwel zeker invloed op gebruikers omdat factoren zoals vertraging en jitter de kwaliteit van het spraakoproep beïnvloeden.

Een ander belangrijk probleem dat prestatiebeheer bemoeilijkt, is dat hoewel hoge netwerkbeschikbaarheid van cruciaal belang is voor zowel grote ondernemingen als netwerken van serviceproviders, de neiging bestaat om economische voordelen op korte termijn te zoeken met het risico van (vaak onvoorziene) hogere kosten op de lange termijn. Tijdens elke begrotingscyclus worstelen netwerkbeheerders en personeel voor projectuitvoering met het vinden van een evenwicht tussen prestaties en snelle implementatie. Verder worden netwerkbeheerders geconfronteerd met uitdagingen zoals snelle productontwikkeling om te kunnen voldoen aan beperkte marktvensters, complexe technologieën, bedrijfsconsolidatie, concurrerende markten, ongeplande downtime, gebrek aan expertise en vaak onvoldoende tools.

Hoe passen prestaties in het licht van deze uitdagingen binnen het kader voor netwerkbeheer? De primaire functie van een ideaal netwerkbeheersysteem is het optimaliseren van de operationele mogelijkheden van een netwerk. Zodra u dit als het ultieme doel voor netwerkbeheer accepteert, is de focus van netwerkbeheer om de netwerkwerking op topprestaties te houden.

Een ideaal netwerkbeheersysteem omvat deze hoofdbewerkingen:

• Informeert de exploitant over een dreigende verslechtering van de prestaties.

• Biedt eenvoudige alternatieve routering en tijdelijke oplossingen wanneer de prestaties verslechteren of uitvallen.

• Biedt de tools om oorzaken van prestatieverslechtering of -falen vast te stellen.

• Het dient als het belangrijkste station voor veerkracht en overlevingsvermogen van het netwerk.

• Communiceert prestaties in realtime.

Op basis van deze definitie voor een ideaal systeem wordt prestatiebeheer essentieel voor netwerkbeheer. Deze prestatiebeheerproblemen zijn van cruciaal belang:

• Gebruikersprestaties

• Toepassingsprestaties

• Capaciteitsplanning

• Proactief storingsbeheer

Het is belangrijk op te merken dat met nieuwere toepassingen zoals spraak en video, prestaties de belangrijkste variabele voor succes zijn en als u geen consistente prestaties kunt bereiken, wordt de service als van lage waarde beschouwd en mislukt. In andere gevallen hebben gebruikers gewoon last van variabele prestaties met intermitterende time-outs van toepassingen die de productiviteit en gebruikerstevredenheid verlagen.

In dit document worden de meest kritieke prestatiebeheerproblemen beschreven, waaronder kritieke succesfactoren, essentiële prestatie-indicatoren en een proceskaart op hoog niveau voor prestatiebeheer. Het bespreekt ook de concepten van beschikbaarheid, responstijd, nauwkeurigheid, gebruik en capaciteitsplanning en bevat een korte discussie over de rol van proactieve foutanalyse binnen prestatiebeheer en het ideale netwerkbeheersysteem.

Kritieke succesfactoren

Kritieke succesfactoren identificeren de vereisten voor best practices voor implementatie. Om als kritische succesfactor te kwalificeren, moet een proces of procedure de beschikbaarheid verbeteren of de afwezigheid van de procedure moet de beschikbaarheid verminderen. Daarnaast moet de kritische succesfactor meetbaar zijn, zodat de organisatie de mate van succes kan bepalen.

Opmerking: Zie prestatiebeheerindicatoren voor gedetailleerde informatie.

Dit zijn de kritische succesfactoren voor performance management:

• Verzamel een basislijn voor zowel netwerk- als toepassingsgegevens.

• Voer een 'what-if'-analyse uit op uw netwerk en toepassingen.

• Uitzonderingsrapportage uitvoeren voor capaciteitsproblemen.

• Bepaal de overheadkosten voor netwerkbeheer voor alle voorgestelde of potentiële netwerkbeheerservices.

• Analyseer de capaciteitsinformatie.

• Periodiek capaciteitsinformatie voor zowel netwerk- als toepassingen, evenals baseline en uitzonderingen, evalueren.

• Upgrade- of afstemprocedures laten instellen om capaciteitsproblemen op zowel reactieve als langetermijnbasis aan te pakken.

Indicatoren voor prestatiebeheer

Prestatie-indicatoren bieden het mechanisme waarmee een organisatie kritische succesfactoren kan meten. Prestatie-indicatoren voor prestatieplanning zijn onder meer:

• Documenteer de bedrijfsdoelstellingen van netwerkbeheer. Dit kan een formeel concept van activiteiten voor netwerkbeheer zijn of een minder formele verklaring van de vereiste kenmerken en doelstellingen.

• Maak gedetailleerde en meetbare doelstellingen voor het serviceniveau.

• Verstrek documentatie van de overeenkomsten inzake het serviceniveau met grafieken of diagrammen die het succes of falen van de manier waarop deze overeenkomsten in de loop van de tijd worden nageleefd, aantonen.

• Verzamel een lijst van de variabelen voor de basislijn, zoals polling interval, netwerkbeheer overhead opgelopen, mogelijke trigger drempels, of de variabele wordt gebruikt als een trigger voor een val, en trending analyse gebruikt tegen elke variabele.

• Een periodieke vergadering houden waarin de analyse van de basislijn en trends wordt beoordeeld.

• Zorg voor een gedocumenteerde what-if analysemethode. Dit moet modellering en verificatie omvatten, indien van toepassing.

• Wanneer de drempelwaarden worden overschreden, ontwikkelt u documentatie over de methodologie die wordt gebruikt om de netwerkmiddelen te verhogen. Een item om te documenteren is de tijdlijn die nodig is om extra WAN-bandbreedte en een kostentabel in te voeren.

processtroom voor prestatiebeheer

Deze stappen bieden een processtroom op hoog niveau voor prestatiebeheer:

1. Ontwikkelen van een Network Management Concept of Operations

   1. De vereiste functies definiëren: services, schaalbaarheid en beschikbaarheidsdoelstellingen

   2. Doelstellingen voor beschikbaarheid en netwerkbeheer definiëren

   3. SLA's en statistieken voor prestaties definiëren

   4. SLA's definiëren

2. Prestaties meten

   1. Netwerkbasisgegevens verzamelen

   2. Beschikbaarheid meten

   3. Reactietijd meten

   4. meetnauwkeurigheid

   5. Gebruik meten

   6. capaciteitsplanning

3. Een proactieve foutanalyse uitvoeren

   1. Drempelwaarden gebruiken voor proactief foutbeheer

   2. Implementatie van netwerkbeheer

   3. Netwerkbewerkingsstatistieken

Ontwikkelen van een Network Management Concept of Operations

Voordat u de gedetailleerde prestatie- en capaciteitsvariabelen voor een netwerk definieert, moet u kijken naar het algemene operationele concept voor netwerkbeheer binnen uw organisatie. Wanneer u dit algemene concept definieert, biedt het een zakelijke basis waarop u nauwkeurige definities van de gewenste functies in uw netwerk kunt bouwen. Als u er niet in slaagt om een operationeel concept voor netwerkbeheer te ontwikkelen, kan dit leiden tot een gebrek aan doelen of doelen die voortdurend veranderen als gevolg van de eisen van de klant.

Normaal gesproken produceer je het netwerkbeheerconcept als de eerste stap in de systeemdefinitiefase van het netwerkbeheerprogramma. Het doel is om de algehele gewenste systeemkenmerken te beschrijven vanuit een operationeel standpunt. Het gebruik van dit document is om de algemene zakelijke (niet-kwantitatieve) doelen van netwerkactiviteiten, engineering, ontwerp, andere bedrijfseenheden en de eindgebruikers te coördineren. De focus van dit document ligt op het vormen van de operationele planningsactiviteiten op lange termijn voor netwerkbeheer en -exploitatie. Het biedt ook richtsnoeren voor de ontwikkeling van alle latere definitiedocumentatie, zoals overeenkomsten inzake het dienstverleningsniveau. Deze eerste set definities kan zich uiteraard niet te beperkt richten op het beheer van specifieke netwerkproblemen, maar op die items die het belang benadrukken voor de algehele organisatie en in relatie tot de kosten die ook moeten worden beheerd. Enkele doelstellingen zijn:

• Identificeer de kenmerken die essentieel zijn voor een efficiënt gebruik van de netwerkinfrastructuur.

• Identificeer de services/toepassingen die het netwerk ondersteunt.

• Start end-to-end servicebeheer.

• Op prestaties gebaseerde statistieken initiëren om de algehele service te verbeteren.

• Verzamelen en verspreiden van performance management informatie.

• Ondersteuning van strategische evaluatie van het netwerk met feedback van gebruikers.

Met andere woorden, het netwerkmanagementconcept van operations moet zich richten op de algemene organisatiedoelen en uw filosofie om die doelen te bereiken. De primaire ingrediënten bestaan uit de definities van het hogere niveau van de missie, de missiedoelstellingen, de systeemdoelen, de betrokkenheid van de organisatie en de algemene operationele filosofie.

Als netwerkbeheerder bent u in de positie om vaak inconsistente prestatieverwachtingen van uw gebruikers te verenigen. Als de primaire vereiste voor het netwerk bijvoorbeeld de overdracht van grote bestanden van de ene locatie naar de andere is, wilt u zich richten op een hoge doorvoer en minder op de responstijden van interactieve gebruikers. Zorg ervoor dat u uw weergave van prestaties niet beperkt, tenzij u verschillende problemen overweegt. Wanneer u bijvoorbeeld een netwerk test, kijkt u naar de laadniveaus die worden gebruikt. De belasting is vaak gebaseerd op zeer kleine pakketten en de doorvoer op zeer grote pakketten. Beide prestatietests kunnen een zeer positief beeld opleveren, maar op basis van uw netwerkverkeersbelasting geven de tests mogelijk geen echt beeld van de prestaties. Bestudeer de netwerkprestaties onder zoveel mogelijk werklastomstandigheden en de prestaties gedocumenteerd.

Hoewel veel netwerkbeheerorganisaties effectieve alarmtechnieken hebben om technici op de hoogte te stellen van een apparaatfout, is het veel moeilijker om een beoordelingsproces voor de end-to-end toepassingsprestaties te definiëren en te implementeren. Daarom, terwijl het Network Operations Center (NOC) snel kan reageren op een neergehaalde router of switch, kunnen de netwerkomstandigheden die de netwerkprestaties kunnen ondermijnen en de perceptie van de gebruiker beïnvloeden gemakkelijk onopgemerkt blijven totdat die perceptie negatief wordt. Hoe moeilijk ook, dit tweede proces kan enorm veel voordeel opleveren voor zowel de bedrijfsorganisatie als het netwerkbeheer.

Zorg er tot slot voor dat u geen onrealistische verwachtingen creëert over uw netwerkprestaties. Onrealistische verwachtingen worden meestal gecreëerd wanneer u de details van netwerkprotocollen of de toepassingen verkeerd begrijpt. Vaak zijn slechte prestaties niet de schuld van het netwerk, maar eerder een gevolg van een slecht applicatieontwerp. De enige manier om de prestaties van toepassingen te documenteren en te meten, is door een basislijn van de netwerkprestaties te hebben voordat de toepassing wordt geïnstalleerd.

De vereiste functies definiëren: services, schaalbaarheid en beschikbaarheidsdoelstellingen

De eerste stap van prestatiebeheer, continue capaciteitsplanning en netwerkontwerp is het definiëren van de vereiste functies en/of services. Deze stap vereist dat u inzicht hebt in toepassingen, basisverkeersstromen, gebruikers- en siteaantallen en vereiste netwerkservices. Het eerste gebruik van deze informatie is het bepalen van de kritikaliteit van de toepassing voor de organisatiedoelen. U kunt deze informatie ook toepassen om een kennisbank te maken voor gebruik in het logische ontwerp om bandbreedte, interface, connectiviteit, configuratie en fysieke apparaatvereisten te begrijpen. Met deze eerste stap kunnen uw netwerkarchitecten een model van uw netwerk maken.

Schaalbaarheidsdoelstellingen voor oplossingen maken om netwerktechnici te helpen netwerken te ontwerpen die voldoen aan toekomstige groeivereisten en ervoor te zorgen dat voorgestelde ontwerpen geen beperkte middelen ervaren als gevolg van groei of uitbreiding van het netwerk. Beperkingen van middelen kunnen zijn:

• Totaal verkeer

• volume

• Aantal routes

• Aantal virtuele circuits

• Buurttellingen

• Uitzenddomeinen

• Doorvoer van medisch hulpmiddel

• Mediacapaciteit

Netwerkplanners moeten de vereiste levensduur van het ontwerp, verwachte uitbreidingen of sites bepalen die nodig zijn gedurende de levensduur van het ontwerp, het volume van nieuwe gebruikers en het verwachte verkeersvolume of de verwachte verandering. Dit plan helpt ervoor te zorgen dat de voorgestelde oplossing voldoet aan de groeivereisten gedurende de verwachte levensduur van het ontwerp.

Wanneer u de schaalbaarheid van oplossingen niet onderzoekt, bent u mogelijk gedwongen om grote reactieve ontwerpwijzigingen door te voeren. Deze ontwerpwijziging kan extra hiërarchie, media-upgrades of hardware-upgrades omvatten. In organisaties die afhankelijk zijn van vrij nauwkeurige budgetcycli voor grote hardwareaankopen, kunnen deze veranderingen een belangrijke remmer zijn van het algehele succes. In termen van beschikbaarheid kunnen netwerken onverwachte beperkingen van middelen ervaren die perioden van niet-beschikbaarheid en reactieve maatregelen veroorzaken.

Het testen van interoperabiliteit en interoperabiliteit kan van cruciaal belang zijn voor het succes van nieuwe implementaties van oplossingen. Interoperabiliteit kan verwijzen naar verschillende hardwareleveranciers of verschillende topologieën of oplossingen die tijdens of na een netwerkimplementatie moeten worden gecombineerd. Interoperabiliteitsproblemen kunnen hardwaresignalering via de protocolstack naar routing- of transportproblemen omvatten. Interoperabiliteitsproblemen kunnen zich voordoen vóór, tijdens of na de migratie van een netwerkoplossing. Interoperabiliteitsplanning moet connectiviteit tussen verschillende apparaten en topologische problemen omvatten die zich tijdens migraties kunnen voordoen.

Oplossingsvergelijking is de praktijk waarin u verschillende potentiële ontwerpen vergelijkt met andere oplossingsvereiste praktijken. Deze praktijk helpt ervoor te zorgen dat de oplossing het beste past bij een bepaalde omgeving en dat persoonlijke vooringenomenheid het ontwerpproces niet aanstuurt. Vergelijking kan verschillende factoren omvatten, zoals kosten, veerkracht, beschikbaarheid, risico, interoperabiliteit, beheerbaarheid, schaalbaarheid en prestaties. Al deze factoren kunnen een groot effect hebben op de algehele beschikbaarheid van het netwerk zodra het ontwerp is geïmplementeerd. U kunt ook media, hiërarchie, redundantie, routeringsprotocollen en vergelijkbare mogelijkheden vergelijken. Maak een grafiek met factoren op de X-as en potentiële oplossingen op de Y-as om oplossingsvergelijkingen samen te vatten. Gedetailleerde oplossingsvergelijking in een laboratoriumomgeving helpt ook om nieuwe oplossingen en functies objectief te onderzoeken in relatie tot de verschillende vergelijkingsfactoren.

Als onderdeel van het netwerkbeheerconcept is het essentieel om de doelen voor het netwerk en de ondersteunde services te definiëren op een manier die alle gebruikers kunnen begrijpen. De activiteiten die volgen op de ontwikkeling van het operationele concept worden sterk beïnvloed door de kwaliteit van dat document.

Dit zijn de standaard prestatiedoelen:

• Responstijd

• gebruik

• doorvoer

• Capaciteit (maximale doorvoersnelheid)

Hoewel deze metingen misschien triviaal zijn voor een eenvoudig LAN, kunnen ze erg moeilijk zijn op een geschakeld campusnetwerk of een bedrijfsnetwerk van meerdere leveranciers. Wanneer u een goed doordacht concept van het operatieplan gebruikt, wordt elk van de prestatiedoelen op een meetbare manier gedefinieerd. De minimale responstijd voor toepassing "x" is bijvoorbeeld 500 ms of minder tijdens piekuren. Dit definieert de informatie om de variabele te identificeren, de manier om deze te meten en de periode van de dag waarop de netwerkbeheertoepassing zich moet concentreren.

Doelstellingen voor beschikbaarheid en netwerkbeheer definiëren

Beschikbaarheidsdoelstellingen bepalen het niveau van de service- of serviceniveauvereisten voor een netwerkservice. Dit helpt ervoor te zorgen dat de oplossing voldoet aan de vereisten voor eindbeschikbaarheid. Definieer verschillende serviceklassen voor een bepaalde organisatie en specificeer netwerkvereisten voor elke klasse die geschikt zijn voor de beschikbaarheidsvereiste. Verschillende delen van het netwerk kunnen ook verschillende niveaus van beschikbaarheid vereisen. Voor een hogere beschikbaarheidsdoelstelling kunnen meer redundantie- en ondersteuningsprocedures nodig zijn. Wanneer u een beschikbaarheidsdoelstelling voor een bepaalde netwerkservice definieert en de beschikbaarheid meet, kan uw netwerkorganisatie de componenten en serviceniveaus begrijpen die vereist zijn om de verwachte SLA's te behalen.

Definieer beheersdoelstellingen om ervoor te zorgen dat het algehele netwerkbeheer niet aan beheerfunctionaliteit ontbreekt. Om beheersdoelstellingen te kunnen stellen, moet u het ondersteuningsproces en de bijbehorende netwerkbeheertools voor uw organisatie begrijpen. Beheersdoelstellingen moeten onder meer betrekking hebben op de kennis van hoe nieuwe oplossingen in het huidige ondersteunings- en gereedschapsmodel passen, met verwijzingen naar mogelijke verschillen of nieuwe vereisten. Dit is van cruciaal belang voor de beschikbaarheid van het netwerk, omdat de mogelijkheid om nieuwe oplossingen te ondersteunen van het grootste belang is voor het succes van de implementatie en om de beschikbaarheidsdoelen te behalen.

Beheersbaarheidsdoelstellingen moeten alle belangrijke informatie over MIB's of netwerkinstrumenten aan het licht brengen die nodig is om een potentieel netwerk te ondersteunen, opleiding die nodig is om de nieuwe netwerkdienst te ondersteunen, personeelsmodellen voor de nieuwe dienst en eventuele andere ondersteuningsvereisten. Vaak wordt deze informatie niet ontdekt voordat deze wordt geïmplementeerd en heeft de algehele beschikbaarheid te lijden onder het gebrek aan middelen die zijn toegewezen om het nieuwe netwerkontwerp te ondersteunen.

SLA's en statistieken voor prestaties definiëren

Prestatie-SLA's en -statistieken helpen bij het definiëren en meten van de prestaties van nieuwe netwerkoplossingen om ervoor te zorgen dat deze aan de prestatievereisten voldoen. De prestaties van de voorgestelde oplossing kunnen worden gemeten met behulp van tools voor prestatiemonitoring of met een eenvoudige ping over de voorgestelde netwerkinfrastructuur. De SLA's voor prestaties moeten het gemiddelde verwachte verkeersvolume, het piekvolume van het verkeer, de gemiddelde responstijd en de maximaal toegestane responstijd bevatten. Deze informatie kan vervolgens later in de sectie voor de validatie van de oplossing worden gebruikt en helpt uiteindelijk bij het bepalen van de vereiste prestaties en beschikbaarheid van het netwerk.

SLA's definiëren

Een belangrijk aspect van netwerkontwerp is wanneer u de service voor gebruikers of klanten definieert. Ondernemingen noemen deze service level agreements, terwijl serviceproviders het service level management noemen. Beheer op serviceniveau omvat doorgaans definities voor soorten problemen en de ernst en verantwoordelijkheden van de helpdesk, zoals het doorverwijspad en de tijd vóór doorverwijzing op elk ondersteuningsniveau, de tijd die nodig is om aan het probleem te beginnen en de tijd die nodig is om doelen te sluiten op basis van prioriteit. Andere belangrijke factoren zijn welke service wordt geboden op het gebied van capaciteitsplanning, proactief storingsbeheer, wijzigingsbeheermeldingen, drempels, upgradecriteria en hardwarevervanging.

Wanneer organisaties serviceniveaus niet van tevoren definiëren, wordt het moeilijk om de bronvereisten die op een later tijdstip zijn vastgesteld, te verbeteren of te verkrijgen. Het wordt ook moeilijk om te begrijpen welke bronnen moeten worden toegevoegd om het netwerk te ondersteunen. In veel gevallen worden deze middelen pas toegepast nadat problemen zijn ontdekt.

Prestaties meten

Performance management is een overkoepelende term die de configuratie en meting van verschillende prestatiegebieden omvat. In deze sectie worden deze zes concepten van prestatiemanagement beschreven:

• Netwerkbasisgegevens verzamelen

• Beschikbaarheid meten

• Reactietijd meten

• meetnauwkeurigheid

• Gebruik meten

• capaciteitsplanning

Netwerkbasisgegevens verzamelen

De meeste bedrijfsintranetten hebben voldoende bandbreedte. Zonder voldoende gegevens kunt u echter mogelijk niet uitsluiten dat netwerkcongestie bijdraagt aan slechte toepassingsprestaties. Een van de aanwijzingen voor congestie of fouten is of de slechte prestaties intermitterend of afhankelijk van het tijdstip van de dag zijn. Een voorbeeld hiervan is wanneer de prestaties laat in de avond voldoende zijn, maar 's ochtends en tijdens de piekuren erg traag.

Zodra u het netwerkbeheerconcept van de activiteiten hebt gedefinieerd en de benodigde implementatiegegevens hebt gedefinieerd, is het noodzakelijk om deze gegevens in de loop van de tijd te verzamelen. Dit type verzameling vormt de basis voor de basislijn van het netwerk.

Voer een basislijn van het huidige netwerk uit voorafgaand aan de implementatie van een nieuwe oplossing (toepassing of IOS-wijziging) en na de implementatie om de verwachtingen voor de nieuwe oplossing te meten. Deze basislijn helpt te bepalen of de oplossing voldoet aan de prestatie- en beschikbaarheidsdoelstellingen en de benchmarkcapaciteit. Een standaard basisrapport van de router/switch bevat capaciteitsproblemen met betrekking tot de processor, het geheugenbeheer, het bufferbeheer, het gebruik van links/media en de doorvoer. Er zijn andere soorten basisgegevens die u ook kunt opnemen, op basis van de gedefinieerde doelstellingen in het concept van bewerkingen. Een beschikbaarheidsbaseline toont bijvoorbeeld een verhoogde stabiliteit/beschikbaarheid van de netwerkomgeving. Voer een basisvergelijking uit tussen oude en nieuwe omgevingen om de vereisten voor de oplossing te controleren.

Een andere gespecialiseerde basislijn is de basislijn van de toepassing, die waardevol is wanneer u netwerkvereisten voor toepassingen ontwikkelt. Deze informatie kan worden gebruikt voor facturerings- en/of budgetteringsdoeleinden in de upgradecyclus. Baselines van toepassingen kunnen ook belangrijk zijn op het gebied van beschikbaarheid van toepassingen in relatie tot voorkeursservices of servicekwaliteiten per toepassing. Basisinformatie over toepassingen bestaat voornamelijk uit bandbreedte die door toepassingen per tijdsperiode wordt gebruikt. Sommige toepassingen voor netwerkbeheer kunnen ook de prestaties van toepassingen baseren. Een uitsplitsing van het verkeerstype (Telnet of FTP) is ook belangrijk voor de planning. In sommige organisaties worden meer kritische gebieden van het netwerk met beperkte middelen gecontroleerd op toppraters. De netwerkbeheerders kunnen deze informatie gebruiken om het netwerk te budgetteren, plannen of afstemmen. Wanneer u het netwerk afstemt, kunt u de servicekwaliteit of wachtrijparameters voor de netwerkservice of -toepassing wijzigen.

Beschikbaarheid meten

Een van de belangrijkste metrics die door netwerkbeheerders wordt gebruikt, is beschikbaarheid. Beschikbaarheid is de tijd waarvoor een netwerksysteem of -toepassing beschikbaar is voor een gebruiker. Vanuit netwerkperspectief vertegenwoordigt beschikbaarheid de betrouwbaarheid van de afzonderlijke componenten in een netwerk.

Om de beschikbaarheid te meten, kunt u bijvoorbeeld de telefoongesprekken van de helpdesk coördineren met de statistieken die zijn verzameld van de beheerde apparaten. Beschikbaarheidstools kunnen echter niet alle redenen voor een storing bepalen.

Netwerkredundantie is een andere factor om te overwegen wanneer u de beschikbaarheid meet. Verlies van redundantie duidt op achteruitgang van de service in plaats van totale netwerkuitval. Het resultaat kan een langzamere responstijd en een verlies van gegevens zijn als gevolg van gedropte pakketten. Het is ook mogelijk dat de resultaten worden weergegeven in de andere gebieden van prestatiemeting, zoals gebruik en responstijd.

Tot slot, als u levert tegen een SLA, moet u rekening houden met geplande uitval. Deze uitval kan het gevolg zijn van verhuizingen, toevoegingen en wijzigingen, het stilleggen van installaties of andere gebeurtenissen die u misschien niet wilt laten melden. Dit is niet alleen een moeilijke taak, maar kan ook een handmatige taak zijn.

Reactietijd meten

De responstijd van het netwerk is de tijd die het verkeer nodig heeft om tussen twee punten te reizen. Responstijden die langzamer zijn dan normaal, gezien door een basislijnvergelijking of die een drempel overschrijden, kunnen wijzen op congestie of een netwerkfout.

Responstijd is de beste maatstaf voor het gebruik van het klantennetwerk en kan u helpen de effectiviteit van uw netwerk te meten. Ongeacht wat de bron van de trage reactie is, gebruikers raken gefrustreerd als gevolg van vertraagd verkeer. In gedistribueerde netwerken hebben veel factoren invloed op de responstijd, zoals:

• Netwerkcongestie

• Minder dan gewenste route naar bestemming (of helemaal geen route)

• Ondermaatse netwerkapparaten

• Netwerkfouten zoals een broadcast storm

• Ruis- of CRC-fouten

In netwerken die gebruikmaken van QoS-gerelateerde wachtrijen, is het meten van de responstijd belangrijk om te bepalen of de juiste soorten verkeer zich zoals verwacht door het netwerk verplaatsen. Wanneer u bijvoorbeeld spraakverkeer via IP-netwerken implementeert, moeten spraakpakketten op tijd en in een constant tempo worden geleverd om een goede spraakkwaliteit te behouden. U kunt verkeer genereren dat is geclassificeerd als spraakverkeer om de responstijd van het verkeer te meten zoals het voor gebruikers wordt weergegeven.

U kunt de responstijd meten om de gevechten tussen toepassingsservers en netwerkbeheerders te helpen oplossen. Netwerkbeheerders worden vaak schuldig geacht wanneer een toepassing of server traag lijkt te zijn. De netwerkbeheerder moet bewijzen dat het netwerk niet het probleem is. Het verzamelen van gegevens over de responstijd is een onbetwistbaar middel om te bewijzen of te weerleggen dat het netwerk de bron is van problemen met toepassingen.

Waar mogelijk moet u de responstijd meten zoals deze voor gebruikers lijkt. Een gebruiker ziet de reactie als de tijd vanaf het moment dat ze op Enter drukken of op een knop klikken totdat het scherm wordt weergegeven. Deze verstreken tijd omvat de tijd die nodig is voor elk netwerkapparaat, het werkstation van de gebruiker en de bestemmingsserver om het verkeer te verwerken.

Helaas is het meten op dit niveau bijna onmogelijk vanwege het aantal gebruikers en het gebrek aan hulpmiddelen. Wanneer u de responstijd van de gebruiker en de server opneemt, biedt dit bovendien weinig waarde wanneer u toekomstige netwerkgroei of problemen met het netwerk vaststelt.

U kunt de netwerkapparaten en servers gebruiken om de responstijd te meten. U kunt ook tools zoals ICMP gebruiken om transacties te meten, hoewel er geen rekening wordt gehouden met eventuele vertragingen die in een systeem zijn geïntroduceerd terwijl de bovenste lagen het verwerken. Deze aanpak lost het probleem van netwerkprestatiekennis op.

Op een simplistisch niveau kunt u de respons op pings van het netwerkbeheerstation naar belangrijke punten in het netwerk timen, zoals een mainframe-interface, het eindpunt van een serviceproviderverbinding of belangrijke IP-adressen van gebruikers, om de responstijd te meten. Het probleem met deze methode is dat deze niet nauwkeurig de perceptie van de responstijd van de gebruiker weergeeft tussen hun machine en de bestemmingsmachine. Het verzamelt eenvoudig informatie en rapporteert de responstijd vanuit het perspectief van het netwerkbeheerstation. Deze methode maskeert ook problemen met de responstijd op hop-by-hop-basis in het hele netwerk.

Een alternatief voor server-centric polling is om de inspanning dichter bij de bron en de bestemming die u wilt simuleren voor meting te verdelen. Gebruik pollers voor gedistribueerd netwerkbeheer en implementeer de Cisco IOS Service Assurance Agent (SAA)-functionaliteit. U kunt SAA inschakelen op routers om de responstijd te meten tussen een router en een bestemmingsapparaat zoals een server of een andere router. U kunt ook een TCP- of UDP-poort opgeven, waardoor verkeer wordt doorgestuurd en geleid op dezelfde manier als het verkeer dat wordt gesimuleerd.

Met de integratie van spraak, video en gegevens op multiservicenetwerken implementeren klanten QoS-prioritering in hun netwerk. Eenvoudige ICMP- of UDP-metingen geven de responstijd niet nauwkeurig weer, omdat verschillende toepassingen verschillende prioriteiten krijgen. Bij tag switching kan de routering van het verkeer ook variëren op basis van het toepassingstype in een specifiek pakket. Dus een ICMP-ping kan verschillende prioriteiten krijgen in hoe elke router ermee omgaat en kan verschillende, minder efficiënte routes ontvangen.

In dit geval is de enige manier om de responstijd te meten het genereren van verkeer dat lijkt op de specifieke toepassing of technologie van belang. Dit dwingt de netwerkapparaten om het verkeer af te handelen zoals ze zouden doen voor het echte verkeer. U kunt dit niveau mogelijk bereiken met SAA of door het gebruik van toepassingsbewuste sondes van derden.

meetnauwkeurigheid

Nauwkeurigheid is de maat van het interfaceverkeer dat niet resulteert in fouten en kan worden uitgedrukt in termen van een percentage dat het succespercentage vergelijkt met de totale pakketsnelheid over een periode. Je moet eerst het foutenpercentage meten. Bijvoorbeeld, als twee van elke 100 pakketten resulteren in fouten, zou het foutenpercentage 2% zijn en de nauwkeurigheid 98%.

Met eerdere netwerktechnologieën, met name in het brede gebied, was een bepaald foutenniveau aanvaardbaar. Met hogesnelheidsnetwerken en hedendaagse WAN-diensten is de transmissie echter aanzienlijk nauwkeuriger en liggen de foutenpercentages dicht bij nul, tenzij er een echt probleem is. Enkele veel voorkomende oorzaken van interfacefouten zijn:

• Bedrading buiten specificatie

• Elektrische interferentie

• Defecte hardware of software

Gebruik een lagere nauwkeurigheidssnelheid om een nader onderzoek te starten. U kunt ontdekken dat een bepaalde interface problemen vertoont en besluit dat de fouten aanvaardbaar zijn. In dit geval moet u de nauwkeurigheidsdrempel voor deze interface aanpassen om weer te geven waar het foutenpercentage onaanvaardbaar is. Het onaanvaardbare foutenpercentage zou in een eerdere uitgangssituatie kunnen zijn gemeld.

De in deze tabel beschreven variabelen worden gebruikt in de formules voor nauwkeurigheid en foutenpercentage:

notatie	Beschrijving
ΔifInErrors	De delta (of het verschil) tussen twee pollcycli die het object snmp ifInErrors verzamelen, dat het aantal inkomende pakketten met een fout weergeeft.
ΔifInUcastPkts	De delta tussen twee pollcycli die het object snmp ifInUcastPots verzamelen, dat het aantal inkomende unicastpakketten weergeeft.
ΔifInNUcastPkts	De delta tussen de twee pollcycli die het object snmp ifInNUcastPots verzamelen, dat het aantal inkomende niet-unicastpakketten (multicast en broadcast) vertegenwoordigt.

De formule voor het foutenpercentage wordt meestal uitgedrukt als een percentage:

Foutpercentage = (ΔifInErrors) *100

---------------------------

(ΔifInUcastPkts + (ΔifInNUcastPkts )

Merk op dat uitgaande fouten niet in aanmerking worden genomen in de formules voor foutenpercentage en nauwkeurigheid. Dat komt omdat een apparaat nooit bewust pakketten met fouten op het netwerk mag plaatsen en de uitgaande interface-foutenpercentages nooit mogen toenemen. Vandaar dat inbound verkeer en fouten de enige maatregelen zijn die van belang zijn voor interfacefouten en nauwkeurigheid.

De formule voor nauwkeurigheid neemt het foutenpercentage en trekt het af van 100 (opnieuw in de vorm van een percentage):

Nauwkeurigheid = 100 - (ΔifInErrors) *100

------------------------------

(ΔifInUcastPkts + (ΔifInNUcastPkts)

Deze formules geven fouten en nauwkeurigheid weer in termen van de generieke tellers van de MIB II-interface (RFC 2233). Het resultaat wordt uitgedrukt in termen van een percentage dat fouten vergelijkt met het totaal aantal pakketten dat wordt gezien en verzonden. Het resulterende foutenpercentage wordt afgetrokken van 100, wat de nauwkeurigheidspercentage oplevert. Een nauwkeurigheid van 100% is perfect.

Omdat de MIB II-variabelen worden opgeslagen als tellers, moet u twee poll-cycli nemen en het verschil tussen de twee berekenen (vandaar de Delta die in de vergelijking wordt gebruikt).

Gebruik meten

Het gebruik meet het gebruik van een bepaalde hulpbron in de tijd. De maatregel wordt meestal uitgedrukt in de vorm van een percentage waarin het gebruik van een middel wordt vergeleken met de maximale operationele capaciteit. Door middel van gebruiksmaatregelen kunt u congestie (of potentiële congestie) in het hele netwerk identificeren. U kunt ook onderbenutte bronnen identificeren.

Gebruik is de belangrijkste maat om te bepalen hoe vol de netwerkleidingen (links) zijn. Meet CPU-, interface-, wachtrijen- en andere systeemgerelateerde capaciteitsmetingen om te bepalen in welke mate netwerksysteembronnen worden verbruikt.

Een hoog gebruik is niet per se slecht. Lage benutting kan wijzen op verkeersstromen op onverwachte plaatsen. Naarmate lijnen te veel worden gebruikt, kunnen de effecten aanzienlijk worden. Overmatig gebruik treedt op wanneer er meer verkeer in de wachtrij staat om over een interface te gaan dan het aankan. Plotselinge sprongen in het gebruik van bronnen kunnen wijzen op een foutconditie.

Als een interface overbelast raakt, moet het netwerkapparaat het pakket opslaan in een wachtrij of weggooien. Als een router probeert een pakket in een volledige wachtrij op te slaan, wordt het pakket verwijderd. Gedropte pakketten ontstaan wanneer het verkeer wordt doorgestuurd van een snelle interface naar een langzamere interface. Dit wordt aangegeven in de formule Q = u / (1-u) waar u gebruik is en Q de gemiddelde wachtrijdiepte is (willekeurig verkeer verondersteld). Dus hoge benuttingsniveaus op links resulteren in hoge gemiddelde wachtrijdiepten, wat voorspelbare latentie is als u de pakketgrootte kent. Sommige netwerkrapporterende leveranciers geven aan dat u minder bandbreedte kunt bestellen en minder voor uw WAN kunt betalen. Latentie-implicaties verschijnen echter wanneer u WAN-koppelingen uitvoert met een gebruik van 95%. Aangezien netwerken worden gemigreerd naar VoIP, moeten de netwerkbeheerders mogelijk hun beleid wijzigen en WAN-koppelingen uitvoeren met een benuttingsgraad van ongeveer 50%.

Wanneer een pakket wordt gedropt, kan het hogere laagprotocol een herverzending van het pakket forceren. Als meerdere pakketten worden verwijderd, kan overmatig doorgaand verkeer ontstaan. Dit type reactie kan leiden tot back-ups op apparaten verderop in de lijn. Om dit probleem op te lossen, kunt u verschillende drempelwaarden instellen.

De belangrijkste maatstaf voor netwerkgebruik is het gebruik van de interface. Gebruik de in deze tabel beschreven formules op basis van de vraag of de verbinding die u meet half-duplex of full-duplex is:

notatie	Beschrijving
ΔifInOctets	De delta (of het verschil) tussen twee pollcycli die het object snmp ifInOctets verzamelen, dat het aantal inkomende octetten van verkeer vertegenwoordigt.
ΔifOutOctets	De delta tussen twee poll cycli die het verzamelen van de snmp ifOutOctets object dat het aantal uitgaande octetten van het verkeer vertegenwoordigt.
ifSpeed	De snelheid van de interface zoals gerapporteerd in het snmp ifSpeed-object. Merk op dat ifSpeed mogelijk niet nauwkeurig de snelheid van een WAN-interface weergeeft.

Gedeelde LAN-verbindingen hebben de neiging half-duplex te zijn, vooral omdat contentiedetectie vereist dat een apparaat luistert voordat het verzendt. WAN-verbindingen zijn meestal full-duplex omdat de verbinding van punt tot punt is; beide apparaten kunnen tegelijkertijd verzenden en ontvangen, omdat ze weten dat er slechts één ander apparaat is dat de verbinding deelt.

Omdat de MIB II-variabelen worden opgeslagen als tellers, moet u twee poll-cycli nemen en het verschil tussen de twee berekenen (vandaar de Delta die in de vergelijking wordt gebruikt).

Gebruik deze formule voor het gebruik van de interface voor half-duplexmedia:

(ΔifInOctets + ΔifOutOctets) * 8 * 100

----------------------------------------

(aantal seconden in Δ) * ifSpeed

Voor full-duplexmedia is de berekening van het gebruik complexer. Met een volledige T-1 seriële verbinding is de lijnsnelheid bijvoorbeeld 1,544 Mbps. Dit betekent dat een T-1-interface zowel 1,544 Mbps kan ontvangen als verzenden voor een gecombineerde mogelijke bandbreedte van 3,088 Mbps.

Wanneer u de interfacebandbreedte voor full-duplexverbindingen berekent, kunt u deze formule gebruiken waarin u de grootste van de in- en uitwaarden neemt en een gebruikspercentage genereert:

max(ΔifInOctets, (ΔifOutOctets) * 8 * 100

------------------------------

(aantal seconden in Δ) * ifSpeed

Deze methode verbergt echter het gebruik van de richting die de minste waarde heeft en minder nauwkeurige resultaten oplevert. Een nauwkeurigere methode is om het input- en outputgebruik afzonderlijk te meten, zoals:

Input Utilization = ΔifInOctets *8 * 100

---------------------------

(aantal seconden in Δ) * ifSpeed

en

Uitvoergebruik = ΔifOutOctets *8 * 100

--------------------------

(aantal seconden in Δ) * ifSpeed

Hoewel deze formules enigszins vereenvoudigd zijn, houden ze geen rekening met overheadkosten in verband met een bepaald protocol. Er bestaan preciezere formules om de unieke aspecten van elk protocol aan te pakken. RFC 1757 bevat bijvoorbeeld formules voor Ethernet-gebruik die rekening houden met de overhead van pakketten. Het team voor hoge beschikbaarheid heeft echter vastgesteld dat de algemene formules die hier worden gepresenteerd in de meeste gevallen betrouwbaar kunnen worden gebruikt voor zowel LAN- als WAN-interfaces.

capaciteitsplanning

Zoals eerder vermeld, is capaciteitsplanning het proces waarin u de waarschijnlijke toekomstige behoeften aan netwerkbronnen bepaalt om een impact op prestaties of beschikbaarheid van bedrijfskritieke toepassingen te voorkomen. Zie het witboek Capaciteits- en prestatiebeheer: beste praktijken voor meer gedetailleerde informatie over dit onderwerp.

Een proactieve foutanalyse uitvoeren

Proactieve storingsanalyse is essentieel voor prestatiebeheer. Hetzelfde type gegevens dat wordt verzameld voor prestatiebeheer kan worden gebruikt voor proactieve foutanalyse. De timing en het gebruik van deze gegevens verschilt echter tussen proactief storingsbeheer en prestatiebeheer.

Proactief storingsbeheer is de manier waarop het ideale netwerkbeheersysteem de door u bepaalde doelen kan bereiken. De relatie met prestatiemanagement is via de basislijn en de gegevensvariabelen die u gebruikt. Proactief storingsbeheer integreert aangepaste gebeurtenissen, een gebeurteniscorrelatiemotor, probleemtickets en de statistische analyse van de basislijngegevens om fouten, prestaties en wijzigingsbeheer samen te voegen in een ideaal, effectief netwerkbeheersysteem.

Wanneer de peiling van de prestatiegegevens gewoonlijk om de 10, 15 of zelfs 30 minuten wordt uitgevoerd, moet de herkenning van een fouttoestand op een veel korter tijdsinterval plaatsvinden. Een methode van proactief storingsbeheer is door het gebruik van RMON-alarmen en gebeurtenisgroepen. U kunt drempelwaarden instellen op uw apparaten die niet worden gepolld door externe apparaten, zodat de drempelwaarden veel korter zijn. Een andere methode, die niet in dit document wordt behandeld, is door het gebruik van een gedistribueerd beheersysteem dat polling op lokaal niveau mogelijk maakt met aggregatie van gegevens bij een manager van managers.

Drempelwaarden gebruiken voor proactief foutbeheer

Thresholding is het proces waarbij u aandachtspunten in specifieke gegevensstromen definieert en gebeurtenissen genereert wanneer drempelwaarden worden geactiveerd. Gebruik uw netwerkprestatiegegevens om die drempelwaarden in te stellen.

Er zijn verschillende soorten drempels, waarvan sommige meer van toepassing zijn op bepaalde soorten gegevens. Drempelwaarden zijn alleen van toepassing op numerieke gegevens, dus zet tekstuele gegevens om in discrete numerieke waarden. Zelfs als u niet alle mogelijke tekstreeksen voor een object kent, kunt u nog steeds de "interessante" tekenreeksen opsommen en alle andere tekenreeksen aan een ingestelde waarde toewijzen.

Er zijn twee klassen van drempels voor de twee klassen van numerieke gegevens: continu en discreet. Continue drempelwaarden zijn van toepassing op continue of tijdreeksgegevens zoals gegevens die zijn opgeslagen in SNMP-tellers of -meters. Er gelden afzonderlijke drempelwaarden voor opgesomde objecten of voor afzonderlijke numerieke gegevens. Booleaanse objecten zijn opgesomde waarden met twee waarden: true of false. Discrete gegevens kunnen ook gebeurtenisgegevens worden genoemd omdat gebeurtenissen de overgang van de ene waarde naar de volgende markeren.

Continue drempelwaarden kunnen gebeurtenissen activeren wanneer het tijdreeksobject de opgegeven waarde van de drempelwaarde overschrijdt. De waarde van het object stijgt boven de drempelwaarde of daalt eronder. Het kan ook nuttig zijn om afzonderlijke stijgings- en dalingsdrempels vast te stellen. Deze techniek, bekend als een hysteresemechanisme, helpt het aantal gebeurtenissen dat uit deze gegevensklasse wordt gegenereerd, te verminderen. Het hysteresismechanisme werkt om het volume van gebeurtenissen te verminderen dat wordt gegenereerd door drempels op snel variërende tijdreeksgegevens. Dit mechanisme kan worden gebruikt met elke drempeltechniek op tijdreeksgegevens.

Het volume van gebeurtenissen wordt verminderd door een alarm dat wordt gegenereerd om de waarde van een object te volgen. Stijgende en dalende drempels worden toegewezen aan dit alarm. Het alarm wordt alleen geactiveerd wanneer de stijgende drempel wordt overschreden. Zodra deze drempel is overschreden, wordt er geen stijgend alarm meer gegenereerd totdat de dalende drempel is overschreden. En hetzelfde mechanisme voorkomt het genereren van dalende drempels totdat de stijgende drempel weer wordt overschreden. Dit mechanisme kan het aantal gebeurtenissen drastisch verminderen en elimineert niet de informatie die nodig is om te bepalen of er een fout bestaat.

Tijdreeksgegevens kunnen worden weergegeven als tellers, waarbij elk nieuw gegevenspunt wordt toegevoegd aan de som van de vorige gegevenspunten, of als een meter, waarbij de gegevens worden weergegeven als een snelheid over een tijdsinterval. Er zijn twee verschillende vormen van continue drempels die van toepassing zijn op elk gegevenstype: absolute continue drempels en relatieve continue drempels. Gebruik absolute continue drempels met meters en relatieve continue drempels met tellers.

Voer de volgende stappen uit om de drempelwaarden voor uw netwerk te bepalen:

1. Selecteer de objecten.

2. Selecteer de apparaten en interfaces.

3. Bepaal de drempelwaarden voor elk object of object/interfacetype.

4. Bepaal de ernst van de gebeurtenis die door elke drempelwaarde wordt gegenereerd.

Er is een behoorlijke hoeveelheid werk nodig om te bepalen welke drempels moeten worden gebruikt op welke objecten (en voor welke apparaten en interfaces). Gelukkig, als u een basislijn van prestatiegegevens hebt verzameld, hebt u al een aanzienlijke hoeveelheid van dat werk gedaan. Ook kunnen NSA en het programma voor hoge beschikbaarheid (HAS) aanbevelingen doen die u helpen objecten in te stellen en bereiken te maken. U moet deze aanbevelingen echter aanpassen aan uw specifieke netwerk.

Aangezien u prestatiegegevens voor het netwerk hebt verzameld, raadt het HAS-programma u aan uw interfaces te groeperen op categorieën. Dit vereenvoudigt het instellen van drempelwaarden omdat u mogelijk drempelwaarden moet bepalen voor het mediatype van elke categorie in plaats van voor elk apparaat en object op dat apparaat. U wilt bijvoorbeeld verschillende drempelwaarden instellen voor Ethernet- en FDDI-netwerken. Er wordt vaak gedacht dat u FDDI-netwerken kunt uitvoeren met een gebruik dat dichter bij 100% ligt dan bij een gedeeld Ethernet-segment. Full-duplex Ethernet kan echter veel dichter bij 100% gebruik worden uitgevoerd omdat ze niet onderhevig zijn aan botsingen. Misschien wilt u uw drempels voor botsingen heel laag instellen voor full-duplex links, omdat u nooit een botsing zou moeten zien.

U kunt ook rekening houden met de combinatie van het belang van de interface en de categorie / ernst van het drempeltype. Gebruik deze factoren om de prioriteit van het evenement te bepalen en daarmee het belang van het evenement en de aandacht van het personeel van de netwerkactiviteiten.

Het groeperen en categoriseren van netwerkapparaten en interfaces kan niet genoeg worden benadrukt. Hoe meer u kunt groeperen en categoriseren, hoe gemakkelijker u de drempelgebeurtenissen kunt integreren in uw netwerkbeheerplatform. Gebruik de basislijn als de belangrijkste bron voor deze informatie. Zie het witboek Capaciteits- en prestatiebeheer: beste praktijken voor meer informatie.

Implementatie van netwerkbeheer

De organisatie moet beschikken over een geïmplementeerd netwerkbeheersysteem dat in staat is de gedefinieerde drempelwaarden te detecteren en gedurende bepaalde perioden verslag uit te brengen over de waarden. Gebruik een RMON-netwerkbeheersysteem dat drempelwaardeberichten in een logbestand kan archiveren voor dagelijkse controle of een meer complete databaseoplossing waarmee kan worden gezocht naar drempelwaardeuitzonderingen voor een bepaalde parameter. De informatie moet permanent beschikbaar zijn voor het personeel en de beheerder van de netwerkactiviteiten. De implementatie van het netwerkbeheer moet de mogelijkheid omvatten om software-/hardwarecrashes of tracebacks, interfacebetrouwbaarheid, CPU, linkgebruik, wachtrij- of bufferfouten, uitzendvolume, carrierovergangen en interfaceresets te detecteren.

Statistieken netwerkbewerkingen

Een laatste gebied van proactief storingsbeheer dat overlapt met prestatiebeheer is de metriek van netwerkbewerkingen. Deze statistieken bieden waardevolle gegevens voor de verbetering van het foutbeheerproces. Deze statistieken moeten minimaal een uitsplitsing bevatten van alle problemen die zich tijdens een bepaalde periode hebben voorgedaan. De uitsplitsing dient informatie te bevatten zoals:

• Aantal problemen die zich voordoen per oproepprioriteit

• Minimale, maximale en gemiddelde sluitingstijd voor elke prioriteit

• Uitsplitsing van problemen naar type probleem (hardware, softwarecrash, configuratie, voeding, gebruikersfout)

• Uitsplitsing van de te sluiten tijd voor elk type probleem

• Beschikbaarheid per beschikbaarheidsgroep of SLA

• Hoe vaak u aan de SLA-vereisten hebt voldaan of deze hebt gemist

De helpdesk heeft vaak een rapportagesysteem met de mogelijkheid om statistieken of rapporten te genereren. Een andere manier om deze gegevens te verzamelen is het gebruik van een tool voor beschikbaarheidsmonitoring. Algemene statistieken moeten maandelijks beschikbaar worden gesteld. Procesverbetering op basis van de discussie moet worden geïmplementeerd om de vereisten voor gemiste serviceniveauovereenkomsten te verbeteren of om de manier waarop bepaalde probleemtypen worden behandeld te verbeteren.

Prestatiebeheerindicatoren

Prestatie-indicatoren bieden het mechanisme waarmee een organisatie kritieke succesfactoren meet.

Documenteer de bedrijfsdoelstellingen voor netwerkbeheer

Dit document kan een formeel concept van activiteiten voor netwerkbeheer zijn of een minder formele verklaring van de vereiste kenmerken en doelstellingen. Het document moet de netwerkbeheerder echter helpen bij het meten van het succes.

Dit document is de strategie voor netwerkbeheer van de organisatie en moet de algemene zakelijke (niet-kwantitatieve) doelen van netwerkactiviteiten, engineering, ontwerp, andere bedrijfseenheden en de eindgebruikers coördineren. Deze focus stelt de organisatie in staat om de langetermijnplanningsactiviteiten voor netwerkbeheer en -exploitatie te vormen, inclusief het budgetteringsproces. Het biedt ook richtlijnen voor de aanschaf van tools en het integratiepad dat nodig is om de netwerkbeheerdoelen, zoals SLA's, te bereiken.

Dit strategisch document kan zich niet te beperkt concentreren op het beheer van specifieke netwerkproblemen, maar op die punten die belangrijk zijn voor de algehele organisatie, waaronder begrotingskwesties. Voorbeeld:

• Maak een plan met haalbare doelen.

• Identificeer elke zakelijke service/toepassing waarvoor netwerkondersteuning nodig is.

• Identificeer de prestatiegerichte statistieken die nodig zijn om de service te meten.

• Plan de verzameling en verspreiding van de prestatiemetrische gegevens.

• Identificeer de ondersteuning die nodig is voor netwerkevaluatie en feedback van gebruikers.

• Beschikt over gedocumenteerde, gedetailleerde en meetbare doelstellingen voor het serviceniveau.

Documenteer de Service Level Agreements

Om de SLA's goed te documenteren, moet u de objectieve metrics voor het serviceniveau volledig definiëren. Deze documentatie moet voor de gebruikers beschikbaar zijn voor evaluatie. Het biedt de feedbacklus om ervoor te zorgen dat de netwerkbeheerorganisatie de variabelen blijft meten die nodig zijn om het niveau van de serviceovereenkomst te handhaven.

SLA's zijn "levende" documenten omdat de bedrijfsomgeving en het netwerk van nature dynamisch zijn. Wat vandaag werkt om een SLA te meten, kan morgen achterhaald zijn. Alleen wanneer ze een feedbacklus van gebruikers instellen en op die informatie reageren, kunnen netwerkbewerkingen de hoge beschikbaarheidsnummers handhaven die door de organisatie worden vereist.

Een lijst met variabelen voor de basislijn maken

Deze lijst bevat items zoals polling interval, netwerkbeheer overhead opgelopen, mogelijke trigger drempels, of de variabele wordt gebruikt als een trigger voor een val, en trending analyse gebruikt tegen elke variabele.

Deze variabelen zijn niet beperkt tot de statistieken die nodig zijn voor de hierboven genoemde doelstellingen op het niveau van de dienstverlening. Ze moeten minimaal deze variabelen bevatten: routergezondheid, routergezondheid, routeringsinformatie, technologiespecifieke gegevens, gebruik en switch. Deze variabelen worden periodiek gepolst en opgeslagen in een database. Rapporten kunnen vervolgens worden gegenereerd op basis van deze gegevens. Deze rapporten kunnen de netwerkbeheeractiviteiten en planningspersoneel op deze manieren helpen:

• Reactieve problemen kunnen vaak sneller worden opgelost met een historische database.

• Prestatierapportage en capaciteitsplanning vereisen dit soort gegevens.

• De doelstellingen van het serviceniveau kunnen daaraan worden afgemeten.

Bekijk de Baseline- en Trendanalyses

Het personeel van het netwerkbeheer moet vergaderingen houden om regelmatig specifieke verslagen door te nemen. Dit geeft extra feedback en een proactieve aanpak van mogelijke problemen in het netwerk.

Deze vergaderingen moeten zowel operationeel als planningspersoneel omvatten. Dit biedt de planners de mogelijkheid om operationele analyse van de baseline- en trendgegevens te ontvangen. Het plaatst ook het operationele personeel "in de lus" voor een deel van de planningsanalyse.

Een ander soort onderwerp dat in deze vergaderingen moet worden opgenomen, zijn de doelstellingen voor het serviceniveau. Bij het benaderen van objectieve drempels kan het personeel van het netwerkbeheer maatregelen nemen om te voorkomen dat een doelstelling wordt gemist en in sommige gevallen kunnen deze gegevens worden gebruikt als gedeeltelijke budgettaire rechtvaardiging. De gegevens kunnen laten zien waar de doelstellingen van het serviceniveau worden overschreden als er geen passende maatregelen worden genomen. Omdat deze doelstellingen zijn geïdentificeerd door zakelijke diensten en toepassingen, zijn ze ook gemakkelijker te rechtvaardigen op een financiële basis.

Voer deze beoordelingen om de twee weken uit en houd elke zes tot twaalf weken een meer grondige analytische vergadering. Deze bijeenkomsten stellen u in staat om zowel korte als lange termijn kwesties aan te pakken.

Documenteer een wat-als-analysemethode

Een what-if-analyse omvat modellering en verificatie van oplossingen. Voordat u een nieuwe oplossing aan het netwerk toevoegt (een nieuwe toepassing of een wijziging in de Cisco IOS-release), documenteert u enkele van de alternatieven.

De documentatie voor deze analyse omvat de belangrijkste vragen, de methodologie, gegevenssets en configuratiebestanden. Het belangrijkste punt is dat de wat-als-analyse een experiment is dat iemand anders zou moeten kunnen recreëren met de informatie die in het document wordt verstrekt.

Documenteer de methodologie die wordt gebruikt voor het verbeteren van de netwerkprestaties

Deze documentatie bevat extra WAN-bandbreedte en een kostentabel die de bandbreedte voor een bepaald type koppeling helpt te verhogen. Deze informatie helpt de organisatie te realiseren hoeveel tijd en geld het kost om de bandbreedte te vergroten. Formele documentatie stelt prestatie- en capaciteitsexperts in staat om te ontdekken hoe en wanneer de prestaties kunnen worden verhoogd, evenals de tijdlijn en kosten voor een dergelijke onderneming.

Herzie deze documentatie regelmatig, misschien als onderdeel van de evaluatie van de prestaties per kwartaal, om ervoor te zorgen dat deze up-to-date blijft.

Samenvatting

De enige manier om de doelen van het ideale netwerkbeheersysteem te bereiken, is door de componenten van prestatiebeheer actief in het systeem te integreren. Dit doel moet ook het gebruik omvatten van in een meldingssysteem gekoppelde maatstaven voor beschikbaarheid en responstijd wanneer drempelwaarden worden overschreden. Het zou ook het gebruik van een referentiewaarde voor capaciteitsplanning moeten omvatten die gekoppeld is aan een heuristisch model voor voorzieningen en rapportage van uitzonderingen. Het zou een ingebouwde modellering of simulatie-engine kunnen hebben waarmee het model in realtime kan worden bijgewerkt en een niveau van zowel planning als probleemoplossing kan bieden door middel van softwaresimulaties.

Hoewel veel van dit systeem een onmogelijk ideaal lijkt dat nooit zou kunnen worden bereikt, is elk van de componenten momenteel beschikbaar. Verder bestaan de tools om deze componenten te integreren ook in programma's zoals MicroMuse. We moeten blijven werken aan dit ideaal, omdat het vandaag realistischer is dan ooit.

Gerelateerde informatie

• Whitepapers over technologie met hoge beschikbaarheid
• Whitepaper over capaciteits- en prestatiebeheer
• Technische ondersteuning en documentatie – Cisco Systems