QOS ja of nee

[Verwijderd]

Ik heb wat kleine probleempjes bij een klant van mij. Hierover krijg ik steeds verschillende adviezen maar het is allemaal ik denk...Dus dacht ik laat ik eens kijken of er hier mensen zijn met ervaring. Het gaat om het volgende:

De klant heeft 30 vestigingen door heel nederland welke met E-pacity van KPN gekoppeld zijn aan ons datacenter. In dit datacenter draait voor de betreffende klant een volledige SBC oplossing. De gebruikers connecten dus via RDP aan deze omgeving. Nu zijn er de laatste tijd traagheden in de omgeving. Hier is onderzoek naar gedaan en één van de oplossingen was het upgraden van lijnen naar 1:1 verbindingen met QOS (quality of service). In die 1 : 1 verbindingen kan ik mij vinden. Met QOS heb ik echt zoiets wat is de toegevoegde waarde, en hoe moet het geimplementeerd worden. Is het een paar settings in een router of is het echt een heel traject?

Heeft er iemand ervaring mee en kan iemand wat roepen?

Grtz!

[Bor]

Als je aan QoS wilt beginnen moet je er rekening mee houden dat echt elk netwerkapparaat op het traject QoS moet ondersteunen, anders werkt het niet.

[Question Mark]

Sorry, maar ik begrijp je bedoeling niet helemaal. Er is een datacenter wat sinds een bepaalde tijd trager performt. Er is onderzoek naar gedaan en hier komen twee adviesen uit. Nu vraag je aan ons of deze twee adviesen de oplossing bieden? Dan zal je toch echt meer info over het probleem en de achtergronden moeten geven. "Traagheid in de omgeving" zegt me nl. niets.

Overigens zou ik me eerst af gaan vragen waardoor het ineens trager geworden is...

[ Voor 6% gewijzigd door Question Mark op 28-08-2005 19:09 ]

[Pacjack]

Question Mark schreef op zondag 28 augustus 2005 @ 19:05:...zou ik me eerst af gaan vragen waardoor het ineens trager geworden is...

Daar heb je wel gelijk in Maar in dit topic is het wel interessant om het nut van QOS duidelijk te maken in de beschreven situatie.

[Verwijderd]

De bedoeling is te begrijpen wat QoS nou precies is en wat de voordelen zijn in de situatie wanneer je met Citrix of Terminal Servers van MS werkt. Daarnaast wil ik weten wat je precies moet doen om het te implementeren, indien er een grote investering aan vooraf gaat kan het advies richting de klant ook zijn dat het wel kan en voordelen biedt maar dat die voordelen niet opwegen tegen de kosten.

Ik ben overigens de Projectmanager van dit traject en hoor veel verschillende adviezen vandaar mijn vraag.

Op de vraag wat er voor gezorgd heeft dat het ineens trager is, is geen eenduidig antwoord te geven. Er zijn een stuk of wat acties, welke ook geimplementeerd worden. Deze staat nog open en ik twijffel.

[bjck]

Move IT --> PNS

[The Eagle]

Disclaimer: ik ben niet echt bekend met SBC, maar ik gok even snel dat het hier om een TS-omgeving gaat Zo ja: welke
Vertragingen kunnen (maar hoeft niet!) duiden op te trage lijnen. Asymetrische verbindingen kan dan een oorzaak zijn, maar ook dat is niet per definitie zo
Ik hoorde laatst (topic van een paar weken terug, kan me het onderwerp zo niet voor de geest halen) iets over het verbreken van TS verbindingen door deze niet op de juiste manier af te sluiten. De gebruikers sloten daar de clients af door op het kruisje rechts in de bovenhoek te klikken...dat werkt, maar de terminal sessie draaide in dat geval gewoon door. Dat vreet geheugen. Wellicht is dat de oorzaak van de traagheid van het datacenter - gebruikers (en dat hoeft er maar 1 te zijn, die het constant fout doet) die gewoon niet op de juiste manier afsluiten, i.c.m. een verkeerde memory release instelling van de terminal server(s).

Maar meten is in dit geval weten: zet meetapparatuur (packeteer of een software-oplossing)) tussen de verbindingen, en zoek naar de oorzaak ipv de oplossing. Als het aan de datalijnen ligt, weet je dat na een weekje meten gauw genoeg Ik verwacht het echter niet; anders had je dat (er vanuit gaande dat er niks aan de verbindingen is veranderd) wel eerder gemerkt. Ik denk dus echt dat jehet ergens van buitenaf moet zoeken, dus bij de klant zelf Tenzij je net de TS omgeving aangepast hebt natuurlijk

Ten aanzien van QOS: ik ken weinig bedrijven die het ook echt gebruiken. Omdat de hele keten er aan moet voldoen (hoe groot is de kans dat je datacenter ook helemaal QOS-compliant is?) zijn de kosten hoog. En met maatwerk zal die klant ook niet echt blij zijn, zeker niet als jullie (en zijzelf ook!) daarvoor QOS compliant moeten worden. Daarnaast is de zekerheid dat het daarmee wel werkt klein - welk bedrijf zal op dit moment die investering aandurven?

[Brahiewahiewa]

Hmmz, als je toch project manager ben, zou ik zeggen: maak een stukje budget vrij voor het inhuren van een onafhankelijke consultant en laat die analyseren waar het probleem vandaan komt.

'k Bedoel maar: als je HP inhuurt, gaan die ongetwijfeld zeggen dat je servers processor- en memory upgrades nodig hebben. En als je Cisco inhuurt, gaan die zeggen dat je QoS moet gebruiken en dus nieuwe routers kopen. Huur je Citrix in, gaan die zeggen dat je meer servers (en dus meer licenties) nodig hebt.

Overigens is het opzetten van QoS inderdaad geen sinecure. Bovendien wordt het vaak ten onrechte aangeraden. Als je - zoals in jouw situatie - maar één type netwerk verkeer hebt, namelijk RDP of ICA, dan valt er niet zoveel te QoS-en. Je kunt niet vaststellen of gebruiker A achter de ene terminal belangrijker werk doet dan gebruiker B achter de andere terminal. QoS wordt pas interessant als je meerdere typen netwerk verkeer hebt (VOIP, NetBIOS, RDP/ICA, X400/SMTP, etc.)

[Question Mark]

Pacjack schreef op zondag 28 augustus 2005 @ 20:27:
[...]
Maar in dit topic is het wel interessant om het nut van QOS duidelijk te maken in de beschreven situatie.

Klopt, maar nog interessanter is het om een oplossing voor het probleem van de TS boven water te krijgen. Het evt. implementeren van QOS is hier slechts een onderdeel van. Handiger is het om het probleem als geheel te onderzoeken.

Symptomen --> Oorzaak --> Oplossing --> Implementatie --> Controle

QOS heeft, zoals Brahiewahiewa terecht opmerkt, weinig zin als al het verkeer van hetzelfde type is. Een upgrade van een verbinding doet ook weinig als het probleem veroorzaakt wordt door te weinig CPU-kracht in de Terminal Servers. Zonder meer informatie over het probleem kan niemand hier een advies geven of het implementeren van QOS de problemen van de TS oplost. Dan wordt dit topic puur een topic over de werking van QOS, maar deze informatie kan zo op de Cisco site opgezocht worden.

TS: wat zijn precies de problemen die de gebruikers ondervinden?

[ Voor 7% gewijzigd door Question Mark op 29-08-2005 08:02 ]

[Verwijderd]

Er zijn een aantal onderzoeken geweest en deze wijzen uit dat het CPU, memory gebruik, disk que's etc etc acceptabele waarden heeft, ongeveer 40% belasting. Hierin zitten de problemen dus niet, ook het gebruik van de omgeving is niet echt toegenomen, maar de sessies zijn tov. januari wel gegroeid (van ongeveer 140 mb --> 170 mb per sessie)

Wat je wel ziet is dat bv. internet verkeer aanmerkelijk is toegenomen, waarbij je ziet dat sites met bewegende beelden (flash etc) een hoop bandbreedte verbruiken, aangezien de refresh van de sessie informatie meer is dan een paar lettertjes....(gemeten 50-70k per sessie daadwerkelijk gebruik, lijnen worden hierop geschaald, alleen nu de vraag QoS hierop activeren of niet)

Daarnaast is er een applicatie welke slecht functioneert, ook dit wordt aangepakt.

Kortom een hoop oorzaken welke voor algemene performance verslechtering zorgen.

[Verwijderd]

Nee, dat gaat zo niet werken, met qos is het de bedoeling dat je pakketjes voorrang geeft boven andere pakketjes. Het is dus de bedoeling kwaliteit op te offeren bij de ene ten bate van andere connecties.

Dus inderdaad eerst goed analiseren, aan de hand van de nu gegeven informatie kun je geen goed besluit nemen.

[nescafe]

Kun je dan niet beter voor het "onbelangrijke verkeer" (w.m.b. is een site met flash-banners etc. niet belangrijk genoeg om je e-pacity-lijn mee te bevuilen) per vestiging een cheap ADSL-lijntje aanvragen?

[ Voor 9% gewijzigd door nescafe op 29-08-2005 08:57 ]

[Bierkameel]

Of een caching proxy servertje zoals Squid op Linux, dat moet aardig schelen als ze toch gaan internetten via RDP.
Alhoewel 30 sites wel erg veel is.

[Abom]

Met een proxy bereik je niet veel. Het probleem is de data die verstuurd moet worden naar de clients, niet het internet verkeer wat er gegenereerd wordt.

Wij hebben nu ook een performance probleem in een branch office. Zodra er geinternet wordt, wordt de lijn dicht getrokken.
Één van de opties die ik wil bekijken zijn 'lokaal' internetten. Een thin-client met Windows XP Embedded als OS en dan de eindgebruikers die moeten kunnen internetten, de applicatie lokaal laten starten ipv remote.
Andere opties die ik bekeken (en nog niet afgeschreven heb) zijn WAN accelerators of gewoon het hele 'surf' beleid voor deze vestiging aanpassen.

[TrailBlazer]

Verwijderd schreef op maandag 29 augustus 2005 @ 08:48:
Nee, dat gaat zo niet werken, met qos is het de bedoeling dat je pakketjes voorrang geeft boven andere pakketjes. Het is dus de bedoeling kwaliteit op te offeren bij de ene ten bate van andere connecties.

Dus inderdaad eerst goed analiseren, aan de hand van de nu gegeven informatie kun je geen goed besluit nemen.

QoS wil niet altijd zeggen dat je pakketjes voorrang geeft. Over het algemeen geef je een bepaalde klasse een gegarandeerde bandbreedte of een maximale bandbreedte. Je praat nu dus nog niet over voorrang. Voorrang wordt het pas als je over priority queuein gaat praten. Dit wordt eigenlijk alleen bij voip toegepast.
Overigens hoeft de overboeking geen probleem te zijn echter QoS wordt alleen geleverd op 1 op 1 omdat QoS anders geen zin heeft.
Qos implementeren is niet het meest eenvoudige op een cisco. Zeker als je gewoon werkt met de CLI en niet werkt met autoqos. Ik raad je wel de CLI methode aan.
Tja verder is het gewoon handig om dit uit te besteden aan een extern bedrijf als je er zelf geen verstand van hebt.
Als het inderdaad een internet/bandbreedte probleem is dan kan dit zeker met QoS worden opgelost
Identificeer eerst het probleem en ga dan kijken hoe en wat

[ Voor 5% gewijzigd door TrailBlazer op 29-08-2005 11:26 ]

[Verwijderd]

Wat heb je aan QOS als alle pakketten dezelfde qualiteit standaard hebben?
QOS heeft alleen voordeel als je verschillende pakketten kan benoemen. VOIP t.o.v. DATA etc.
volgens mij is het niet mogelijk RDP verkeer voorrang te geven op niet RDP verkeer...

[TrailBlazer]

Verwijderd schreef op maandag 29 augustus 2005 @ 11:31:
Wat heb je aan QOS als alle pakketten dezelfde qualiteit standaard hebben?
QOS heeft alleen voordeel als je verschillende pakketten kan benoemen. VOIP t.o.v. DATA etc.
volgens mij is het niet mogelijk RDP verkeer voorrang te geven op niet RDP verkeer...

QoS werkt in de Epacity wolk op basis van het DSCP veld in de IP header. Dus kwestie van de goede bitjes in het ip packet zetten dmv van acl's en route maps ed en je kan zelfs bittorent een gegarandeerde bandbreedte geven.

[Brahiewahiewa]

TrailBlazer schreef op maandag 29 augustus 2005 @ 11:37:
[...]QoS werkt in de Epacity wolk op basis van het DSCP veld in de IP header. Dus kwestie van de goede bitjes in het ip packet zetten dmv van acl's en route maps ed en je kan zelfs bittorent een gegarandeerde bandbreedte geven.

Ja maar het punt is dus dat je bijvoorbeeld bittorent alszodanig niet kunt herkennen, omdat het terminal clients zijn en er dus alleen RDP/ICA over je WAN verbindingen gaat. (nog even afgezien van de vraag of KPN zelf al niet QoS toepast in hun e-pacity wolk en de DSCP velden doodleuk overschrijft)

Anyway, in dit specifieke geval zou je meer hebben aan een packet shaper; die kan TCP sessies knijpen, zodat iedere terminal een maximale hoeveelheid bandbreedte krijgt*. Dan garandeer je een minimale bandbreedte voor mensen die legitiem zitten te werken en mensen die filmpjes zitten te kijken moeten maar wennen aan een wat slechtere beeldkwaliteit. Tenzij er een business reason is voor het kijken van filmpjes; in dat geval moet je je lijnen upgraden.

*) theoretisch kan QoS dit ook, alleen een packet shaper doet 't wat intelligenter, door in te grijpen in het sliding windows protocol.

[TrailBlazer]

Brahiewahiewa schreef op maandag 29 augustus 2005 @ 15:12:
[...]
Ja maar het punt is dus dat je bijvoorbeeld bittorent alszodanig niet kunt herkennen, omdat het terminal clients zijn en er dus alleen RDP/ICA over je WAN verbindingen gaat. (nog even afgezien van de vraag of KPN zelf al niet QoS toepast in hun e-pacity wolk en de DSCP velden doodleuk overschrijft)

Anyway, in dit specifieke geval zou je meer hebben aan een packet shaper; die kan TCP sessies knijpen, zodat iedere terminal een maximale hoeveelheid bandbreedte krijgt*. Dan garandeer je een minimale bandbreedte voor mensen die legitiem zitten te werken en mensen die filmpjes zitten te kijken moeten maar wennen aan een wat slechtere beeldkwaliteit. Tenzij er een business reason is voor het kijken van filmpjes; in dat geval moet je je lijnen upgraden.

*) theoretisch kan QoS dit ook, alleen een packet shaper doet 't wat intelligenter, door in te grijpen in het sliding windows protocol.

in een cisco kan je ook per applicatie binnen een isa sesie verkeer markeren dmv nbar. Overigens als je betaalt aan KPN dan zet KPN QoS aan op jouw poorten. Je kan dan zelf kiezen tussen priority queuing of een bepaalde bandbreedte per klasse. In ieder geval dat was zo toen ik dat netwerk beheerde

[Brahiewahiewa]

TrailBlazer schreef op maandag 29 augustus 2005 @ 15:27:
[...]in een cisco kan je ook...

Dat zeg ik.
Maar een QoS router kan alleen maar kiezen tussen het doorsturen, queuen of droppen van een packet. Als je niet wilt droppen (want dan gaan de computers het packet gewoon retryen en maak je 't probleem alleen maar erger) dan moet je dus queuen en dat doet een zware aanslag op de buffers van je routers. Een packet shaper verandert de packets die-ie doorstuurt zodanig dat de servers en/of clients die buffering zelf gaan doen.

[koppie]

Ik weet er niet zoveel vanaf, maar volgens mij is Citrix één applicatie, en kan je in je netwerk-apparatuur niet onderscheiden wat de gebruiker aan het doen is. Volgens mij is QOS een opmerking van een manager die ooit eens een klepel heeft gehoord, en zich weer eens niet interesseert waar de bel hangt.

Het is allemaal CITRIX-verkeer, en wat daar binnen een sessie gebeurt, kan je alleen beinvloeden op de CITRIX-servers. Bijvoorbeeld flash afzetten, of de kwaliteit bijvoorbeeld lager zetten. Dan is I-net lokaal een beter idee, en dan kan je eventueel met QOS Citrix meer prioriteit geven, maar dat kan je ook doen door internet een beetje te knijpen. Sowieso is de impact dan minder, omdat er dan ingepakte flash over het netwerk gaan, en geen frame per frame zoals bij citrix.

[TrailBlazer]

Brahiewahiewa schreef op maandag 29 augustus 2005 @ 15:57:
[...]
Dat zeg ik.
Maar een QoS router kan alleen maar kiezen tussen het doorsturen, queuen of droppen van een packet. Als je niet wilt droppen (want dan gaan de computers het packet gewoon retryen en maak je 't probleem alleen maar erger) dan moet je dus queuen en dat doet een zware aanslag op de buffers van je routers. Een packet shaper verandert de packets die-ie doorstuurt zodanig dat de servers en/of clients die buffering zelf gaan doen.

nee door te droppen zal een TCP sessie teruggaan regelen in throughput. Bufferen gebruikt inderdaad het geheugen van een router maar daar is het ook voor natuurlijk. Overigens moet je niet denken in vele Megabytes geheugen die je nodig hebt. stel dat je een 2Mbit verbinding hebt dan kan je in 2 MB geheugen al 10 seconden bufferen. Dan staat die TCP sessie wel stil hoor
Overigen met packetshapers heb ik wel eens hele vage testen gehad dat een ing er 20 seconden over deed. Klant de routering is fout ik kan niet pingen. Timeout op 30 jawel hoor sloop die ragbak packeteer er maar uit.

koppie1 schreef op maandag 29 augustus 2005 @ 16:05:
Ik weet er niet zoveel vanaf, maar volgens mij is Citrix één applicatie, en kan je in je netwerk-apparatuur niet onderscheiden wat de gebruiker aan het doen is. Volgens mij is QOS een opmerking van een manager die ooit eens een klepel heeft gehoord, en zich weer eens niet interesseert waar de bel hangt.

Het is allemaal CITRIX-verkeer, en wat daar binnen een sessie gebeurt, kan je alleen beinvloeden op de CITRIX-servers. Bijvoorbeeld flash afzetten, of de kwaliteit bijvoorbeeld lager zetten. Dan is I-net lokaal een beter idee, en dan kan je eventueel met QOS Citrix meer prioriteit geven, maar dat kan je ook doen door internet een beetje te knijpen. Sowieso is de impact dan minder, omdat er dan ingepakte flash over het netwerk gaan, en geen frame per frame zoals bij citrix.

ik weet niet of je deze link kan lezen
http://www.cisco.com/en/U...0080087f42.html#wp1066704
maar een samenvatting

match protocol citrix
To configure Network-Based Application Recognition (NBAR) to match Citrix traffic, use the match protocol citrix class-map configuration command. To disable NBAR from matching Citrix traffic, use the no form of this command.

match protocol citrix [app application-name-string]

no match protocol citrix [app application-name-string]

Syntax Description
app
(Optional) Specifies matching of an application name string.

application-name-string
(Optional) Specifies string to be used as the subprotocol parameter.


Defaults
This command has no default behavior or values.

Command Modes
Class-map configuration

Command History
Release Modification
12.1(2)E
This command was introduced.

12.1(5)T
This command was integrated into Cisco IOS Release 12.1(5)T.


Usage Guidelines
Entering the match protocol citrix command without the app keyword establishes all Citrix traffic as successful match criteria.

Examples
The following example configures NBAR to match all Citrix traffic:

match protocol citrix


The following example configures NBAR to match Citrix traffic with the application name of packet1:

match protocol citrix app packet1

kortom kan gewoon naar de app kijken binnen de citrix paketten.
Ica is toch Citrix of ben in nu gek. Ik heb verstand van Cisco enzo maar alles wat boven laag 4 zit laat maar

[Maarten @klet.st]

TrailBlazer schreef op maandag 29 augustus 2005 @ 18:35:
kortom kan gewoon naar de app kijken binnen de citrix paketten.
Ica is toch Citrix of ben in nu gek. Ik heb verstand van Cisco enzo maar alles wat boven laag 4 zit laat maar

Het hele punt is volgens mij dat de gebruikers dus teveel verkeer in hun ICA (Citrix dus) sessie gebruiken. Dus bijvoorbeeld http verkeer. Die cisco commands zorgen ervoor dat het ICA verkeer als zodanig herkend wordt, maar niet het verkeer in de ICA sessie. Dat is ook niet mogelijk, het ICA protocol verstuurd grafische gegevens, niet het verkeer waarmee een browser deze grafische gegevens kan tonen.

Dus het hoeveelheid ICA verkeer per user of sessie eerlijker verdelen (shaping of QoS, wat je wilt), OF de primaire bron van overmatig grafisch geweld aan de serverkant aanpakken. Als dat laatste het overmatig gebruik van flash is, dan is er weinig aan te doen, anders dan flash verbieden/blokkeren.
Interessant probleem. Persoonlijk vraag ik me af waar de bottleneck zit. 30 vestigingen met 2mbit/s zou 60mbit/s aan verkeer opleveren in het datacenter. Doet dat het ook, c.q. heb je daarvoor voldoende bandbreedte?

[Gomez12]

Wat gaat er allemaal over de lijn??? Is dit alleen ica verkeer dan heeft qos weinig tot geen zin, want je kan dan garanderen dat de service voor ica al de prioriteit krijgt, maar dit is al zo omdat je maar 1 type verkeer hebt.

Of werken de printers buiten ica om, gaat het internet buiten ica om.
Indien niet dan eens kijken naar tierelantijnen die aanstaan bij een default session ( ik heb wel eens een screensaver over ica zien gaan op ongebruikte computers is heel erg leuk voor je bandbreedte, office menutjes die "mooi" uitklappen zijn ook zo'n berucht verschijsel ). Onthoud dat ica in principe elke schermverandering over de lijn heen moet sturen ( dus een uitschuifend menutje van 100 px is 100x zoveel bandbreedte als een menutje wat er in 1 keer staat in theorie althans, door compressie wordt dit wel heeeel erg teruggedrongen maar toch alle tierelantijnen uitzetten )

[Verwijderd]

In essentie natuurlijk wel daar je de volgorde van versturen van pakketten aanpast.

TrailBlazer schreef op maandag 29 augustus 2005 @ 11:25:
[...]

QoS wil niet altijd zeggen dat je pakketjes voorrang geeft. Over het algemeen geef je een bepaalde klasse een gegarandeerde bandbreedte of een maximale bandbreedte. Je praat nu dus nog niet over voorrang. Voorrang wordt het pas als je over priority queuein gaat praten. Dit wordt eigenlijk alleen bij voip toegepast.
Overigens hoeft de overboeking geen probleem te zijn echter QoS wordt alleen geleverd op 1 op 1 omdat QoS anders geen zin heeft.
Qos implementeren is niet het meest eenvoudige op een cisco. Zeker als je gewoon werkt met de CLI en niet werkt met autoqos. Ik raad je wel de CLI methode aan.
Tja verder is het gewoon handig om dit uit te besteden aan een extern bedrijf als je er zelf geen verstand van hebt.
Als het inderdaad een internet/bandbreedte probleem is dan kan dit zeker met QoS worden opgelost
Identificeer eerst het probleem en ga dan kijken hoe en wat

[Abom]

De TS gebruikt RDP, geen ICA (Citrix). My bad dat ik erover begon.

Geavanceerde QoS moet ook de mogelijkheid hebben om QoS toe te passen op virtual channels (in iedergeval van ICA) binnen het protocol. Hierdoor is het dus mogelijk om verschillende soorten data, binnen het RDP protocol geprioriteerd worden.

Toch denk ik niet dat je er heel veel mee bereikt, maar ik ben dan niet echt heel erg thuis op het gebied van QoS. Ik denk dat de winstmarge heel erg minimaal is en met de verkeerde hardware zou het wel eens minder goed kunnen zijn.

Ik zou eerst kijken naar het tunen van het RDP protocol, tenzij dit al geregeld is en jullie voldoende kennis op dit gebied hebben. Standaard staan teveel onderdelen gewoon aan; zo kun je kijken of clip-board mapping en audio-mapping nodig is, zo niet, kun je dit het beste server-side uitzetten.

Never the less, denk ik dat het verstandig is om het advies van KPN toch uit te voeren, je kunt het toch nog altijd uitzetten?

Nadat je dit uitgevoerd hebt en mocht het onvoldoende blijken, kun je nog van alles proberen, overstappen op Citrix en/of WAN accelerators (van Expand bijvoorbeeld).

[ Voor 8% gewijzigd door Abom op 29-08-2005 22:05 ]

[TrailBlazer]

QoS kan kan een oplossing zijn maar het is eerst raadzaam om alles te tunen aan de applicatie voordta je iets aanschaft bij de provider. Met een beetje mazzel kan je tijdelijk QoS krijgen op een verbinding maar dan nog moet je weten hoe je je routers configged en ik heb niet het idee dat de TS instaat is dit te doen NOFI

[Maarten @klet.st]

TrailBlazer schreef op maandag 29 augustus 2005 @ 22:24:
Met een beetje mazzel kan je tijdelijk QoS krijgen op een verbinding maar dan nog moet je weten hoe je je routers configged en ik heb niet het idee dat de TS instaat is dit te doen NOFI

De TS geeft aan projectleider/manager te zijn. Die hoeft niet zelf in staat te zijn om de router te configureren, zolang hij iemand anders het kan laten doen. Ik zelf dat de TS een actieve bijdrage zal (gaan) leveren aan gathering, vanwege zijn prille lidmaatschap .

[Gomez12]

Ok 1 advies nog dan. Doe 1 ding tegelijkertijd. Doe of QoS of doe verhogen van je bandbreedte. Kijk het een maandje aan, werkt het niets. Dan kun je het 2e middel erbij gooien.
2 dingen tegelijkertijd doen heeft als nadeel dat je niet weet wat geholpen heeft en dat je op jaarbasis een leuke extra verhoging van de infrastructuur kosten hebt ( waar boekhouders niet altijd blij mee zijn )

[Zoetjuh]

Just mijn paar centjes; maar is het niet dat het vooral de Flash-sites zijn die voor problemen zorgen (doordat er dus veel visuele wijzigingen richting de client terug worden gestuurd).? Het lijkt niet dat QOS je daarme/tegen kan helpen toch?

[Parasietje]

Als voorlopige oplossing kan je inderdaad makkelijk de bandbreedte per client knijpen. Dit moet simpel te doen zijn, ofwel in de configuratie van je RDP server, ofwel mbv een traffic shaper/QoS.

Ik begrijp niet dat QoS over het hele traject moet gebeuren. Als de server uitgaande pakketjes buffert en de routers in de filialen dat ook gaan doen, worden de clients toch geknepen?


Verder zou ik eens kijken om intensieve grafische applicaties in de filialen zelf te gaan draaien, zij het op de clients, zij het op een Terminal server die daar geinstalleerd staat. Straks willen mensen ook Photoshop gebruiken en moet dat ook beperkt worden...

[hapklaar]

Zoetjuh schreef op dinsdag 30 augustus 2005 @ 00:36:
Just mijn paar centjes; maar is het niet dat het vooral de Flash-sites zijn die voor problemen zorgen (doordat er dus veel visuele wijzigingen richting de client terug worden gestuurd).? Het lijkt niet dat QOS je daarme/tegen kan helpen toch?

Wanneer je IE als published application aanbiedt wel, dan kan je shapen (met bijvoorbeeld een PacketShaper) op basis van Published Application en hierdoor IE een lagere prio geven.

Ook kan je in het geval van Citrix shapen op basis van priority tag. Interactief verkeer heeft een prio 0 (hoog) tag en Citrix printverkeer een prio 3 tag. Een shaper kan op basis hiervan pakketten voorrang geven. Je kan ook een guaranteed rate die mag bursten er op zetten, waardoor iedere sessie (flow) een minimale gergarandeerde bandbreedte krijgt.

Ik zit met eenzelfde probleem, alleen gebruiken wij geen published applications, de klant krijgt dus gewoon een ICA desktop voor zich. Als hij een drukke flashsite opent is dit allemaal prio 0 verkeer en dus niet te onderscheiden van verkeer wat wordt gegenereerd door Word/Excel/PowerPoint gebruikers...

Zie verder
http://support.packeteer....ge-citrix-performance.htm

Ik zag overigens dat er werd geadviseerd de lijnen te upgraden naar 1:1 overboeking. Dit kan helpen, helemaal als het de laatste tijd drukker is geworden op dat segment van KPN, waardoor je nu met de huidige (ik neem aan 1:4) lijnen nog maar 25% van de snelheid haalt. Overboekingen gaan pas parten spelen als het druk wordt op het netwerk tenslotte.

[hanhoo]

Naar mijn bescheiden mening zijn er twee wegen te bewandelen:

1: Zoek naar de oorzaak. Is dit daadwerkelijk een bandbreedte probleem. Indien op de coreswitch van de servers een client wordt aangesloten, ondervindt deze dan dezelfde vertraging? Ja? Servers of corenetworking. Nee? Bandbreedte
2: Indien vraag 1: Bandbreedte zul je moeten achterhalen of het probleem in de bandbreedte van het datacentre ligt of van de individuele vestiging.
3: Tenslotte ga je op zoek naar het type verkeer wat deze vertraging veroorzaakt.

Het is in dit soort copmlexe omgevingen absoluut devies om in een nominale, goedwerkende situatie een database met baseline performance gegevens aan te leggen. Dat maakt het veel eenvoudig om ervaringscijfers te vergelijken. Heb je die? Dan kun je gelijk aan de slag.

Bij gebruik van QoS, zoals eerder gelezen, ga je traffic shapen aan de hand van bepaalde gegevens (TCP poort, doel adres, afkomst adres). Alle apparatuur die hierin moet meedraaien moet idd. dit ondersteunen.

Een zeer bekende bandbreedte slokker is het printverkeer. Indien default TS-RDP kan dit oplopen tot tientallen Mb's per printopdracht. Daar is een goede workaround voor die ik ALTIJD toepas op onze Citrix servers: Maak de printers lokaal aan op de terminal server met een TCP/IP port rechtstreeks naar de printer. Je schakelt op het RDP protocol printermapping uit en maakt een script dat indien een gebruiker inlogt, zij de juiste default printer krijgen toegewezen.

Als je met zeer veel printers te maken hebt, is het eenvoudig om een aparte printserver naast de Citrix in het datacenter te plaatsen. Dan kun je via script regels een printer toewijzen aan het profiel van de gebruiker en ziet de gebruiker slechts 1 printer.

Het gevolg is dat de printopdrachten over de wan link nu slechts enkele Kb's zijn in plaats van tientallen Mb's. Doet wonderen en printen werkt veel sneller.

Suc6