Hallo zusammen,
ich würde gerne die Performance einer HP EVA3000 bewerten.
Aktuell gibt es hier einige Probleme (Outlook ruft oft Daten vom Server ab / ist schlecht zu bedienen, Programmstarts unter Citrix langsam, Öffnen von Dateien sehr langsam, etc. pp) und wir vermuten, dass die EVA zu ausgelastet ist - auf der quasi alle wichtigen Systeme liegen.
Die EVA hat 2 DiskGroups - eine mit 300GB HDDs (14 Stck), eine mit 146GB HDDs (42 Stck) - allesamt FibreChannel Disks mit 10k. Zusätzlich gibt es noch eine EVA5000 mit 168x 146GB FC-HDDs (lediglich für Backups...).
Die PhysicalDiskGroups haben folgende durschschnittlichen Latenzen: (ermittelt mit EVA PerfMon über ~24 Stunden an einem normalen Arbeitstag)
-300GB DiskGroup: Read Latency 8,8ms // Write Latency 11,8ms
-146GB DiskGroup: Read Latency 14,5ms // Write Latency 21,4ms
(-EVA5000: Read Latency 4,1ms // Write Latency 29,5ms)
Peaks:
-300GB DiskGroup: Read 132ms // Write 148ms
-146GB DiskGroup: Read 232ms // Write 246ms
(-EVA5000: Read 59ms // Write 66ms )
Genutzt werden fast ausschließlich vRaid5, keinerlei "Enterprise Funktionen" (SnapShots, Mirrors, etc), die Controller sind bei Peaks max. 41% ausgelastet, im Durchschnitt unter 5%.
Nun die Frage: Sind solche Werte normal oder gibt´s Grund zur Sorge?
Und generell würde ich gerne wissen, wie man Storage-Systeme sinnvoll bewerten kann, um Engpässe im Backend zu identifizieren. Gibt es hier irgendwelche Guides/Richtlinien/Tools?
Danke & Gruß
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Performance von HP EVA beurteilen
Re: Performance von HP EVA beurteilen
Hallo,
Die Werte sind okay. Die Write-Latency wird wegen vRAID 5 kommen. Müsste man aber mal im Detail schauen.
Gut, das sind Peaks, aber trotzdem spooky...
Welches VCS habt ihr im Einsatz? Wieviele Shelfs pro EVA? Welche Version von VMware ESX? Wie groß sind eure VMFS Dateisysteme? Wieviele Gäste pro VMFS?
nbfbe hat geschrieben: -300GB DiskGroup: Read Latency 8,8ms // Write Latency 11,8ms
-146GB DiskGroup: Read Latency 14,5ms // Write Latency 21,4ms
(-EVA5000: Read Latency 4,1ms // Write Latency 29,5ms)
Die Werte sind okay. Die Write-Latency wird wegen vRAID 5 kommen. Müsste man aber mal im Detail schauen.
nbfbe hat geschrieben:Peaks:
-300GB DiskGroup: Read 132ms // Write 148ms
-146GB DiskGroup: Read 232ms // Write 246ms
(-EVA5000: Read 59ms // Write 66ms )
Gut, das sind Peaks, aber trotzdem spooky...
Welches VCS habt ihr im Einsatz? Wieviele Shelfs pro EVA? Welche Version von VMware ESX? Wie groß sind eure VMFS Dateisysteme? Wieviele Gäste pro VMFS?
Hallo,
die EVA3000 hat 4 Shelfs (3x mit 146GB HDDs, 1x mit 300GB) - VCS 4100. Diese merklichen Peaks waren überigens nur zu einer bestimmten Uhrzeit mit ein paar Ausnahmen drin. Die "normalen Peaks" gingen bis ca. 30ms im read.
Aktuell haben wir 4 ESX-Hosts in einem DRS/HA Cluster unter 3.5 U5 und 2 ESXi (nicht lizensiert, auch an EVA).
Es gibt 7 VMFS mit je 500GB und 2 mit 2TB.
-Auf den beiden 2TB VMFS liegt je nur 1 Server (u.A. Fileserver)
-Auf 2 der 500GB LUNs liegt auch je nur 1 Server
-Auf den anderen 5 500GB LUNs liegen je ~ 8-15 VMs
Mein Gefühl sagt mir, dass das Storage zu langsam ist - Perfmon sagt was anderes!?
Gruß
die EVA3000 hat 4 Shelfs (3x mit 146GB HDDs, 1x mit 300GB) - VCS 4100. Diese merklichen Peaks waren überigens nur zu einer bestimmten Uhrzeit mit ein paar Ausnahmen drin. Die "normalen Peaks" gingen bis ca. 30ms im read.
Aktuell haben wir 4 ESX-Hosts in einem DRS/HA Cluster unter 3.5 U5 und 2 ESXi (nicht lizensiert, auch an EVA).
Es gibt 7 VMFS mit je 500GB und 2 mit 2TB.
-Auf den beiden 2TB VMFS liegt je nur 1 Server (u.A. Fileserver)
-Auf 2 der 500GB LUNs liegt auch je nur 1 Server
-Auf den anderen 5 500GB LUNs liegen je ~ 8-15 VMs
Mein Gefühl sagt mir, dass das Storage zu langsam ist - Perfmon sagt was anderes!?
Gruß
Schwer zu beurteilen. Ihr könnte die Pfade kontrollieren und schauen, ob nicht evtl. die Vdisks über den "falschen" Controller angesprochen werden. In dem Fall nimmt der Controller zwar den IO an, schickt den aber über den Mirrorport zum owning Controller. Welcher Controller welche Vdisks in Besitzt hat, sieht man im Command View EVA.
Hallo,
der IO geht derzeit komplett über einen Controller - und die ESX-Server nutzen auch den richtigen Pfad...gerade nochmal kontrolliert. Ich könnte nun sicherlich noch das Ganze auf 2 Controller aufsplitten, aber ob´s das bringt!?
Ich habe nun mal noch Kontakt zu einem HP Händler aufgenommen, der wohl auch 2 Techniker hat, die die Umgebung entsprechend bewerten können - ich hoffe das dies etwas bringt.
Gruß
der IO geht derzeit komplett über einen Controller - und die ESX-Server nutzen auch den richtigen Pfad...gerade nochmal kontrolliert. Ich könnte nun sicherlich noch das Ganze auf 2 Controller aufsplitten, aber ob´s das bringt!?
Ich habe nun mal noch Kontakt zu einem HP Händler aufgenommen, der wohl auch 2 Techniker hat, die die Umgebung entsprechend bewerten können - ich hoffe das dies etwas bringt.
Gruß
Wie viele I/O´s macht das System denn im Schnitt und bei Peaks? Du kannst Dir die maximale I/O Leistung Deines Systems ja ausrechnen und mal mit dem was drüber läuft vergleichen.
Wie viele I/O´s hast Du errechnet was Dein System schafft? Und wie viel geht drüber?
Ich persönlich bin Anhänger der Theorie einer verschränkten Fragmentierung von länger laufenden Storage Systemen. Sprich Dein NTFS (und insbesondere die MFT) in Deinen Gästen fragmentiert und das Filesystem des Storages fragmentiert ebenso. VMFS kann man wegen der großen Blockgröße wohl ignorieren. Dadurch entsteht eine verschränkte Fragmentierung.
Somit steigt im Laufe der Zeit wohl die nötige Anzahl an I/O´s für die geforderten Transferraten. Das übersteigt wiederum irgendwann die I/O Leistung was Deine Spindeln schaffen und dann wird es nach und nach eben langsam bzw. sicher nicht schneller oder gleich. Es gibt Leute die Behaupten das spiele alles keine Rolle in einem SAN aber wie gesagt ich persönlich bin nicht dieser Meinung.
Es spielt dann keine Rolle, welche Blöcke eine VM anfordert bei einer beliebigen Fragmentierung, wenn die Zugriffszeit quasi 0 ist, und das ist derzeit nur bei SSD´s der Fall.
Wie viele I/O´s hast Du errechnet was Dein System schafft? Und wie viel geht drüber?
Ich persönlich bin Anhänger der Theorie einer verschränkten Fragmentierung von länger laufenden Storage Systemen. Sprich Dein NTFS (und insbesondere die MFT) in Deinen Gästen fragmentiert und das Filesystem des Storages fragmentiert ebenso. VMFS kann man wegen der großen Blockgröße wohl ignorieren. Dadurch entsteht eine verschränkte Fragmentierung.
Somit steigt im Laufe der Zeit wohl die nötige Anzahl an I/O´s für die geforderten Transferraten. Das übersteigt wiederum irgendwann die I/O Leistung was Deine Spindeln schaffen und dann wird es nach und nach eben langsam bzw. sicher nicht schneller oder gleich. Es gibt Leute die Behaupten das spiele alles keine Rolle in einem SAN aber wie gesagt ich persönlich bin nicht dieser Meinung.
Es spielt dann keine Rolle, welche Blöcke eine VM anfordert bei einer beliebigen Fragmentierung, wenn die Zugriffszeit quasi 0 ist, und das ist derzeit nur bei SSD´s der Fall.
Hallo,
zum Thema IOPS:
Sehe ich es richtig, dass "IOPS per disc * Anzahl der Disk = max. IOPS / DiskGroup" bedeutet?
Weiter: Wenn ich mit dem PerfMon die Werte "Read Req/s" und "Write Req/s" auslese, diese zusammenrechne (Peak und Durchschnitt) und diese von der "max. IOPS / DiskGroup" abziehe, ich die Reserven bzw. auch die "zuwenigen" IOPS habe?
Demnach wäre die eine DiskGroup, auch während der Peaks, im grünen Bereich - die andere DiskGroup hingegen hat eindeutig zu wenig IOPS.
Gruß
zum Thema IOPS:
Sehe ich es richtig, dass "IOPS per disc * Anzahl der Disk = max. IOPS / DiskGroup" bedeutet?
Weiter: Wenn ich mit dem PerfMon die Werte "Read Req/s" und "Write Req/s" auslese, diese zusammenrechne (Peak und Durchschnitt) und diese von der "max. IOPS / DiskGroup" abziehe, ich die Reserven bzw. auch die "zuwenigen" IOPS habe?
Demnach wäre die eine DiskGroup, auch während der Peaks, im grünen Bereich - die andere DiskGroup hingegen hat eindeutig zu wenig IOPS.
Gruß
IOPS und I/O´s sind nicht dasselbe. 
Aber die Rechnung Anzahl Disken (in der Raidgroup) mal deren jeweiligen I/O Leistung (abhängig von der Drehzahl, sollten natürlich alle dieselbe haben.) abzüglich Raid bzw. Parity Verluste ergibt aus meiner Sicht die maximale I/O Leistung einer Raidgroup.
Deine Rechnung klingt plausibel, bin aber nicht 100%tig sicher ob die PerfMon Werte mit I/O´s gleichzusetzen sind. Diese kann man sicher aber z.B. mit ESXTOP anzeigen lassen. Gut bei vielen ESXen macht das nicht mehr viel Sinn aber ggf. bringt es ja bei VM´s welche im Verdacht stehen Lastschweine zu sein was.
Möglicherweise verschiebst du einige Systeme aus den überlasteten Raidgroups in eine mit weniger Last. Es sollten auch nicht zu viele VM´s in einem VMFS Volume laufen… Vielleicht solltest du manche Raidgroups neu machen. Auch hier könnte es ja sein das welche zu wenig Spindeln haben aber zu viele VM´s bedienen müssen.
Das Thema ist sehr komplex und ich bin da auch kein Profi, aber erzähl mal wie es weitergeht.
Aber die Rechnung Anzahl Disken (in der Raidgroup) mal deren jeweiligen I/O Leistung (abhängig von der Drehzahl, sollten natürlich alle dieselbe haben.) abzüglich Raid bzw. Parity Verluste ergibt aus meiner Sicht die maximale I/O Leistung einer Raidgroup.
Deine Rechnung klingt plausibel, bin aber nicht 100%tig sicher ob die PerfMon Werte mit I/O´s gleichzusetzen sind. Diese kann man sicher aber z.B. mit ESXTOP anzeigen lassen. Gut bei vielen ESXen macht das nicht mehr viel Sinn aber ggf. bringt es ja bei VM´s welche im Verdacht stehen Lastschweine zu sein was.
Möglicherweise verschiebst du einige Systeme aus den überlasteten Raidgroups in eine mit weniger Last. Es sollten auch nicht zu viele VM´s in einem VMFS Volume laufen… Vielleicht solltest du manche Raidgroups neu machen. Auch hier könnte es ja sein das welche zu wenig Spindeln haben aber zu viele VM´s bedienen müssen.
Das Thema ist sehr komplex und ich bin da auch kein Profi, aber erzähl mal wie es weitergeht.
Erstmal hat die EVA keine RAID-Groups und ist auch vom logischen Aufbau nicht mit einer CLARiiON, Symmetrix oder einem Filer von NetApp zu vergleichen. In jedem Fall ist das, was EVAperf ausgibt das, was das System wirklich treibt.
Um deine Performanceprobleme wirklich bewerten zu können, muss man Tests machen. Sowas lässt sich per Forum schlecht klären.
Um deine Performanceprobleme wirklich bewerten zu können, muss man Tests machen. Sowas lässt sich per Forum schlecht klären.
Na dann eben DiskGroups. Ich denke eine NetApp Raidgroup und eine HP Diskgroup ist in etwa das Gleiche (wenn nicht behaupte ich das Gegenteil und lasse mich gerne belehren *g*).
In einer solchen liegen nun mal LUNs welche performancetechnisch durch das Design einer Disk/Raidgroup limitiert werden.
Aber stimmt schon, ein komplexes Thema für ein Forum. Dennoch kann man Anregungen und Erfahrungen etc. austauschen welche hier und da einen vielleicht auch ein wenig was bringen.
In einer solchen liegen nun mal LUNs welche performancetechnisch durch das Design einer Disk/Raidgroup limitiert werden.
Aber stimmt schon, ein komplexes Thema für ein Forum. Dennoch kann man Anregungen und Erfahrungen etc. austauschen welche hier und da einen vielleicht auch ein wenig was bringen.
eini hat geschrieben:Na dann eben DiskGroups. Ich denke eine NetApp Raidgroup und eine HP Diskgroup ist in etwa das Gleiche (wenn nicht behaupte ich das Gegenteil und lasse mich gerne belehren *g*)
Na für den Vergleich würdest du von HP und NetApp Mitarbeitern weltweit auf die "Dead or Alive" Liste kommen.
Setze dich bitte mal mit den Systemen auseinander, bevor du so einen Vergleich bringst. Das Konzept von RAID Groups/ Plexen/ Aggregaten/ Volumes/ LUNs und von Diskgroups und Vdisks ist grundsätzlich total unterschiedlich.Wie gesagt, ich lasse mich gerne belehren. Wo sind denn die großen Unterschiede das ich gleich weltweit gejagt werde? Erklärs mir damit ich nicht dumm sterbe, habe leider keine EVA hier und bin offensichtlich nicht so tief im Thema drin wie du.
Ich meine eben das eine Anzahl X Platten zunächst eine Diskgroup bildet oder? Das tut eine Raidgroup eben auch, gut hier wird das Raidlevel gleich festgelegt (Raid DP etc.) Bei einer Diskgroup gibt es wohl noch besagte Vdisks welche ein Raidlevel festlegen.
Will aber hier nicht offtopic werden es geht aber im Kern darum wieviel I/O´s seine Diskgroup leisten kann welche ich fälschlicherweise als Raidgroup bezeichnet habe aber eine Diskgroup meinte.
Ich meine eben das eine Anzahl X Platten zunächst eine Diskgroup bildet oder? Das tut eine Raidgroup eben auch, gut hier wird das Raidlevel gleich festgelegt (Raid DP etc.) Bei einer Diskgroup gibt es wohl noch besagte Vdisks welche ein Raidlevel festlegen.
Will aber hier nicht offtopic werden es geht aber im Kern darum wieviel I/O´s seine Diskgroup leisten kann welche ich fälschlicherweise als Raidgroup bezeichnet habe aber eine Diskgroup meinte.
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 9 Gäste