Benchmark für Windows-VMs gesucht

[GMBauer]

Grueziwoll beinand,

sagt mal, wenn Ihr auf einem neuen System eine VM aufsetzt, prüft Ihr das ganze auch auf Geschwindigkeit? Ich meine, nur rumklicken auf der Oberfläche verrät ja nichts über die Geschwindigkeit einer VM und damit, ob sie "richtig" läuft.

Wenn ja, welches Banchmarkprogramm nutzt ihr? Cinebench scheitert an Grafikblabla, die meisten anderen brauchen zu lange für die Installation...

Ich habe beim heise den Passmark PerformanceTest gefunden, der mir eigentlich gefällt. Wie macht Ihr das? Welche Programme nutzt ihr?

Have a nice week!

 

[Impact]

Was genau willst du testen?

 

[rprengel]

Du müsstest schon beschreiben was die VM funktional liefern soll. Persönlich empfehle ich synthetische Tests mit z.B. RobotMK um User-Interaktionen zu simulieren. Da sieht man dann zügig ob Wunsch und Wirklichkeit zueinander passen,

 

[GMBauer]

War eine blöde Frage von mir, oder?

Ich bin nur etwas verschreckt von den - gefühlt immer mehr werdenden - Menschen, die hier aufschlagen und Probleme mit zu langsamen VMs haben. Wie kann ich erkennen, dass eine VM zu langsam läuft? Klar, wenn die Anwendung drauf installiert ist, aber es wäre halt nett, wenn man vorher checken könnte, dass die VM grundsätzlich in den Grenzen ihrer virtualisierten Hardware "läuft".

Gebe gerne zu, dass ich noch nie ein Problem hatte.

Ich rede hier eigentlich nur von Windows Server 2025-VMs für Business-Software, also Datenbank-Anwendungen.

 

[rprengel]

Alles gut. Mehr user = mehr immer wieder die gleichen Fragen.

Zum Thema:
1) Mit synthetischem Monitoring misst du z.B. das Verhalten deiner Webanwendung in allen Einzelschritten. Lass das x mal pro Tag laufen und du siehst ganz zügig positive und negative Effekte wenn Änderungen an der VM /dem Proxmox-Host durch schlagen.
2) Zusätzlich monitore den Zustand deiner Hardware. Platten die sterben oder CPUs die brennen machen Systeme auch nicht schneller.
3) Überwache die Netzwerkkarte und den Switch. Paketfehler die durch die Decke gehen sind auch ein Zeichen für Ärger.

Nagios-Zabbis-checkmk-Icinga wären typische Tools. Ich nutze chckmk.
Gruß

 

[TErxleben]

War eine blöde Frage von mir, oder?

Ich bin nur etwas verschreckt von den - gefühlt immer mehr werdenden - Menschen, die hier aufschlagen und Probleme mit zu langsamen VMs haben. Wie kann ich erkennen, dass eine VM zu langsam läuft? Klar, wenn die Anwendung drauf installiert ist, aber es wäre halt nett, wenn man vorher checken könnte, dass die VM grundsätzlich in den Grenzen ihrer virtualisierten Hardware "läuft".

Gebe gerne zu, dass ich noch nie ein Problem hatte.

Ich rede hier eigentlich nur von Windows Server 2025-VMs für Business-Software, also Datenbank-Anwendungen.

ich mache es mir recht einfach und ziehe gedanklich nur 5-10% von möglichen Baremetal-Leistungen ab. Erst wenn z.B. GPUs durchgereicht werden, kann es überhaupt zur Performancesuche kommen. Wenn eine Brot+Butter-VM als langsam beschrieben wird, prüfe ich die Netzverbindung und ob der Host womöglich am Anschlag läuft. Nebenbei sind Nutzer, die kurzfristig fundierte Rückmeldung geben, ein gutes Indiz. Dann merkt man beim Remotezugriff aus Erfahrung recht schnell, wie sich eine VM "anfühlt" und die Auslasstung innerhalb der VM anschauen. Automatisiert geht das m.E. nichts

 

[rprengel]

ich mache es mir recht einfach und ziehe gedanklich nur 5-10% von möglichen Baremetal-Leistungen ab. Erst wenn z.B. GPUs durchgereicht werden, kann es überhaupt zur Performancesuche kommen. Wenn eine Brot+Butter-VM als langsam beschrieben wird, prüfe ich die Netzverbindung und ob der Host womöglich am Anschlag läuft. Nebenbei sind Nutzer, die kurzfristig fundierte Rückmeldung geben, ein gutes Indiz. Dann merkt man beim Remotezugriff aus Erfahrung recht schnell, wie sich eine VM "anfühlt" und die Auslasstung innerhalb der VM anschauen. Automatisiert geht das m.E. nichts

Das Stichwort ist syntetic monitoring. Damit simulierst du vollständige Client-Interaktion aus Sicht des Users und bekommst jede Menge Menge Metriken. Z.B. wie lange dauerte ein Login, wie schnell war eine definierte Suche oder wie schnell wird ein Dokument angezeigt.

 

[TErxleben]

Das Stichwort ist syntetic monitoring. Damit simulierst du vollständige Client-Interaktion aus Sicht des Users und bekommst jede Menge Menge Metriken. Z.B. wie lange dauerte ein Login, wie schnell war eine definierte Suche oder wie schnell wird ein Dokument angezeigt.

Es geht aber nicht um Simulation sondern Protokollierung. Das macht ein PVE für die wichtigsten Werte schon von Haus aus. Diese Werte weiter aufzudröseln, ist Augenwischerei und lohnt den massiven Aufwand für schnöde ArbeitsVMs nicht.

 

[rprengel]

Das lohnt sich sofort wenn Kunden / Mitarbeiter reklamieren und man das gleiche Verhalten in seinen Metriken sieht. Oder halt auch nicht und sich sicher sein kann das man das Verhalten sehen würde.
Gruß

 

[TErxleben]

Dummerweise sieht man das so gut wie nie in irgendwelchen aufgedröselten Metriken.
Ich verlasse mich jedenfalls viel eher auf die Schilderung von echten Usern und freue mich, wenn ich das in Metriken wieder finden kann. Anders herum geht das einfach nicht. Es gilt immer noch die goldene Regel: Wer viel misst, misst Mist.

 

[rprengel]

Dummerweise sieht man das so gut wie nie in irgendwelchen aufgedröselten Metriken.
Ich verlasse mich jedenfalls viel eher auf die Schilderung von echten Usern und freue mich, wenn ich das in Metriken wieder finden kann. Anders herum geht das einfach nicht. Sonst gilt die goldene Regel: Wer viel misst, misst Mist.

Du kennst Tools wie RobotMK die dir jeden einzelnen Arbeitsschritt messen können so das du bei Login dauert zu lange sehen kannst on die Anmeldemaske zu lange braucht, die Login Abfrage sich zieht oder aber die nachfolgende Seite zu langsam hoch kommt?

Gruß

 

[TErxleben]

Du kennst Tools wie RobotMK die dir jeden einzelnen Arbeitsschritt messen können so das du bei Login dauert zu lange sehen kannst on die Anmeldemaske zu lange braucht, die Login Abfrage sich zieht oder aber die nachfolgende Seite zu langsam hoch kommt?

Gruß

RobotMK nun nicht aber IDS-Systeme nur zu gut. Schon wenn man 3rd-party Tools installieren muss, dann ist es m.E. zuviel Gehüser für fragwürdigen Erfolg.
Nur als Beispiel: Wenn dir deine Metrik hohen Disk-IO zeigt, woran liegt es? Daran das die Bude aus Redmond mal wieder Updates installiert? Das kann ich sogar mit den rudimentären Statistiken eines PVE entnehmen.

 

[rprengel]

RobotMK nun nicht aber IDS-Systeme nur zu gut. Schon wenn man 3rd-party Tools installieren muss, dann ist es m.E. zuviel Gehüser für fragwürdigen Erfolg.
Nur als Beispiel: Wenn dir deine Metrik hohen Disk-IO zeigt, woran liegt es? Daran das die Bude aus Redmond mal wieder Updates installiert? Das kann ich sogar mit den rudimentären Statistiken eines PVE entnehmen.

Nope robotmk wird nicht installiert sondern simuliert einen Anwender der z.B. ein shopsystem aufruft und bestellt. Wenn dann in den Arbeitsschritten Probleme auftreten kann man schauen was man z.B. in Proxmox selber oder seinem Monitoring an Hinweisen findet.

 

[TErxleben]

Nope robotmk wird nicht installiert sondern simuliert einen Anwender der z.B. ein shopsystem aufruft und bestellt. Wenn dann in den Arbeitsschritten Probleme auftreten kann man schauen was man z.B. in Proxmox selber oder seinem Monitoring an Hinweisen findet.

Und wie analysiere ich dann den Schluckauf einer einzelnen Büro-VM?

 

[rprengel]

Logfiles lesen wenn klar ist wonach man suchen muss. Zeitstempel + Fehlerbeschreibung. Ich habe aber grundsätzliche alles Systeme in einem zentralen Monitoring. Wenn man das alles sauber aufsetzt und mit eine ordentlichen Softwareverwaltung arbeitet alles kein Hexenwerk. Stichworte in meiner Umgebung sind terraform, ansible , checkmk und splunk. Alles beliebig austauschbar solange sie Funktionen verfügbar sind. Ein SIEM und ein Kali mit einem Securityscanner runden das dann noch ab.

 

[TErxleben]

Natürlich jedem Tierchen sein Pleasirchen.

In meinen Augen viel zu viel Aufwand.
Erst wenn sich jemand beschwert, lohnt sich ein intensiverer Blick. Dafür halte ich nicht einen Korb von Glaskugeln vorrätig.
Nochmal die Frage, wie du den Schluckauf einzelner 0815-VMs erruieren kannst.
Schon beim Logfile lesen, aka Ereignisprotokoll im Windowsumfeld, drücke ich dir die Daumen und bedauere gleichzeitig die verplemperte Zeit.
Das soll dann standardisiert funktionieren? Mit soviel vermeintlicher "Überwachungs-SW" kannst du gar nicht schmeißen.
P.S.:
Ich kenne zwar viele IDS-Systeme, aber keines welche mir mal eben netzweit aufschlüsselt, wer denn nun Disk-iO auf einem PVE-Host verursacht. Oder gar auf Knopfdruck einen History-Verlauf anzeigt.

Nebenbei würde mir ein Übersichtsdiagramm seitens Proxmox sehr gefallen, in dem jede VM einzeln dargestellt wird. DAS hilft bei der Identifizierung "schlimmer" Finger.

 

[rprengel]

35 Jahre IT Support, da hat man seine Tools parat und man kann auch Windows-Logfiles in z.B. ELK zusammen ziehen um zentral zu suchen. Wenn an einmal die passenden Vorlagen für VMs und eine Handvoll Scripte parat hat ist das Routine. Wobei Linux-System in aller Regel deutlich geschmeidiger laufen und besser zu entstören sind. Bei einer 4stelligen Anzahl von VMs und Container sind Standards und definierte Verfahren Pflicht.

 

[TErxleben]

35 Jahre IT Support, da hat man seine Tools parat und man kann auch Windows-Logfiles in z.B. ELK zusammen ziehen um zentral zu suchen. Wenn an einmal die passenden Vorlagen für VMs und eine Handvoll Scripte parat hat ist das Routine. Wobei Linux-System in aller Regel deutlich geschmeidiger laufen und besser zu entstören sind. Bei einer 4stelligen Anzahl von VMs und Container sind Standards und definierte Verfahren Pflicht.

Bis zu 9.999 Vms ist doch ein ganz anderer Schuh. Da wird gerne Versprochen und bezahlt, dass dieses Vorgehen der letze Schrei sei. Ich kenne zwar Firmen, die ähnlich viele VMs haben, jedoch keine, bei denen proaktiv aufgrund von Metriken gehandelt wird. Da kann man die IT eher mit Druckern überraschen, die es deren Meinung gar nicht gibt. Eine amoklaufende VM wird einfach nur auf eine ältere Version zurückgesetzt.