Prestatiebeheer: Whitepaper over beste praktijken

Inleiding

Prestatiebeheer omvat optimalisering van de responstijd van de netwerkdienst en beheer van de consistentie en kwaliteit van individuele en algemene netwerkdiensten. De belangrijkste dienst is de noodzaak om de responstijd van de gebruiker/toepassing te meten. Voor de meeste gebruikers is de responstijd de cruciale succesfactor. Deze variabele geeft de perceptie van netwerksucces aan zowel uw gebruikers als toepassingsbeheerders.

Achtergrondinformatie

Capaciteitsplanning is het proces waarmee u vereisten voor toekomstige netwerkbronnen bepaalt om een prestatie of een beschikbaarheidsimpact op zakelijk kritieke toepassingen te voorkomen. Op het gebied van capaciteitsplanning kan de netwerkbaseline (CPU, geheugen, buffers, in/uit octetten, enz.) de responstijd beïnvloeden. Houd er dan ook rekening mee dat prestatiekaarten vaak verband houden met capaciteit. In netwerken, is dit typisch bandbreedte en gegevens die in rijen moeten wachten alvorens het door het netwerk kan worden overgebracht. In spraaktoepassingen heeft deze wachttijd vrijwel zeker gevolgen voor gebruikers, omdat factoren als vertraging en jitter van invloed zijn op de kwaliteit van spraakoproepen.

Een ander belangrijk punt dat het prestatiebeheer bemoeilijkt is dat, hoewel hoge netwerkbeschikbaarheid van cruciaal belang is voor zowel grote ondernemingen als dienstverlenende netwerken, de neiging bestaat economische winst op korte termijn te behalen met het risico van (vaak onvoorziene) hogere kosten op lange termijn. Tijdens elke begrotingscyclus hebben de netwerkbeheerders en het personeel voor de uitvoering van projecten moeite om een evenwicht te vinden tussen prestatie en snelle uitvoering. Verder staan netwerkbeheerders voor uitdagingen zoals een snelle productontwikkeling om te kunnen voldoen aan smalle marktvensters, complexe technologieën, bedrijfsconsolidatie, concurrerende markten, ongeplande downtime, gebrek aan expertise en vaak ontoereikende instrumenten.

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

Een ideaal netwerkbeheersysteem omvat deze basisoperaties:

• informeert de exploitant over dreigende verslechtering van de prestaties.

• Biedt makkelijke alternatieve routing en werkronden wanneer de prestaties achteruitgaan of falen optreedt.

• Hier vindt u de gereedschappen om oorzaken van verslechtering of falen van de prestaties aan te duiden.

• Dient als het belangrijkste station voor netwerkveerkracht en overlevingsvermogen.

• Communiceert prestaties in real time.

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

• Gebruikersprestaties

• Toepassingsprestaties

• Capaciteitsplanning

• Proactief foutenbeheer

Het is belangrijk om op te merken dat met nieuwere toepassingen zoals spraak en video, prestaties de belangrijkste variabele voor succes zijn en als u geen consistente prestatie kunt bereiken, wordt de dienst beschouwd als van lage waarde en mislukt. In andere gevallen hebben gebruikers eenvoudigweg te lijden onder variabele prestaties met intermitterende applicatietijden die de productiviteit en gebruikerstevredenheid ondermijnen.

In dit document worden de belangrijkste kwesties op het gebied van prestatiemanagement beschreven, waaronder cruciale succesfactoren, belangrijke prestatie-indicatoren en een proceskaart op hoog niveau voor prestatiemanagement. Het behandelt ook de concepten van beschikbaarheid, responstijd, nauwkeurigheid, gebruik en capaciteitsplanning en omvat een korte discussie over de rol van proactieve foutanalyse binnen prestatiemanagement en het ideale netwerkbeheersysteem.

Belangrijke succesfactoren

Belangrijke succesfactoren identificeren de vereisten voor de implementatie van beste praktijken. Om als een kritieke succesfactor te kunnen worden aangemerkt, moet een proces of procedure de beschikbaarheid verbeteren of moet het ontbreken van de procedure de beschikbaarheid verminderen. Bovendien moet de doorslaggevende succesfactor meetbaar zijn, zodat de organisatie kan bepalen in hoeverre zij succesvol zijn.

Opmerking: Zie Prestatiebeheerindicatoren voor meer informatie.

Dit zijn de kritieke succesfactoren voor prestatiemanagement:

• Verzamel een basislijn voor zowel netwerk als toepassingsgegevens.

• Voer een wat-als analyse op uw netwerk en toepassingen uit.

• Uitzonderingsrapportage uitvoeren voor capaciteitsproblemen.

• Bepaal de overhead van het netwerkbeheer voor alle voorgestelde of potentiële netwerkbeheerdiensten.

• De capaciteitsinformatie analyseren.

• Regelmatig de capaciteitsinformatie voor zowel het netwerk als de toepassingen te evalueren, evenals de uitgangssituatie en de uitzondering.

• Er zijn upgrades- of afstemming-procedures ingesteld om capaciteitsproblemen op zowel reactieve als langetermijnbasis aan te pakken.

Indicatoren voor prestatiebeheer

Prestatie-indicatoren vormen het mechanisme waarmee een organisatie kritische succesfactoren kan meten. Prestatie-indicatoren voor prestatieplanning omvatten:

• Documenteren over de zakelijke doelstellingen van het netwerkbeheer. Dit kan een formeel concept zijn van activiteiten voor netwerkbeheer of een minder formele verklaring van de vereiste kenmerken en doelstellingen.

• Gedetailleerde en meetbare doelstellingen voor serviceniveaus creëren.

• Verstrek documentatie over de overeenkomsten inzake serviceniveaus met kaarten of grafieken die aantonen dat deze overeenkomsten in de loop der tijd succesvol zijn of niet worden nageleefd.

• Verzamelen van een lijst van de variabelen voor de basislijn, zoals het steminterval, de overheadkosten van het netwerk, mogelijke drempelwaarden, of de variabele gebruikt wordt als trigger voor een val, en trending analysis gebruikt tegen elke variabele.

• Een periodieke vergadering houden die de analyse van de uitgangssituatie en de trends beoordeelt.

• Laat een wat-als analysemethode gedocumenteerd zijn. Dit moet, waar van toepassing, modellering en verificatie omvatten.

• Wanneer de drempels worden overschreden, ontwikkelt u documentatie over de methodologie die wordt gebruikt om de netwerkbronnen te vergroten. Eén item naar document is de tijdlijn die vereist is om extra WAN-bandbreedte en een kostentabel in te voeren.

Prestatiebeheerprocessen

Deze stappen bieden een hoogwaardige processtroom voor prestatiebeheer:

1. Een concept voor netwerkbeheer ontwikkelen

   1. De gewenste functies definiëren: Diensten, schaalbaarheid en beschikbaarheid

   2. Beschikbaarheid en netwerkbeheerdoelstellingen definiëren

   3. Prestatie-SLA’s en parameters definiëren

   4. SLA’s definiëren

2. Meetprestaties

   1. Verzamel netwerkbasisgegevens

   2. Beschikbaarheid meten

   3. Response Time meten

   4. Nauwkeurigheid meten

   5. Meettoepassing

   6. Capaciteitsplanning

3. Een proactieve foutanalyse uitvoeren

   1. Drempels voor proactief foutenbeheer gebruiken

   2. Implementatie van netwerkbeheer

   3. Metriek van netwerkwerking

Een concept voor netwerkbeheer ontwikkelen

Voordat u de gedetailleerde prestatie- en capaciteitsvariabelen voor een netwerk definieert, moet u het algemene concept van werking voor netwerkbeheer binnen uw organisatie bekijken. Wanneer u dit algemene concept definieert, biedt het een zakelijke basis waarop u nauwkeurige definities kunt bouwen van de functies die in uw netwerk worden gewenst. Als u er niet in slaagt een operationeel concept voor netwerkbeheer te ontwikkelen, kan het leiden tot een gebrek aan doelen of doelen die constant verschuiven vanwege eisen van klanten.

Normaal gesproken stelt u het netwerkbeheerconcept van de activiteiten op als de eerste stap in de systeemontwerpfase van het netwerkbeheerprogramma. Het doel is de algemene gewenste systeemkenmerken vanuit operationeel oogpunt te beschrijven. Het gebruik van dit document is gericht op de coördinatie van de algemene zakelijke (niet-kwantitatieve) doelstellingen van netwerkoperaties, engineering, design, andere bedrijfseenheden en eindgebruikers. Dit document is gericht op de vorming van operationele planningsactiviteiten op lange afstand voor netwerkbeheer en -exploitatie. Het biedt tevens een leidraad voor de ontwikkeling van alle latere definitiedocumentatie, zoals overeenkomsten inzake dienstverleningsniveau. Deze eerste reeks definities kan zich uiteraard niet te strikt richten op het beheer van specifieke netwerkproblemen, maar op die punten die de nadruk leggen op het belang van de algehele organisatie en de kosten die ook moeten worden beheerd. Enkele doelstellingen zijn:

• Vaststellen welke kenmerken essentieel zijn voor een efficiënt gebruik van de netwerkinfrastructuur.

• Identificeer de diensten/toepassingen die het netwerk ondersteunt.

• Start end-to-end servicebeheer.

• Stel een op prestaties gebaseerde metriek in om de algehele service te verbeteren.

• Verzamel en verspreid informatie over prestatiebeheer.

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

Met andere woorden, het netwerkbeheerconcept van operaties zou zich moeten richten op de algemene organisatorische doelstellingen en uw filosofie om deze doelen te bereiken. De belangrijkste elementen zijn de definities op hoger niveau van de missie, de doelstellingen van de missie, de systeemdoelstellingen, de organisatorische betrokkenheid en de algemene operationele filosofie.

Als netwerkbeheerder bent u in de positie om vaak inconsistente prestatieverwachtingen van uw gebruikers te verenigen. Bijvoorbeeld, als het primaire vereiste voor het netwerk de overdracht van grote dossiers van de ene plaats naar de andere is, wilt u zich op hoge snelheid en minder op de antwoordtijden van interactieve gebruikers concentreren. Let erop dat u de weergave van de prestaties niet beperkt blijft, tenzij u een aantal problemen nadenkt. Kijk bijvoorbeeld bij het testen van een netwerk naar de belastingniveaus die worden gebruikt. De lading is vaak gebaseerd op zeer kleine pakketten en de doorvoersnelheid op zeer grote pakketten. Beide prestatietests kunnen een zeer positief beeld produceren, maar gebaseerd op uw lading van het netwerkverkeer, zouden de testen geen echt beeld van prestaties kunnen geven. De netwerkprestaties onder zoveel mogelijk werklastomstandigheden en de gedocumenteerde prestaties bestuderen.

Bovendien, terwijl veel netwerkbeheerorganisaties effectieve alarmtechnieken hebben om technici op de hoogte te stellen van een storing, is het veel moeilijker om een beoordelingsproces te definiëren en ten uitvoer te leggen voor de end-to-end applicatie prestaties. Daarom, terwijl het centrum van netwerkoperaties (NOC) snel op een gedempte router of switch kan reageren, zouden de netwerkomstandigheden die netwerkprestaties kunnen ondermijnen en de perceptie van gebruikers beïnvloeden gemakkelijk onopgemerkt kunnen gaan tot die perceptie negatief wordt. Hoe moeilijk het ook is, dit tweede proces kan enorme voordelen opleveren voor zowel de bedrijfsorganisatie als het netwerkbeheer.

Ten slotte, zorg ervoor dat u geen onrealistische verwachtingen van uw netwerkprestaties creëert. Onrealistische verwachtingen worden meestal gemaakt wanneer u de details van netwerkprotocollen of de toepassingen verkeerd begrijpt. Vaak zijn slechte prestaties niet de fout van het netwerk, maar eerder het gevolg van slecht toepassingsontwerp. De enige manier om toepassingsprestaties te documenteren en te meten is om een basislijn van de netwerkprestaties te hebben vóór de installatie van de toepassing.

De gewenste 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 diensten. Deze stap vereist dat u toepassingen, basisverkeersstromen, gebruikers- en site tellingen en vereiste netwerkservices begrijpt. Het eerste gebruik van deze informatie is om te bepalen of de toepassing kritiek is op de organisatorische doelen. U kunt deze informatie ook toepassen om een kennisbasis te maken voor gebruik in het logische ontwerp om bandbreedte, interface, connectiviteit, configuratie, en fysieke apparatenvereisten te begrijpen. Deze eerste stap stelt uw netwerkarchitecten in staat een model van uw netwerk te maken.

Schoon doelen voor schaalbaarheid om netwerkengineers te helpen netwerken te ontwerpen die voldoen aan toekomstige groeivereisten en zorg ervoor dat de voorgestelde ontwerpen geen middelbeperkingen ondervinden ten gevolge van groei of uitbreiding van het netwerk. Er zijn onder meer beperkingen voor bronnen:

• Totaal verkeer

• Volume

• Aantal routes

• Aantal virtuele circuits

• Buurlanden tellen

• Breedbanddomeinen

• Doorvoersnelheid voor apparaat

• Mediacapaciteit

Netwerkplanners dienen de vereiste levensduur van het ontwerp, verwachte uitbreidingen of locaties te 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 geen onderzoek doet naar de schaalbaarheid van een oplossing, kunt u gedwongen worden om belangrijke reactieve ontwerpveranderingen door te voeren. Deze ontwerpverandering kan extra hiërarchie, media upgrades of hardware-upgrades omvatten. In organisaties die vertrouwen op vrij precieze begrotingscycli voor grote hardwareaankopen kunnen deze veranderingen een belangrijke remmer voor het algehele succes zijn. In termen van beschikbaarheid kunnen netwerken onverwachte middelen beperkingen ervaren die periodes van niet beschikbaarheid en reactieve maatregelen veroorzaken.

Interoperabiliteit en interoperabiliteitstests kunnen van cruciaal belang zijn voor het succes van nieuwe oplossingen-implementaties. Interoperabiliteit kan verwijzen naar verschillende hardwareverkopers, of verschillende topologieën of oplossingen die tijdens of na een netwerkimplementatie moeten samenwerken. Interoperabiliteitsproblemen kunnen hardware signalering via de protocolstapel omvatten om problemen bij het routeren of transporteren op te lossen. Interoperabiliteitsproblemen kunnen zich voordoen voor, tijdens of na de migratie van een netwerkoplossing. De planning van interoperabiliteit zou connectiviteit tussen verschillende apparaten en topologie kwesties moeten omvatten die tijdens migraties zouden kunnen voorkomen.

Vergelijking van de oplossing is de praktijk waarin je verschillende mogelijke ontwerpen vergelijkt met andere methoden die een oplossing vereisen. Deze praktijk helpt ervoor te zorgen dat de oplossing het best geschikt is voor een bepaalde omgeving en dat persoonlijke vooringenomenheid het ontwerpproces niet aanstuurt. Vergelijking kan verschillende factoren omvatten zoals kosten, veerkracht, beschikbaarheid, risico, interoperabiliteit, beheersbaarheid, schaalbaarheid en prestaties. Dit kan een belangrijk effect hebben op de algemene netwerkbeschikbaarheid zodra het ontwerp is uitgevoerd. U kunt ook media, hiërarchie, redundantie, routingprotocollen en soortgelijke functies vergelijken. Maak een grafiek met factoren op de X-as en mogelijke oplossingen op de Y-as hulp om de vergelijking van de oplossing samen te vatten. Gedetailleerde vergelijking van oplossingen in een laboratoriumomgeving helpt ook om nieuwe oplossingen en kenmerken objectief te onderzoeken met betrekking tot de verschillende vergelijkingsfactoren.

Als onderdeel van het netwerkbeheerconcept van operaties is het van essentieel belang om de doelstellingen voor het netwerk en ondersteunde diensten op een manier te definiëren 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 standaardprestatiedoelen:

• responstijd

• Gebruik

• Doorvoersnelheid

• Capaciteit (maximale doorvoersnelheid)

Hoewel deze metingen triviaal kunnen zijn voor een eenvoudig LAN, kunnen ze zeer moeilijk zijn op een geschakeld campus netwerk of een netwerk van meerdere leveranciers. Wanneer je een weloverwogen concept van een operatieplan gebruikt, wordt elk van de prestatieconjecten 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 zou moeten concentreren.

Beschikbaarheid en netwerkbeheerdoelstellingen definiëren

De doelstellingen van de beschikbaarheid definiëren het niveau van de dienst of de vereisten van het dienstniveau voor een netwerkdienst. Dit helpt ervoor te zorgen dat de oplossing voldoet aan de eisen inzake eindbeschikbaarheid. Defineer verschillende serviceklasse voor een bepaalde organisatie en gedetailleerd netwerkvereisten voor elke klasse die aan de beschikbaarheidseis zijn aangepast. Verschillende gebieden van het netwerk zouden ook verschillende niveaus van beschikbaarheid kunnen vereisen. Een hogere beschikbaarheid zou meer redundantie en ondersteuningsprocedures kunnen vereisen. Wanneer u een beschikbaarheidsdoelstelling voor een bepaalde netwerkdienst definieert en de beschikbaarheid meet, kan uw netwerkorganisatie componenten en serviceniveaus begrijpen die vereist zijn om geprojecteerde SLAs te bereiken.

Vaststellen van beheersdoelstellingen om te waarborgen dat het algemene netwerkbeheer niet aan beheersfuncties ontbreekt. Om beheerdoelstellingen te kunnen instellen, dient u het ondersteuningsproces en de bijbehorende netwerkbeheertools voor uw organisatie te begrijpen. Bij de doelstellingen inzake beheersbaarheid moet onder meer worden gekeken naar de vraag hoe nieuwe oplossingen passen in het huidige ondersteunings- en steunmodel, waarbij wordt verwezen naar eventuele verschillen of nieuwe eisen. Dit is van cruciaal belang voor de beschikbaarheid van netwerken, aangezien het vermogen om nieuwe oplossingen te ondersteunen van het allergrootste belang is voor succes bij de implementatie en het halen van de beschikbare doelen.

Met de doelstellingen inzake beheersbaarheid moet alle belangrijke informatie over de MIB of de netwerkinstrumenten worden onthuld die nodig is om een mogelijk netwerk te ondersteunen, moet worden voorzien in opleiding die nodig is om de nieuwe netwerkdienst te ondersteunen, in personeelsmodellen voor de nieuwe dienst en in andere ondersteuningsvereisten. Vaak wordt deze informatie vóór de plaatsing niet onthuld en de algemene beschikbaarheid lijdt onder het gebrek aan middelen toegewezen om het nieuwe netwerkontwerp te ondersteunen.

Prestatie-SLA’s en parameters definiëren

SLA's en maatstaven van prestaties helpen de prestaties van nieuwe netwerkoplossingen te definiëren en te meten om ervoor te zorgen dat ze aan prestatievereisten voldoen. De prestaties van de voorgestelde oplossing kunnen worden gemeten met instrumenten voor prestatiebewaking of met een eenvoudige pingelen in de voorgestelde netwerkinfrastructuur. De SLA's moeten het gemiddelde verwachte verkeersvolume, het piekvolume, de gemiddelde responstijd en de maximaal toegestane responstijd omvatten. Deze informatie kan dan later worden gebruikt in het onderdeel validatie van de oplossing en helpt uiteindelijk de vereiste prestaties en beschikbaarheid van het netwerk te bepalen.

SLA’s definiëren

Een belangrijk aspect van netwerkontwerp is wanneer u de service voor gebruikers of klanten definieert. Ondernemingen noemen deze dienstenlevel-overeenkomsten, terwijl de dienstverleners het beheer van het serviceniveau noemen. Het beheer op serviceniveau omvat doorgaans definities voor probleemtypes en ernst en verantwoordelijkheden van helpdesk, zoals escalatiepad en tijd voor escalatie op elk niveau van steun, tijd om te beginnen met werken aan het probleem en tijd om doelen te sluiten op basis van prioriteit. Andere belangrijke factoren zijn welke dienst wordt verleend op het gebied van capaciteitsplanning, proactief foutenbeheer, kennisgeving van wijzigingsbeheer, drempels, upgradecriteria en hardwarevervanging.

Als organisaties geen serviceniveaus vooraf definiëren, wordt het moeilijk om de behoeften aan middelen te verbeteren of te verkrijgen die op een latere datum worden geïdentificeerd. Het wordt ook moeilijk te begrijpen welke middelen er moeten worden toegevoegd om het netwerk te ondersteunen. In veel gevallen worden deze middelen pas toegepast nadat er problemen zijn ontdekt.

Meetprestaties

Prestatiebeheer is een overkoepelende term die de configuratie en meting van verschillende prestatieterreinen omvat. In dit deel worden deze zes begrippen van prestatiemanagement beschreven:

• Verzamel netwerkbasisgegevens

• Beschikbaarheid meten

• Response Time meten

• Nauwkeurigheid meten

• Meettoepassing

• Capaciteitsplanning

Verzamel netwerkbasisgegevens

De meeste bedrijfsintranets hebben voldoende bandbreedte. Zonder adequate gegevens kunt u echter netwerkcongestie niet uitsluiten als bijdrage aan slechte prestaties van toepassingen. Een van de aanwijzingen voor congestie of fouten is of de slechte prestaties intermitterend zijn of de tijd-van-dag afhankelijk zijn. Een voorbeeld van deze voorwaarde is wanneer de prestaties te laat in de avond zijn, maar zeer langzaam in de ochtend en tijdens de piekuren.

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

Voer een basislijn van het huidige netwerk uit vóór een nieuwe oplossing (toepassing of IOS verandering) plaatsing en na de plaatsing om verwachtingen voor de nieuwe oplossing te meten. Deze basislijn helpt te bepalen of de oplossing voldoet aan prestatie- en beschikbaarheidsdoelstellingen en benchmarkcapaciteit. Een typisch router/switch basisrapport omvat capaciteitsproblemen gerelateerd aan CPU, geheugen, bufferbeheer, link/mediabereik en doorvoersnelheid. Er zijn andere soorten basisgegevens die je zou kunnen opnemen, gebaseerd op de gedefinieerde doelstellingen in het concept van operaties. Bijvoorbeeld, een beschikbaarheidsbasislijn toont verhoogde stabiliteit/beschikbaarheid van de netwerkomgeving aan. Voer een basisvergelijking uit tussen oude en nieuwe omgevingen om de vereisten voor de oplossing te controleren.

Een andere speciale basislijn is de toepassingsbasislijn, die waardevol is wanneer u netwerkvereisten voor toepassingen op de trend zet. Deze informatie kan worden gebruikt voor facturering en/of budgettering in de upgradecyclus. Toepassingsbasislijnen kunnen ook van belang zijn op het gebied van de beschikbaarheid van toepassingen in relatie tot de voorkeursdiensten of de kwaliteit van de dienstverlening per toepassing. De basisinformatie van de toepassing bestaat hoofdzakelijk uit bandbreedte die door toepassingen per tijdsperiode wordt gebruikt. Sommige netwerkbeheertoepassingen kunnen ook de prestaties van de basistoepassing meten. Een uitsplitsing van het type verkeer (telnet of FTP) is ook belangrijk voor de planning. In sommige organisaties, worden de meer kritieke middelen-ingeperkte gebieden van het netwerk gecontroleerd voor top talkers. De netwerkbeheerders kunnen deze informatie gebruiken om het netwerk te begroten, te plannen of aan te passen. Wanneer u het netwerk aanpast, kunt u de kwaliteit van de service of de wachtrijparameters voor de netwerkservice of -toepassing wijzigen.

Beschikbaarheid meten

Een van de belangrijkste metriek die door netwerkmanagers wordt gebruikt is beschikbaarheid. Beschikbaarheid is de tijdsmaat waarvoor een netwerksysteem of toepassing beschikbaar is voor een gebruiker. Vanuit een netwerkperspectief vertegenwoordigt beschikbaarheid de betrouwbaarheid van de individuele componenten in een netwerk.

Bijvoorbeeld, om beschikbaarheid te meten, zou u de telefoongesprekken van de helpdesk met de statistieken kunnen coördineren die van de beheerde apparaten worden verzameld. Beschikbaarheidsgereedschappen kunnen echter niet alle oorzaken van het falen bepalen.

Netwerkredundantie is een andere factor die u in overweging moet nemen wanneer u de beschikbaarheid meet. Verlies van redundantie betekent achteruitgang van de service in plaats van totale netwerkstoring. Het resultaat is mogelijk een tragere responstijd en een verlies aan gegevens door gevallen pakketten. Het is ook mogelijk dat de resultaten op de andere gebieden van prestatiemeting, zoals gebruikstijd en responstijd, worden weergegeven.

Ten slotte, als u tegen een SLA levert, zou u rekening moeten houden met geplande uitval. Deze uitval zou het resultaat kunnen zijn van bewegingen, toevoegingen, veranderingen, sluitingen van fabrieken, of andere gebeurtenissen die u niet zou willen rapporteren. Dit is niet alleen een moeilijke taak, maar zou ook een handmatige taak kunnen zijn.

Response Time meten

De antwoordtijd van het netwerk is de tijd die nodig is om tussen twee punten te kunnen reizen. De responstijden trager dan normaal, gezien door een uitgangsvergelijking of die een drempel overschrijden, kunnen wijzen op congestie of een netwerkfout.

De antwoordtijd is de beste maat van het gebruik van het netwerk van de klant en kan u helpen de doeltreffendheid van uw netwerk te meten. Wat de bron van de langzame reactie ook is, gebruikers worden gefrustreerd als resultaat van het vertraagde verkeer. In gedistribueerde netwerken beïnvloeden veel factoren de responstijd, zoals:

• Netwerkcongestie

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

• Ondergedreven netwerkapparaten

• Netwerkfouten zoals een uitzendstorm

• Ruis of CRC-fouten

In netwerken die een QoS-gerelateerde wachtrij gebruiken, is meting van de responstijd belangrijk om te bepalen of de juiste typen verkeer via het netwerk bewegen zoals verwacht. Wanneer u bijvoorbeeld spraakverkeer via IP-netwerken uitvoert, moeten spraakpakketten op tijd en met een constante snelheid worden geleverd om een goede spraakkwaliteit te behouden. U kunt verkeer genereren geclassificeerd als stemverkeer om de responstijd van het verkeer te meten zoals het aan gebruikers lijkt.

U kunt de responstijd meten om de gevechten tussen toepassingsservers en netwerkmanagers te helpen oplossen. Netwerkbeheerders worden vaak schuldig geacht wanneer een toepassing of server langzaam lijkt te zijn. De netwerkbeheerder moet bewijzen dat het netwerk niet het probleem is. De gegevensverzameling van de responstijd biedt een onmisbaar middel om aan te tonen of te ontkennen dat het netwerk de bron van toepassingsproblemen is.

Indien mogelijk dient u de responstijd te meten zoals deze bij de gebruikers lijkt. Een gebruiker ziet de reactie als het tijdstip vanaf wanneer hij op ENTER drukt of klikt op een knop totdat het scherm wordt weergegeven. Deze verlopen tijd omvat de tijd die voor elk netwerkapparaat, het gebruikerswerkstation en de doelserver vereist is om het verkeer te verwerken.

Helaas is meting op dit niveau bijna onmogelijk door het aantal gebruikers en het gebrek aan hulpmiddelen. Verder, wanneer u gebruikers en server responstijd integreert, biedt het weinig waarde wanneer u toekomstige netwerkgroei bepaalt of netwerkproblemen oplossen.

U kunt de netwerkapparaten en -servers gebruiken om de responstijd te meten. U kunt ook instrumenten zoals ICMP gebruiken om transacties te meten, hoewel er geen rekening wordt gehouden met vertragingen die in een systeem zijn geïntroduceerd omdat de bovenste lagen het verwerken. Deze benadering lost het probleem op van de kennis van de netwerkprestaties.

Op een simplistisch niveau kunt u de reactie op pings van het netwerkbeheerstation op belangrijke punten in het netwerk, zoals een mainframe-interface, eindpunt van een service provider-verbinding of belangrijke IP-adressen van gebruikers instellen om de responstijd te meten. Het probleem met deze methode is dat het de gebruikerspatronen van de responstijd tussen de machine en de doelmachine niet nauwkeurig weergeeft. Het verzamelt gewoon informatie en rapporteert responstijd vanuit het perspectief van de netwerkbeheerstations. Deze methode maskeert ook de responstijd op basis van hop-voor-hop in het hele netwerk.

Een alternatief voor server-centrische opiniepeiling is de inspanning dichter bij de bron en de bestemming te verdelen die u voor meting wilt simuleren. Gebruik gedistribueerde netwerkbeheercontrollers en voer Cisco IOS Service Assurance Agent (SAA)-functies uit. U kunt SAA op routers inschakelen om de responstijd tussen een router en een doelapparaat zoals een server of een andere router te meten. U kunt ook een TCP- of UDP-poort specificeren, waarin verkeer wordt geforceerd om door te sturen en gericht te worden op dezelfde manier als het verkeer dat het simuleert.

Met de integratie van spraak, video, en gegevens op multiservice netwerken implementeren klanten QoS-prioritering in hun netwerk. Eenvoudige ICMP- of UDP-metingen geven de responstijd niet nauwkeurig weer, omdat verschillende toepassingen verschillende prioriteiten ontvangen. Ook, met tagswitching, kan de routing variëren op basis van het toepassingstype in een specifiek pakket. Dus een ICMP ping zou verschillende prioriteiten kunnen ontvangen in de manier waarop elke router het behandelt en zou verschillende, minder efficiënte routes kunnen 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 aan te kunnen zoals zij voor het echte verkeer zouden doen. Mogelijk kunt u dit niveau bereiken met SAO of door het gebruik van toepassingsgerichte prikproblemen van derden.

Nauwkeurigheid meten

Nauwkeurigheid is de maat voor het interfaceverkeer dat niet tot fouten leidt en kan worden uitgedrukt in een percentage dat het succespercentage vergelijkt met het totale pakkettarief over een periode. U moet eerst het foutenpercentage meten. Als twee van elke 100 pakketten bijvoorbeeld een fout opleveren, is het foutenpercentage 2% en is de nauwkeurigheid 98%.

Met eerdere netwerktechnologieën, vooral op het brede gebied, was een bepaald foutenpercentage aanvaardbaar. Maar met hogesnelheidsnetwerken en de huidige WAN-services is de transmissie aanzienlijk accurater en de foutenpercentages zijn bijna nul, tenzij er een reëel probleem is. Sommige veel voorkomende oorzaken van interfacefouten zijn:

• Uitgebreide bedrading

• Elektrische storing

• Ondeugdelijke hardware of software

Gebruik een verlaagd nauwkeurigheidspercentage om een nader onderzoek te starten. U zou kunnen ontdekken dat een bepaalde interface problemen oplevert en beslist dat de fouten aanvaardbaar zijn. In dat geval dient u de nauwkeurigheidsdrempel voor deze interface aan te passen om weer te geven waar het foutenpercentage onacceptabel is. Het onacceptabele foutenpercentage zou in een eerdere uitgangssituatie kunnen zijn gemeld.

De in deze tabel beschreven variabelen worden gebruikt in nauwkeurigheids- en foutenformules:

Opmerking	Beschrijving
indienInfouten wordt fouten gemaakt	De delta (of verschil) tussen twee opiniepeilcycli die de snmp ifInFoutes object verzamelen, wat het aantal inkomende pakketten met een fout representeert.
ifInUcastPackets	De delta tussen twee opiniepeilcycli die de snmp ifInUcastPkts object verzamelen, wat de telling van inkomende eenastpakketten representeert.
ifInNUcastPacketPacket	De delta tussen de twee opiniepeilcycli die de snmp ifInNUcastPkts-object verzamelen, dat de telling van inkomende niet-eenwichtige pakketten vertegenwoordigt (multicast en uitzending).

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

Error rate = (ifInErOUters) *100

—

(indienInUcastPkts + (indienInNUcastPkts )

Merk op dat uitgaande fouten niet in aanmerking worden genomen in de foutenpercentages en de nauwkeurigheidsformules. Dat komt doordat een apparaat nooit bewust pakketten met fouten op het netwerk zou moeten plaatsen, en de uitgaande foutenpercentages zouden nooit moeten stijgen. Daarom zijn inkomende verkeer en fouten de enige maatstaven van belang voor interfacefouten en nauwkeurigheid.

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

Nauwkeurigheid = 100 - (alsInfouten) *100

—

(indienInUcastPackts + (indienInNUcastPackts)

Deze formules weerspiegelen fouten en nauwkeurigheid in termen van generieke tellers van de MIB II-interface (RFC 2233). Het resultaat wordt uitgedrukt in termen van een percentage dat fouten op totale pakketten die worden gezien en verzonden vergelijkt. Het foutenpercentage dat resulteert uit 100, wat het nauwkeurigheidspercentage oplevert. Een accuraat percentage van 100% is perfect.

Omdat de MIB II variabelen als tellers worden opgeslagen, moet u twee opiniecycli nemen en het verschil tussen de twee bedenken (vandaar de delta die in de vergelijking wordt gebruikt).

Meettoepassing

Het gebruik van een bepaalde hulpbron in de loop der tijd wordt gemeten. De maatregel wordt doorgaans uitgedrukt in een percentage waarin het gebruik van een bron wordt vergeleken met de maximale operationele capaciteit. Via gebruiksmaatregelen kunt u congestie (of potentiële congestie) in het hele netwerk identificeren. U kunt ook onderbenutte hulpbronnen identificeren.

Het gebruik is de belangrijkste maatregel om te bepalen hoe vol de netwerkleidingen (koppelingen) zijn. Meten van de CPU, interface, wachtrij en andere systeemgerelateerde capaciteitsmetingen om te bepalen in welke mate de netwerksysteembronnen worden verbruikt.

Hoge benutting is niet per se slecht. Een lage benutting kan wijzen op verkeersstromen op onverwachte plaatsen. Als de lijnen worden overschreden, kunnen de effecten aanzienlijk worden. Overgebruik gebeurt wanneer er meer verkeer in de wachtrij staat om over een interface heen te gaan dan dat het kan verwerken. Plotselinge sprongen bij gebruik van hulpbronnen kunnen wijzen op een defect.

Aangezien een interface verstopt wordt, moet het netwerkapparaat het pakket in een rij opslaan of het weggooien. Als een router probeert een pakket in een volledige wachtrij op te slaan, wordt het pakket verbroken. Gedrukte pakketten resulteren wanneer verkeer van een snelle interface naar een langzamere interface wordt verzonden. Dit wordt aangegeven in formule Q = u / (1-u) waarin u gebruikt, en Q is de gemiddelde rijdiepte (willekeurig verkeer verondersteld). Dus hoge benuttingsniveaus op koppelingen resulteren in hoge gemiddelde wachtrijdiepten, wat voorspelbare latentie is als u de pakketgrootte kent. Sommige netwerk-meldende verkopers wijzen erop dat u minder bandbreedte kunt bestellen en minder voor uw WAN kunt betalen. De gevolgen voor de latentie worden echter weergegeven als u WAN-links op 95% van het gebruik uitvoert. Bovendien, aangezien netwerken naar VoIP worden gemigreerd, kunnen de netwerkbeheerders hun beleid moeten veranderen en WAN links moeten uitvoeren bij ongeveer 50% gebruik.

Wanneer een pakje valt, kan het hogere laagprotocol het pakje opnieuw verzenden. Als meerdere pakketten worden verzonden, kan dit resulteren in overmatig verkeer. Dit type reactie kan resulteren in back-ups op apparaten verderop in de lijn. Om dit probleem op te lossen, kunt u verschillende graden van drempels instellen.

De primaire maatregel voor netwerkgebruik is interfacegebruik. Gebruik de formules die in deze tabel zijn beschreven en die zijn gebaseerd op de vraag of de verbinding die u meet halftweezijdig of volledig duplex is:

Opmerking	Beschrijving
ifInOctets	De delta (of verschil) tussen twee opiniepeilcycli die het snmp ifInOctets object verzamelen, dat de telling van inkomende octetten van het verkeer representeert.
ifOutOctets	De delta tussen twee opiniepeilcycli die het snmp ifOutOctets object verzamelen dat de telling van uitgaande octetten van het verkeer vertegenwoordigt.
alsSnelheid	De snelheid van de interface zoals gerapporteerd in het snmp ifSpeed object. Merk op dat alsSpeed niet accuraat de snelheid van een WAN-interface zou kunnen weerspiegelen.

Gedeelde LAN-verbindingen hebben de neiging half-tweezijdig te zijn, vooral omdat de contentdetectie vereist dat een apparaat luistert voordat het wordt verzonden. WAN-verbindingen zijn doorgaans volledig duplex omdat de verbinding een punt naar punt is; beide apparaten kunnen tegelijkertijd verzenden en ontvangen aangezien zij weten dat er slechts één ander apparaat is dat de verbinding deelt .

Omdat de MIB II variabelen als tellers worden opgeslagen, moet u twee opiniecycli nemen en het verschil tussen de twee bedenken (vandaar de delta die in de vergelijking wordt gebruikt).

Gebruik deze formule voor half-duplexmedia voor interfacegebruik:

(indienInOctets + ifOutOctets) * 8 * 100

—

(aantal seconden per 000) * indienSnelheid

Voor full-duplex media is de bruikbaarheidsberekening complexer. Met een volledige T-1 seriële verbinding is de lijnsnelheid bijvoorbeeld 1,54 Mbps. Dit betekent dat een T-1 interface zowel 1,544 Mbps kan ontvangen en verzenden voor een gecombineerde mogelijke bandbreedte van 3,088 Mbps.

Wanneer u interfacebandbreedte voor full-duplex verbindingen berekent, kunt u deze formule gebruiken waarin u de grotere van de in en out waarden neemt en een gebruikspercentage genereert:

max (ifInOctets, (ifOutOctets) * 8 * 100

—

(aantal seconden per 000) * indienSnelheid

Deze methode verhult echter het gebruik van de richting die de laagste waarde heeft en levert minder accurate resultaten op. Een nauwkeuriger methode is om het invoergebruik en het uitvoergebruik afzonderlijk te meten, zoals:

Invoergebruik = ifInOctets *8 * 100

—

(aantal seconden per 000) * indienSnelheid

en

Uitvoer = indienOutOctets *8 * 100

—

(aantal seconden per 000) * indienSnelheid

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

Capaciteitsplanning

Zoals eerder vermeld, is capaciteitsplanning het proces waarin u de waarschijnlijke toekomstige vereisten van de netwerkmiddelen bepaalt om een prestatie of een beschikbaarheidsimpact op zakelijk kritieke toepassingen te voorkomen. Raadpleeg het capaciteitsbeheer en het prestatiebeheer: Witboek over beste praktijken voor meer gedetailleerde informatie over dit onderwerp.

Een proactieve foutanalyse uitvoeren

Proactieve foutanalyse is van essentieel belang voor prestatiemanagement. Hetzelfde type gegevens dat voor prestatiebeheer wordt verzameld, kan worden gebruikt voor proactieve foutanalyse. De timing en het gebruik van deze gegevens verschillen echter van het pro-actief foutenbeheer tot het prestatiemanagement.

Proactief foutenbeheer is de manier waarop het ideale netwerkbeheersysteem de door u bepaalde doelen kan bereiken. Het verband met prestatiemanagement is door de basislijn en de gegevensvariabelen die u gebruikt. Bij het proactief foutenbeheer worden op maat gesneden gebeurtenissen, een correlatiemotor voor gebeurtenissen, het testen van problemen en de statistische analyse van de basisgegevens geïntegreerd om fouten, prestaties en wijzigingsbeheer te combineren in een ideaal, effectief netwerkbeheersysteem.

Wanneer de prestatiegegevens gewoonlijk om de 10, 15 of zelfs 30 minuten worden ondervraagd, moet de herkenning van een defect veel korter zijn. Eén methode van proactief foutenbeheer is door het gebruik van RMON - alarmen en groepen gebeurtenissen. U kunt drempelwaarden op uw apparaten instellen die niet door externe apparaten worden opgevraagd zodat de drempels veel korter zijn. Een andere methode, die niet in dit document wordt behandeld, is het gebruik van een gedistribueerd beheersysteem dat op lokaal niveau kan worden ondervraagd met samenvoeging van gegevens bij een manager.

Drempels voor proactief foutenbeheer gebruiken

Drempelwaarde is het proces waarin u punten van belang in specifieke gegevensstromen definieert en gebeurtenissen genereert wanneer drempelwaarden worden geactiveerd. Gebruik uw gegevens van de netwerkprestaties om die drempels 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 zodat tekstgegevens worden omgezet in afzonderlijke numerieke waarden. Zelfs als u niet alle mogelijke tekstkoorden voor een object kent, kunt u de "interessante" strings nog opsommen en alle andere strings aan een ingestelde waarde toewijzen.

Er zijn twee categorieën drempels voor de twee klassen numerieke gegevens: continu en discreet. Doorlopende drempels zijn van toepassing op continue of tijdreeksgegevens zoals gegevens die in SNMP-tellers of -meters worden opgeslagen. Specifieke drempels zijn van toepassing op opgesomde objecten of op afzonderlijke numerieke gegevens. Booleaanse objecten worden opgesomd waarden met twee waarden: waar of onjuist. Discrete gegevens kunnen ook eventgegevens worden genoemd omdat gebeurtenissen de overgang van één waarde naar de volgende markeren.

Doorlopende drempels kunnen gebeurtenissen veroorzaken wanneer het tijdreeksobject de gespecificeerde waarde van de drempel overschrijdt. De waarde van het object stijgt boven de drempel of daalt eronder. Het kan ook nuttig zijn afzonderlijke stijgende en dalende drempels vast te stellen. Deze techniek, die bekend staat als een hysterese-mechanisme, helpt het aantal gebeurtenissen dat uit deze gegevensklasse is ontstaan te verminderen. Het hysterese-mechanisme werkt om het volume van gebeurtenissen die zijn ontstaan door drempelwaarden voor snel variërende tijdreeksgegevens te verminderen. Dit mechanisme kan met elke drempeltechniek voor de tijdreeksgegevens worden gebruikt.

Het volume van gebeurtenissen wordt verminderd door een alarm dat wordt gegenereerd om de waarde van een object te volgen. De stijgende en dalende drempels worden aan dit alarm toegewezen. Het alarm wordt alleen geactiveerd wanneer de stijgende drempel wordt overschreden. Zodra deze drempel is overschreden, wordt er pas opnieuw een stijgend alarm gegenereerd totdat de dalende drempel is overschreden. Hetzelfde mechanisme voorkomt het ontstaan van dalende drempels totdat de stijgende drempel opnieuw wordt overschreden. Dit mechanisme kan het aantal gebeurtenissen drastisch verminderen en voorkomt geen informatie die vereist is om te bepalen of er een fout bestaat.

Tijdreekgegevens kunnen worden weergegeven in de vorm van tellers, waarbij elk nieuw gegevenspunt wordt toegevoegd aan de som van de vorige gegevenspunten, of in de vorm van een maatstaf, waarbij de gegevens over een tijdsinterval worden weergegeven als een tarief. Er zijn twee verschillende vormen van doorlopende drempels voor elk gegevenstype: absolute continue drempels en relatieve continue drempels. Gebruik absolute continue drempels met maten en relatieve continue drempels met tellers.

Voltooi de volgende stappen 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, elk object en elk interfacetype.

4. Bepaal de ernst voor de gebeurtenis die door elke drempel wordt gegenereerd.

Er is een behoorlijke hoeveelheid werk nodig om te bepalen welke drempels moeten worden gebruikt voor welke objecten (en voor welke apparaten en interfaces). Gelukkig, als je een basislijn van prestatiegegevens verzamelde, heb je al een aanzienlijk deel van dat werk gedaan. Ook kunnen NSA en het HAS-programma (High Availability Service) aanbevelingen doen die u helpen om objecten in te stellen en bereik te maken. U moet deze aanbevelingen echter aanpassen aan uw specifieke netwerk.

Aangezien u prestatiegegevens voor het netwerk hebt verzameld, wordt in het HAS-programma aanbevolen om de interfaces per categorie te groeperen. Dit vereenvoudigt het instellen van drempels omdat u drempelwaarden voor het mediatype van elke categorie in plaats van voor elk apparaat en voorwerp op dat apparaat zou kunnen moeten bepalen. U wilt bijvoorbeeld verschillende drempels voor Ethernet- en FDDI-netwerken instellen. Het wordt algemeen gedacht dat u FDDI netwerken bij dichter 100% gebruik kunt lopen dan u een gedeeld Ethernet segment kunt. Full-duplex Ethernet kan echter veel dichter bij 100% gebruik worden uitgevoerd omdat zij niet aan botsingen zijn onderworpen. Je zou je drempels voor botsingen heel laag kunnen instellen voor compleet-duplex links omdat je nooit een botsing zou moeten zien.

U kunt ook de combinatie van het interfacebelang en de categorie/ernst van het drempeltype in overweging nemen. Gebruik deze factoren om de prioriteit van het evenement vast te stellen en derhalve het belang van het evenement en de aandacht van het personeel van de netwerkoperaties.

De groepering en categorisering van netwerkapparaten en interfaces kan niet worden overdreven. Hoe meer u kunt groeperen en categoriseren, hoe gemakkelijker u de drempelgebeurtenissen in uw netwerkbeheerplatform kunt integreren. Gebruik de basislijn als belangrijkste hulpbron voor deze informatie. Raadpleeg het capaciteitsbeheer en het prestatiebeheer: Whitepaper over beste praktijken voor meer informatie.

Implementatie van netwerkbeheer

De organisatie moet beschikken over een systeem voor netwerkbeheer dat de gedefinieerde drempelwaarden kan detecteren en de waarden voor bepaalde tijdsperioden kan rapporteren. Gebruik een RMON - netwerkbeheersysteem dat drempelberichten in een logbestand voor dagelijkse review of een vollediger gegevensbank oplossing kan archiveren die op drempeluitzonderingen voor een bepaalde parameter toestaat. De informatie moet voortdurend ter beschikking van het personeel en de beheerder van de netwerkoperaties staan. De netwerkbeheerimplementatie moet de mogelijkheid omvatten om software/hardwarecrashes of tracbacks, interfacebetrouwbaarheid, CPU, koppelingsgebruik, wachtrijen of bufferfouten, uitzendvolume, overgangen en interfaceresets te detecteren.

Metriek van netwerkbewerkingen

Een laatste gebied van proactief foutenbeheer dat overlapt met prestatiemanagement is de metriek van netwerkbewerkingen. Deze parameters bieden waardevolle gegevens voor de verbetering van het proces van foutbeheer. Ten minste, deze parameters moeten een uitsplitsing bevatten van alle problemen die gedurende een bepaalde periode zijn opgetreden. De uitsplitsing dient informatie te bevatten zoals:

• Aantal problemen die per vraagprioriteit voorkomen

• Minimale, maximum- en gemiddelde tijd om in elke prioriteit te sluiten

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

• Uitsplitsing van tijd naar sluiten voor elk probleemtype

• Beschikbaarheid per beschikbaarheidsgroep of SLA

• Hoe vaak u aan de SLA-vereisten voldeed of niet aan de eisen voldeed

De helpdesk heeft vaak een rapportagesysteem dat metriek of rapporten kan genereren. Een ander middel om deze gegevens te verzamelen is het gebruik van een instrument voor het toezicht op de beschikbaarheid. De gegevens dienen maandelijks beschikbaar te worden gesteld. Op de discussie gebaseerde verbetering van de procedure moet worden doorgevoerd om de gemiste eisen van de dienstenovereenkomst te verbeteren of om de manier waarop bepaalde probleemtypes worden behandeld, te verbeteren.

Indicatoren voor prestatiebeheer

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

Document de zakelijke doelstellingen van het netwerkbeheer

Dit document zou een formeel concept van activiteiten voor netwerkbeheer kunnen 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 beheersstrategie van het organisatienetwerk en moet de algemene zakelijke (niet-kwantitatieve) doelstellingen van netwerkoperaties, engineering, ontwerp, andere bedrijfseenheden en de eindgebruikers coördineren. Deze focus stelt de organisatie in staat om de planningsactiviteiten op lange afstand voor netwerkbeheer en -exploitatie te vormen, hetgeen ook het budgettaire proces omvat. Het biedt ook een leidraad voor het aanschaffen van gereedschappen en het integratiepad dat nodig is om de netwerkbeheerdoelstellingen, zoals SLA's, te realiseren.

Dit strategische document kan niet te strikt gericht zijn op het beheer van specifieke netwerkproblemen, maar op de punten die belangrijk zijn voor de algehele organisatie, waaronder begrotingskwesties. Bijvoorbeeld:

• Een alomvattend plan opstellen met haalbare doelen.

• Identificeer elke zakelijke service/toepassing die netwerkondersteuning vereist.

• Identificeer die op prestaties gebaseerde metriek die nodig is om de dienst te meten.

• Plan de verzameling en distributie van de prestatiegegevens.

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

• beschikken over gedocumenteerde, gedetailleerde en meetbare doelstellingen op serviceniveau.

Documenteren over de Service Level Agreements

Om de SLA's goed te kunnen documenteren, moet u de serviceniveaus volledig definiëren. Deze documentatie moet ter beoordeling beschikbaar zijn voor de gebruikers. Het biedt de feedback loop om ervoor te zorgen dat de netwerkbeheerorganisatie de variabelen blijft meten die nodig zijn om het niveau van de dienstenovereenkomst te handhaven.

SLA's zijn "levende" documenten omdat het bedrijfsklimaat en het netwerk van nature dynamisch zijn. Wat vandaag werkt om een SLA te meten, zou morgen verouderd kunnen worden. Alleen wanneer zij een feedback loop van gebruikers opzetten en op die informatie reageren kunnen netwerkbewerkingen de hoge beschikbaarheid handhaven die door de organisatie wordt vereist.

Een lijst met variabelen voor de basislijn maken

Deze lijst omvat posten zoals oplegtussenpozen, overheadkosten voor netwerkbeheer, mogelijke drempelwaarden, of de variabele gebruikt wordt als trigger voor een val, en trending analysis gebruikt tegen elke variabele.

Deze variabelen zijn niet beperkt tot de parameters die nodig zijn voor de hierboven genoemde doelstellingen van het serviceniveau. Ten minste dienen deze variabelen te worden opgenomen: gezondheid van de router, gezondheid van de switch, het routeren van informatie, technologie-specifieke gegevens, gebruik, en vertraging. Deze variabelen worden periodiek opgevraagd en in een database opgeslagen. Aan de hand van deze gegevens kunnen rapporten worden gegenereerd. Deze verslagen kunnen de netwerkbeheeroperaties en het planningspersoneel op deze wijze bijstaan:

• Reactieve kwesties kunnen vaak sneller worden opgelost met een historische databank.

• Voor prestatierapportage en capaciteitsplanning zijn dit soort gegevens nodig.

• De doelstellingen van het dienstverleningsniveau kunnen aan de hand daarvan worden afgemeten.

Evaluatie van de basislijn- en trendanalyses

Netwerkbeheerpersoneel moet vergaderingen houden om periodiek specifieke verslagen te bespreken. Dit levert extra feedback op, evenals een proactieve benadering van mogelijke problemen in het netwerk.

Bij deze vergaderingen moeten zowel operationele als planningspersoneel betrokken zijn. Dit biedt de planners de mogelijkheid operationele analyse van de basisgegevens en de trending data te ontvangen. Het operationele personeel voor een deel van de planningsanalyse "in de lus".

Een ander soort onderwerp dat in deze vergaderingen moet worden opgenomen, zijn de doelstellingen op het gebied van dienstverlening. Aangezien objectieve drempels worden gehanteerd, kan het personeel van het netwerkbeheer maatregelen nemen om te voorkomen dat een doelstelling ontbreekt, en in sommige gevallen kunnen deze gegevens worden gebruikt als gedeeltelijke begrotingsrechtvaardiging. De gegevens kunnen aantonen waar de doelstellingen van het serviceniveau worden overschreden als er geen passende maatregelen worden genomen. Aangezien deze doelstellingen door de zakelijke dienstverlening en de toepassingen zijn vastgesteld, zijn zij ook gemakkelijker te rechtvaardigen op financiële basis.

Deze beoordelingen om de twee weken uitvoeren en om de zes tot twaalf weken een grondiger analytische vergadering houden. Met deze bijeenkomsten kunt u zowel op korte als op lange termijn ingaan.

Document a What-if Analytics

Een wat-als analyse model en verificatie van oplossingen inhoudt. Voordat u een nieuwe oplossing aan het netwerk toevoegt (een nieuwe toepassing of een verandering in de Cisco IOS release), documenteert u een aantal van de alternatieven.

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

Document de methodologie die wordt gebruikt voor het verhogen van de netwerkprestaties

Deze documentatie omvat extra WAN bandbreedte en een kostentabel die de bandbreedte voor een bepaald type link helpt vergroten. Deze informatie helpt de organisatie te realiseren hoeveel tijd en geld het kost om de bandbreedte te vergroten. Formele documentatie stelt prestatie- en capaciteitsdeskundigen in staat te ontdekken hoe en wanneer de prestaties te verbeteren, evenals de tijdlijn en de kosten voor een dergelijke inspanning.

Deze documentatie periodiek te herzien, wellicht als onderdeel van de prestatietoetsing op kwartaalbasis, om ervoor te zorgen dat zij actueel blijft.

Samenvatting

De enige manier om de doelstellingen van het ideale netwerkbeheersysteem te bereiken is de componenten van het prestatiebeheer actief in het systeem te integreren. Dit doel moet het gebruik van de beschikbare en responstijdmetriek in een meldingssysteem omvatten wanneer de drempelwaarden worden overschreden. Het zou het gebruik van een basislijn voor capaciteitsplanning moeten omvatten die gekoppeld zou zijn aan een heuristisch model voor provisioning en rapportage van uitzonderingen. Het zou een ingebouwde modellering of simulatiemotor kunnen hebben die het model in real time kan worden bijgewerkt en een niveau van zowel planning als probleemoplossing door middel van softwaresimulaties kan bieden.

Hoewel een groot deel van dit systeem een onmogelijk ideaal zou kunnen lijken dat nooit zou kunnen worden verwezenlijkt, is elk van de componenten vandaag de dag beschikbaar. Verder zijn de gereedschappen om deze componenten te integreren ook aanwezig in programma's zoals MicroMuse. We moeten blijven werken aan dit ideaal omdat het vandaag de dag realistischer is dan ooit.

Gerelateerde informatie

• Whitepaper over technologie met hoge beschikbaarheid
• Whitepaper over capaciteit en prestatiebeheer
• Technische ondersteuning en documentatie – Cisco Systems

Revisiegeschiedenis