riverbed steelhead/ TS 2008 R2 compressie problemen

[Verwijderd]

Hoi, ik heb het volgende probleem.

De situatie is: 1 kantoor in Sydney met 10 users, 1 kantoor in Melbourne met 10 users.
De users in Sydney hebben een windows 2000 of windows XP pc, gekoppeld aan het domein met een RDP connectie op de desktop. Via een permanente IPSec tunnel dmv 2 watchguard routers, zijn de 2 kantoren verbonden.
In Melbourne staan een server 2003 Terminal server en een server 2008 R2 Terminal server (encryption low).

gisteren heb ik 2 riverbed stealhead geactiveerd, 1 aan elke kant. Ik heb poort 3389 in de in path rules toegevoegd en QOS geconfigureerd. Ik krijg ongeveer 10% reductie op RDP en wat meer op de domein informatie en SMB etc. Dit is op zich goed, maar er is meer uit te halen door middel van het volgende truckje:

In sydney, open de rdp file met notepad en verander:
compression:i:1 in compression:i:0
Zonder compressie kan de stealhead veel beter optimizen...

Alleen als ik dat doe wordt de verbinding naar de 2008 R2 server heeeeel traag. De verbinding naar de 2003 terminal server (zelfde kantoor in Melbourne) blijft prima...

Wat kan dit zijn?

[jvanhambelgium]

Voor zo'n problemen :

1) Riverbed support/knowledgebase doorlezen
2) Riverbed support inschakelen, daarom heb je nu eenmaal zo'n duur apparaat

Weet wel dat er verschillende versies van RDP zijn en dat vb Windows 2008R2 op versie 7 zit terwijl dat versie 5.2 werd geintroduceerd ten tijde van Windows 2003 server.

Heb je meer info rond de ondersteuning voor welke RDP protocols of details hierrond.
Mischien 1 van de RDP7 features die ergens nadelig werkt icm de Riverhead...

[Predator]

Sta je wel op de laatste firmware ?
Dat is toch het eerste wat je moet checken, zelfs voor je een support call gaat loggen.
Anders krijg je dat toch als eerste vraag op je bord

[Bl@ckbird]

- Zorg dat compressie uit staat. (Want dit wil je door de Steelhead laten doen.)

- Zorg dat encryptie van de RDP sessie uit staat. (Of op low. Random data kan je namelijk niet optimaliseren.)

- Als je file sharing doet, en je gebruikt windows 7 en Windows 2008 dan wordt standaard SMB signing gebruikt en hier zit standaard encryptie op. De Steelhead moet je dan even laten inloggen op het domein, zodat het dezelfde credentials heeft. De Steelhead doet dan de signing. Hier niet van toepassing want je gebruikt RDP. Maar misschien handig voor de toekomst.

- Bel Riverbed Support.

[Verwijderd]

Bedankt voor de reacties.

Compressie staat uit op de shortcut en encryptie op de 2008 r2 server staat op low.

De riverbed steelheads zijn te leen van de leverancier zodat we de klant het verschil kunnen laten zien en dus de leverancier dat spul verkoopt. Support van de leverancier is een kerel die daar net begonnen is en wel heel erg zijn best doet, maar in deze finetuning weinig ervaring heeft.

[Verwijderd]

Predator schreef op dinsdag 30 november 2010 @ 10:15:
Sta je wel op de laatste firmware ?
Dat is toch het eerste wat je moet checken, zelfs voor je een support call gaat loggen.
Anders krijg je dat toch als eerste vraag op je bord

firmware is 6.1 trouwens, dus dat moet het probleem niet zijn (schijnt ook nog 's beter te werken met rdp volgens riverbed website)

[Bl@ckbird]

Hou er rekening mee dat RDP / Citrix verkeer stream van screenshot zijn die geoptimaliseerd worden.
Het heeft minder repeterende data dan Windows file shares. Hoewel je nog best wel een goede reductie van data kan krijgen. Hier staan wat cijfers wat je zou kunnen halen:
http://community.riverbed...f-Fame-2010/bd-p/PHOF2010

Verwijderd schreef op dinsdag 30 november 2010 @ 11:41:
De riverbed steelheads zijn te leen van de leverancier zodat we de klant het verschil kunnen laten zien en dus de leverancier dat spul verkoopt. Support van de leverancier is een kerel die daar net begonnen is en wel heel erg zijn best doet, maar in deze finetuning weinig ervaring heeft.

Je leverancier ( distributeur of Riverbed partner) kan eventueel een support case loggen Riverbed.
Of hij kan met zijn presales engineer bij Riverbed contact op nemen.

[ Voor 4% gewijzigd door Bl@ckbird op 30-11-2010 21:03 ]

[Verwijderd]

Compressie staat uit op de shortcut en encryptie op de 2008 r2 server staat op low.

Kan de encryptie niet helemaal uit? Of zijn de Riverbeds lid van het domain? Ze kunnen niet namelijk zomeer de geencrypte data "zien".

Overigens is de kracht van de Riverbed niet het optimaliseren van het RDP of ICA protocol. Deze zijn al geoptimaliseerd waardoor het in de praktijk vaak weinig zin heeft.

Heb je gekeken in de Riverbed interface of je connectie naar de 2008 server wel optimzed is? Of pass-through? Verkeer naar de 2003 machine zal niet encrypted zijn en dit wordt dus wel geoptimaliseerd door de Riverbed.

[ Voor 21% gewijzigd door Verwijderd op 11-12-2010 12:27 ]

[Bl@ckbird]

Voor een paar sessies heeft het idd geen zin, maar als je een verbinding wil vullen met een hoop sessies dan scheelt het toch nog. (Maar het zal niet dezelfde performance winst als bij bijvoorbeeld CIFS verkeer.)

Riverbed heeft en apparte optimalisatie engine voor ICA, die beter schijnt te zijn dan WAN Scaler van Citrix zelf.
( En dat heb ik van een Riverbed SE die bij Citrix heeft gewerkt... ) Vaak is gaat het niet eens om datareductie, maar om er voor te zorgen dat Citrix wat vloeiender loopt.

Zie:
http://community.riverbed...Saved-Per-Month/td-p/3766

[Verwijderd]

Maar het gaat hier alleen niet om ICA maar RDP. Dat screenshot zegt overigens ook niets. Hoeveel verkeer gaat er over de lijn met de normale ICA compressie? Misschien wel hetzelfde, of maar iets meer. Dan is het zonde van je coonecties.

[ Voor 10% gewijzigd door Verwijderd op 11-12-2010 23:30 ]

[Verwijderd]

Even een kleine update. Wat instellingen geprobeerd met riverbed tech en krijg nu 70% optimization op rdp traffic (na rdp compressie in xp client uit te zetten, dus die 70% is relatief minder natuurlijk), maar vooral de latency is minder wat erg goed is! Gebruikers noemen een terminal server via VPN met latency over slechte adsl lijn met 110ms latency nu net zo snel als de locale terminal server vroeger werkte.

[ Voor 24% gewijzigd door Verwijderd op 12-12-2010 09:28 ]

[Verwijderd]

Dat is goed om te horen. En is je probleem met 2008 nu ook opgelost?

[Verwijderd]

Verwijderd schreef op zondag 12 december 2010 @ 14:54:
Dat is goed om te horen. En is je probleem met 2008 nu ook opgelost?

Ja dat ging om "packet order" in plaats van de mij geadviseerde "MXTCP" in de poort 3389 QoS rule... vraag me niet waarom, maar dat werkte prima. Kwam de Rvierbed engineer mee, terwijl in hun whitepaper over RDP toch MXTCP stond. Heeft iets met latency te maken.