[Forschung] Auswirkungen der Meltdown- und Spectre-Patches auf die Leistung von Terminalservern - und damit auch auf Citrix XenApp

Das Thema Terminal Server/Citrix XenApp-Workloads steht seit der Veröffentlichung der Meltdown- und Spectre-Patches im Mittelpunkt unserer Aufmerksamkeit. Das Potenzial für Verlangsamungen nach der Anwendung von Meltdown- und Spectre-Patches hat uns dazu veranlasst, die Angelegenheit selbst zu untersuchen, und wir haben einige erste Ergebnisse für VDI veröffentlicht, die eine spürbare CPU-Auswirkung zeigten (mit dem Vorbehalt, dass die Auswirkung von der Arbeitslast abhängt). Jetzt, da wir die Gelegenheit hatten, eine ähnliche Analyse für XenApp abzuschließen, sind wir bereit, unsere Erkenntnisse zu teilen.

Warum XenApp zusätzlich zu VDI (und anstelle von reinen Terminal Services) testen?

Einfach ausgedrückt: Während ein winziger Prozentsatz unserer Kunden reine Terminaldienste für RDS und Anwendungsvirtualisierung nutzt, verwendet die Mehrheit XenApp, und das ist es, was wir in unseren Labors eingerichtet haben. Wir wollen nicht auf XenApp an sich herumhacken. Wir gehen davon aus, dass die von uns beobachteten Auswirkungen auf die XenApp-Leistung wahrscheinlich auf die Eigenschaften von Terminal Server zurückzuführen sind. Darüber hinaus möchten wir unseren Gedankengang veranschaulichen, wie sich VDI-Workloads von XenApp- oder Terminal Service-Workloads unterscheiden, da sie einzigartige Merkmale aufweisen und wir davon ausgehen, dass sie unterschiedliche Auswirkungen zeigen werden.

Da es sich hier um einen Blogbeitrag und nicht um ein Whitepaper handelt, sind einige der hierin enthaltenen technischen Beschreibungen zu stark vereinfacht. Wir werden daher ein technisches Whitepaper und Best Practices zur Messung der Leistungsauswirkungen von Betriebssystem-Patches nachreichen.

Doch zunächst möchte ich ein paar Worte zu den grundlegenden Unterschieden zwischen RDS-Host-Maschinen und VDI sagen, um zu verdeutlichen, warum sich Meltdown- und Spectre-Patches unterschiedlich auswirken. Vereinfacht gesagt, besteht das Konzept von RDS (oder, wie es früher hieß, Terminal Services) darin, dass ein System (in der Regel ein Serverbetriebssystem) als Host fungiert, der zahlreiche Sitzungen mit einem übergeordneten Betriebssystemkontext bedient, der die Arbeitslast enthält. Dies führt zu einer gewissen Komplexität bei der Art und Weise, wie dieses System einen Großteil der Aktivitäten abwickelt, die beim Hin- und Herwechseln zwischen dem Benutzer und dem Kernel stattfinden (im Grunde wird zwischen dem Ort, an dem die Konstruktion des Materials verarbeitet wird, und dem Ort, an dem die eigentliche Ausführung stattfindet, hin- und hergeschoben). Es gibt also viele verschiedene Arbeitslasten, die gleichzeitig auf einem System stattfinden; diese Prozesse teilen sich CPU-Ressourcen und die verschiedenen Benutzerkontexte, die auf dem System selbst existieren. Das bedeutet, dass auf einem Terminalserver im Allgemeinen mehr Aktivitäten zu erwarten sind, die von der spekulativen Ausführungsausnutzung betroffen sind, die Updates abschwächt.

Im Vergleich dazu gibt es bei VDI einen kleinen, aber signifikanten Unterschied. Im Wesentlichen handelt es sich um ein ähnliches Konzept, bei dem letztlich eine gemeinsam genutzte Ressource (in diesem Fall ein Hostsystem) mehrere Workloads ausführt. In diesem Fall führt jede VM die Arbeitslast eines individuellen Benutzerkontextes aus (jedenfalls die meiste Zeit). Unterm Strich bedeutet dies, dass die Auswirkungen der Entschärfungspatches auf VM-Basis zwar geringer ausfallen, aber in der Summe doch beträchtlich sein werden. Was bedeutet das alles?

Die Schlussfolgerung: Es ist zu erwarten, dass Terminalserver stärker von den für Meltdown und Spectre verwendeten Abschwächungstechniken betroffen sein werden. Das wollten wir mit einer echten Arbeitslast testen.

Prüfmethodik

Wie bei unseren ersten Tests waren wir auf der Suche nach einer Lösung, die auch bei einer geringeren Arbeitsbelastung eine deutlich spürbare Wirkung hat, und beschlossen daher, verschiedene Plattformen zu testen. Eine Sache, die wir jedoch beibehalten wollten, war die Arbeitslast. Dies geschah mit einem synthetischen Transaktionstool und konzentrierte sich nur auf den Anwendungsfall des veröffentlichten Browsers, da wir festgestellt haben, dass eine sehr große Anzahl von Unternehmen dies mit XenApp unterstützt.

Bei unseren Tests haben wir hauptsächlich zwei Konfigurationen verwendet, die in etwa den gängigen Konfigurationen entsprechen, die wir in der freien Wildbahn sehen, und wir haben sowohl das physische als auch das virtuelle Gehäuse ausprobiert:

 

Alt - Physisch

Patch getestet	Meltdown und Spectre
OS	Windows Server 2008 R2 SP1
CPU	Intel Xeon E5650 @ 2,67GHz
Speicher	32 GB
Festplatte	SSD
Benutzerdichte	20 Sitzungen
XenApp	6.5
Arbeitsbelastung	Nur Browser

 

Alt - Virtuell

Patch getestet	Meltdown und Spectre
Hypervisor	VMware ESXi, 6.0.0, 6921384
Gast-OS	Windows Server 2008 R2 SP1
CPU	Intel Xeon E5650 @ 2,67GHz
vCPUs	2
Speicher	16 GB
Festplatte	Lokaler SSD-Speicher
Benutzerdichte	20 Sitzungen
XenApp	6.5
Arbeitsbelastung	Nur Browser

 

Neu(er) - Physisch

Patch getestet	Meltdown und Spectre
OS	Windows Server 2012 R2
CPU	Intel Xeon X7350@ 2,93GHz
Speicher	144 GB
Festplatte	SSD
Benutzerdichte	20 Sitzungen
XenApp	7.7
Arbeitsbelastung	Nur Browser

 

Neu(er) - Virtuell

Patch getestet	Meltdown und Spectre
Hypervisor	VMware ESXi, 6.0.0, 6921384
OS	Windows Server 2012 R2
CPU	Intel Xeon X7350@ 2,93GHz
vCPUs	4
Speicher	72 GB
Festplatte	Lokaler SSD-Speicher
Benutzerdichte	20 Sitzungen
XenApp	7.7
Arbeitsbelastung	Nur Browser

 

Feststellen: Meltdown- und Spectre-Patches erhöhen CPU-Auslastung auf XenApp-Rechnern

Fall	Plattform	Auswirkungen
Alte (Server 2008 R2 und ältere Proc)	Physisch	20%
	Virtuell	22%
Neuere (Server 2012 R2 und neuere Proc)	Physisch	16%
	Virtuell	19%

 

Der physische Workload mit den größten Auswirkungen basierte, wie zu erwarten, auf älterer Hardware und einem älteren Betriebssystem (Server 2008 R2). Ein weiterer Faktor ist, dass es sich bei der XenApp-Maschine selbst um eine VM handelt. Wir fanden heraus, dass die Gesamtauswirkungen auf jeden XenApp-Server im Durchschnitt etwa 20 % mehr CPU-Overhead bedeuteten. Die neuere Serverarchitektur mit Windows Server 2012 R2 wies ein deutlich geringeres Delta auf und kam auf einen Anstieg von nur 16 %.

Die Nachrichten für virtuelle Arbeitslasten sind deutlich schlechter: Wir haben festgestellt, dass die Gesamt-CPU-Last bei der älteren Architektur um 22 % und bei der neueren Architektur sogar um 19 % gestiegen ist.

Welche Schlussfolgerungen können wir daraus ziehen? Zunächst einmal zeigt sich, dass selbst bei einer relativ geringen Arbeitslast die CPU-Last auf einem XenApp-Server wesentlich stärker ansteigt als auf einer Desktop-VM. Dies ist höchstwahrscheinlich auf die Verarbeitungseigenschaften der Arbeitslast zurückzuführen, die in Terminal Server-Umgebungen zu beobachten sind, und hat einige interessante Auswirkungen. Die zweite und vielleicht interessanteste Erkenntnis ist, dass sich die Virtualisierung direkt auf den Gesamt-Overhead pro XenApp-VM auswirkt, und das wiederum hat große Auswirkungen auf die Dichte. Wie gesagt, das hängt von der jeweiligen Arbeitslast ab, aber wenn dies ein Anhaltspunkt ist, sollten Sie davon ausgehen, dass schwerere Arbeitslasten (vor allem solche mit höherem Festplattendurchsatz) zu einem potenziell erheblichen Anstieg der Last auf älteren Prozessorarchitekturen führen.

Microsoft gibt folgende Hinweise zu den Auswirkungen von Patches auf die Leistung:

Windows Server auf einem beliebigen Silizium, insbesondere in einer IO-intensiven Anwendung, zeigt eine deutlichere Auswirkung auf die Leistung, wenn Sie die Mitigations aktivieren, um nicht vertrauenswürdigen Code innerhalb einer Windows Server-Instanz zu isolieren.  

TLDR: Diese Microsoft-Patches scheinen sich viel stärker auf Terminal Server/XenApp-Server-Workloads auszuwirken als auf XenDesktop- und Horizon-Desktop-Workloads. Modernere physische Systeme erfahren eine geringere Verschlechterung (unser etwas älteres System verzeichnete einen CPU-Anstieg von 16 %) als ältere (unsere ältere Plattform verzeichnete eine Auswirkung von 20 %). Es überrascht nicht, dass virtuelle Server einen noch höheren Overhead aufweisen(16 % - 22 % je nach Alter der Architektur und des Betriebssystems). Alle Arbeitslasten sind unterschiedlich, daher sollten Sie Ihre eigenen Basiswerte ermitteln.