Designentscheidung: Skalierbarkeit eines einzelnen Servers

Übersicht

Dieser Artikel enthält Empfehlungen und Anleitungen zum Schätzen, wie viele Benutzer oder virtuelle Maschinen (VMs) auf einem einzelnen physischen Host unterstützt werden können. Dies wird allgemein als “Single-Server-Skalierbarkeit” (SSS) von Citrix Virtual Apps and Desktops bezeichnet. Im Zusammenhang mit Citrix Virtual Apps (CVA) oder Sitzungsvirtualisierung wird es auch allgemein als “Benutzerdichte” bezeichnet. Die Idee besteht darin, festzustellen, wie viele Benutzer oder VMs auf einer einzigen Hardware ausgeführt werden können, auf der ein großer Hypervisor wie ein Citrix Hypervisor ausgeführt wird.

In diesem Artikel behandeln wir einige der Variablen oder Faktoren, die Citrix Virtual Apps and Desktops (CVAD) SSS beeinflussen. Wir geben Empfehlungen und einfache Richtlinien, um SSS für eine bestimmte Umgebung schnell zu schätzen. Abschließend stellen wir einige Größenbeispiele unter Verwendung von realen Szenarien zur Verfügung.

Achtung!Dieser Artikel enthält Anleitungen zum Schätzen von SSS. Es sollte beachtet werden, dass die Anleitung auf hohem Niveau ist und nicht unbedingt spezifisch für Ihre einzigartige Situation oder Umgebung sein wird. Die einzige Möglichkeit, CVAD SSS wirklich zu verstehen, besteht darin, ein Skalierbarkeits- oder Lasttest-Tool wie Login VSI zu verwenden. Citrix empfiehlt, diese Anleitung und diese einfachen Regeln zu verwenden, um SSS schnell zu schätzen. Citrix empfiehlt jedoch die Verwendung von Login VSI oder dem Lasttest-Tool Ihrer Wahl, um die Ergebnisse zu validieren, insbesondere vor dem Kauf von Hardware oder bei finanziellen Entscheidungen.

Skalierbarkeitsfaktoren

Es gibt viele Faktoren, Parameter oder Variablen, die sich auf SSS auswirken. Dies ist keineswegs eine erschöpfende Liste, aber die folgenden sind einige der wichtigsten Faktoren, die Auswirkungen auf die SSS haben. Zwar gibt es viele weitere Faktoren, die Leistung und Skalierbarkeit beeinflussen, wie Antiviren- und Überwachungsagenten, Grafikcodierung, aktuelle Sicherheitslücken wie Spectre und L1 Terminal Fault, aber die unten aufgeführten Faktoren haben in der Regel die größten Auswirkungen auf CVAD SSS. Sehen wir uns nun an, wie man CVAD SSS mit einer einfachen Formel schnell einschätzen kann.

Workload

Einer der Hauptfaktoren, die sich auf Performance und Skalierbarkeit auswirken, ist die Arbeitslast selbst. Bei einigen Workloads kann es vorkommen, dass Task-Worker einfache Dateneingabetasks auf einem CVA-Server ausführen. Bei anderen Workloads kann es sich um Entwickler handeln, die Code kompilieren oder Ingenieure, die 3D-Modelle über Citrix Virtual Desktops (CVD) bearbeiten. Diese werden allgemein als “leichte” bzw. “schwere” Workloads bezeichnet. Und wie Sie später in diesem Artikel sehen, kann diese Art der Arbeitslastvarianz dramatische Auswirkungen auf SSS haben.

Hardware

Die physische Hardware, auf der die Workloads ausgeführt werden, hat direkte Auswirkungen auf SSS. Es versteht sich wahrscheinlich von selbst, aber ein neuerer Server mit 28 Kernen und 1 TB RAM wird in der Lage sein, mehr Benutzer als eine ältere Hardware mit nur 12 Kernen und 256 GB RAM zu unterstützen, die eine ähnliche Arbeitslast ausführen. Und die CPU spielt eine besonders wichtige Rolle im CVAD SSS, wie Sie später sehen.

Aktivitätsverhältnis

静脉der oft ubersehenen Aspekte冯SSS的】Aktivitätsverhältnis oder wie oft Benutzer im Leerlauf arbeiten. Viele Tools für Skalierbarkeitstests verfolgen einen konservativen Ansatz und können ein ziemlich hohes Aktivitätsverhältnis wie 80% nutzen (was bedeutet, dass Benutzer aktiv sind oder 80% der Zeit arbeiten und 20% der Zeit im Leerlauf sind). Allerdings sehen wir oft in der realen Welt, dass die Aktivitätsquoten näher bei 40 -60% liegen. Und diese zusätzliche Leerlaufzeit kann sich dramatisch auf SSS auswirken und wie viel Hardware man kaufen muss, um eine CVAD-Umgebung zu unterstützen.

CPU-Über-Abonnement-Verhältnis

Die meisten CVAD-Workloads sind CPU-gebunden, was bedeutet, dass der ultimative Punkt der Ressourcenerschöpfung direkt mit der Anzahl der im System verfügbaren physischen Kerne zusammenhängt. Und da Benutzer möglicherweise nicht 100% der Zeit aktiv sind und wir Tools wie Intel Hyper Threading zur Verfügung haben (ganz zu schweigen davon, dass Hypervisor-CPU-Scheduler immer effizienter werden), können wir Ressourcen wie CPU oft “überbeauftragen” oder überabonnieren. Und das Verhältnis, dass man die CPU überzeichnet, kann auch SSS beeinflussen (positiv oder negativ, wenn nicht sorgfältig gemacht). Citrix hat festgestellt, dass ein CPU-Überabonnementverhältnis von 2:1 in CVA SSS oft optimal ist. Wenn beispielsweise ein physischer Server mit Dual-Sockel-20-Core-Chips (das heißt “2 x 20”) ausgestattet ist, stehen insgesamt 40 physische Kerne zur Verfügung. Bei aktiviertem Hyper-Threading stehen 80 virtuelle oder logische Kerne zur Verfügung. Durch die Anwendung eines Verhältnisses von 2:1 auf die Anzahl der physischen Kerne (40) würden wir effektiv empfehlen, bei der Dimensionierung oder Schätzung von SSS 80 Kerne zu verwenden. Weitere Beispiele finden Sie am Ende dieses Artikels, um dieses Konzept ausführlicher zu veranschaulichen.

Mikroprozessorarchitektur und -funktionen

Die zugrunde liegende Chip- und Speicherarchitektur kann auch in SSS eine wichtige Rolle spielen. Und Intel hat kürzlich signifikante Verbesserungen im zugrunde liegenden Mikroprozessor-Architekturdesign vorgenommen. Auf älteren Chips, wie Broadwell und Haswell, verband Intel Prozessoren mit einer ringbasierten Architektur. Da jedoch die Anzahl der Kerne zunahm, erhöhte sich die Zugriff-Latenz und die Bandbreite pro Kern verringerte, so dass Intel dies mildert, indem er den Chip in zwei Hälften aufteilt und einen zweiten Ring hinzufügte, um Entfernungen zu reduzieren. Und diese unsichtbare Spaltung war etwas, das in CVAD SSS berücksichtigt werden musste, um optimale Ergebnisse zu erzielen. Dies wurde in der Vergangenheit als “NUMA” oder Non-Uniform Memory Access bezeichnet. Und die führende Anleitung bestand darin, sicherzustellen, dass Sie CVA-VMs so groß wie möglich dimensionieren, aber nicht gleichzeitig NUMA-Knoten, Sub-NUMA-Cluster oder Ringe kreuzen. Wenn Sie Ihre CVA-VMs zu groß bemessen und NUMA-Knoten oder Ringe effektiv überspannt haben, kann dies dazu führen, dass NUMA durch den Zugriff auf nicht-lokale Ressourcen auf nicht lokale Ressourcen erfolgt, und dies würde zu einer reduzierten SSS führen. Schnellvorlauf bis heute und Intel hat sich von einer ringbasierten Architektur zu einer netzbasierten Architektur entwickelt. Und diese neue Mesh-Architektur, die in Skylake eingeführt wurde, hat nicht die gleichen Einschränkungen wie zuvor, wo wir Chips spalten, Kerne teilen oder Ringe hinzufügen müssen. Und das ändert insbesondere die Art und Weise, wie wir CVA-Server skalieren. Daher ist es wichtig, den spezifischen Chip zu verstehen, der in der von Ihnen gekauften Hardware verwendet wird, und wie die zugrunde liegende Mikroprozessorarchitektur entworfen und konstruiert wird

Die Magic Multiplikatoren

Wenn Sie CVAD SSS schnell beurteilen oder schätzen möchten, ist diese Anleitung wirksam. So einfach ist das:Nehmen Sie die Anzahl der physischen Kerne in einem Server, multiplizieren Sie es mit 5 oder 10, und das Ergebnis wird Ihr SSS sein.Wenn Sie nach der Anzahl der CVD-VMs suchen, die Sie unterstützen können, dann würden Sie den “magischen Multiplikator” von 5 verwenden. Wenn Sie versuchen zu verstehen, wie viele CVA-Benutzer auf einer einzigen Hardware laufen können, würden Sie 10 verwenden. Schauen wir uns ein paar Beispiele aus der Praxis an, um zu sehen, wie dies in der Praxis angewendet wird.

Beispiel 1: Citrix Virtual Desktops

Angenommen, Sie führen Windows 10 mit Standard-Office-Anwendungen und einigen benutzerdefinierten Anwendungen aus. Sie haben festgestellt, dass eine VM-Spezifikation mit 2 vCPU/4 GB RAM für gegebene Workloads/Images am besten funktioniert. Sie erwägen den Kauf von Cisco-Blades mit 36 physischen Kernen (2 x 18) und 768 GB RAM. Und Sie möchten wissen, welche Dichte Sie erwarten können. Nutzen wir die 5-Regel für CVD:

5 x 36 = 180 VMs pro Host

Hinweis:Auf Citrix spezialisierte VDI- und RDSH-basierte Workloads sind in 99,9% der Fälle CPU-gebunden. Die CPU ist im Gegensatz zu Arbeitsspeicher, Datenträgerspeicher oder Netzwerkspeicher zum Skalierbarkeitsengpass geworden. Diese Multiplikatoren lassen andere Bereiche außer der CPU weg, weil die CPU zum Hauptfaktor geworden ist. Obwohl Hyper-Threading, Taktraten und virtuelle Kerne wichtig sind, ist nichts wichtiger als die Anzahl der physischen Kerne auf einem Server. Wenn Sie die Regel 5 und 10 verwenden, ist es am besten, zuerst alle anderen Zahlen zu ignorieren, um die anfängliche Größe durchzuführen, um Verwirrung zu vermeiden.

Beispiel 2: Citrix Virtual Apps (ältere Hardware)

Nehmen wir an, Sie führen eine Anwendung wie SAP unter Windows Server 2012 R2 über CVA aus. Sie verwenden einige ältere HP-Blades mit 24 physischen Kernen (2 x 12) und 256 GB RAM. Sie haben auf der Website von Intel untersucht, dass der zugrunde liegende Chip eine Ringpuffer-Architektur verwendet und jeder Socket effektiv in 2 NUMA-Knoten mit jeweils 6 Kernen aufgeteilt ist. Daher scheint eine 6-vCPU/24-GB-RAM-VM-Spezifikation optimal zu sein, um die lineare Skalierbarkeit zu maximieren und NUMA-Thrashing zu minimieren. Mit einem CPU-Überabonnement-Verhältnis von 2:1 nutzen Sie alle 48 logischen Kerne und stellen 8 XenApp-Server auf jedem Host bereit (48/ 6 = 8). Anwendung der Regel von 10 für CVA:

10 x 24 = 240 Benutzer pro Host

Beispiel 3: Citrix Virtual Apps (neuere Hardware)

Nehmen wir an, Sie führen eine beliebte Anwendung für das Gesundheitswesen unter Windows Server 2016 über CVA aus. Sie erwägen den Kauf von Dell Blades mit 32 physischen Kernen (2 x 16) und 256 GB RAM. Sie haben auf der Website von Intel recherchiert, dass der zugrunde liegende Chip eine Mesh-Architektur verwendet, und es gibt eine Geschäftsrichtlinie, um Ihren VM-Footprint so weit wie möglich zu reduzieren. Sie entscheiden sich für eine 16 vCPU/48 GB RAM VM-Spezifikation. Mit einem CPU-Überabonnement-Verhältnis von 2:1 nutzen Sie alle 64 logischen Kerne und stellen 4 XenApp-Server auf jedem Host bereit (64/16 = 4). Anwendung der Regel von 10 für CVA:

10 x 32 = 320 Benutzer pro Host

Wie bereits erwähnt, erkennen wir, dass es viele weitere Variablen oder Parameter gibt, die die Skalierbarkeit im Vergleich zu der Anzahl der physischen Kerne in einem Server beeinflussen. Und es kann bestimmte Situationen geben, in denen die CVAD-Arbeitslast nicht CPU-gebunden ist, daher ist bei der Dimensionierung besondere Vorsicht geboten. Darüber hinaus sind auch andere Faktoren, über die wir nicht diskutiert haben, wie CPU-Taktfrequenz und Logon-Stürme, und erschweren die Größenübungen weiter. Aber wir haben durch jahrelange Erfahrung im Feld und Hunderte von Bereitstellungen festgestellt, dass nichts so wichtig ist wie die Anzahl der physischen Kerne. Wenn Sie Ihren genauen SSS für Ihre spezielle Arbeitslast und Ihre einzigartige Umgebung verstehen möchten, empfiehlt Citrix dringend, ein Tool wie Login VSI zu verwenden, um die Ergebnisse ordnungsgemäß zu testen und/oder zu validieren.

Referenzen

Intel Xeon Prozessorfamilie — Technische Übersicht

Best Practices für Virenschutz

Login VSI-Lastprüfung

Designentscheidung: Skalierbarkeit eines einzelnen Servers