How-To-Compute

IT-Pro Blog: Anleitungen, Tipps und Tricks um euch das Leben leichter zu machen.

Citrix Provisioning Retry Problem / viele Retries

Vor kurzem hat ein Kunde über die schlechte Performance seiner Provisioning Umgebung geklagt, ein kurzer Blick auf die vDisk Usage zeigte den vermeintlichen Grund, eine erhöhte Anzahl Retries. Teilweise im dreistelligen Bereich. Aber bevor wir ins Detail gehen ein paar kurze Hintergrundinfos.

Typische Symptome bei Retryproblemen

  • generell schlechte Performance bei Target Devices
  • Verzögerung bei Mausbewegungen und Tastatureingaben
  • Verzögerung beim Bildaufbau
  • Langsame Anwendungen

Problematisch ist es hier die Wurzel des Übels ausfindig zu machen. Denn häufig treten die besagten Probleme sporadisch auf und sind nicht wirklich zu greifen. Umso mehr Systeme provisioniert werden umso schwerer wird es die Ursache zu lokalisieren.

Ich nehme an das diese Probleme allen die bereits Erfahrungen mit Desktop- bzw. Anwendungsvirtualisierung gesammelt haben bekannt vorkommen und häufig auf die Produkte XenApp und XenDesktop sowie Terminaldienste im allgemeinen geschoben werden. Solltet ihr Provisioning im Einsatz haben (sonst würdet ihr ja vermutlich diesen Artikel nicht lesen 🙂 überprüft also erstmal eure PVS-Umgebung.

Wo kann ich sehen, ob und wenn ja wie viele Retries meine provisionierten Systeme haben?

Provisioning Services Console > Farm > Stores > Euer Store > rechte Maustaste auf eine eurer vDisks > Show Usage…

Sieht dann ungefähr so aus:

Alternativ zur Console, könnt ihr euch noch ein paar detailliertere Informationen über das Tray Icon der PVS Target Device Software holen:

Solltet ihr dieses ausgeblendet haben könnt ihr es über z.B. C:\Programme\Citrix\Provisioning Services\StatusTray.exe manuell starten.

Solange sich die Anzahl der Retries im Bereich zwischen 0-20 bewegen braucht ihr euch keine großen Sorgen zu machen, das kann durchaus schon mal vorkommen. Nichts desto trotz könnt ihr mit den später folgenden Schritten vielleicht noch ein bisschen die Performance bzw. Verfügbarkeit eurer Systeme verbessern.

Was bedeuten die Retries eigentlich?

Leider findet man zu der genauen Definition in den Untiefen des Internets nicht wirklich etwas. Von meinem Verständnis sind es Netzwerkverbindungsabbrüche zwischen Target Device und Provisioning Server mit anschließender Verbindungswiederherstellung. Im Moment in dem so ein Verbindungsabbruch stattfindet friert das Target Device kurzzeitig ein und zwar solange bis die Verbindung zum PVS-Server wiederhergestellt wurde. Wenn das immer mal wieder kurzzeitig passiert, führt das natürlich zu den bereits o.g. Symptomen.

Wie werde ich das Problem los???

Hier wird es spannend, das Problem kann natürlich durch verschiedene Faktoren bedingt sein.

1. Antivirus Einstellungen

Immer wieder sehe ich in Produktivumgebungen Standard Anti-Virus Konfigurationen, das vielleicht ein paar Modifikationen für die auf dem System installierte Software von Vorteil wären, scheint vielen nicht in den Sinn zu kommen:

2. Taskoffloading deaktivieren

Auch immer gern genommen, sobald es zu Verzögerungen und unerklärlichen Netzwerkproblemen auf virtuellen Maschinen (egal welcher Hypervisor) kommt.

Mit folgendem Skript kann man das ganze wunderbar ausrollen:

rem Taskoffloading deaktivieren
reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters” /v DisableTaskOffload /t REG_DWORD /d 1 /f

reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters” /v DisableLargeSendOffload /t REG_DWORD /d 1 /f

reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters” /v EnableTCPA /t REG_DWORD /d 0 /f

reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters” /v EnableRSS /t REG_DWORD /d 0 /f

reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters” /v EnableTCPChimney /t REG_DWORD /d 0 /f

3. PVS Advanced Server Properties anpassen

Wenn die beiden bereits genannten Schritte nicht geholfen haben, müssen wir etwas tiefer in die Trickkiste greifen. Ja, auch PVS-Seitig können wir hier noch an einigen Schrauben stellen.

Provisioning Services Console > Farmname > Sitename > Servers > rechte Maustaste auf einen Server > Server Properties > Advanced

Local concurrent I/O Limit

MTU Size und I/O Burst Size

Jetzt solltet ihr die hier hinterlegte MTU Size mit der Konfiguration eurer Switchports vergleichen, und ggf. auf einer von beiden Seiten die Konfiguration anpassen, in der Regel ist es weniger Aufwand dies am PVS-Server zu machen. Durch Anpassung von Local concurrent I/O und I/O Burst Size soll es möglich sein die Anzahl Retries noch weiter zu minimieren, ich habe diesbezüglich aber leider keine Erfahrungswerte, in der Regel lassen wir diese Werte auf Standard stehen

Hier hat ein Kollege alle hier verfügbaren Optionen wunderbar erklärt:

http://knowcitrix.hpage.co.in/pvs-server-properties_83783659.html#.Ura7HvTuIy5

Einfach in dem Artikel nach Retries suchen und ihr findet die entsprechenden Informationen.

5. Die Lösung

In meinem Fall lag es letztendlich an der MTU Size. Wir haben von dem vorher konfiguriertem Wert die Bytes für die Header Informationen (Ethernet, VLAN – Tagging  und IP Header) abgezogen und den Wert auf 1456 Bytes gesenkt. Wichtig hierbei ist es, dass bei beiden PVS-Servern der Streaming Dienst neu gestartet wird, auch wenn der Wert nur an einem Server verändert wird! (Warum auch immer!?)

Anschließend waren die Retries der Server bei 98% der Targets auf 0. Die anderen waren noch im vertretbaren Bereich zwischen 0 und 20.

6. Ergänzendes Troubleshooting

Solltet ihr anschließend immernoch Probleme mit Retries haben prüft doch bitte folgendes:

  • http://support.citrix.com/article/CTX117374 (Von Citrix Empfohlene PVS Netzwerkkonfiguration)
  • Die üblichen Verdächtigen, Hypervisorupdates, Tools aktuell, Microsoft Updates, PVS-Server und Target Device Updates etc.

Im Zweifelsfall fragt uns einfach.

Ich hoffe der Artikel hilft dem ein oder anderem weiter.

3 Comments

Add a Comment
  1. Hallo Dennis, das ist wirklich ein sehr guter und ausführlicher Artikel. Ich habe noch eine Quelle für deinen Reg. Key “DisableLargeSendOffload” von Microsoft:
    http://support.microsoft.com/kb/933118/en-us
    Für den VMware Bereich solltest Du vielleicht noch folgende Quellen/Parameter hinzufügen:
    http://support.citrix.com/article/CTX139498
    Gruß, Frank

    1. Hallo Frank,

      vielen Dank für das Lob und die Links. Ich hoffe der Artikel hat dir bei etwaigen Retry Problemen weitergeholfen.

      Gruß
      Dennis

  2. We have just installed this and have it setup for both our prucodtion and disaster recovery locations. We have already performed an update to a vDisk and everything is working like it should. This is truly a great product of Citrix Admins and this should def be part of the infrastructure design for anyone working with XenApp.The one thing we are not 100% sure about is the use of caching to RAM. We have 33 blades with 96GB of RAM each, with 200 users connecting to each blade, we don’t know what we should set the RAM cache to. Has anyone had experience with that setting? Any feedback would be greatly appreciated.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

How-To-Compute © 2017 Frontier Theme