Service of Quality, eller QoS, er et sammensatt emne. Men bruken er så vanlig i disse dager at hver nettverksadministrator bør vite om det. QoS ble populært ettersom flere og flere nettverk begynte å bære data som må prioriteres, samtidig som bruk av fritidsnettverk ble mer og mer vanlig. Intensjonen vår er ikke å gjøre deg til QoS-eksperter, men i stedet ønsker vi å belyse emnet er så mye som en ikke-teknisk måte som mulig. Tu sa det enkelt, vårt mål med dette er å svare på følgende spørsmål: Hva er QoS, og hva er det bra for?
Dette er ikke et kurs i QoS teori oggjennomføring. Vi vil ikke vise deg en eneste bytte eller ruterkommando. Målet vårt er å la deg bare forstå essensen i QoS. Vi begynner med å avklare hva QoS er - og ikke. Etter det tar vi en kort pause for å diskutere noen få verktøy fra SolarWinds som du kanskje vil prøve. Deretter diskuterer vi de forskjellige faktorene som kan påvirke nettverksytelsen. Dette vil ta oss til kjernen i vår sak: hvordan QoS fungerer. Som du vil se, er det mye enklere enn det ser ut. Og før vi konkluderer, diskuterer vi hva som skjer når du ikke bruker QoS og hva QoS ikke kan hjelpe deg med.
Så, hva er QoS, nøyaktig?
Etter hvert som nettverksbruken vokste til å omfatte mer og mertrafikk av forskjellig type og etter hvert som trafikkstoppingen ble mer og mer hyppig og viktig, innså ingeniører at de trengte en måte å organisere og prioritere trafikk på. QoS er ikke en ting, men en kombinasjon av funksjoner og teknologier som fungerer sammen for å oppnå det. Gjennom mye prøving og feiling har vi nå et relativt universelt QoS-system som kan brukes til å pålitelig sikre at viktig trafikk får den oppmerksomheten den trenger.
Et viktig aspekt ved QoS er at det må være detimplementert fra ende til annen for å være til nytte. QoS er satt opp på enhetene - for eksempel brytere og rutere - som håndterer trafikk. Enhver slik enhet i datafanen må ha riktig QoS-konfigurasjon, ellers har ikke ting den forventede effekten. Hver enhet må også ha en QoS-konfigurasjon som er kompatibel med de andres. QoS bruker prioriterte markeringer for å oppnå sin magi. Du kan lett forestille deg hva som ville skje hvis en enhet ansett høye prioriteringer som viktigere, mens en annen gjorde det motsatte.
En virkelighetsanalogi
Vi sammenligner ofte nettverk med biltrafikkder motorveier representerer nettverkskoblinger og kjøretøy representerer datapakker. Det er en ganske god analogi, da det er mange likheter mellom de to trafikktypene. Sannsynligvis mer enn det er forskjeller. Vi bruker den samme analogien for å prøve å konkret forklare hva QoS er.
Så la oss tenke oss en travel motorvei. Det er fredag ettermiddag i rushtiden, og det er mange biler og lastebiler. Trafikken beveger seg allerede ganske sakte, men for å gjøre ting verre, nærmer vi oss et veikryss, og på den andre siden av krysset skjer det noe veiarbeid som ikke gjør annet enn å legge til problemet. De fleste av dere har mer enn sannsynlig vært i en slik situasjon.
For å prøve å hjelpe trafikken til å gå litt bedre,det er en trafikkjef i det neste krysset. Han gjør sitt beste for å prøve å gi hver eneste bilist sin rettferdige del av veien. Men selv med hans assistanse, beveger ikke ting seg mye, og liker det eller ikke, sitter du fast i trafikken.
Så på avstand hører du en ambulansesirene kommer bak deg. Dette er når trafikkjefen i krysset skifter i høyt gir. Han erkjenner at ambulansen virkelig trenger å passere, og sørger for å la trafikken foran ambulansen gå gjennom og stoppe motstanderen av trafikken, og sørger for at den kan fortsette sin rute med så liten forsinkelse som mulig. I mellomtiden må andre bilister vente på sin tur før de kan gjenoppta ruten når det prioriterte kjøretøyet har passert.
To flotte verktøy fra SolarWinds
Før vi går videre, vil jeg diskutere enfå verktøy fra SolarWinds. Selv om de ikke er direkte relatert til QoS, er begge veldig nyttige for å identifisere hvor det er flaskehalser i nettverkene dine og hva som forårsaker dem. De vil hjelpe deg med å vurdere dagens situasjon, som er det første trinnet i å rette problemer generelt og implementere QoS.
1. Network Performance Monitor (Gratis prøveperiode)
SolarWinds 'flaggskip-produkt, nettverketPerformance Monitor er muligens et av de beste overvåkingsverktøyene for SNMP båndbredde. Dette er et verktøy som vil bruke Simple Network Management Protocol for å tegne utviklingen av nettverkskretsens båndbreddebruk over tid. Programvarens instrumentbord, visninger og diagrammer kan tilpasses helt. Verktøyet kan settes opp med minimal innsats og kan begynne å overvåke nesten umiddelbart etter installasjon. NPM kan skalere fra de minste nettverkene til store nettsteder med hundrevis av enheter spredt over flere nettsteder.
GRATIS 30-DAGERS prøve: SolarWinds Network Performance Monitor
SolarWinds Network Performance Monitor brukerSNMP å polle enheter med jevne mellomrom - vanligvis fem minutter - og lese grensesnittstellene deres. Den beregner deretter båndbreddeutnyttelsen lagrer den i en database for fremtidig referanse og viser grafer som viser utviklingen av båndbreddebruk over tid. NPM er et stort verktøy med flere ekstrafunksjoner. For eksempel kan den bygge nettverkskart og vise den kritiske banen mellom to enheter.
Prisene for Network Performance Monitor starter på rundt 3000 dollar. En 30-dagers prøveversjon er tilgjengelig hvis du foretrekker å prøve produktet før du kjøper det.
2. NetFlow Traffic Analyzer (Gratis prøveperiode)
SolarWinds NetFlow Traffic Analyzer giradministrator en mer detaljert oversikt over nettverkstrafikk. Det viser ikke bare bruken av båndbredde i biter per sekund. Verktøyet gir detaljert informasjon om den observerte trafikken. Den vil fortelle deg hvilken type trafikk som er mer utbredt, eller hvilken bruker som bruker mer båndbredde. Det vil også gi uvurderlig informasjon om forskjellige typer trafikk - som nettlesing, forretningsapper, telefoni eller streamingvideo - som føres i nettverket ditt.
GRATIS 30-DAGERS prøve: SolarWinds Netflow Traffic Analyzer
NetFlow Traffic Analyzer bruker NetFlowprotokoll for å samle detaljert bruksinformasjon fra nettverksenhetene dine. NetFlow-protokollen er innebygd i mange nettverksenheter fra forskjellige leverandører. Når de er konfigurert, sender nettverksenheter detaljert informasjon om hver nettverk “samtale” eller flyt til en NetFlow-samler og analysator. SolarWinds NetFlow Traffic Analyzer er en slik samler og analysator.
Hvis du vil prøve produktet før du forplikter deg til å kjøpe det, kan en gratis 30-dagers prøveversjon lastes ned fra SolarWinds. Dette er en fullt utstyrt versjon som ikke har noen begrensning, men tid.
Faktorer som påvirker nettverksytelsen
I et typisk nettverk kan datatilførsel påvirkes av flere faktorer. Vi har satt sammen en liste over de viktigste faktorene som kan påvirke nettverksytelsen.
Lav gjennomstrømning
Dette har med kapasiteten til en nettverkskobling å gjøre. Noen takler mer trafikk enn andre. Det måles vanligvis i bit - eller ofte kilo eller megabit - per sekund. Hvis du overskrider koblingens kapasitet, vil overbelastning oppstå og ytelsen blir forringet.
Droppet pakker
Pakker kan droppes av nettverksenheter formange grunner. Kanskje de ble ødelagt i transitt og ikke kan bli gjenkjent lenger. Men mer ofte blir pakker droppet når de ankommer en enhet hvis buffere allerede er fulle. Den mottakende applikasjonen vil vanligvis innse at noen data mangler og be om overføring av dem, noe som vil føre til ytterligere forsinkelser og forringelse av ytelsen.
feil
Støy og interferens kan ødelegge data. Dette gjelder spesielt i trådløs kommunikasjon og over lange kobberledninger. Når det oppdages feil, vil den mottakende applikasjonen be om at de manglende dataene skal overføres på nytt, noe som igjen ødelegger ytelsen.
Ventetid
Latency har å gjøre med nettverksenheter i kødata før du sender den ut. Det kan også skje når lengre ruter brukes for å unngå overbelastning. Det skal ikke forveksles med gjennomstrømning. Med latenstid kan forsinkelsen bygge seg opp over tid, selv om gjennomstrømningen er tilstrekkelig.
jitter
Jitter er definert som en variasjon i forsinkelsentar for hver datapakke å nå sin destinasjon. Det skjer av forskjellige grunner. For eksempel kan to pakker ta forskjellige ruter. Konsekvensen er at når jitter blir for høyt, kan pakker ankomme rekkefølgen til deres destinasjon. Hvis pakkene er del av et Word-dokument, vil de bli ordnet riktig og ingen vil bli berørt, men hvis vi snakker om tale eller strømme videodata, kan det føre til alle slags problemer.
Som vi nettopp har sett, vil noen typer trafikk - for eksempel tale- eller streamingvideo - bli mer påvirket av ytelsesproblemer. Dette er grunnen til at ulik trafikk trenger ulik håndtering og hvorfor QoS eksisterer.
Slik fungerer QoS
Før vi begynner, vil jeg oppgi noen få ting. For det første er jeg ingen nettverksingeniør. For det andre er målet med denne forklaringen ikke å være helt nøyaktig. Jeg over vitende overforenkler ting og vrir kanskje virkeligheten i en viss grad for å gjøre denne delen lettere å fordøye. Målet mitt er å gi deg en generell ide om hvordan det fungerer, ikke å trene deg på QoS-konfigurasjon.
QoS fungerer ved å identifisere hvilken trafikk som er mer“Viktig” og ved å prioritere den trafikken i hele nettverket. Det er ingen "gyldne regel" om hvilken trafikk som er viktigere enn andre. Det er klart, noe trafikk - for eksempel tale- eller streamingvideo - vil normalt bli ansett som viktig bare fordi den ikke fungerer som den skal når du lider av ytelsesforringelse. Noe trafikk - for eksempel nettlesing i mange organisasjoner - regnes som uviktig og vil derfor ikke bli prioritert.
Det er to komponenter til QoS. Først må trafikken klassifiseres og merkes. Selv om det er flere måter trafikk kan markeres, er Differensierte tjenester de mest utbredte i dag. Dette er den vi vil detaljere om kort tid. Den andre komponenten er køen som vil sikre at prioriterte data blir overført med så lite forsinkelser som mulig. Kø gjøres på nettverksenhetene i henhold til markerte differensierte tjenester.
Differensierte tjenester, eller DiffServ, bruker aseks-biters kode i overskriften til hver pakke å merke er i henhold til flere klasser med økende prioritet. Denne markeringen blir referert til som kodenummer for differensieringstjenester, eller DSCP. Typiske DSCP-verdier spenner fra 0, den minst viktige trafikken til 48, den viktigste.
Klassifisering og merking
For at nettverkstrafikken skal håndteres korrekti henhold til dens prioritet, må den først klassifiseres og merkes på riktig måte. Merking kan gjøres rett ved kilden. For eksempel er det ikke uvanlig at IP-telefonsett markerer trafikken sin som DSCP 46, en høy prioritert verdi. For trafikk som ikke er merket ved kilden, er ting litt mer komplisert.
Umerket trafikk eksisterer faktisk ikke medDiffServ. Som standard er all trafikk merket DSCP 0, den laveste prioriteten. Det er opp til den første nettverksenheten som håndterer trafikken - vanligvis en bryter - for å merke den. Hvordan gjøres det? Mest gjennom ACL-er.
ACL-er, eller tilgangskontrollister, er en funksjon avmest nettverksutstyr som kan brukes til å identifisere trafikk. Som navnet tilsier, ble de opprinnelig brukt som et middel til å kontrollere tilgangen. ACL-er identifiserer trafikk basert på flere kriterier. Blant dem, desto vanligere er IP-adressen til kilden og destinasjonen og portnummeret til kilden og destinasjonen. Gjennom årene har ACL-er blitt mer og mer raffinert og kan nå brukes til å velge nøyaktig en veldig spesifikk trafikk.
Når det gjelder ACL-er som brukes til å sette inn QoS-markeringer, angir reglene ikke bare hvordan du skal gjenkjenne trafikk, men også hvilken DSCP-verdi du skal merke den med.
Queuing
Nå som trafikken er merket, er alt det som gjenstårprioriter den i henhold til markeringen. Dette oppnås normalt ved å bruke flere køer med økende prioritet. Selv om DSCP-verdiene er 6-bits brede og derfor kan variere fra 0 til 63, bruker nettverksutstyr sjelden så mange køer. Det er typisk for de fleste nettverksutstyr å bruke fra tre til syv køer, hvor fem er det vanligste tallet. Med fem køer og over 60 markeringer, har du helt klart funnet ut at mer enn én DSCP-verdi går i hver kø.
Kø med lavest prioritet, som ofte kallesden beste innsatsen eller BE-køen er den som får minst oppmerksomhet fra dirigeringsmotoren. Motsatt vil den høyeste prioriterte køen, som vi ofte kaller sanntid eller RT, få mest oppmerksomhet. Dette sikrer at "viktig" trafikk blir dirigert eller byttet i prioritet. Selvfølgelig betyr dette også at best innsats kan bli alvorlig forsinket og kanskje til og med aldri bli levert. Dette er noe du må huske på når du klassifiserer og markerer beste innsats for trafikk
Konsekvenser av ikke å bruke QoS
Konsekvensene av å ikke bruke QoS varierer mye. Hvis nettverket ditt for eksempel ikke har veldig følsom trafikk som IP-telefoni eller streaming av video, kan det å gjøre ikke bruk av QoS gjøre noen forskjell. Dette gjelder spesielt når de nåværende trafikknivåene dine er lave. I en situasjon med lite trafikk gir QoS faktisk ingen fordeler. Hvis vi går tilbake til motorvei-analogien vår. Hvis ambulansen er alene på en motorvei med 5 felter, trenger den ikke å prioriteres.
Men i situasjoner der nettverket ditt lider undernoen - eller mange - problemer som overutnyttelse og overbelastning, vil fraværet av QoS føre til alle slags problemer. For trafikk som krever overføring i sanntid eller nær sanntid - for eksempel IP-telefoni, kan det for eksempel være årsaken til forvirret, hakket eller uforståelig lyd. Strømming av video vil også bli påvirket, og føre til overdreven buffring under avspilling.
Men selv andre tjenester kan lide avfravær av QoS. Se for deg at en bruker av et bedriftsnettverk prøver å få tilgang til et viktig nettbasert regnskapssystem, samtidig som hundrevis av brukere er på lunsjpausen og surfer på Internett. Dette kan gjøre regnskapsapplikasjonen ubrukelig med mindre trafikken er riktig prioritert ved bruk av QoS.
QoS vil ikke fikse alt
Men så bra som det er, er det ikke implementering av QoSløsning på alle problemer. Nettverksadministratorer har en tendens til å tro at implementering av QoS vil avlaste dem fra behovet for å legge til båndbredde. Selv om det er sant at implementering av QoS vil føre til en øyeblikkelig og veldig tydelig forbedring av driften av høyprioritert trafikk. Det vil også forringe lavere prioritet.
QoS vil ta seg av midlertidig nettverkoverbelastning og det vil sikre at forretningskritiske tjenester fortsetter å fungere korrekt mens det er overbelastning, men det vil ikke stoppe det. Du må fortsatt overvåke nettverksbruk og ha et kapasitetsplanleggingsprogram på plass.
Konklusjon
QoS bør være en del av enhver organisasjons nettverkstrategi, men det skal ikke være den eneste varen. Men mer enn noe annet, bør ekstrem forsiktighet tas i bruk i planlegging og konfigurering av QoS. Selv om det kan gjøre små mirakler når den brukes riktig, kan det gjøre situasjonen mye verre for visse brukere. Og før du implementerer QoS, bør også overvåkingsverktøy settes på plass for å vurdere situasjonen. De samme verktøyene vil også være uvurderlige etter implementering.
kommentarer