gelöst: HP FC Problem Durchsatz ~12MBit

[irix]

Also ich kann mit dem gesagten von Dayworker so nicht ganz anschliessen. Ja, natuerlich hat VMware da Reibungsverluste aber ob die nun gefuehlte Faktor 5 sind da hab ich so meine Zweifel.

Ich hab hier auch Systeme wo mit 32 SATA Platten angefangen wurde. Aufgeteilt auf 2 Arrays und am Ende dann ca. 80 VMs. Beim kopieren von VMDKs war schon ein zweistelliger Wert abzulesen.

Bei Luegenbenchmarks mittels IOmeter und 32/64KB sequential Read konnte das Transfermedium durchaus ausgeschoepft werden (1Gb iSCSI).

Ergo... versuche ein Array frei zubekommen oder zumind. das wenig Last drauf ist. und Mache ein paar Benchmarks und dann gehen zum Support deiner Hersteller. Ich kenne HP Storages nun nicht so aber es muss doch Moeglichkeiten geben da ein paar Statistiken und Werte sich anzugucken.

Ja es ist richtig das VMware bestimmte Prozesse was das Kopieren/Migrationen limitiert. Ein Supporter meinte zu 3.5 Zeiten das man so 2-3GB pro Minute erreichen wuerde beim Clonen.

Gruss
Joerg

[mangold]

das kopieren von vmdks innerhalb von vmfs Volumes war doch schon immer langsam, ausschlaggebend für die Performance einer virtualisierungs Umgebung ist aber die Leistung bei Operationen innerhalb einer VM. Vielleicht sollte innerhalb einer VM gestestet werden, wie schnell da die Kopiervorgänge sind.

[stahly]

das kopieren von vmdks innerhalb von vmfs Volumes war doch schon immer langsam,...

Das ist aber - soweit ich weiß - so gewollt, da der laufende Betrieb der VMs nicht gestört werden soll.

Anders siehts bei Storage-vMotion aus. Da wird die VM mit ca. 250 MB/sek verschoben.

[mangold]

da hast du natürlich recht, eine Storage Migaration sollte deutlich schneller sein, und 12 Mbit sind so oder so viel zu wenig.

Wobei ich hier eine 8 jahre alte IBM DS4400 stehen habe, mit RAID 5 Arrays auf je 7 Spindeln und das lief jahre lang performant, bis zu 100 VMs auf 4 solcher Raids. Sind zwar FC Platten, kann mir irgendwie nicht vorstellen (rein gefühlt), dass aktuelle SATA Platten so viel schlechter sind, dass man von einem Designfehler sprechen kann. Da ist irgend etwas anderes im Argen...fragt sich nur was.

[Dayworker]

Also ich kann mit dem gesagten von Dayworker so nicht ganz anschliessen. Ja, natuerlich hat VMware da Reibungsverluste aber ob die nun gefuehlte Faktor 5 sind da hab ich so meine Zweifel.

Im Land der Desktopvirtualisierer wird ja eigentlich die strikte Trennung sprich separate Platten für OS und VMs empfohlen, die es beim schlanken ESXi aus den bekannten Gründen ja so nicht gibt. Dazu kommt, daß sämtliche Desktopvirtualisierer eh nur ~75%, anstatt der ~95% beim ESX(i), der verfügbaren Systemleistung in ihren VMs erreichen können. Daher fällt die Performance hier eh noch etwas weiter gegenüber vollwertigen Hypervisoren ab.

Ich hab hier leider nur Sata2-Platten ohne HW-Controller am Start, die zusätzlich neben den VMs auch noch vom Host-OS mitgenutzt werden und von daher eh schon mit einer gewissen Grundlast laufen. Ich denke aber mal, daß die verbaute Quad-CPU als kleinen Ausgleich in jedem Fall mehr Dampf hat, als ein HW-Controller der Wald-und-Wiesen-Fraktion. Zumal der CPU bei den Tests sämtliche Energiespareinstellungen vorenthalten wurden und auch der max.Multiplikator eingestellt war.

Leider habe ich keine eigenen Werte mit SSD oder einem richtigen Storage ermitteln können. Es wäre also gut möglich, daß meine Werte nur im Rahmen eines Apfel-Birne-Vergleichs übertragbar wären. Allerdings würde dann dazu die Reibungsverluste-Aussage nicht passen...

Wobei ich hier eine 8 jahre alte IBM DS4400 stehen habe, mit RAID 5 Arrays auf je 7 Spindeln und das lief jahre lang performant, bis zu 100 VMs auf 4 solcher Raids. Sind zwar FC Platten, kann mir irgendwie nicht vorstellen (rein gefühlt), dass aktuelle SATA Platten so viel schlechter sind, dass man von einem Designfehler sprechen kann. Da ist irgend etwas anderes im Argen...fragt sich nur was.

Doch, Sata-Platten sind so lahm.

Code: Alles auswählen

 7,200 rpm SATA drives   HDD   ~75-100 IOPS   SATA 3 Gb/s   
10,000 rpm SATA drives   HDD   ~125-150 IOPS   SATA 3 Gb/s   
10,000 rpm SAS drives   HDD   ~140 IOPS      SAS   
15,000 rpm SAS drives   HDD   ~175-210 IOPS   SAS

Die genannten Werte werden sehr anschaulich unter http://www.symantec.com/connect/articles/getting-hang-iops aufgedrösselt.
An dieser Auflistung ändert auch SATA mit 6Gb/s rein garnichts, da Sata2-Platten ihr Interface bisher höchstens aus dem Plattencache auslasten konnten und sich die prinzipiellen Drive-Eigenschaften bei gleichbleibender Drehzahl nur mit einem anderen Aufzeichnungsverfahren wesentlich ändern könnten.
Vollkommen anders sieht es dagegen bei SSDs aus. Der Link zu Wikipedia liefert dort auch einige Werte, die ein vielfaches von SAS-Platten erreichen.

[j.michaelis]

Da ist irgend etwas anderes im Argen...fragt sich nur was.

genau meine Meinung! Mir fällt halt nichts mehr ein...

[j.michaelis]

Nachbrenner: hab jetzt eine MSA komplett auf Raid10 geändert. Das Ergebnis gefühlt flotter...

Noch ne Frage an die Profis. Kann es an der Firmware des BrocadeSwitches (HP 8/8 SanSwitch) liegen? Diese ist sehr veraltet 6.0.2 vs 7.0.1, der Updateprozess jedoch nicht ganz trivial;-). Also hier vorab die Frage: lohnt sich ein Update oder kann ich den Switch als Quelle allen Übels ausschließen? Eure Erfahrungen würden mir bei der Entscheidung helfen.

[MarcelMertens]

Ausschließen naturlich nicht.
Wenn die Portstatistiken alles OK sind (dropped frames, error frames etc) würde ich die Warscheinlichkeit aber auf sehr gering schätzen

[stahly]

Nachbrenner: hab jetzt eine MSA komplett auf Raid10 geändert. Das Ergebnis gefühlt flotter...
....

Da ich für meinen neuen Veeam-Backup-Server ein Raid über 14 Platten planen muss, habe ich mich mit dem Thema Raid 5 vs. Raid 10 etwas näher beschäftigt:
Das Fazit bis jetzt ist, das das Raid 10 bei gleicher Anzahl von Spindeln nur unwesentlich schneller ist als das Raid 5.

Was heisst gefühlt? Hast Du Zahlen? Was macht die Latenz? Immer noch so hoch?

[e-e-e]

Da ich für meinen neuen Veeam-Backup-Server ein Raid über 14 Platten planen muss, habe ich mich mit dem Thema Raid 5 vs. Raid 10 etwas näher beschäftigt:
Das Fazit bis jetzt ist, das das Raid 10 bei gleicher Anzahl von Spindeln nur unwesentlich schneller ist als das Raid 5.

Was heisst gefühlt? Hast Du Zahlen? Was macht die Latenz? Immer noch so hoch?

Ich befürchte das wird nur auf deinen Backup-Server zutreffen, da der fast nur sequenzielle IOs ausführt.

[bla!zilla]

Da ich für meinen neuen Veeam-Backup-Server ein Raid über 14 Platten planen muss, habe ich mich mit dem Thema Raid 5 vs. Raid 10 etwas näher beschäftigt:
Das Fazit bis jetzt ist, das das Raid 10 bei gleicher Anzahl von Spindeln nur unwesentlich schneller ist als das Raid 5.

Was nachvollziehbar ist: Du hat beim Backup eher long Writes, wo also ganze Stripes geschrieben werden. Die Write Penalty schlägt nicht so zu.

[j.michaelis]

Wollt nur allen die es interessiert erzählen wie es weitergegangen ist.
Habe bei einem der beiden fieberswitch (brocade300 HP gelabelt) versucht das Firmwareupdate, zu machen mit dem Ergebnis, dass nun der Service ihn austauschen muss. Irgendwie war eine der beiden bootpartitionen defekt.
Mal schauen was der Wechsel bringt...

Zum Thema gefühlt schneller: das verschieben von vms berichtet der Switch 16mb/s also marginal höher. EsxTop meldet jetzt Über 300 Cmd/s zu vormals 100-150. Die User beschweren sich auch nicht mehr( was aber nicHts heißt )

Bei der Analyse des switches ist mir noch was aufgefallen in den errorlogs ist ein extrem hoher Wert bei invalid transmitted word >5e6 aufgefallen.

[irix]

Was zeigt denn ein porterrshow auf dem Brocade? Im Normalfall sind Transmitted Word count aber Hardwarefehler was die SFP und Verkabelung mit einschliessen.

Gruss
Joerg

[MarcelMertens]

Der Invalid transmitted words ist absolut. Am besten mal resetten und schauen was z.b. nach 24h der wert ist. Brocade gibt folgendes als Maximum an:

Recommended high port fencing thresholds
High threshold (per minute) E_Ports = 40
High threshold (per minute) Storage FOP_Ports = 80
High threshold (per minute) Host FOP_Ports = 1000

[mangold]

bei einem der beiden fieberswitch (brocade300 HP gelabelt)

jetzt wo du die FC Switche erwähnst, bei meinem ersten SAN hatte das ein Dienstleister dieses und die Switche eingerichtet. Leider dabei vergessen das Zoning zu aktivieren und zu konfigurieren. So lange nur der Storage und 3 Server dran waren ging das alles ok, als dann der vierte ESX Server dazu kam (1,5 Jahre später), ging die Performance so in den Keller, bis zum Komplettstillstand der VMs. Ursache war eben das nicht-vorhandene Zoning. Nach dem Einrichten lief alles wie es sollte. Ich denke aber natürlich nicht, dass euer Zoning nicht eingerichtet ist

[j.michaelis]

Der Invalid transmitted words ist absolut. Am besten mal resetten und schauen was z.b. nach 24h der wert ist.

Hallo der FCSwitch-Tausch ist durch, das FabricOS jetzt 7.0.1, die Counter resettet und..
Invalid Transmitted Words = 0 nach 12h.
Der Durchsatz hat sich auf 35-50MB/s erhöht und ich bin zufrieden;-)
Also lags doch an der Fw der Switche..

Die Zahlen zu cmds/s liefere ich natürlich nach.
Die HyperV Fraktion (mein Kollegen) hab ich nun auch wieder im Griff

Mein Servicetechniker hatte übrigens auch keine Fehler in Konfig und Setting gefunden.
@mangold Danke für den Tip. Das Zoning ist eingestellt und aktiviert (single HBA centric Zoning).
Danke nochmals allen für die Mithilfe und Ideen.

[j.michaelis]

hier der versprochen Snapshot http://db.tt/XPSNQVUT
man beachte die GAVG/cmd