VMware-Forum

Hallo,

kann mir jemand sagen wie ich mir die aktuellen IOPS für meinen ESXi Host anzeigen lassen kann?

Ich habe mir unter Leistung -> Diagrammoptionen -> Datenspeicher die durchschnittlichen Lese und Schreibanforderungen anzeigen lassen.
Sind das die IOPS?

Hier komme ich auf Spitzenwerte von ca 400 - 500.

Danke

Ja das sollten sie sein. Im engl
- Read requests
- Write requests
- Command issued sollten dann die kumulierten sein

Kannst du abgleichen mit esxtop und dort "CMDs". Die VM hier macht 14051 IOPs und im Durchschnitt 4624.

Gruss
Joerg

@irix:

Siehst Du dort die IOs pro Host? Ich sehe die nur pro LUN...
Oder wird es Zeit für den wohlverdienten Feierabend

Oehmm.. Aeh..... wer wird denn gleich so kleinlich sein


Aber wenn ich auf den Host anstelle einer VM gehe sind es die gleichen Counter. Dumm nur das ich nur Metriks fuer die LUNs aber nicht den ganzen Host bekomme. Somit muss man die Werte manuell zusammen zaehlen.

Mein vCOPS will irgendwie das auch nicht so rausruecken wie gewuenscht *Grummel*.

Gruss
Joerg

irix hat geschrieben:Oehmm.. Aeh..... wer wird denn gleich so kleinlich sein
...

Es sei Dir verziehen

Mal zu Veeam ONE rübergeschwenkt und siehe da: Er kanns! Habe ich aber noch nie nach gesucht
Max: 16.480 / Average: 2257 / Min: 695

Die Frage ist nur, wie "gemittelt" sind die Werte? Wenn ich mich recht erinnere sollte das ein Durchschnittswert von 30 Sekunden sein.

@Supermario:

Was hast Du denn vor?

ich will unser neues Storage in Betrieb nehmen und kann mich nicht entscheiden zwischen
Raid 10 oder Raid 6

Grüße

Erstelle dir doch einfach ein neues VMFS ... leg ne VM rein und Teste die IOPS mit IO-Meter ... das gleiche dann nochmal für das andere Raidlevel. Wirst aber die besten IO-Werte mit Raid10 erhalten.

Das Raid 10 mehr IO's produziert ist klar.
Ich hätte aber lieber den Platz als die Performance, die wir (wahrscheinlich) nicht brauchen.

Hallo,

wie sind denn die Anforderungen, denn RAID 1 wird üblicherweise nicht mit RAID 6 verglichen.

Gruß,
Ralf

Wie vorgeschlagen eine VM mit IOmeter als Lastgenerator und dann im ESX mit esxtop und vscsiStats kontrollieren. Ein esxtop kann auch aufzeichen und irgendwo gibt es auch ein ESXplot als grafischen Frontend.

Ich erinnere mich an eine Lastgenerator VA von Fling
http://labs.vmware.com/flings/io-analyzer

Gruss
Joerg

@kastlr
Also wir haben
1x SBS mit Exchange
1x SQL Server
2x Terminalserver a 20 User

Wie Eingangs schon beschrieben, habe ich unter Leistung -> Diagrammoptionen -> Datenspeicher die durchschnittlichen Lese und Schreibanforderungen eingestellt.
Dort werden mir 400-500 angezeigt.

Wenn ich einen IO Rechner bemühe komme ich mit Raid 6 auf ca. 1200 und mit Raid 10 auf 2800 IO's.

Wenn ich im Endeffekt nur 1000 IO's brauche wären mit Raid 10 gute 4 TB verschenkt.

Raid 10 -> 4 TB
Raid 6 -> 9TB

Ich werde die Links mal durcharbeiten. Sind ja schöne Tools dabei

Grüße

irix hat geschrieben:
Mein vCOPS will irgendwie das auch nicht so rausruecken wie gewuenscht *Grummel*.

Hi Jörg,
im vC Ops kann man sich aber eig. die IOPS in allen möglichen Varrianten anzeigen lassen (Pro Host, pro VM, pro Cluster, pro Datastore etc.).

OT: Sieht man sich nächste Woche auf der VMUG ?

Gruß Mario

Super Mario hat geschrieben:Raid 10 -> 4 TB
Raid 6 -> 9TB

Vergleich auch mal die Rebuild-Zeiten, falls ne Platte ausfällt (Wie viele dürfen denn ausfallen?). Ein riesiger Raid 6 Verbund braucht schon ganz schön lange. Und in der Zeit können die IOs, die den VMs zur Verfügung stehen, ganz schön in den Keller gehen.

vMario156 hat geschrieben:

irix hat geschrieben:
Mein vCOPS will irgendwie das auch nicht so rausruecken wie gewuenscht *Grummel*.

Hi Jörg,
im vC Ops kann man sich aber eig. die IOPS in allen möglichen Varrianten anzeigen lassen (Pro Host, pro VM, pro Cluster, pro Datastore etc.).

Bin ich ja auch der Meinung. Aber es ist wohl gut versteckt oder so offensichtlich das ich es uebersehen habe.

OT: Sieht man sich nächste Woche auf der VMUG ?

Ich glaube nicht. Ich bin Froh wenn mir morgens einfaellt in welcher Stadt ich gerade bin. Aktuelle schoene Gruesse aus Poing!

Ameldeschluss war schon oder?

Edit: Gerade angemeldet. ICH BIN DABEI

Gruss
Joerg

Hallo,

die nackte IO Anzahl hält sich ja im Rahmen, für den Storage sollte das aber fast auschließlich als Random IO Workload ankommen.
Und da Ihr auch SQL Server einsetzt, kann die IO Size auch 64kB groß sein.
Daher solltest du das bei der Berechnung berücksichtigen.

Man sieht sich auf der VMUG.
Ralf

Also der IO-Meter ist für mich eher ein Tool um zu testen wie gut meine Netzwerk- (iSCSI, FCoE) oder FC-Anbindung ist.
Hat man ne Storage mit nem ordentlichem Cache davor stimmen die IOMeter Werte hinten und vorne nicht mehr.
Unser Storage zB. ist insgesamt auf 50.000 IOPS gesized. ca. 1/3 dessen ist reserviert für VMWare. Und trotzdem schaffe ichs problemlos aus ner einzelnen VM per IOMeter jenseits der 100K IOPS rauszuzaubern. Das coole daran ist ja dann noch, dass von den 100K IOPS keine 2000 beim Diskbackend ankommen. Das macht bei mir vielleicht 10% zusätzliche Last auf den Disken.

Für die SAN- u. Storageport-Überwachung verwenden wir eigene FC-Hardwareprobes von Virtual Instruments. Wie ich finde das einzig wirklich aussagekräftige. Da die mit ihren Hardware Taps wie ein Sniffer jede Transaction zwischen Storage und Hosts analysieren und auswerten.

Na ja,

IOMeter ist tatsächlich nur bedingt geeignet die Performance eines Storages zu analysieren.
Das liegt aber eher daran, das die generische Last von IOMeter überhaupt gar nichts mit dem Lastverhalten einer produktiven Umgebung zu tun hat.

Aber ich kann mit IOMeter jeden Array Cache innerhalb kürzester Zeit aus dem Spiel nehmen, indem ich das Testdevice groß genug wähle.
Bei einem 100% Random Read Test auf einer 2 TB LUN mit genügend outstanding IO und einer vernünftigen IO Size ist der Cache innerhalb von Sekunden aus dem Spiel.
Nur tritt so ein Anwendungsverhalten in der produktiven Welt halt nie auf.

Im übrigen glaube ich nicht, das jemand mit einem Array um 10TB Größe in die von dir genannten FC-Hardwareprobes investieren möchte.
Zumal es einem Array ziemlich egal ist, ob der "Test" IO von so einer Probe oder von einem IOMeter Server kommt.


Gruß,
Ralf

kastlr hat geschrieben:...
Aber ich kann mit IOMeter jeden Array Cache innerhalb kürzester Zeit aus dem Spiel nehmen, indem ich das Testdevice groß genug wähle.
Bei einem 100% Random Read Test auf einer 2 TB LUN mit genügend outstanding IO und einer vernünftigen IO Size ist der Cache innerhalb von Sekunden aus dem Spiel.
...

Hast Du ne Beipspielconfig für so einen Fall?

@kastlr

du hast recht. Die HW-Probe Lösung ist natürlich die Enterpriselösung. Wobei ich damit nicht meine, dass ich Last durch die Probe erzeugen lassen. Die Probe ist passiv und und erzeugt rein gar nichts. Sie dient nur dem Monitoring aller Storageports und tut außer mitlauschen gar nichts. Diese Probes sind auch immer aktiv und laufen nicht nur zu Debuggingzwecken.

Ein Virtual Wisdom Server zeichnet alle Statistiken auf, korreliert sie und macht daraus schöne Graphen. Zusätzlich kann auch der vCenter SDK als SW-Probe abgegriffen werden. Diese Daten werden mit denen der HW-Probes ebenfalls korreliert und sind somit schön auf einer schiebbaren Timeline abrufbar.

Was ich damit eigentlich sagen wollte: Man sollte nicht allzuviel auf Benchmarks geben. Die "IOPS" Werte sind niemals repräsentativ. Wichtiger ist eher wie gut das Ganze skaliert wenn mehrere dicke Anforderungen gleichzeitig kommen
-> wie schnell gehen die Transaction Latenzen hoch
-> wie schnell/hoch füllt sich die Storageadapterqueue (Sollte bei einem reinen esxi-Betrieb dank SIOC nicht mehr das Thema sein)

Am schnellsten gehen schwachbrüstige Storagesystem in die Knie wenn Storagevmotions durchgeführt werden, noch schlimmer wenn vmware meint gleich mehrere gleichzeitig amselben Storage anzustarten

Hängt natürlich immer von dem zu testendem Array ab, aber mit folgenden Werten sollte ein Cache schnell aus dem Spiel sein.

1. LUN deutlich größer als verfügbarer Array Cache
2. 100% Random Read
3. 32 - 64kB IO Size
4. 32 - 64 outstanding IO's

Wenn sich die Daten nicht im Cache befinden, muß das Array sie von den Platten holen (Read Miss).
In der Hoffnung, das diese Daten noch einmal benötigt werden, legt das Array diese im Cache ab.
Wenn die Test LUN zu klein ist, kann es passieren, das Teile deiner Random Read Abfragen sich noch im Array Cache befindet und dann werden diese Anfragen nicht von den Disks beantwortet. (Read Hit)
Durch eine große LUN und den Random Pattern stellst du sicher, das die Daten im Cache ständig veraltet sind, da Sie nicht nochmal angefordert werden.

Writes gehen bei den meisten Arrays direkt in den Cache, daher ist das weniger aussagekräftig.
Zwar müssen die Daten auch mal auf die Platte geschrieben werden, allerdings kann da das Array die Reichenfolge optimieren, denn der Host hat sein ACK bereits erhalten.

Aber das alles erklärt auch, warum IOMeter Tests in den allermeisten Fällen nur zu einem gut sind.
Damit kann man in einem POC unterschiedliche Syteme mit vergleichbaren Parametern testen und die gewonnenen Ergebnisse vergleichen.

Über die Aussagekraft der Ergebnisse im Hinblick auf eine Produktionsumgebung habe ich mich ja schon ausgelassen.

Hier nen Spruch aus meiner Lehrzeit (Generation Golf), der ist auch heute noch aktuell.
Wer viel misst, misst Mist.

Gruß,
Ralf

kastlr hat geschrieben:Hier nen Spruch aus meiner Lehrzeit (Generation Golf), der ist auch heute noch aktuell.
Wer viel misst, misst Mist.

Dazu hast du meine vollste Zustimmung

Denn auch das aushebeln aller Cachemechanismen ist eigentlich am Ziel vorbeigeschossen. Denn bei welchem echten System hast du das schon wirklich. (Hoffentlich bei keinem)
Auf unsere DS-LUNs haben wir im Schnitt eine Read-Hit Ratio von 50-85% und das ist auch gut so.

@Topic:Das vCenter alleine gibt wohl leider wirklich nicht her, wieviele IOPS alle LUNs gemeinsam verursachen

Bei vCOPs muss ich mal schauen wie das geht.
BTW: ist euch eigentlich auch schon aufgefallen, dass die Filtermöglichkeiten im vCOPs echt ziemlich blöd zu konfigurieren sind? Vielleicht bin ich auch nur zu blöd dazu

Eigentlich sollte man sein Array immer so dimensionieren, das es die Last auch ohne Cache bedienen kann.
Denn nur dann bin ich auf der sicheren Seite.

Aber da die Welt ja von Kaufleuten regiert wird bleibt das mal wieder ein frommer Wunsch.
Wenn Ingenieure so arbeiten würden, dann wäre der Weg zur Arbeit wieder richtig spannend.

• Trägt die Brücke wirklich?
• Wenn ich Grün habe, haben die anderen dann auch Rot?
• Wenn ich am Anfang des Quartals auf die Bremse drücke, wird mein Wunsch dann auch erhört?

Lässt sich beliebig fortsetzen, solange die Zahlen stimmen.


Gruß,
Ralf

kastlr hat geschrieben:Eigentlich sollte man sein Array immer so dimensionieren, das es die Last auch ohne Cache bedienen kann.
Denn nur dann bin ich auf der sicheren Seite.

Auch da geb ich dir grundsätzlich recht. Nur leider ist das bei größeren Systemen mit normalen Disken kaum noch zu realisieren. Grade unser Usage-Profil ist da extrem schwierig. Wir haben am Storage fast nur große Oracle DBs u. VMWare + ein paar TB Fileservices. Das macht ein Netto Datenvolumen von vielleicht 150TB (also praktisch nix). Dafür haben wir aber ein IO-Grundrauschen von über 20.000. Von Spitzen will ich gar nicht reden. Wie will man das mit reinen Disken realisieren wenn man von ca. 200 IOPS / Spindel im Optimalfall ausgeht. Das ginge nur mit SSDs und die sind in unserem Enterprise-Segment schlichtweg nicht leistbar. Kostet die jetztige Storagelösung schon im mittleren 7-stelligen Bereich

@blue_focus:

Die VSP kann doch Tiering. (glaube ich...) Macht es nicht Sinn, ein paar SSDs zu verbauen?

Wir haben seit ein paar Wochen ein Flash-System zwischen SVC und Plattenturm gebaut: Es ist der Hammer! Unser jetziges ERP-System ist bei nächtlichen Batches um viele Stunden schneller geworden. Sogar das Arbeiten am ERP-Client ist spürbar besser geworden. ...
Wir haben den Einbau des Flashs im laufenden Betrieb gemacht, ohne die anderen Admins darauf hinzuweisen. Die kamen dann von alleine auf mich zu und haben gefragt: "Habt ihr was umgestellt? Ist alles viel schneller geworden". Schönes Feedback

Und ohne Cache-Mechanismen wirds wirklich schwierig - da stimme ich Dir zu.

Bei uns sieht so aus:
4 SVC-Knoten: Durchschnitt. ca. 20.000 bis 30.000 IOs
2 Flashsysteme: Durchschnitt ca. 3.000 bis 10.000 IOs (Spitzen bis zu 2x 40.000 IOs)
2 gespiegelte Plattentürme: Durchschnitt 1.000 bis 5.000 je Turm

...und SAP kommt noch!!! Was der eigentliche Grund für das Flash war.

Ja da hast du recht. Tiering funktioniert grundsätzlich. Aber das ist bei uns eher in die lowend Richtung im Einsatz.

Wir haben das jetzige System Anfang des Jahres bekommen. Bislang hatten wir zum Glück noch nicht ansatzweise irgendwelche Performance Impacts.

Wir hatten vorher mehrere Net-App Metrocluster die wir damit abgelöst hatten. Mit denen hatten was die Performance betrifft nur Probleme trotz PAM-Maximalausbau und jehnseits der 500 Spindeln pro Clusternode.

SSDs als Tier1 wäre natürlich super. Aber wir haben stattdessen 180GB RAM-Cache pro VSP.

Insgesamt haben wir 3 VSPs im Einsatz mit nahezu identer Ausstattung. Jede ca. auf 50.000 IOPs gesized.

2x Prod -> in 2 Brandabschnitte aufgeteilt. Untereinander HA-geclusterd mit einhergehendem Sync-Mirror.

1x QA/Test: auf einem 3. Standort. mit Asynchr. Mirror von Prod-System.


Als Tier2 haben wir eine Hand voll HDS HUS-System Im Einsatz.

Mal schauen wie es in 3 Jahren bei der nächsten Storageausschreibung aussieht. Wir werden sehen, ob SSDs dann schon erschwinglicher werden.

Achja: SAP haben wir auch, zusätzlich Lotus Dominio Server für rund 7000-8000 User. Oracle DBs noch und nöcher auf AIX. Und eben unsere VMWare die auch ein großer Storageabnehmer ist.

Speicherplatz ist bei uns eben überschaubar. aber die Random-IO Last ist enorm

SVC war jetzt die IBM-Lösung oder? Ich glaube die wurden bei uns auch mit SVC und XIV vorstellig. Das System hat meinen Storagekollegen damals auch recht gut gefallen.