Citrix Virtual Apps and Desktops: Zonen, Latenz und Brokering-Leistung

Zonen

Bei Bereitstellungen, die sich über weit verstreute Standorte erstrecken, die über ein WAN miteinander verbunden sind, kann es zu Netzwerklatenz- und Zuverlässigkeitsproblemen kommen.
Anstatt mehrere Sites zu erstellen, von denen jede ihre eigene SQL Server-Standortdatenbank benötigt, die separat verwaltet werden muss, können Sie Zonen innerhalb einer einzelnen Site konfigurieren.

Auswirkungen der Latenz auf die Vermittlungsleistung

Endbenutzer starten täglich Ressourcen. Durch das Hinzufügen von Zonen können Benutzer jetzt Links mit höherer Latenz verwenden, solange es einen lokalen Broker gibt.
Zusätzliche Latenz wirkt sich auf das Endbenutzererlebnis aus. Bei den meisten Arbeiten, die Benutzer ausführen, stellen sie die erwartete Langsamkeit fest, die mit Roundtrips zwischen den Satellite-Brokern und der SQL-Datenbank verbunden ist.

Das eigentliche Vermitteln von Sitzungen hat ein Problem. Es liegt daran, dass der VDA mit der niedrigsten Auslastung ausgewählt werden muss, auf dem eine App gestartet werden soll.
Es findet innerhalb einer Datenbanktransaktion statt und benötigt einen Snapshot aller aktuellen Lasten auf den VDAs innerhalb der Bereitstellungsgruppe.
Für alle Worker in einer Bereitstellungsgruppe wird eine Sperre aufgehoben, wodurch verhindert wird, dass andere Benutzer dieselben Sperren verwenden (was zu einer Serialisierung führt). Es wartet auch auf Änderungen des Worker-Status (z. B. Sitzungsereignisse) und blockiert diese.

Bei niedriger Latenz ist die Verzögerung zwischen dem Aufheben der Sperren und deren Freigabe gering. Mit zunehmender Latenz nimmt jedoch die Zeit zu, in der die Sperren gehalten werden, und damit auch die Zeit, die für die Vermittlung von Sitzungen benötigt wird.

Wir haben uns verschiedene Arten von Latenzen und Startraten angesehen.
Die Latenzen sind die Round-Trip-Zeiten (RTTs) und basieren auf den Verizon-IP-Latenzstatistiken.
Die meisten RTTs liegen unter den angegebenen Höchstwerten, aber wir wollten sicherstellen, dass wir mit einigen brauchbaren RTTs getestet haben.

Hin- und Rückflugzeiten von 10 Millisekunden (ms) decken die meisten Verzögerungen zwischen Ländern ab, 45 ms decken Nordamerika, Europa und Japan ab, 90 ms decken den Transatlantik ab, 160 ms decken den Transpazifik, Lateinamerika und den asiatisch-pazifischen Raum ab und 250 ms decken EMEA bis Asien-Pazifik ab.

Wir haben mit verschiedenen Arten von gleichzeitigen Anfragen getestet, wobei Werte von 12 bis 60 in Schritten von 12 abgedeckt wurden.

Hinweis: Die VDA-Sitzungen werden simuliert, da sich die Tests auf die Auswirkungen der Latenz auf den Broker konzentrieren. Für diesen Test gibt es 57 VDAs in einer Bereitstellungsgruppe. Bei jedem Test wurde versucht, 10.000 Benutzer zu starten.

10 ms RTT-Ergebnisse          
Gleichzeitige Anforderungen 12 24 36 48 60
Durchschnittliche Antwortzeit (Sekunden) 0.9 1.4 1.6 2.1 2.6
Vermittlungsanforderungen pro Sekunde 14 17.8 22.9 23.2 22.9
Fehler (%age) 0 0 0 0 0
Zeit bis zum Start von 10.000 Benutzern 11m 57s 9m 24s 7m 16s 7m 11s 7m 17s

Wie erwartet sind 10 ms schnell genug, um die Belastung des Systems zu bewältigen, und es gab keine Fehler. Dies ist der schnellste Weg, Benutzer zu starten. Bei einer maximalen Startrate von 60 gleichzeitigen Benutzern betrugen die durchschnittlichen Antwortzeiten 2,6 Sekunden. Das Starten aller 10.000 Benutzer dauerte 7 Minuten und 17 Sekunden.

45 ms RTT-Ergebnisse          
Gleichzeitige Anforderungen 12 24 36 48 60
Durchschnittliche Antwortzeit (Sekunden) 1.7 3.1 4.3 6.4 7.3
Vermittlungsanforderungen pro Sekunde 7.1 7.8 8.4 7.5 8.2
Fehler (%age) 0 0 0 0.01 0.01
Zeit bis zum Start von 10.000 Benutzern 23m 28s 21m 19s 19m 51s 22m 15s 20m 19s

Mit 45 ms waren die Ergebnisse immer noch gut. Bei den sehr hohen Startraten haben ein oder zwei Benutzer einen Fehler festgestellt.

Hinweis: Die Auswirkungen der Serialisierung zeigen sich in den Antwortzeiten, wobei die Dauer der Vermittlung einer Sitzung von 1,7 Sekunden auf 7,3 Sekunden gestiegen ist. Die Gesamtzeit für die Vermittlung von 10.000 Benutzern betrug 20—23 Minuten.

90 ms RTT-Ergebnisse          
Gleichzeitige Anforderungen 12 24 36 48 60
Durchschnittliche Antwortzeit (Sekunden) 2.9 6.4 9.5 12.9 16.2
Vermittlungsanforderungen pro Sekunde 4.1 3.7 3.8 3.7 3.7
Fehler (%age) 0 0 0 0.01 0.01
Zeit bis zum Start von 10.000 Benutzern 40m 30s 44m 29s 44m 11s 44m 55s 45m 04s

Die 90-ms-Ergebnisse wiesen nur wenige Fehler auf.
Die Auswirkungen von Transaktionen über die Latenz werden noch deutlicher, wenn Benutzer eine akzeptable durchschnittliche Zeit von 2,9 Sekunden für die Vermittlung einer Sitzung mit 12 gleichzeitigen Anfragen benötigen. Für eine Sitzung mit 60 gleichzeitigen Anfragen sind es inakzeptable 16,2 Sekunden.
In diesem Fall ist es vorteilhafter, Benutzer zu einem niedrigeren Tarif zu vermitteln. Es dauerte 40—45 Minuten, um alle 10.000 Benutzer zu starten.

160 ms RTT-Ergebnisse          
Gleichzeitige Anforderungen 12 24 36 48 60
Durchschnittliche Antwortzeit (Sekunden) 5.7 11.4 17.3 23.2 28.0
Vermittlungsanforderungen pro Sekunde 2.1 2.1 2.1 2.1 2.1
Fehler (%age) 0 0 0.12 4.0 17.7
Zeit bis zum Start von 10.000 Benutzern 1 h 19 min 0 s 1 h 19 min 27 s 1 h 19 min 55 s 1 h 20 min 26 s

Bei 160 ms treten bei höheren Startraten allmählich signifikante Fehler auf, wobei 4 Prozent Fehler bei 48 Anfragen und 17,7 Prozent Fehler bei 60 Anfragen auftreten, zusammen mit Reaktionszeiten von fast 30 Sekunden.
Bei bis zu 36 Anfragen liegt die Fehlerrate jedoch bei 0,1 Prozent bei einer durchschnittlichen Vermittlungszeit von 17 Sekunden.

Hinweis: Es ist schwierig, die Startzeit für 60 Anfragen einzuschätzen, da ein Ausfall von 17 Prozent schwer zu berücksichtigen ist.

Bei dieser Latenz empfehlen wir, nicht 24 gleichzeitige Anfragen weiterzuleiten. Auch die Größe der Website kann ein Faktor sein — der Start von 1.000 Benutzern würde etwa 8 Minuten dauern. Dies würde für 10.000 Benutzer auf bis zu 1 Stunde und 20 Minuten skalieren. Daher würden wir eine große Site mit dieser Latenz für die Datenbank nicht empfehlen.

250 ms RTT-Ergebnisse          
Gleichzeitige Anforderungen 12 24 36 48 60
Durchschnittliche Antwortzeit (Sekunden) 9.3 15.4 26.7 - -
Vermittlungsanforderungen pro Sekunde 1.3 1.6 1.3 - -
Fehler (%age) 0 0 4.6 42.8 99.0
Zeit bis zum Start von 10.000 Benutzern 2h 8min 33s 1 h 46 min 52 s 2h 3min 46s

Bei einer so hohen Latenz traten viele Timeouts bei höheren gleichzeitigen Startraten auf. Bei 48 Anfragen schlugen 42,8 Prozent der Anfragen fehl. Bei 60 Anfragen kam es so häufig zu Timeouts, dass die Site unbrauchbar war, da 99 Prozent der Anfragen fehlschlugen. Die einzig akzeptablen Startraten waren 12 und 24 Anfragen. Es wäre schwer, die Bereitstellung einer großen Site mit dieser Latenz zu empfehlen: Der Start von 1.000 Benutzern dauerte 13 Minuten bei 12 gleichzeitigen Anfragen und 11 Minuten bei 24 gleichzeitigen Anfragen. Für 10.000 Benutzer würde es bis zu 2 Stunden und 8 Minuten dauern.

Drosselung von Anfragen

Wenn Sie mit hoher Latenz arbeiten müssen und feststellen, dass zu viele Timeouts auftreten, wurde XenApp und XenDesktop 7.7 ein Registrierungsschlüssel hinzugefügt, damit nur eine feste Anzahl gleichzeitiger Brokering-Anfragen verarbeitet werden kann. StoreFront versucht nach einigen Sekunden erneut, Anfragen, die das Limit überschreiten, anzufordern. Dies hilft dabei, Anfragen zurückzuhalten und so die Warteschlangen von Sperren zu reduzieren. Bei einigen Benutzern kann es jedoch zu längeren Startzeiten kommen, da sie immer Pech haben und ihre Anfrage immer zurückgewiesen wird.

Der Schlüssel ist ein DWORD und sollte gespeichert werden in:HKEY_LOCAL_MACHINE\Software\Citrix\DesktopServer\ThrottledRequestAddressMaxConcurrentTransactions

Wenn der Schlüssel nicht existiert, gibt es keine Begrenzung für Vermittlungsanfragen.

Hinweis: Der Schlüssel gilt pro Delivery Controller, sodass die Gesamtzahl der Anfragen auf dem SQL Server auf die Remote-Controller aufgeteilt werden muss.

Zusammenfassung

Brokering funktioniert zwar über Latenz, aber die Latenz muss bei der Dimensionierung einer Remote-Zone berücksichtigt werden. Wenn eine Zone groß ist, kann es dennoch wünschenswert sein, eine lokale Datenbank für diese Zone zu verwenden. Wenn die Zone klein ist, kann die Verwendung einer Remote-Zone gut funktionieren und auch die Verwaltungskosten senken, ohne das Endbenutzererlebnis zu beeinträchtigen.

Wir empfehlen, dass Ihre Zonen weniger als 250 ms RTT haben. Darüber hinaus sollten Sie die Einrichtung verschiedener Sites in Betracht ziehen.

Dieser Artikel wurde aus einem Blogbeitrag von Chris Gilbert geändert. Um den ursprünglichen Blog zu lesen und die Kommentare zu sehen, gehen Sie zu https://www.citrix.com/blogs/2016/02/09/zones-latency-and-brokering-performance-2/.

Citrix Virtual Apps and Desktops: Zonen, Latenz und Brokering-Leistung