Der Kunde wollte VDI und hat sich intensiv mit der Kombination SimpliVity + VDI Citrix Virtual Desktop befasst. Dies gilt für alle Operatoren und Büromitarbeiter in verschiedenen Städten. In der ersten Welle der Migration gibt es allein fünf Tausend Benutzer, weshalb sie auf Lasttests bestanden haben. VDI kann anfangen, langsam zu werden; es kann auch einfach ausfallen – und das passiert nicht immer aufgrund von Problemen mit der Verbindung. Wir haben ein sehr leistungsfähiges Testpaket speziell für VDI gekauft und die Infrastruktur so lange belastet, bis sie überlastet war, sowohl in Bezug auf die Festplatten als auch auf die Prozessoren.
Dafür benötigen wir eine Plastikflasche und die Software LoginVSI für erweiterte VDI-Tests. Wir haben die Lizenzen für 300 Benutzer. Dann haben wir die Hardware HPE SimpliVity 380 beschafft, die für die maximale Benutzeranzahl pro Server geeignet ist, und haben virtuelle Maschinen mit einer guten Überbuchung erstellt, darauf Office-Software mit Windows 10 installiert und mit den Tests begonnen.
Los geht's!
System
Zwei Knoten (Server) HPE SimpliVity 380 Gen10. Auf jedem:
- 2 x Intel Xeon Platinum 8170 26c 2.1GHz.
- Arbeitsspeicher: 768GB, 12 x 64GB LRDIMMs DDR4 2666MHz.
- Hauptspeichercontroller: HPE Smart Array P816i-a SR Gen10.
- Festplatten: 9 x 1.92 TB SATA 6Gb/s SSD (in RAID6 7+2 konfiguriert, also das Modell Medium in den Begriffen von HPE SimpliVity).
- Netzwerkkarten: 4 x 1Gb Eth (Benutzerdaten), 2 x 10Gb Eth (BackendSimpliVity und vMotion).
- Spezielle integrierte FPGA-Karten in jedem Knoten für Deduplizierung/Kompaktheit.
Die Knoten sind über ein 10Gb Ethernet-Interconnect direkt miteinander verbunden, ohne externen Switch, der als Backend für SimpliVity und für die Datenübertragung virtueller Maschinen über NFS verwendet wird. Die Daten der virtuellen Maschinen im Cluster werden immer zwischen zwei Knoten gespiegelt.
Die Knoten sind zu einem VMware vSphere-Cluster unter der Verwaltung von vCenter zusammengefasst.
Für Tests wurden ein Domänencontroller und ein Citrix-Connection-Broker bereitgestellt. Der Domänencontroller, der Broker und vCenter sind in einem separaten Cluster untergebracht.
Als Testinfrastruktur wurden 300 virtuelle Desktops mit der Konfiguration Dedicated – Full Copy bereitgestellt, d. h., jeder Desktop ist eine vollständige Kopie des Originalimages der virtuellen Maschine und speichert alle Änderungen, die von Benutzern vorgenommen wurden.
Jede virtuelle Maschine verfügt über 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 bedeutet, dass derzeit der vollständige Datensatz auf jedem der Knoten vorhanden ist. Bei einem Cluster mit drei oder mehr Knoten befinden sich die Blockkopien an zwei verschiedenen Orten. Bei der Erstellung einer neuen VM wird eine zusätzliche Kopie auf einem der Knoten im Cluster erstellt. Wenn ein Knoten ausfällt, werden alle vorangegangenen VMs, die dort ausgeführt wurden, automatisch auf anderen Knoten mit vorhandenen Replikaten neu gestartet. Fällt ein Knoten länger aus, beginnt die schrittweise Wiederherstellung der Redundanz, und das Cluster kehrt wieder zur N+1-Reservierung zurück.
Die Datenbalance und -speicherung erfolgen auf der Ebene des Software-Speichers von SimpliVity.
Virtuelle Maschinen starten den Virtualisierungscluster, der sie auch im Software-Speicher anordnet. Die Arbeitsplätze basieren auf Standardvorlagen: Es wurden Tische für Finanz- und Betriebsteams getestet (das sind zwei verschiedene Vorlagen).
Testen
Für die Durchführung der Tests wurde die Software-Suite LoginVSI 4.1 verwendet. Die LoginVSI-Suite, bestehend aus einem Management-Server und 12 Maschinen für Testverbindungen, wurde auf einem separaten physischen Host bereitgestellt.
Die Tests wurden in drei Modi durchgeführt:
Benchmark-Modus – Lastszenarien mit 300 Knowledge Workers und 300 Storage Workers.
Standardmodus – Lastszenario mit 300 Power Workers.
Um das Arbeiten der Power Workers zu ermöglichen und die Lastvariabilität zu erhöhen, wurde der LoginVSI-Suite eine Bibliothek zusätzlicher Dateien, die Power Library, hinzugefügt. Um die Wiederholbarkeit der Ergebnisse sicherzustellen, wurden alle Einstellungen des Teststandes auf Standard belassen.
Die Tests der Knowledge und Power Workers simulieren die tatsächliche Belastung von Benutzern, die auf virtuellen Arbeitsplätzen arbeiten.
Der Storage Workers-Test wurde speziell für die Prüfung von Datenspeichersystemen entwickelt und entfernt sich von realistischen Lasten, indem er größtenteils aus der Interaktion der Benutzer mit einer Vielzahl von Dateien unterschiedlicher Größen besteht.
Während des Tests melden sich die Benutzer über einen Zeitraum von 48 Minuten an den Arbeitsplätzen an, wobei alle 10 Sekunden ungefähr ein Benutzer hinzukommt.
Ergebnisse
Das Hauptresultat des LoginVSI-Tests ist die VSImax-Metrik, die aus der Ausführungszeit verschiedener vom Benutzer gestarteter Aufgaben besteht. Zum Beispiel: die Zeit zum Öffnen einer Datei im Editor, die Zeit zum Komprimieren einer Datei mit 7-Zip usw.
Eine ausführliche Beschreibung der Metrik-Berechnung finden Sie in der offiziellen Dokumentation zu .
Mit anderen Worten, LoginVSI simuliert ein typisches Lastprofil, das Benutzeraktionen in einem Office-Paket, beim Lesen von PDFs usw. nachahmt und verschiedene Latenzen misst. Es gibt einen kritischen Latenzlevel, bei dem "alles ruckelt, Arbeiten ist unmöglich"; bis zu diesem Punkt wird angenommen, dass die maximale Anzahl von Benutzern nicht erreicht ist. Wenn die Antwortzeit unter 1.000 ms liegt, während es noch nicht zum Zustand "alles ruckelt" gekommen ist, gilt das System als normal und es können weitere Benutzer hinzugefügt werden.
Hier sind die Hauptmetriken:
Metrik
Durchgeführte Aktionen
Ausführlich Beschreibung
Belastete Komponenten
NSLD
Zeit zum Öffnen einer Textdatei
mit einer Größe von 1.500 KByte
Der Editor wird gestartet und
öffnet ein zufälliges Dokument mit 1.500 KByte, das aus dem Ressourcenpool kopiert wurde.
Ressourcen
CPU und I/O
NFO
Zeit zum Öffnen des Dialogfensters im Editor
Öffnen der VSI-Notepad-Datei [Ctrl+O]
CPU, RAM und I/O
CPU, RAM и I/O
ZHC*
Zeit zur Erstellung einer Zip-Datei mit starker Komprimierung
Komprimierung einer lokalen
zufälligen Datei im .pst-Format mit einer Größe von 5 MB, die aus
dem Ressourcenpool
CPU und I/O
ZLC*
Zeit zur Erstellung einer Zip-Datei mit schwacher Komprimierung
Komprimierung einer lokalen
zufälligen Datei im .pst-Format mit einer Größe von 5 MB, die aus
dem Ressourcenpool
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 von Tests wird zunächst die Basismetrik VSIbase ermittelt, die die Bearbeitungsgeschwindigkeit ohne Systemlast anzeigt. Auf dieser Grundlage wird die VSImax-Schwelle festgelegt, die VSIbase + 1.000 ms entspricht.
Erscheinungen zur Systemleistung werden anhand zweier Metriken gemacht: VSIbase, die die Systemgeschwindigkeit bestimmt, und die VSImax-Schwelle, die die maximale Anzahl an Benutzern angibt, die das System ohne wesentliche Beeinträchtigung verarbeiten kann.
300 Benchmark für Wissensarbeiter
Wissensarbeiter sind Nutzer, die regelmäßig Speicher, Prozessor und IO mit verschiedenen kleinen Spitzen belasten. Die Software simuliert die Last anspruchsvoller Büroanwender, als würden sie ständig etwas klicken (PDF, Java, Office-Paket, Fotos anzeigen, 7-Zip). Mit zunehmender Nutzerzahl von null bis 300 steigt die Latenz bei jedem Nutzer allmählich an.
VSImax Statistiken:
VSIbase = 986 ms, VSI-Schwelle wurde nicht erreicht.
Statistiken zur Last auf das Speichersystem aus dem Monitoring von SimpliVity:
Bei dieser Art der Last hält das System die Erhöhung der Last nahezu ohne Leistungseinbußen stand. Die Ausführungszeit der Benutzeraufgaben steigt allmählich an, die Systemantwortzeit bleibt während des Tests unverändert und beträgt bis zu 3 ms beim Schreiben und bis zu 1 ms beim Lesen.
Fazit: 300 Wissensnutzer arbeiten problemlos im aktuellen Cluster und stören einander nicht, wobei ein Überbuchungsverhältnis von pCPU/vCPU von 1 zu 6 erreicht wird. Die Gesamtlatenzen steigen gleichmäßig mit zunehmender Last, aber der definierte Grenzwert wurde nicht erreicht.
Benchmark für 300 Storage Arbeiter
Das sind Benutzer, die ständig im Verhältnis 30 zu 70 schreiben und lesen. Dieser Test wurde eher zum Experiment durchgeführt. VSImax Statistikdaten:
VSIbase = 1673, der VSI-Schwellenwert wurde bei 240 Benutzern erreicht.
Statistiken zur Last auf das Speichersystem aus dem Monitoring von SimpliVity:
Diese Art von Belastung ist im Grunde ein Stresstest der Speichersysteme. Bei der Durchführung zeichnet jeder Benutzer viele zufällige Dateien unterschiedlicher Größen auf die Festplatte. In diesem Fall zeigt sich, dass bei Überschreitung eines bestimmten Lastgrenzwerts die Zeit für das Schreiben von Dateien bei einigen Benutzern ansteigt. Die Belastung des Speichersystems, der Prozessor und der Arbeitsspeicher der Hosts bleibt jedoch weitgehend unverändert, weshalb momentan nicht genau festgestellt werden kann, woran die Verzögerungen liegen.
Schlussfolgerungen zur Leistungsfähigkeit des Systems mithilfe dieses Tests können nur im Vergleich zu den Ergebnissen von Tests auf anderen Systemen gezogen werden, da solche Lasten synthetisch und unrealistisch sind. Dennoch lief der Test insgesamt gut. Bis zu 210 Sitzungen lief alles reibungslos, danach traten unverständliche Reaktionen auf, die nirgendwo außer bei Login VSI erfasst wurden.
300 Power-Worker
Dies sind Benutzer, die Prozessor, Arbeitsspeicher und hohe IO bevorzugen. Diese „fortgeschrittenen Benutzer“ führen regelmäßig komplexe Aufgaben mit längeren Spitzen durch, wie die Installation neuer Software und das Entpacken großer Archive. Daten von VSImax:
VSIbase = 970, VSI Schwellenwert wurde nicht erreicht.
Statistiken zur Last auf das Speichersystem aus dem Monitoring von SimpliVity:
Beim Testen wurde der Belastungsschwellwert der Prozessoren auf einem der Knoten des Systems erreicht, was jedoch keine wesentlichen Auswirkungen auf die Betriebsfähigkeit hatte:
In diesem Fall hält das System auch bei höherer Last stand, ohne dass es zu einer wesentlichen Verschlechterung der Leistung kommt. Die Ausführungszeit der Benutzeraufträge steigt allmählich, die Reaktionszeit des Systems ändert sich während des Tests nicht und bleibt bei bis zu 3 ms beim Schreiben und bis zu 1 ms beim Lesen.
Die regulären Tests reichten dem Kunden nicht aus, also gingen wir einen Schritt weiter: Wir erhöhten die Spezifikationen der VM (Anzahl der vCPUs, um den Anstieg der Überbuchung zu bewerten, und die Größe der Festplatte) und fügten zusätzliche Last hinzu.
Bei der Durchführung zusätzlicher Tests wurde folgende Standkonfiguration verwendet:
300 virtuelle Desktops wurden mit 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 Nachschreibung von 12
VSImax Statistiken:
VSIbase = 921 ms, der VSI-Schwellenwert wurde nicht erreicht.
Statistiken zur Last auf das Speichersystem aus dem Monitoring von SimpliVity:
Die erhaltenen Ergebnisse ähneln den Tests der vorherigen VM-Konfiguration.
300 Power Workers mit einer Nachschreibung von 12
VSImax Statistiken:
VSIbase = 933, der VSI-Schwellenwert wurde nicht erreicht.
Statistiken zur Last auf das Speichersystem aus dem Monitoring von SimpliVity:
Bei diesem Test wurde ebenfalls die Prozessorlastegrenze erreicht, jedoch hatte dies keinen signifikanten Einfluss auf die Leistung:
Die erhaltenen Ergebnisse sind vergleichbar mit den Tests der vorherigen Konfiguration.
Was passiert, wenn wir die Last für 10 Stunden laufen lassen?
Nun schauen wir, ob ein „Kumulierungseffekt“ auftritt, und führen die Tests 10 Stunden am Stück durch.
Langzeittests und die Beschreibung des Abschnitts sollten darauf abzielen, ob während einer längeren Belastung Probleme mit der Farm auftreten.
300 Knowledge Workers-Benchmark + 10 Stunden
Zusätzlich wurde ein Test mit 300 Knowledge Workers durchgeführt, gefolgt von einer Benutzung der Benutzer über 10 Stunden.
VSImax Statistiken:
VSIbase = 919 ms, der VSI-Schwellenwert wurde nicht erreicht.
Statistikdaten VSImax Detailed:
Dem Diagramm ist zu entnehmen, dass während des gesamten Tests keine Leistungsdegradation zu beobachten war.
Statistiken zur Last auf das Speichersystem aus dem Monitoring von SimpliVity:
Die Speicherleistung bleibt während des gesamten Tests konstant.
Zusätzliche Tests mit künstlicher Last
Der Kunde bat darum, eine hohe Last auf die Festplatte zu simulieren. Dafür wurde auf jeder der virtuellen Maschinen der Benutzer ein Auftrag eingerichtet, der beim Anmelden des Benutzers auf die Festplatte synthetische Last erzeugte. Die Last wurde mit dem Tool fio erzeugt, das die Festplattenlast in Bezug auf die Anzahl der IOPS begrenzen kann. Auf jeder Maschine wurde ein zusätzlicher Lastauftrag mit 22 IOPS im Verhältnis 70 % / 30 % für 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 im Hinblick auf die CPU und hatte erhebliche Auswirkungen auf die Systemleistung insgesamt.
CPU-Belastung der Hosts:
Die Verzögerungen im Speichersystem sind entsprechend ebenfalls gestiegen:
Der Mangel an Rechenleistung wurde ab etwa 240 Benutzern kritisch.
Basierend auf den erzielten Ergebnissen wurde beschlossen, einen Test durchzuführen, der die CPU weniger belastet.
230 Büroangestellte Benchmark + 22 IOPS pro Benutzer
Um die CPU-Belastung zu verringern, wurde der Belastungstyp Büroangestellte gewählt, und jeder Sitzung wurden zusätzlich 22 IOPS synthetische Belastung hinzugefügt.
Der Test war auf 230 Sitzungen begrenzt, um die maximale CPU-Belastung nicht zu überschreiten.
Der Test wurde mit einer anschließenden Nutzung durch die Benutzer über 10 Stunden gestartet, um die Stabilität des Systems bei längeren Arbeiten unter einer nahezu maximalen Belastung zu überprüfen.
VSImax Statistiken:
VSIbase = 918 ms, der VSI-Schwellenwert wurde nicht erreicht.
Statistikdaten VSImax Detailed:
Dem Diagramm ist zu entnehmen, dass während des gesamten Tests keine Leistungsdegradation zu beobachten war.
Statistikdaten zur CPU-Belastung:
Während dieses Tests war die CPU-Belastung der Hosts nahezu maximal.
Statistiken zur Last auf das Speichersystem aus dem Monitoring von SimpliVity:
Die Speicherleistung bleibt während des gesamten Tests konstant.
Die Belastung des Speichersystems 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 durchschnittliche Reaktionszeit betrug 3 ms beim Schreiben und bis zu 1 ms beim Lesen.
Zusammenfassung
Bei der Modellierung realer Lasten auf die HPE SimpliVity-Infrastruktur wurden Ergebnisse erzielt, die die Fähigkeit des Systems bestätigen, den Betrieb von mindestens 300 Full Clone-Desktops mit einem Paar SimpliVity-Knoten zu gewährleisten. Dabei blieb die Reaktionszeit des Speichersystems während der gesamten Testphase auf einem optimalen Niveau.
Wir schätzen den Ansatz von Langzeit-Tests und den Vergleich von Lösungen vor der Implementierung sehr. Gerne können wir die Leistung auch für Ihre spezifischen Lasten testen, falls gewünscht. Dies schließt auch andere hyperkonvergente Lösungen ein. Der erwähnte Kunde schließt derzeit Tests mit einer anderen Lösung parallel ab. Seine aktuelle Infrastruktur besteht einfach aus einer Vielzahl von PCs, einer Domäne und Software auf jedem Arbeitsplatz. Ein Umstieg auf VDI ohne Tests ist natürlich ziemlich schwierig. Besonders herausfordernd ist es, die realen Möglichkeiten einer VDI-Farm zu verstehen, ohne echte Nutzer darauf migriert zu haben. Diese Tests ermöglichen es, die tatsächlichen Fähigkeiten eines Systems schnell zu bewerten, ohne gewöhnliche Nutzer hinzuziehen zu müssen. Daher entstand diese Untersuchung.
Der zweite wichtige Ansatz besteht darin, dass der Kunde sofort auf die richtige Skalierung gesetzt hat. Hier kann man Server dazu kaufen und beispielsweise eine Farm für 100 Benutzer hinzufügen, die Kosten pro Benutzer sind dadurch gut vorhersehbar. Wenn ihnen beispielsweise 300 weitere Benutzer hinzukommen, wissen sie, dass sie zwei Server in einer bereits festgelegten Konfiguration benötigen, anstatt die Möglichkeiten zur Modernisierung ihrer Infrastruktur insgesamt zu überdenken.
Die Möglichkeiten der HPE SimpliVity-Föderation sind interessant. Das Geschäft ist geografisch verteilt, daher macht es Sinn, in entfernten Büros eigene VDI-Hardware einzusetzen. In der SimpliVity-Föderation wird jede virtuelle Maschine nach einem Zeitplan repliziert, mit der Möglichkeit, dies zwischen geografisch entfernten Clustern sehr schnell und ohne Belastung des Kanals durchzuführen – das ist ein integriertes Backup von sehr hohem Niveau. Bei der Replikation von VMs zwischen den Standorten wird der Kanal so minimal wie möglich genutzt, was interessante DR-Architekturen ermöglicht, bei denen es ein zentrales Management und viele dezentralisierte Speicherorte gibt.
All dies ermöglicht eine sehr detaillierte Bewertung der finanziellen Aspekte sowie die Verknüpfung der Kosten für VDI mit den Wachstumsplänen des Unternehmens. So kann auch verstanden werden, wie schnell sich die Lösung amortisiert und wie sie funktioniert. Denn jede VDI-Lösung spart letztendlich eine Menge Ressourcen, bietet jedoch wahrscheinlich keine wirtschaftlich vorteilhafte Möglichkeit, sie innerhalb von 5 bis 7 Jahren Nutzung auszutauschen.
Wenn Sie weitere Fragen haben, die nicht für die Kommentare gedacht sind, schreiben Sie mir bitte an mk@croc.ru.
Quelle: habr.com
