5 netwerkstatistieken voor een cloudwereld

Nu het netwerk is geëvolueerd van een fysieke naar een meer abstracte, heeft IT moedig gelijke tred gehouden door nieuwe netwerkapparaten en -functionaliteit te onderzoeken en in te zetten. IT-teams moesten de werklast en mentaliteit verschuiven naar de cloud en naar SaaS-providers, terwijl ze verantwoordelijk bleven voor de eindgebruikerservaring, wat steeds belangrijker wordt. Maar welke netwerkstatistieken kunnen het succes van een cloudimplementatie aantonen?

Het is een verward web in de netwerkwereld van vandaag, maar niet alles is verloren. We raden deze vijf statistieken aan als bouwstenen voor het meten van de eindgebruikerservaring en netwerkprestaties in de cloud. Ze zullen er waarschijnlijk vrij bekend uitzien:het zijn dezelfde oude statistieken die nuttig waren in de pre-cloudwereld, en kunnen nu ook waardevolle inzichten bieden (hoewel je in de cloud moet kunnen kijken om ze te krijgen —AppNeta kan hierbij helpen). Deze netwerkstatistieken kunnen uw favoriete cloudstatistieken worden.

1. Latentie. Deze statistiek meet de tijd die pakketten nodig hebben om van de bron naar de bestemming te reizen, asymmetrisch gemeten om overeen te komen met de asymmetrische aard van internet. Latency gaat over perceptie, dus de perceptie van latency is verschillend voor verschillende gebruikers en applicaties. Vroeger, toen 100 mensen een lokale applicatie gebruikten, was 10 milliseconden latentie geen probleem. Maar nu zijn er duizenden mensen die een app in de cloud gebruiken, en een tienvoudige toename van de latentie (100 milliseconden) is niet acceptabel.

Bovendien zijn webapplicaties erg spraakzaam. Een web-app bestaat uit een reeks verzoeken en antwoorden van de client naar de webserver. De toename van de latentie zal dus van invloed zijn op elk van deze verzoeken en gedownloade objecten. Voor een bedrijfskritieke SaaS-app kan de verhoogde latentie een groot effect hebben op de productiviteit.

Zodra je hebt vastgesteld dat latentie een probleem is, moet je uitzoeken waar het zich voordoet. Het kan in uw netwerk zijn, uw wifi, uw WAN-verbinding, via het open internet of zelfs in de omgeving van uw serviceprovider. Naast eenvoudige probleemoplossing, hebt u betere hulpmiddelen nodig. Eenvoudige methoden zoals traceroute kunnen een globaal idee geven van de route van de gebruiker naar de app, maar de routes zullen waarschijnlijk elke keer anders zijn.

2. Pakketverlies . Dit is het percentage netwerkpakketten dat verloren gaat tussen de bron en de bestemming. Afhankelijk van het gebruikte protocol kan pakketverlies leiden tot netwerkcongestie, tijdverspilling en gefrustreerde gebruikers. In kleine bursts kunnen netwerken verlies aan, maar als het verlies groter wordt, kan dit ernstige gevolgen hebben voor eindgebruikers.

Toen apps allemaal intern via het LAN werden gehost, was pakketverlies niet echt een probleem. Als er pakketverlies was, was het vrij eenvoudig te vinden en op te lossen. Maar op het open internet is het een ander verhaal. Internetprotocol TCP garandeert levering, maar als het pakketverlies detecteert en de gegevens opnieuw verzendt, voegt het latentie toe en leidt het tot overbelaste netwerken.

In de hedendaagse VoIP- en videostreamingtoepassingen kan pakketverlies bijzonder merkbaar zijn, met verbroken oproepen en slechte kwaliteit. Het is mogelijk om pakketverlies onafhankelijk op te sporen op zowel data als spraak als je die applicaties ondersteunt.

3. Capaciteit. Capaciteit heeft de bandbreedte overgenomen, wat vroeger een primaire netwerkstatistiek was. Nu zijn padgebaseerde statistieken zoals capaciteit echter meer indicatief voor de gebruikerservaring. Capaciteit is een end-to-end meeteenheid die de maximaal mogelijke transitsnelheid tussen bron en bestemming meet, beperkt door de meest overbelaste hop langs het applicatieleveringspad. Dit wordt vooral belangrijk bij het overwegen van cloudservices, omdat je geen controle hebt over het netwerk van een provider en niet weet hoe snel de verbinding werkelijk is.

Het meten van capaciteit meet het daadwerkelijke applicatiepad, inclusief wifi. En continue monitoring, inclusief capaciteit, is wat nodig is bij het gebruik van dynamisch internet.

Er zijn twee soorten capaciteit:beschikbaar en benut. Beschikbaar is de meest nauwkeurige meting van netwerkbronnen die beschikbaar zijn voor toepassingen en kan de hoofdoorzaak van degradatie identificeren. Als we kijken naar de benutte capaciteit, is een hoge bezettingsgraad een sterke indicator voor prestatievermindering. Het is mogelijk om de tijd voor het oplossen van problemen te verminderen bij het volgen van de capaciteit door te isoleren waar de langzaamste hops zijn.

4. Jitter. Deze statistiek geeft het percentage pakketten weer met vertragingsvariatie tussen bron en bestemming. Wanneer jitter problematisch is, is het goed zichtbaar. De kwaliteit van een gesprek of online vergadering kan worden beïnvloed met een jitter van slechts 30 tot 40 ms.

5. Kwaliteit van de dienstverlening. Deze statistiek is gekoppeld aan de routeringsprioriteit voor verkeer via specifieke poorten of protocollen. Het is van belang wanneer congestie een netwerk treft, aangezien QoS zorgt voor een goede ervaring op bedrijfskritieke applicaties. Voor sommige apps, zoals VoIP of video, kan het netwerk jitter, gegevensverlies en latentie ervaren als die routeringsprioriteiten worden verlaagd of opnieuw worden gemarkeerd.

In deze wereld van clouduitdagingen en -mogelijkheden is het gemakkelijk om de oude netwerkstatistieken uit het oog te verliezen. Maar deze vijf statistieken zijn een goede manier om de juiste hoeveelheid controle over uw apps en gebruikerservaring terug te krijgen.