Der Kunde wollte VDI. Er hatte sich intensiv mit der Kombination SimpliVity + VDI Citrix Virtual Desktop beschäftigt. Für alle Betreiber, Mitarbeiter in Büros in den Städten usw. Bei der ersten Welle der Migration gibt es bereits fünftausend Benutzer, weshalb sie auf Lasttests bestanden haben. VDI kann anfangen zu ruckeln oder kann einfach ausfallen – und das passiert nicht immer aufgrund von Kanalproblemen. Wir haben ein sehr leistungsstarkes Testpaket speziell für VDI gekauft und die Infrastruktur so lange belastet, bis sie bei den Festplatten und der CPU zusammenbrach.
Also brauchen wir eine Plastikflasche, die Software LoginVSI für anspruchsvolle VDI-Tests. Wir haben Lizenzen für 300 Benutzer. Dann haben wir die Hardware HPE SimpliVity 380 in einer Konfiguration gewählt, die für die maximale Benutzeranzahl pro Server geeignet ist, haben virtuelle Maschinen mit gutem Oversubscribing erstellt, Office-Software unter Win10 installiert und mit dem Testen begonnen.
Los geht's!
Das System
Zwei Knoten (Server) HPE SimpliVity 380 Gen10. Auf jedem:
- 2 x Intel Xeon Platinum 8170 26c 2,1 GHz.
- Arbeitsspeicher: 768 GB, 12 x 64 GB LRDIMMs DDR4 2666 MHz.
- Primärer Festplattencontroller: HPE Smart Array P816i-a SR Gen10.
- Festplatten: 9 x 1,92 TB SATA 6 Gb/s SSD (in RAID6 7+2 konfiguriert, d. h. dies ist das Modell Medium in den Begriffen von HPE SimpliVity).
- Netzwerkkarten: 4 x 1 Gb Eth (Benutzerdaten), 2 x 10 Gb Eth (Backend SimpliVity und vMotion).
- Spezielle integrierte FPGA-Karten in jedem Knoten zur Deduplizierung/Kompresion.
Die Knoten sind über einen 10 Gb Ethernet-Interconnect direkt miteinander verbunden, ohne einen externen Switch, der als Backend für SimpliVity und zur Übertragung von Virtual Machine-Daten über NFS verwendet wird. Die Daten der virtuellen Maschinen im Cluster werden immer zwischen zwei Knoten gespiegelt.
Die Knoten sind in einem Vmware vSphere-Cluster unter der Verwaltung von vCenter zusammengefasst.
Für die Durchführung der Tests wurden ein Domänencontroller und ein Citrix-Connection-Broker bereitgestellt. Der Domänencontroller, der Broker und vCenter befinden sich in einem separaten Cluster.
Als Testinfrastruktur wurden 300 virtuelle Desktops in der Konfiguration Dedicated – Full Copy bereitgestellt, d. h. jeder Desktop ist eine vollständige Kopie des Original-Images der virtuellen Maschine und speichert alle Änderungen, die von den Benutzern vorgenommen werden.
Jede virtuelle Maschine hat 2 vCPU und 4 GB RAM:
Auf den virtuellen Maschinen wurde folgende Software installiert, die für die Durchführung der Tests erforderlich ist:
- Windows 10 (64-Bit), Version 1809.
- Adobe Reader XI.
- Citrix Virtual Delivery Agent 1811.1.
- Doro PDF 1.82.
- Java 7 Update 13.
- Microsoft Office Professional Plus 2016.
Zwischen den Knoten erfolgt eine synchrone Replikation. Jeder Datenblock im Cluster hat zwei Kopien. Das heißt, derzeit ist der vollständige Datensatz auf jedem der Knoten vorhanden. Bei einem Cluster mit drei oder mehr Knoten befinden sich die Blockkopien an zwei verschiedenen Orten. Wenn eine neue VM erstellt wird, wird eine zusätzliche Kopie auf einem der Knoten im Cluster erstellt. Bei einem Ausfall eines Knotens werden alle VMs, die zuvor auf diesem Knoten ausgeführt wurden, automatisch auf anderen Knoten neu gestartet, wo sie Replikate haben. Wenn ein Knoten auf unbestimmte Zeit ausfällt, beginnt eine schrittweise Wiederherstellung der Redundanz, und das Cluster kehrt erneut zur Reservierung N+1 zurück.
Die Lastenverteilung und Speicherung von Daten erfolgt auf der Ebene des Softwarespeichers von SimpliVity.
Virtuelle Maschinen starten den Virtualisierungscluster, der sie im Softwarespeicher anordnet. Die Arbeitsplätze verwendeten ein standardmäßiges Template: beim Test waren die Arbeitsplätze von Finanzfachleuten und Operateuren (das sind zwei unterschiedliche Templates) beteiligt.
Tests
Für die Durchführung von Tests wurde das Testkomplex-Softwarepaket LoginVSI 4.1 verwendet. Das LoginVSI-Paket, bestehend aus einem Steuerungsserver und 12 Maschinen für Testverbindungen, wurde auf einem separaten physischen Host bereitgestellt.
Die Tests wurden in drei Modi durchgeführt:
Benchmark-Modus — Lastoptionen mit 300 Knowledge Workers und 300 Storage Workers.
Standardmodus — Lastoption mit 300 Power Workers.
Um die Möglichkeit der Arbeit von Power Workers zu schaffen und die Lastenvielfalt zu erhöhen, wurde dem LoginVSI-Paket eine Bibliothek zusätzlicher Dateien, die Power Library, hinzugefügt. Um die Wiederholbarkeit der Ergebnisse zu gewährleisten, wurden alle Einstellungen des Teststandes auf Standard belassen.
Die Tests der Knowledge und Power Workers simulieren die tatsächliche Benutzerlast, die an virtuellen Arbeitsplätzen arbeitet.
Der Test der Storage Workers wurde speziell für die Prüfung von Datenspeichersystemen erstellt und weicht von realen Lasten ab; er besteht größtenteils aus der Interaktion des Benutzers mit einer großen Anzahl von Dateien unterschiedlicher Größen.
Während des Tests loggen sich die Benutzer über einen Zeitraum von 48 Minuten ein, wobei etwa alle 10 Sekunden ein Benutzer hinzukommt.
Ergebnisse
Das Hauptresultat des LoginVSI-Tests ist die Metrik VSImax, die aus der Zeit für die Ausführung verschiedener vom Benutzer gestarteter Aufgaben ermittelt wird. Zum Beispiel: die Zeit zum Öffnen einer Datei in Notepad, die Zeit zum Komprimieren einer Datei in 7-Zip usw.
Eine detaillierte Beschreibung der Metriken ist in der offiziellen Dokumentation verfügbar unter .
Anders ausgedrückt, simuliert LoginVSI ein typisches Lastmuster, indem es die Aktionen von Benutzern in einer Büroanwendung, beim Lesen von PDFs usw. nachahmt und verschiedene Latenzen misst. Es gibt einen kritischen Latenzlevel (alles ruckelt, Arbeiten ist unmöglich), bis zu dem als maximale Benutzeranzahl nicht erreicht angesehen wird. Wenn die Antwortzeit um 1.000 ms schneller ist als dieser Zustand (alles ruckelt), wird die Systemleistung als normal betrachtet, und es können weitere Benutzer hinzugefügt werden.
Hier sind die wichtigsten Metriken:
Metrik
Durchgeführte Aktionen
Detailliert Beschreibung
Belastete Komponenten
NSLD
Zeit zum Öffnen einer Textdatei
von 1.500 KB
Notepad wird gestartet und
öffnet ein zufälliges Dokument mit 1.500 KB, das aus dem Pool
von Ressourcen kopiert wurde
CPU und I/O
NFO
Zeit zum Öffnen des Dialogfensters
im Notepad
Öffnen der VSI-Notepad-Datei [Ctrl+O]
CPU, RAM und I/O
ZHC*
Zeit zum Erstellen einer stark komprimierten Zip-Datei
Kompression einer lokalen
zufälligen Datei im .pst-Format mit 5 MB, die aus
dem Ressourcenpool kopiert wurde
CPU und I/O
ZLC*
Zeit zum Erstellen einer schwach komprimierten Zip-Datei
Kompression einer lokalen
zufälligen Datei im .pst-Format mit 5 MB, die aus
dem Ressourcenpool kopiert wurde
I/O
CPU
Berechnung eines großen
Arrays zufälliger Daten
Erstellung eines großen Arrays
zufälliger Daten, die im I/O-Timer verwendet werden
CPU
Bei der Durchführung des Tests wird zunächst die Basis-Metrik VSIbase ermittelt, die die Ausführungsgeschwindigkeit ohne Systembelastung anzeigt. Auf ihrer Basis wird die VSImax-Grenze definiert, die VSIbase + 1.000 ms entspricht.
Die Leistungsbewertung des Systems erfolgt auf der Grundlage von zwei Metriken: VSIbase, die die Geschwindigkeit des Systems bestimmt, und der VSImax-Grenze, die die maximale Anzahl von Benutzern definiert, die das System ohne wesentliche Leistungseinbußen verarbeiten kann.
300 Knowledge Worker Benchmark
Knowledge Worker sind Benutzer, die regelmäßig den Speicher, die CPU und die IO durch verschiedene kleine Spitzen belasten. Die Software simuliert die Last anspruchsvoller Büroanwender, als ob sie ständig auf etwas klicken (PDF, Java, Büroanwendungen, Fotoanzeige, 7-Zip). Mit der Hinzufügung von Benutzern von null bis 300 nimmt die Latenz jedes Einzelnen allmählich zu.
VSImax Statistik:
VSIbase = 986 ms, VSI-Grenze wurde nicht erreicht.
Statistik zur Systembelastung aus dem Monitoring von SimpliVity:
Bei dieser Art von Last hält das System eine steigende Belastung nahezu ohne Leistungsabfall aus. Die Ausführungszeit der Benutzeraufgaben steigt allmählich, die Reaktionszeit des Systems ändert sich während des Tests nicht und beträgt bis zu 3 ms beim Schreiben und bis zu 1 ms beim Lesen.
Ausgabe: 300 Knowledge-Nutzer arbeiten ohne Probleme im aktuellen Cluster und stören sich nicht gegenseitig, was zu einem pCPU/vCPU-Überbuchungsverhältnis von 1 zu 6 führt. Die Gesamtlatenzen steigen gleichmäßig mit wachsender Last, aber ein festgelegtes Limit wurde nicht erreicht.
300 Storage-Arbeiter-Benchmark
Dies sind Nutzer, die ständig im Verhältnis 30 zu 70 schreiben und lesen. Dieser Test wurde eher aus experimentellen Gründen durchgeführt. Statistiken aus VSImax:
VSIbase = 1673, VSI-Schwellenwert wurde bei 240 Benutzern erreicht.
Statistik zur Systembelastung aus dem Monitoring von SimpliVity:
Diese Art der Last ist im Grunde ein Stresstest für das Speichersystem. Bei seiner Durchführung schreibt jeder Benutzer eine Vielzahl zufälliger Dateien unterschiedlicher Größe auf die Festplatte. In diesem Fall ist zu erkennen, dass bei Überschreitung eines bestimmten Lastgrenzwerts die Ausführungszeiten von Aufgaben zum Schreiben von Dateien bei einigen Benutzern ansteigen. Dabei ändert sich die Last auf das Speichersystem, die CPU und den Speicher der Hosts nicht signifikant, daher kann derzeit nicht genau bestimmt werden, was die Verzögerungen verursacht.
Schlussfolgerungen zur Systemleistung aus diesem Test können nur im Vergleich zu den Testergebnissen anderer Systeme gezogen werden, da solche Lasten synthetisch und unrealistisch sind. Dennoch lief der Test insgesamt gut. Bis zu 210 Sitzungen lief alles reibungslos, danach traten unklare Reaktionen auf, die jedoch nirgendwo außer bei Login VSI verfolgt wurden.
300 Power-Arbeiter
Dies sind Benutzer, die CPU, Speicher und hohe IO schätzen. Diese 'fortgeschrittenen Benutzer' führen regelmäßig komplexe Aufgaben mit langen Spitzen aus, wie die Installation neuer Software und das Entpacken großer Archive. Statistiken aus VSImax:
VSIbase = 970, VSI-Schwellenwert wurde nicht erreicht.
Statistik zur Systembelastung aus dem Monitoring von SimpliVity:
Während des Tests wurde die Belastungsgrenze der Prozessoren auf einem der Knoten des Systems erreicht, aber dies hatte keinen nennenswerten Einfluss auf dessen Betrieb:
In diesem Fall hält das System auch bei erhöhter Last stand, ohne dass es zu einer wesentlichen Verschlechterung der Leistung kommt. Die Ausführungszeit der Benutzeraufgaben steigt allmählich, die Reaktionszeit des Systems ändert sich während der Tests nicht und beträgt bis zu 3 ms beim Schreiben und bis zu 1 ms beim Lesen.
Die üblichen Tests waren für den Kunden nicht ausreichend, also gingen wir weiter: Wir haben die Spezifikationen der VM (Anzahl der vCPUs, um die Erhöhung der Überbuchung und die Größe der Festplatte zu bewerten) erhöht und zusätzliche Last hinzugefügt.
Bei den zusätzlichen Tests wurde die folgende Standkonfiguration verwendet:
Es wurden 300 virtuelle Desktops in der Konfiguration 4vCPU, 4GB RAM, 80GB HDD bereitgestellt.
Konfiguration einer der Testmaschinen:
Die Maschinen wurden in der Variante Dedicated – Full Copy bereitgestellt:
300 Knowledge Workers Benchmark mit einer Überbuchung von 12
VSImax Statistik:
VSIbase = 921 ms, der VSI-Schwellenwert wurde nicht erreicht.
Statistik zur Systembelastung aus dem Monitoring von SimpliVity:
Die erhaltenen Ergebnisse entsprechen den Tests der vorherigen VM-Konfiguration.
300 Power Workers mit einer Überbuchung von 12
VSImax Statistik:
VSIbase = 933, der VSI-Schwellenwert wurde nicht erreicht.
Statistik zur Systembelastung aus dem Monitoring von SimpliVity:
Bei diesem Test wurde ebenfalls der Belastungsschwellwert der Prozessoren erreicht, aber dies hatte keine wesentlichen Auswirkungen auf die Leistung:
Die erhaltenen Ergebnisse entsprechen den Tests der vorherigen Konfiguration.
Was passiert, wenn die Last 10 Stunden lang läuft?
Jetzt sehen wir, ob es einen „Kumulationseffekt“ gibt, und führen die Tests 10 Stunden lang nacheinander durch.
Längere Tests und die Beschreibung des Abschnitts sollten darauf abzielen, zu überprüfen, ob während einer längeren Belastung auf der Farm Probleme auftreten.
300 Knowledge Workers Benchmark + 10 Stunden
Zusätzlich wurde ein Test mit einer Last von 300 Knowledge Workers durchgeführt, gefolgt von 10 Stunden Benutzerarbeit.
VSImax Statistik:
VSIbase = 919 ms, der VSI-Schwellenwert wurde nicht erreicht.
Daten der VSImax Detailed Statistik:
Der Graph zeigt, dass während des gesamten Tests keine Leistungsverschlechterung zu beobachten war.
Statistik zur Systembelastung aus dem Monitoring von SimpliVity:
Die Leistung des Speichers bleibt während des gesamten Tests auf einem konstanten Niveau.
Zusätzliches Testen mit добавлением синтетической нагрузки
Der Kunde bat darum, eine hohe Last auf die Festplatte zu erzeugen. Dazu wurde in jeder der virtuellen Benutzermaschinen ein Auftrag zur Ausführung synthetischer Lasten auf der Festplatte beim Anmelden des Benutzers im System hinzugefügt. Die Last wurde mit dem Tool fio bereitgestellt, das die Last auf die Festplatte nach IOPS begrenzen kann. In jeder Maschine wurde ein Auftrag zur Ausführung zusätzlicher Lasten mit 22 IOPS 70 %/30 % Zufälliges Lesen/Schreiben gestartet.
300 Wissensarbeiter Benchmark + 22 IOPS pro Benutzer
Bei den anfänglichen Tests wurde festgestellt, dass fio eine erhebliche zusätzliche Last auf die CPU der virtuellen Maschinen erzeugt. Dies führte zu einer schnellen Überlastung der Hosts hinsichtlich CPU und hatte große Auswirkungen auf die gesamte Systemleistung.
Belastung der CPU der Hosts:
Die Verzögerungen des Speichersystems nahmen dabei ebenfalls zwangsläufig zu:
Der Mangel an Rechenleistung wurde bei etwa 240 Benutzern kritisch:
Infolge der erhaltenen Ergebnisse wurde entschieden, Tests durchzuführen, die die CPU weniger belasten.
230 Büroangestellte Benchmark + 22 IOPS pro Benutzer
Um die CPU-Last zu reduzieren, wurde der Typ der Last auf Büroangestellte gewählt, zudem wurden für jede Sitzung ebenfalls 22 IOPS synthetische Last hinzugefügt.
Der Test wurde auf 230 Sitzungen begrenzt, um die maximale CPU-Last nicht zu überschreiten.
Der Test wurde mit anschließender Benutzerarbeit über 10 Stunden gestartet, um die Stabilität des Systems bei Langzeitarbeit unter nahezu maximaler Last zu überprüfen.
VSImax Statistik:
VSIbase = 918 ms, der VSI-Schwellenwert wurde nicht erreicht.
Daten der VSImax Detailed Statistik:
Der Graph zeigt, dass während des gesamten Tests keine Leistungsverschlechterung zu beobachten war.
Statistische Daten zur CPU-Last:
Während dieses Tests war die CPU-Last der Hosts nahezu maximal.
Statistik zur Systembelastung aus dem Monitoring von SimpliVity:
Die Leistung des Speichers bleibt während des gesamten Tests auf einem konstanten Niveau.
Die Last auf dem Speichersystem während des Tests betrug etwa 6.500 IOPS im Verhältnis 60/40 (3.900 IOPS für Lesen, 2.600 IOPS für Schreiben), was etwa 28 IOPS pro Arbeitsstation entspricht.
Die Reaktionszeit betrug im Durchschnitt 3 ms für Schreiben und bis zu 1 ms für Lesen.
Fazit
Bei der Simulation realer Lasten auf die Infrastruktur HPE SimpliVity wurden Ergebnisse erzielt, die die Fähigkeit des Systems bestätigen, den Betrieb von virtuellen Desktops in einer Anzahl von mindestens 300 Full Clone-Maschinen auf einem Paar von SimpliVity-Knoten zu gewährleisten. Dabei blieb die Reaktionszeit des Speichersystems während des gesamten Tests auf optimalem Niveau.
Wir schätzen den Ansatz mit längeren Tests und dem Vergleich von Lösungen vor der Implementierung sehr. Wir können die Leistung auch für Ihre Lasten testen, wenn Sie möchten. Dazu gehören auch andere hyperkonvergente Lösungen. Der genannte Kunde beendet derzeit Testläufe mit einer anderen Lösung parallel. Seine aktuelle Infrastruktur besteht nur aus einem Pool von PCs, einer Domain und Software an jedem Arbeitsplatz. Ohne Tests auf VDI umzusteigen, ist natürlich ziemlich schwierig. Insbesondere ist es schwierig, die tatsächlichen Möglichkeiten der VDI-Farm zu verstehen, ohne reale Benutzer darauf migriert zu haben. Und diese Tests ermöglichen es, die realen Möglichkeiten eines Systems schnell zu bewerten, ohne dass übliche Benutzer herangezogen werden müssen. Daher entstand diese Studie.
Ein weiterer wichtiger Ansatz ist, dass der Kunde bereits auf richtige Skalierung gesetzt hat. Hier kann man Server dazukaufen und beispielsweise eine Farm für 100 Benutzer hinzufügen, alles vorhersehbar in Bezug auf die Kosten pro Benutzer. Wenn sie zum Beispiel 300 weitere Benutzer hinzufügen müssen, wissen sie, dass sie zwei Server in einer bereits definierten Konfiguration benötigen, anstatt die Möglichkeiten der Modernisierung ihrer Infrastruktur insgesamt zu überdenken.
Die Möglichkeiten der HPE SimpliVity-Federation sind interessant. Das Geschäft ist geografisch verteilt, daher macht es Sinn, im entfernten Büro eine eigene VDI-Hardware einzurichten. In der SimpliVity-Federation wird jede virtuelle Maschine gemäß einem Zeitplan repliziert, mit der Möglichkeit, zwischen geografisch entfernten Clustern sehr schnell und ohne Belastung des Kanals zu arbeiten – das ist ein in-built Backup von sehr hohem Niveau. Bei der VM-Replikation zwischen Standorten wird der Kanal so minimal wie möglich genutzt, was interessante DR-Architekturen bei Vorhandensein eines zentralen Managements und vieler dezentralisierter Speicherorte ermöglicht.
All dies zusammen bietet die Möglichkeit, auch die finanziellen Aspekte sehr detailliert zu bewerten, die Kosten für VDI auf die Wachstumspläne des Unternehmens zu legen und zu verstehen, wie schnell sich die Lösung amortisieren wird und wie sie arbeiten wird. Denn jede VDI ist eine Lösung, die letztendlich eine Menge Ressourcen spart, aber wahrscheinlich ohne eine wirtschaftlich rentable Möglichkeit, sie innerhalb von 5–7 Jahren Nutzung zu ändern.
Wenn Sie Fragen haben, die nicht in die Kommentare gehören, schreiben Sie mir bitte eine E-Mail an mk@croc.ru.
Quelle: habr.com
