Sep 29, 2024, updated at 10:27:06 (UTC)

4163

VMware ESXi 8 neue Server langsamer als alter Server

Hi,
ich hoffe ihr könnt mir helfen.
Komme einfach nicht weiter mit meinem Problem

Wir haben 4 neue Server für unsere VM Landschaft.
Diese sind (mit Absicht) mehr als ausreichend dimensioniert.

Neue Server: (x4)
Lenovo Thinksystem SR 650 V3
CPU: 2x Intel Xeon Platinum 8462y+
Ram: 2TB
SSD: 8x Samsung PM1743 4TB
25gbit SFP+
Die 4 Maschinen arbeiten als VSAN Cluster in einer ESXI 8 Umgebung

alter Server
Huawei 2288h v5
CPU: 2x Intel Xeon Gold 6134
Ram: 1,5TB
SSD: 12x2TB SAS SSD in Raid 10

Jetzt zu meinem Problem:
Wir haben ein eher Nischen ERP System (Drink.Pro von Copasysteme) im Einsatz und dieses läuft deutlich schlechter auf den neuen Servern. Das Öffnen der Auftragsbearbeitung z.B. dauert auf den neuen Servern in der VM 30s teils 40s, auf dem alten Server in einer identisch konfigurierten VM sind es hingegen 15s - auf physischen Clients 10-12s

Dazu habe ich zwei identische Test VMs aufgesetzt und verglichen.
Die Konfiguration dabei war folgende:
1/2/4/8 Kerne - alle das gleiche Ergebnis ~30s neue Umgebung ~15s alter Server
8GB Ram
100GB thin provisioned auf nvme Controller

Das betrifft aber nicht nur das oben genannte Problem an sich. Generell fühlen sich die Windows VMs auf den neuen Servern deutlich träger und langsamer an - es fällt in dem Programm nur am meisten auf, weil die Leute hauptsächlich damit arbeiten.
Ich habe ausserdem eine identisch erstellte VM auf einen der neuen Hosts getestet und dabei local Datastore genutzt um VSAN ausschließen zu können. Selbes Ergebnis

Ich hoffe ihr habt noch einen Tipp für mich, denn mir gehen die Ideen echt aus...

Please also mark the comments that contributed to the solution of the article

Content-ID: 668459

Url: https://administrator.de/contentid/668459

Printed on: October 15, 2024 at 07:10 o'clock

79 Comments

Latest comment

Also bevor es hier gleich völlig wild wird und ganz viele Leute ganz viel Zeugs Posten und Raten...

Was hast du bisher systematisch untersucht und an Beweisen gesammelt?

Moin...

dein ERB ist ein Singel Core Programm, deine alte CPU war im grunde schneller mit 3,2 GHz... die neue CPU ist mit 2,7 GHz. langsamer....
wann und wie lange braucht die neue CPU bis der Turbo auf 3,8 GHz kommt?
da wird der hund begraben liegen....

Frank

Im Prinzip als allererstes erstmal quer getestet wie im Eingangspost.

Ausserdem, High Performance mode im Bios als auch ESXI eingestellt
Testweise CPU Profil 2 eingestellt (24 statt 32 Kerne aktiv - dafür Basetakt auf 3,0Ghz statt 2,8Ghz)

Eine identisch ausgestattete TestVM mit lokalem Datastore (1x Samsung PM1743 4TB) um VSAN als Ursache auszuschließen.

Und zu guter letzt ein paar Benchmarks gemacht. Und dort ist ersichtlich, dass die CPU irgendwie nicht die Leitung liefert wie erwartet.

Xeon Platinum Profile 2 @3ghz
https://browser.geekbench.com/v6/cpu/8040414
vergleich andere
https://browser.geekbench.com/search?utf8=%E2%9C%93&q=xeon+platinum+ ...

Xeon Gold
https://browser.geekbench.com/v6/cpu/8040417
vergleich andere
https://browser.geekbench.com/search?utf8=%E2%9C%93&q=xeon+gold+6134 ...

27 Punkte Single Thread Unterschied bei iwie 5 CPU Generationen, ich glaube eher nicht.

Moin,

Was ja noch nicht aus deinem vorherigen Post hervorgeht:

Sind die VMware Tools aktualisiert worden?
Ist das HW-Level der VM hochgezogen worden?
Sind die Kerne auf 1 oder mehr Sockets verteilt worden?
Ist der Lenovo vorher mit allen Updates versorgt worden (XClarity)?

Und wie habt ihr die VMs migriert? die neuen Hosts ins vCenter eingebunden und dann rüber?

Alles auf aktuellem Stand
Kerne sind auf 1 Sockel um NUMA möglichst zu vermeiden

Aber ich hab grad mal aus Verzweiflung im Bios auf einem Host testweise alles auf Max gestellt ohne Rücksicht auf Verbrauch und danach die VM auf dem entsprechenden Host getestet - Ergebnisse sahen erstmal gut genug aus, dass ich die anderen 3 Hosts nachziehe und dann nochmal ausgiebig teste.

Kurzes Update
es hing tatsächlich mit Bios Einstellungen zusammen.
Jetzt läuft alles wie erwartet

Moin @haudegen93,

Das betrifft aber nicht nur das oben genannte Problem an sich. Generell fühlen sich die Windows VMs auf den neuen Servern deutlich träger und langsamer an - es fällt in dem Programm nur am meisten auf, weil die Leute hauptsächlich damit arbeiten.
Ich habe ausserdem eine identisch erstellte VM auf einen der neuen Hosts getestet und dabei local Datastore genutzt um VSAN ausschließen zu können. Selbes Ergebnis

Ich hoffe ihr habt noch einen Tipp für mich, denn mir gehen die Ideen echt aus...

das riecht mir zu sehr nach dem RSC Murks, respektive, beim Pinguin heisst es ja LRO oder GRO. 🙃

Folgend ist beschrieben, wie du es ausschalten kannst.

https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.network ...
https://docs.vmware.com/de/VMware-vSphere/7.0/com.vmware.vsphere.network ...

https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-networking/GUID-51 ...

Gruss Alex

Moin @haudegen93,

Neue Server: (x4)
Lenovo Thinksystem SR 650 V3
CPU: 2x Intel Xeon Platinum 8462y+
Ram: 2TB
SSD: 8x Samsung PM1743 4TB
25gbit SFP+
Die 4 Maschinen arbeiten als VSAN Cluster in einer ESXI 8 Umgebung

alter Server
Huawei 2288h v5
CPU: 2x Intel Xeon Gold 6134
Ram: 1,5TB
SSD: 12x2TB SAS SSD in Raid 10

und welche NIC's genau waren in dem alten Server verbaut und welche sind in dem neuen Verbaut und mit welcher realen Uplink-Geschwindigkeit laufen diese?

Gruss Alex

Moin @haudegen93:

es hing tatsächlich mit Bios Einstellungen zusammen.
Jetzt läuft alles wie erwartet

tja, die heutigen Server sind heutzutage per Default eben nicht mehr auf Performance, sondern eher auf Energiesparren, sprich eher das Gegenteil davon getrimmt. 😔😭

By the Way, du musst auch im ESXi dessen Host-Energieverwaltungsrichtlinien auf Hochleistung stellen, damit die Performance der Hardware richtig ausgenutzt wird.

https://docs.vmware.com/de/VMware-vSphere/8.0/vsphere-resource-managemen ...

Und schalte LRO trotzdem aus, dann läuft das System wahrscheinlich noch um einiges schneller. 😉

Gruss Alex

Hi ALex,
um deine ganzen Beiträge etwas ausführlicher zu beantworten:

Aktuell sieht die Konfig noch so aus:
Serverraum 1
Unifi Aggregation Pro
4x Lenovo Server jeweils mit 1x 25Gbit und 1x 10Gbit an oben genanntem Unifi Switch angeschlossen
vMotion, vSAN und Bereitstellung laufen auf dem 25Gbit Port, Management Network auf dem 10Gbit Port.
2x USW Pro 48 PoE im Serverraum angeschlossen an oben genanntem Unifi Switch via 10GBit SFP
1x USW Pro 48 PoE in anderem Raum des Gebäudes angeschlossen an oben genanntem Unifi Switch via 10Gbit SFP

Serverraum 2 (gut 300m am anderen Ende des Gebäudes)
Unifi Aggregation Pro - angeschlossen an Aggregation Pro in Serverraum 1 via 4x10Gbit Link Aggregation
1x USW Pro 48 PoE im Serverraum angeschlossen an oben genanntem Unifi Switch via 10Gbit SFP
1x USW Pro 24 PoE in anderem Raum des Gebäudes angeschlossen an oben genanntem Unifi Switch via 10Gbit SFP

Divers verteilt im gesamten Gebäude sind knapp 20 Unifi UAP AC M Pro und U6 Pro

Kurzum, derzeit bis alles vernünftig läuft sind die 4 Server noch in einem Serverraum angeschlossen - später soll aber die Aufteilung 2:2 sein
Also quasi
Unifi Aggregation Pro 4x10Gbit SFP LAG <--> Unifi Aggregation Pro 4x10Gbit SFP LAG

2x Lenovo Server ----- 2x Lenovo Server
je 2x25Gbit SFP für vSAN ----- je 2x25Gbit SFP für vSAN
je 2x10Gbit SFP für Rest ----- je 2x10Gbit SFP für Rest

PS: Die neuen Lenovo Server haben Intel(R) E810-DA4 10/25GbE SFP28 4-port
Der alte Huawei Server hatte ne Intel X722 2x10GBit / 2x GBit Karte verbaut.

Zu dem Thema lags der VMs, das hat sich mit dem Entfernen sämtlicher Energiesparmechanismen (auch in den Vcenter Einstellungen bei den Hosts) deutlich gebessert. Zwar immer noch nicht zu vergleichen mit nem physischen PC wo ich mich via RDP drauf schalte, aber deutlich besser.

Moin @haudegen93,

danke für die ganzen Infos, deine Hauptprobleme bezüglich der Performance, liegen wahrscheinlich jedoch weniger an den Switchen ... wobei du auf diesen auf jeden Fall FlowControl aktivieren solltest, sondern meiner bisherigen Erfahrung nach eher an den Servern und auch den Einstellungen der NIC's. 😔

PS: Die neuen Lenovo Server haben Intel(R) E810-DA4 10/25GbE SFP28 4-port

Oh, E810, lecker, die haben ordentlich Bums und auch ordentlich Ressourcen für Virtualisierung. 😁

Der alte Huawei Server hatte ne Intel X722 2x10GBit / 2x GBit Karte verbaut.

Die Intel X7xx sind auch nicht schlecht, auf jeden Fall um Welten besser als 10G NIC's von Broadcom.

Zu dem Thema lags der VMs, das hat sich mit dem Entfernen sämtlicher Energiesparmechanismen (auch in den Vcenter Einstellungen bei den Hosts) deutlich gebessert.

Schau dir mal die folgende Doku an ...
https://lenovopress.lenovo.com/lp1836.pdf
... und stelle deine Systeme so ein, dass diese möglichst auf "Maximum Performance" respektive "Low Latency" laufen. 😉

Zwar immer noch nicht zu vergleichen mit nem physischen PC wo ich mich via RDP drauf schalte, aber deutlich besser.

Das liegt wahrscheinlich daran, dass auf deinem System SR-IOV/VMQ/NetQueue deaktiviert, respektive nicht funktional ist, ohne diese Features, bekommst du jedoch bei den vNIC's der VMs nicht mal ansatzweise die Effizienz und Performance hin, wie bei einem rein physischen System. 😔

Weitere Infos:
https://docs.vmware.com/de/VMware-vSphere/7.0/com.vmware.vsphere.network ...
https://docs.vmware.com/de/VMware-vSphere/7.0/com.vmware.vsphere.network ...
https://docs.vmware.com/de/VMware-SD-WAN/6.0/vmware-sd-wan-partner-guide ...
https://www.youtube.com/watch?v=n0A6LPL6COE

Oh man, wie ich sehe sind die Informationen zu VMQ/SR-IOV, bei VMware noch viel magerer ausgeprägt als bei Microsoft, dabei gibt es diese Technologie schon seit über 15 Jahren. 😔😭

Gruss Alex

danke für die ganzen Infos, deine Hauptprobleme bezüglich der Performance, liegen wahrscheinlich jedoch weniger an den Switchen ... wobei du auf diesen auf jeden Fall FlowControl aktivieren solltest, sondern meiner bisherigen Erfahrung nach eher an den Servern und auch den Einstellungen der NIC's. 😔

Flow Control ist tatsächlich aus. Aber macht das überhaupt Sinn? Ich dachte Flow Controll braucht man nur wenn man über unterschiedliche Portbandbreiten geht. Der einzige Traffic ausserhalb der VMs / des Aggregation Switches ist ja nur der RDP Zugriff
Anders gefragt, hätte es einen negativen Effekt das zu aktivieren?

Also Geschwindigkeit zwischen den einzelnen VMS ist bei uns eigentlich das allerwichtigste, da wir zu 99% auf Terminalservern arbeiten

Wobei ich jetzt mal nen einfachen Atto Benchmark einmal VM mit Disk auf vSAN und einmal VM mit Disk auf lokaler einzelnen SSD des Hosts und die einzelne SSD gut doppelt so schnell war oO - da muss ich auch noch nachforschen was da los ist.

Zu dem Thema lags der VMs, das hat sich mit dem Entfernen sämtlicher Energiesparmechanismen (auch in den Vcenter Einstellungen bei den Hosts) deutlich gebessert.

Das habe ich tatsächlich getan, was am Ende auch im Eingang erwähnte Probleme behoben hat.
Geekbench von anfänglich knapp 1050 Pkt Single Thread auf gut 1900 Punkte

Das schaue ich mir auf jeden Fall mal an, aber heißt das dann, dass ich am Ende nur auf die SR-IOV "NICs" setzen sollte statt auf die VMXNet3?

Moin @haudegen93,

wenn ich deine obere Ausführungen richtig verstanden habe, dann läuft der vSAN-Sync ja auch über die Switche und hier kann schon mal ordentlich Durchsatz durchgehen. Das Ziel kann sich dabei, trotz der 25G Anbindung, ja auch mal "verschlucken" und wenn das passiert, dann ist es schon hilfreich dem Sendenden das mitzuteilen, sonst ballert dieser nur unnötig die Puffer der Switche voll. 😉

Anders gefragt, hätte es einen negativen Effekt das zu aktivieren?

Eher einen positiven.

Also Geschwindigkeit zwischen den einzelnen VMS ist bei uns eigentlich das allerwichtigste, da wir zu 99% auf Terminalservern arbeiten

Dann solltest du darauf achten, dass z.B. Applikationsserver und zugehörige DB's, immer auf demselben Host laufen,
dadurch kommunizieren die untereinander am effektivsten.

Wobei ich jetzt mal nen einfachen Atto Benchmark einmal VM mit Disk auf vSAN und einmal VM mit Disk auf lokaler einzelnen SSD des Hosts und die einzelne SSD gut doppelt so schnell war oO - da muss ich auch noch nachforschen was da los ist.

Na ja, ein vSAN ist unter dem Strich ein meist auch noch über das Netzwerk verteiltes Software-RAID.
Und über die meist sehr bescheidene Leistung eines reinen Software-RAID's haben wir hier im Forum schon oft gesprochen und dass ein solches dann auch noch über das "Netzwerk" verteilt wird, mach die Sache nicht wirklich besser. 😔
Sprich, wenn du von deinem vSAN Performance erwartest, dann müssen die entsprechenden/beteiligten Netzwerkkomponenten erst recht 1A getrimmt sein, damit das vSAN überhaupt konstante Leistung bringt.

Aber trotzt besten Tunings, wird ein vSAN niemals an die Leistung eines HW-SAN's kommen und zwar ganz egal wie sehr sich das entsprechende Marketing oder der Vertrieb der entsprechenden vSAN/S2D Lösungen auch anstrengen mag, weil es schlichtweg technisch nicht wirklich möglich ist. 🙃

Geekbench von anfänglich knapp 1050 Pkt Single Thread auf gut 1900 Punkte

Glaub mir, ich kann ganz viele solcher Lieder mittlerweile singen.
Folgend eines der letzten ...

NVIDIA L40S - Die erste Erfahrung ist etwas bescheiden
😔

Das schaue ich mir auf jeden Fall mal an, aber heißt das dann, dass ich am Ende nur auf die SR-IOV "NICs" setzen sollte statt auf die VMXNet3?

Ähm, ja, mit SR-IOV/NetQueue und VMware kenne ich mich nicht wirklich gut aus, mir reicht schon das Desaster, welches ich momentan bei Microsoft damit durchmachen muss. 😭

Aber, bevor du das auf dem produktiven System aktivierst, solltest du dich etwas Detailierter mit dem Thema befassen, den es ist technisch nicht ohne, bringt jedoch wie ich geschrieben habe, zum Teil um Faktoren bessere Leistung.

By the Way, welche ... ah, ich sehe es schon, du hast Intel CPU's verbaut, sehr gut, mit diesen laufen die Intel NIC's am Besten, ausserdem ist Intel quasi die Mama von SR-IOV/VMQ/NetQueue.

https://www.youtube.com/watch?v=QvKXbpV6WXk
https://www.youtube.com/watch?v=lOBOEcBSSkQ
https://www.youtube.com/watch?v=hRHsk8Nycdg

https://networkbuilders.intel.com/university/course/single-root-io-virtu ...
https://networkbuilders.intel.com/university/course/the-importance-of-sr ...
😉

Gruss Alex

Kleine Info/Frage am Rande, bevor wieder in der Wortklauberei des Fuchsbaus sind: Können die Switches überhaupt DCB?
Ich empfehle weiterhin eine systematische Arbeitsweise, wenn es mit Fachwissen nicht so gut aussieht.

Ich empfehle weiterhin eine systematische Arbeitsweise, wenn es mit Fachwissen nicht so gut aussieht.

Mit dem Fachwissen sieht es tatsächlich nicht top aus.
Ist mein erstes mal mit mehreren Hosts und dann noch vSAN.
Die Lösung der oben genannten Lenovo Hosts ist hier seit gut 3 Monaten im Einsatz und die Performance dieser war halt bisher immer unterirdisch bzw. weniger als erwartet, weshalb ich mich hier hin wandte.

Das Software Raid im Vergleich zu Hardware Raid schlechter ist, ist mir bewusst, jedoch sollte doch ein Software Raid nicht so arg schlechter Performen als eine einzelne Platte

Hier mal zwei Beispiele (identisch konfigurierte VMs, einmal mit lokal Datastore SSD und einmal mit vSAN)

lokaler Datastore

vSAN

Aber, bevor du das auf dem produktiven System aktivierst, solltest du dich etwas Detailierter mit dem Thema befassen, den es ist technisch nicht ohne, bringt jedoch wie ich geschrieben habe, zum Teil um Faktoren bessere Leistung.

Ja das würde ich sowieso vorher machen, da dient der alte Huawei Server derzeit ganz gut als Testsystem

Kleine Info/Frage am Rande, bevor wieder in der Wortklauberei des Fuchsbaus sind: Können die Switches überhaupt DCB?

Ich denke nicht, dass die Switches das können.
Was die Optionen angeht, sieht es tatsächlich echt mau aus.

Trotzdem bin ich euch für sämtliche Tipps und Hilfen dankbar

Ich meine das System an sich läuft ja jetzt und ist tausendmal bessere als vor den Einstellungen und nochmal deutlich besser als mit dem Huawei Server (der am Limit lief xD), aber wenn es noch Möglichkeiten zur Verbesserung gibt, will man das natürlich nicht liegen lassen.

Ich Frage noch mal:

1. Hat es eine systematische Untersuchung zur Ursache (root case) der Problematik gegeben? Es wirkt nicht so.
2. DCB ist nicht zwingend nötig. Aber sollte als Mindest-Featureset vorhanden sein. sonst macht es wenig Sinn über Funktionen und Protokolle zu diskutieren, wie geschehen.

Beide deine Screenshots laufen offensichtlich in ein Limit, wenn auch unterschiedlicher Herkunft. (Die Benchmarksoftware ist aber auch nciht optimal.)

Moin @Trinatrium,

1. Hat es eine systematische Untersuchung zur Ursache (root case) der Problematik gegeben? Es wirkt nicht so.

alles der Reihe nach, du musst halt etwas Geduld haben und auch noch einiges lernen.
Und wenn deine Sprüche nicht besser werden, dann werde ich bei nächsten Mal auch mal eine Kralle mit ausfahren. 😉

Beide deine Screenshots laufen offensichtlich in ein Limit, wenn auch unterschiedlicher Herkunft. (Die Benchmarksoftware ist aber auch nciht optimal.)

Die Benchmark Software ist ganz sicher nicht das Problem, eher deine Kristallkugel.

Denn 512Bytes * 3,06K IO/s, sind gerade mal 1530 KB/s oder ~1,50 MB/s und das sollte eine 25G NIC auch ohne irgendwelches QOS auf die Reihe bekommen.

Gruss Alex

Naja, eher Pfote. Na Kralle werden wir hier nie sehen: Außer ich bin schon länger dabei und die Forenregeln verbieten es mir, mein Wissen zu teilen. Hatten wir alles schon. Bringt aber hier niemanden weiter.

Auch wird SR-IOV nicht erklären, dass er in ein Limit lesend wie schreibend läuft, dass über viele IO-Größen wohl ganz offensichtlich und dringend fehlt. Und auch das ist ganz offensichtlich nciht einem SR-IOV geschuldet.

Nun stellt sich wieder die Frage: Was wurde unternommen um die Gründe für das Limit des Storages zu ergründen?
@haudegen93: Hast Du mal die Hosts direkt das vSAN-ports verbunden, also ohne Switch dazwischen? Damit kannst Du erstmal ausschließen, dass das Switch damit nichts zu tun hat. Ich befürchte dass das Switch kein DCB kann, was aber nicht die sooo miese Performance erklärt. Wie vorgerechnet ist die Performance nicht gut. Eine Floppy hätte 25kb/Sek, zum Vergleich.
Du solltest primär klären woher das Limit kommt.
stammte das Image von Lenovo oder ist es ein generisches Image?

Moin @Trinatrium,

Naja, eher Pfote.

ja, bisher sogar nur die Samtpfote. 😁

Na Kralle werden wir hier nie sehen:

Oh, täusch dich da nicht zu sehr, früher hätte ich schon viel früher die Krallen ausgefahren, natürlich so gut es geht Regelkonform. 🙃
Aber ja, mittlerweile bin ich auch schon etwas älter geworden und kralle/beisse daher auch nicht mehr so schnell wie früher. 🤪

und die Forenregeln verbieten es mir, mein Wissen zu teilen.

Jup, so ist das bei manchem Wissen auch und irgendwann wirst du das warum dahinter, vielleicht auch mal verstehen.

Bringt aber hier niemanden weiter.

Natürlich, deshalb sind auch 133 meiner Kommentare, bereits als Lösung getagt. 🙃

Auch wird SR-IOV nicht erklären, dass er in ein Limit lesend wie schreibend läuft, dass über viele IO-Größen wohl ganz offensichtlich und dringend fehlt. Und auch das ist ganz offensichtlich nciht einem SR-IOV geschuldet.

Das SR-IOV habe ich nicht wirklich im Zusammenhang mit dem vSAN angesprochen.
Jedoch, je nachdem wie das SDN beim TO Designt ist, kann es auch bei dem vSAN Thema eine Rolle spielen.

@haudegen93: Hast Du mal die Hosts direkt das vSAN-ports verbunden, also ohne Switch dazwischen?

Du hast aber schon gelesen, dass der TO nicht nur zwei, sondern vier Hosts hat?

Damit kannst Du erstmal ausschließen, dass das Switch damit nichts zu tun hat. Ich befürchte dass das Switch kein DCB kann, was aber nicht die sooo miese Performance erklärt. Wie vorgerechnet ist die Performance nicht gut. Eine Floppy hätte 25kb/Sek, zum Vergleich.

Lass bitte mal das DCB in Ruhe, das bringt bei der Bandbreite die niemals eine Überlast erzeugt, genau gar nichts.

Du solltest primär klären woher das Limit kommt.
stammte das Image von Lenovo oder ist es ein generisches Image?

Was soll den nun das Image damit zu tun haben?

Gruss Alex

Moin @haudegen93,

lokaler Datastore

vSAN

😧 ... 😭 ... ja, das sieht schon etwas gruselig aus. 😬

Hast du denn wie bereits angesprochen, das LRO/GRO schon hostseitig deaktiviert?

Gruss Alex

Zitat von @MysticFoxDE:

Du hast aber schon gelesen, dass der TO nicht nur zwei, sondern vier Hosts hat?

Lass bitte mal das DCB in Ruhe, das bringt bei der Bandbreite die niemals eine Überlast erzeugt, genau gar nichts.

Du solltest primär klären woher das Limit kommt.
stammte das Image von Lenovo oder ist es ein generisches Image?

Was soll den nun das Image damit zu tun haben?

Gruss Alex

Ja, deshalb kann es ja mit zwei der vier Hosts, das in in Minuten testen.

OEM Images haben angepasste Treiber, Konfigs usw.... Besonders bei vSAN macht es viel Sinn eine explizit unterstützte Umgebung zu haben, weil sonst kein Hersteller-Support in der Subscription möglich ist.

War heut den ganzen Tag unterwegs...

Fangen wir von oben an:

Du solltest primär klären woher das Limit kommt.
stammte das Image von Lenovo oder ist es ein generisches Image?

Damit sagst du das offensichtliche auf, weshalb ich hier nach Rat frage oO
Aktuell ist das generische Build 8.0.2 auf den Lenovo Hosts.

Hast du denn wie bereits angesprochen, das LRO/GRO schon hostseitig deaktiviert?

Noch nicht, bin bei Änderungen was die Hardware / VMs angeht eher überfürsorglich und mache sowas wenn dann eher am WE wenn die ganzen Standorte nicht arbeiten (falls doch was schief gehen sollte) - Oder kann ich das bedenkenlos im Live Betrieb deaktivieren?

Ja, deshalb kann es ja mit zwei der vier Hosts, das in in Minuten testen.

Ich kann doch jetzt nicht einfach das vSAN "ausseinander reißen" Das ist wie gesagt unser Live System - den Usern fällt es nicht auf, dass es langsamer ist als es eig sein sollte - mich stört das aber.

OEM Images haben angepasste Treiber, Konfigs usw.... Besonders bei vSAN macht es viel Sinn eine explizit unterstützte Umgebung zu haben, weil sonst kein Hersteller-Support in der Subscription möglich ist.

Der Umstieg auf die Lenovo Firmware ist zeitnah geplant. XClarity Integrator mit der Firmware etc. ist soweit vorbereitet. - Eine SSD lässt sich leider nicht in der Firmware auf den seiten VMware unterstützten Stand upgraden (da warten wir noch auf die RMA Antwort seitens Lenovo)
Und ja sonst schmeißt er mir die Meldungen raus, weil das UEFI / BMC neurer als in dem Image ist.
Oder kann ich die Meldung ignorieren, bzw. wie würde das "Update" dann verlaufen? downgraded er die bemängelten Versionen auf die im Image hinterlegten?

Hast Du auf den ESXi und das vSAN Support?

Moin @Trinatrium,

Ja, deshalb kann es ja mit zwei der vier Hosts, das in in Minuten testen.

ein vier Node vSAN Cluster mal kurz zweiteilen, ja, der ist gut. 🙃

Jetzt kommen wir so langsam auf den selben Kurs. 😁
Ähm ja, gerade bei einem vSAN ist es mehr als nur wichtig, nur "supportete" Komponenten zu benutzen, sonst kann man jegliche Supportanfrage, auch gleich wieder knicken, vor allem bei Broadcom. 😔

Gruss Alex

Moin @haudegen93,

so, jetzt habe ich mir das ganze mal genauer angeschaut, vor allem im Hinblick auf das vSAN.

Damit dein Konstrukt, respektive das vSAN ansatzweise performant läuft, musst du unbedingt sicherstellen, dass die Intel E810er NIC's mit iWARP laufen, den RoCE kannst du bei dir knicken, da deine Switche das nicht supporten.

Und hier liegt glaube ich auch schon der Großteil des Hundes begraben, denn meine Kristallkugel sagt mir, dass deine E810er NIC's, über die ja auch das vSAN läuft, ohne RDMA laufen. 😔

Sprich, schau mal bitte nach ob bei dir RDMA grundsätzlich aktiviert ist und die E810 auch sauber auf iWARP konfiguriert sind und dieses nicht nur konfiguriert, sondern auch funktional ist.

Übrigens ...

Kurzum, derzeit bis alles vernünftig läuft sind die 4 Server noch in einem Serverraum angeschlossen - später soll aber die Aufteilung 2:2 sein
Also quasi
Unifi Aggregation Pro 4x10Gbit SFP LAG <--> Unifi Aggregation Pro 4x10Gbit SFP LAG

... das ist keine wirklich gute Idee, denn einen 25G Uplink, kann man nicht wirklich über ein 4x10Gbit LAG weiterreichen. Also ja schon aber nur mit 10G und nicht 25G.
Sprich, genau an dieser Stelle hast du später ein Bottleneck und spätestens wenn dann kein Flow-Control oder QOS konfiguriert ist, wirst du mit deinem vSAN wahrscheinlich noch viel grössere Probleme haben. 😔

Aber, wenn zwei Server links stehen und zwei rechts, dann hast du pro Unifi Aggregation Pro Switch ja zwei SFP28 Ports frei. 😁
Sprich, darüber kannst du die beiden Serverräume ja dann mit einem 2x25G LAG koppeln und dann ist die Sache mit dem oben angesprochenem Bottleneck auch wieder vom Tisch. 😉

Ähm ja, by the Way, schau dir bitte auch unbedingt mal das Folgende an.

https://knowledge.broadcom.com/external/article/313796/enabling-and-disa ...
😬

Gruss Alex

Und hier liegt glaube ich auch schon der Großteil des Hundes begraben, denn meine Kristallkugel sagt mir, dass deine E810er NIC's, über die ja auch das vSAN läuft, ohne RDMA laufen.

Laut https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-storage/GUID-F4B42 ... soll man das einfach in dem jeweiligen Host aktivieren können, jedoch habe ich den Menüpunkt gar nicht. Muss ich erst auf die neuste Firmware von den NICs aktuallisieren oder das gar im BIOS aktivieren?

Aber, wenn zwei Server links stehen und zwei rechts, dann hast du pro Unifi Aggregation Pro Switch ja zwei SFP28 Ports frei. 😁
Sprich, darüber kannst du die beiden Serverräume ja dann mit einem 2x25G LAG koppeln und dann ist die Sache mit dem oben angesprochenem Bottleneck auch wieder vom Tisch.

Das wäre tatsächlich die andere Alternative die ich im Kopf hatte

Und nein nen Supportvertrag an sich haben wir nicht. Wir haben einen Dienstleister der uns dabei n bissl. unterstützt mit vSAN an sich aber auch noch nix groß zu tun hatte.

Ähm ja, gerade bei einem vSAN ist es mehr als nur wichtig, nur "supportete" Komponenten zu benutzen, sonst kann man jegliche Supportanfrage, auch gleich wieder knicken, vor allem bei Broadcom. 😔

Die Hardware an sich ist ja supported, das einzige wo er noch meckert ist die 1 SSD die sich net upgraden lassen will Firmware OPPA3 - supported sind aber nur 2 4 und 6 ... :D

Moin @Trinatrium,

ich habe gerade spasseshalber mal bei einem unserer Kunden den ATTO über eines seiner "Cluster Shared Volumes" welche auf einem Hardware SAN basieren drüber gejagt.

😁

Und behaupte jetzt mal ganz frech, dass an diese Leistung so schnell kein vSAN wirklich herankommt, vor allem nicht mit gerade mal einem Worker und 4 oIOs.

Übrigens, mit etwas mehr Anforderung, sprich, 8 Worker und je 8 oIOs, kann das entsprechende SAN locker > 1.400.000 IO/s liefern und das bei einer durchschnittlichen Latenz von gerade mal 0,0881 ms.

Infortrend DS4000U - Meine neue Liebe . . . natürlich nur SAN technisch
🤪

Sprich, ein vSAN ist eben ein vSAN und ein anständiges SAN ist ein anständiges SAN und dazwischen liegen zum Teil sehr sehr grosse Welten, vor allem performancetechnisch.
Marketing- und vertriebstechnisch sieht die Sache natürlich oft ganz anders aus. 🙃

Gruss Alex

Moin @haudegen93,

Laut https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-storage/GUID-F4B42 ... soll man das einfach in dem jeweiligen Host aktivieren können, jedoch habe ich den Menüpunkt gar nicht.

das ist auch eine Anleitung um RDMA per RoCE v2 zu aktivieren, das funktioniert bei dir jedoch nicht, weil deine Switche das nicht supporten. Für iWARP benötigt man jedoch keine bestimmte Switche, wie man das bei einem ESXi aktiviert weis ich jetzt aus dem Stehgreif nicht wirklich, da ich eher auf Hyper-V spezialisiert bin. 🙃

Muss ich erst auf die neuste Firmware von den NICs aktuallisieren

Das sollte man grundsätzlich immer machen.

oder das gar im BIOS aktivieren?

Ja, du musst für RDMA im BIOS der Server unbedingt mindestens Global SR-IOV einschalten, siehe auch ...

https://edc.intel.com/content/www/xl/es/design/products/ethernet/adapter ...

Und nein nen Supportvertrag an sich haben wir nicht. Wir haben einen Dienstleister der uns dabei n bissl. unterstützt mit vSAN an sich aber auch noch nix groß zu tun hatte.

Ich schreib jetzt lieber nicht, was meiner Kristallkugel darauf gerade ausgespuckt hat. 🙃

Die Hardware an sich ist ja supported, das einzige wo er noch meckert ist die 1 SSD die sich net upgraden lassen will Firmware OPPA3 - supported sind aber nur 2 4 und 6 ... :D

Oh ja Firmwareupgrades, ähm, ganz wichtig ... nach jedem Firmwareupgrade, müssen mindestens die BIOS Default geladen werden, damit sämtliche Änderungen auch wirklich sauber übernommen werden. Manchmal ist sogar ein CMOS-Reset notwendig. Und nein, das ist jetzt kein böser Scherz.

Steht, respektive, stand auch früher in jeder BIOS-Update-ReadMe eines Intel Servers drin, doch bei Anbieter die DELL, HPE & Co. KG, schein diese wichtige Info bei deren ReadMe's wohl irgendwie untergegangen zu sein. 😔

Gruss Alex

Noch mal für RDMA ist DCB Voraussetzung. Für iWARP wäre es optional, aber sehr empfehlenswert.

Moin @Trinatrium,

Noch mal für RDMA ist DCB Voraussetzung.

ganz sicher nicht, denn für RDMA, wozu übrigens sowohl RoCE als auch iWARP zählt, benötigt man in erster Linie ein sogenanntes "Lossless-Network/Non-Blocking-Network" und das erreicht man in erster Linie durch die Wahl der richtigen Switche, was beim TO schon mal nicht der Fall ist.

Und wenn man auf die suboptimale Idee kommt, RDMA Storage-Traffic mit sonstigem Datenverkehr über dieselbe Infrastruktur zu betreiben, sprich, nicht wirklich rein hardwaretechnisch sicherstellen kann, dass vor allem der RDMA Datenverkehr wirklich "lossless/non-blocking" ist, kann mit DCB (QOS) etwas nachhelfen.

Für iWARP wäre es optional, aber sehr empfehlenswert.

Ja, iWARP ist viel unempfindlicher wie RoCE (V2), weil es auch über das viel sicherere/stabilere TCP und nicht das, zumindest was diesen Fall angeht, bescheuerte UDP läuft. 🙃

Und empfehlenswert währe es sowohl bei RoCE als auch für iWARP, wie schon oben geschrieben, gleich die richtigen Switche zu verwenden und über diese auch nur den Storage-Datenverkehr drüber zu jagen und nicht mit anderem zu mixen, dann benötigt man auch meistens kein zusätzliches QOS.

By the Way, oder man nimmt gleich ein anständiges SAN, schliesst es per SAS oder FC direkt an die Nodes an und spart sich den ganzen RDMA & Co. Krampf und hat dann auch noch ordentlich mehr Leistung. 😉

Gruss Alex

Moin @Trinatrium,

😯 ... wo sind den die ganzen Nettigkeiten hin, die heute Morgen noch da waren? 🤔
Na ja, hab zur Erinnerung ja noch einen Screenshot.

Noch mal für RDMA ist DCB Voraussetzung. Für iWARP wäre es optional, aber sehr empfehlenswert.

So jetzt mal der Ruhe nach. 🤪

Also, iWARP und RoCE sind grundsätzlich mal beides RDMA, sprich, basieren auf derselben Hardwaretechnologie und zwar VMDq, respektive SR-IOV, zumindest bei Intel Plattformen.

RoCE wurde jedoch von der IBTA ...

https://en.wikipedia.org/wiki/InfiniBand

... entickelt und iWARP von der IETF ...

https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force

... und der Hauptunterschied zwischen diesen beiden Ausprägungen ist, dass iWARP über TCP läuft und RoCE über UDP.

Da UDP jedoch im Grunde ein "Fire und Forget" Protokoll ist, sprich, von sich aus kein QOS oder Überlaststeuerung oder Übertragungskontrolle mit sich bringt, taugt es von Haus aus eigentlich auch nicht wirklich für kritischen Storage-Datenverkehr, bei dem Überlast oder gar ein Paketverlust, tunlichst zu vermeiden sind. Und um das bei RoCE zu erreichen, muss man eben entweder einen Lossless-Backend haben oder Dinge wie DCB verwenden.

Da iWARP jedoch auf TCP fusst und TCP schon von Haus aus solche Dinge wie QOS oder Überlaststeuerung beherrscht, muss man bei iWARP auch nicht wirklich DCB verwenden. 😉

Falls du noch mehr zu DCB Wissen möchtest.
https://www.ieee802.org/1/files/public/docs2018/tsn-farkas-intro-0318-v0 ...
https://edc.intel.com/content/www/us/en/design/products/ethernet/adapter ...

Und da beim TO kein RoCE möglich ist, da die Switche das nicht supporten, muss er sich um DCB auch keinen Kopf zerbrechen.

Gruss Alex

Moin,
LRO habe ich deaktiviert, was aber keine wirkliche Auswirkung hatte.

Ich werde mal schauen, wir haben noch "ältere" HPE Aruba 10Gbit Switches im Büro wie sich die Performance da dran verhält.

NIC Firmware Update etc. ist am WE geplant.

Alex, ich habe tatsächlich bis InfiniBand gelesen.

@topic: Wir wissen weiterhin nichts. Wir wissen nichts über die Konfig des vSANS. Selbst triviale Logs haben wir ncht gesehen. Ein "esxcli network nic..." usw alles nichts da.
Wir wissen nur, dass es nicht gut läuft. Die IOPS Richtung Storage im verdacht stehen nicht gut zu sein, aber ohne vSAN Policys zu kennen, schaffen es die Bilder nur in den Fuchsbau. Es gibt Switches die sehr eingeschränkt sind und nicht viel Forward können ohne hochlatenz zu zeigen. Wir kennen (sinnlose) BEnchmarks aus einer VM, aber der Hypervisor ist nicht untersucht worden. Das wäre ein fall für systematisches Arbeiten. Wir haben viele "Ratschläge" gehört, etwas zu verstellen. Ganz wundersame Dinge, die aber mit dem Ansatz, dass das Lesen und Scheiben in ein verteiltes Blockleveldateissystem NICHTS zu tun haben. Man dreht sich im Kreis.

Lange Rede Kurzer Sinn. Die Umgebung ist weit weg von einer supporteten Umgebung. Wo überall die Best Practices verlassen sind können wir nciht einschätzen.
Somit kommt jeder IT-Pro eigentlich immer an den Punkt Systematisch die Vitalparameter zu untersuchen.

Gut, ich bin raus. Ich würde die Zeit dann doch eher in unsere Cluster stecken, die laufen.
Kleine Info noch. Wenn man mit ESXi gut kann, vielleicht ein Zertifikat hat, dann kann man das Zertifikat zum vSAN Specialist in drei Stunden machen. Weil es wirklich keine große Sache ist. Wie alle VMWare Zertifikate die im Feld einen Einsatz finden würden, geht es um systemtisches Arbeiten. Noch NIE ist in einer Zertifizierung ein Disk Benchmark gemacht worden und wenn es jemand macht, dann würde man dem keine Bedeutung beimessen. Und in der völligen Unkenntnis eines vSANs macht dann jemand, auf Kundenhardware ^^, eine Diskbenchmark - obwohl das nichts zur Sache beiträgt und absolut keine Aussagekraft hat. Um dann noch was von 1,4Mio IOPS zu erzählen. wirklich völlig irrer Thread hier. Ich sollte es auch Screenshoten und bei Reddit posten, zum kaputtlachen. Ich würde mir Gedanken machen, dass ein Kunde hier mit liest. Das Verhalten ist Treu und Glauben zu wieder.

@66505: Poste mal die Konfigs der NICs: "esxcli network nic dcb status get -n vmnicxyz" xyz ist der nurmerische Wert der richtigen NIC.

Hast Du die vSAN (storage) policies verändert, bzw welche angelegt? (Unpassende Storage Policies würden die SLAs brechen.)
https://core.vmware.com/resource/vsan-proof-concept-vsan-performance-tes ...

https://core.vmware.com/resource/vsan-proof-concept-vsan-performance-tes ... Hier geht es darum, warum die ATTO-BM keine Aussagekraft hat.

Moin @haudegen93,

LRO habe ich deaktiviert, was aber keine wirkliche Auswirkung hatte.

ich wollte dir gestern noch schreiben, dass du das LRO erstmal in Ruhe lässt und dich primär lieber darum kümmerst, dass die Strecke über die das vSAN läuft, auf jeden Fall per iWARP läuft. Den RoCE, was übrigens die favorisierte Methode von VMware ist, kommt bei dir aufgrund der fehlenden Unterstützung der Switche, leider nicht wirklich in Frage.

Ich werde mal schauen, wir haben noch "ältere" HPE Aruba 10Gbit Switches im Büro wie sich die Performance da dran verhält.

Ich fürchte die wird noch bescheidener. 😬
Denn meine Kristallkugel sagt mir, dass dein bestehender Aruba Switch, zu > 99,99 auch kein RoCE kann.

Denn RoCE gibt es bei Aruba so wie ich das sehe, erst ab der CX 8100 Serie ...

https://buy.hpe.com/de/de/networking/switches/fixed-port-l3-managed-ethe ...

... und die kosten richtig Asche. 😔

https://www.kaufland.de/product/477751313/?search_value=HPE%20Networking ...

Zu hart, weder bei Bechtle noch bei der Cancom sind CX 8100 Switche im Onlineshop gelistet, dafür aber beim Kaufland. 😖

Na ja, wie du siehst, ist RoCE für dich wahrscheinlich keine Option.
Alleine schon deshalb, weil man für einen sauberen Aufbau, pro Site/Serverraum zwei von den Dingen benötigt um die vSAN Pfade, wie auch von VMware per Best Practice empfohlen ...

https://docs.vmware.com/en/VMware-vSphere/8.0/vsan-planning/GUID-031F963 ...

... auch in HA zu haben.

Bevor du jetzt jedoch vollends einen Schock bekommst, ganz Ruhig, deine E810er können ja auch iWARP und dafür benötigst du auch keine besondere Switche. 😉

Sprich, als nächstes solltest du sicherstellen, dass die Links worüber das vSAN läuft, mit iWAPR laufen.
Hier kann ich dir jedoch nur sehr begrenzt helfen, da ich wie schon geschrieben, eher auf Hyper-V spezialisiert bin.

Ich schau aber dennoch, ob ich hierzu noch weitere Infos finde. Denn die Menschen, die sich mit dem ja auch so geilen vSAN wirklich auszukennen scheinen, sind gerade leider zu sehr mit anderen Dingen beschäftigt. 😔

NIC Firmware Update etc. ist am WE geplant.

👍👍👍

Gruss Alex

Moin @Trinatrium,

also, bei dem hier ...

... muss ich irgendwie automatisch an das hier denken.

Eine Boeing 777 ist auf dem Weg über den Atlantik. Sie fliegt gleichbleibend mit 800 km/h in 30.000 Fuß Höhe, als plötzlich eine F-17 mit Tempo Mach 2 auftaucht. Der Pilot des Kampfjets bremst ab, fliegt neben der Boeing her und grüßt den Piloten des Passagierflugzeugs per Funk: "Langweiliger Flug, was? Dann pass mal auf!"

Er rollt seinen Jet auf den Rücken, beschleunigt, durchbricht die Schallmauer, steigt rasant in eine schwindelerregende Höhe, nur um gleich darauf in einem atemberaubenden Sturzflug fast bis hinunter auf Meereshöhe zu stürzen. Mit einem Looping kehrt er neben die Boeing zurück und fragt: "Na, wie war das?"

Der Pilot der Boeing antwortet: "Sehr beeindruckend. Aber jetzt schau du mal her!"

Der Jetpilot beobachtet die Boeing, aber es passiert nichts. Sie fliegt weiter stur geradeaus, mit immer gleichem Tempo. Nach fünf Minuten meldet sich der Boeing-Pilot per Funk: "Na, was sagst Du jetzt!?"

Der Jetpilot fragt irritiert: "Was hast du denn gemacht?" Der andere lacht und sagt: "Ich bin aufgestanden, habe mir die Beine vertreten, bin nach hinten auf die Toilette gegangen, dann habe ich mir einen Kaffee und eine Zimtschnecke geholt und mich für die nächsten drei Nächte mit der Stewardess verabredet - in einem 5-Sterne-Hotel, das von meinem Arbeitgeber bezahlt wird."

😉

Kleine Info noch. Wenn man mit ESXi gut kann, vielleicht ein Zertifikat hat, dann kann man das Zertifikat zum vSAN Specialist in drei Stunden machen. Weil es wirklich keine große Sache ist. Wie alle VMWare Zertifikate die im Feld einen Einsatz finden würden, geht es um systemtisches Arbeiten.

😩 ... oh jäh, jetzt kommt du auch noch mit der Zertifikats-Keule. 🥱
Sorry, bei den meisten VMware Schulungen die ich früher zwangsweise machen musste, bin ich fast eigeschlafen und habe dennoch die Zertifikate bekommen.

Noch NIE ist in einer Zertifizierung ein Disk Benchmark gemacht worden und wenn es jemand macht, dann würde man dem keine Bedeutung beimessen.

Aha, ihr habt bei einer Zertifizierung also auch noch nie einen Leistungstest dessen gemacht was konfiguriert wurde ... tja, auch deshalb fand ich früher diese Zertifizierungen auch sooo "spannend". 🙃

Und in der völligen Unkenntnis eines vSANs macht dann jemand, auf Kundenhardware ^^, eine Diskbenchmark - obwohl das nichts zur Sache beiträgt und absolut keine Aussagekraft hat.

Das mag schon sein, dass dir der Benchmark keine Anhaltspunkte liefert, zumal er ja auch in keiner deiner bisherigen Zertifizierungen angesprochen wurde. Mir sagt dieser jedoch schon einiges.

Um dann noch was von 1,4Mio IOPS zu erzählen. wirklich völlig irrer Thread hier. Ich sollte es auch Screenshoten und bei Reddit posten, zum kaputtlachen.

Na ja, zum Kaputtlachen ist genaugenommen die Tatsache, dass du noch nach wie vor an deinem DCB fest halten tust, obwohl der TO seine Switch-Architektur schon sehr genau beschrieben hat und sich bereits daraus ableiten lässt, dass es mit RoCE/DCB nichts werden kann. 🙃

Ich würde mir Gedanken machen, dass ein Kunde hier mit liest. Das Verhalten ist Treu und Glauben zu wieder.

Ähm, um genau zu sein benchmarken wir so gut wie jedes System welches wir ausliefern, damit auch sichergestellt ist, dass der Kunde die Leistung bekommt, die die Hersteller versprechen und er am Ende des Tages auch bezahlt.

NVIDIA L40S - Die erste Erfahrung ist etwas bescheiden

Und hin und wieder messen wir auch mal nach, da sich die Performance vor allem nach Updates, auch mal negativ verändern kann. 😉

Gruss Alex

Die vSAN Speicherrichtlinien sind die vorgegebenen vSAN-Cluster - Optimal Datastore Default Policy - RAID5.
Da das Thema HCIBench angesprochen wurde, hier 4 PDFs mit Tests. Getestet wurde mit der aktuellen HCIBench Version und Eaysrun / FIO Benchmark. Hier kann man leider keine PDFs hochladen.

https://drive.google.com/file/d/1KcOH40Q6XybUFtKzPpKD-LAZPZQloZFk/view?u ...
https://drive.google.com/file/d/1w36sYSyBHrvR59VEcd3FNuJU3HrZozj6/view?u ...
https://drive.google.com/file/d/1kZ7w5bhyx6p8-UllrFuthTQknBXIp7Ck/view?u ...
https://drive.google.com/file/d/1g277iJdc6REGgNz3Ude-mHy0TyP0Tlaf/view?u ...

Zum Thema HPE Aruba Switches, das sollte eher als Test dazu dienen ob der Unifi Switch nicht evtl. einen weg hat. Denn seit heute Nacht erkennt er die Unifi 25GB SFP+ DAC nicht mehr auf den 25Gbit Ports, warum auch immer...
Das vSAN macht grad noch eine Neusynchronisieren von Objekten weshalb ich die Hosts heute Nacht mal in den Wartungsmodus versetze und den Switch mal neu starte?

Moin @Trinatrium,

https://core.vmware.com/resource/vsan-proof-concept-vsan-performance-tes ... Hier geht es darum, warum die ATTO-BM keine Aussagekraft hat.

na ja, wenn man an den Anforderungen der Kunden ständig dran vorbei entwickelt und oder ums Verrecken irgendeinen Krampf verkaufen möchte, respektive muss, um z.B. die Rendite der Anleger so hoch wie möglich zu bekommen, dann kann das schon sein, dass solche Dinge wie ATTO-BM, bei einem Storage keine Relevanz haben.

Aber, wenn man den Markt kennt und auch weiss, dass bei der Mehrheit der am Markt befindlichen Business-Anwendungen, für deren Performance nicht die maximale IO-Leistung des Storages entscheidend ist, die die jeweiligen Systeme meist erst durch eine Last von hunderten Workers/Threads erreichen, sondern eher die Single Worker/Thread Leistung und vor allem auch eine geringe Latenz, dann kommt man eigentlich auch ganz gut mit dem ATTO-BM zurecht, vor allem da dieser relativ schnell und simpel ist.

Denn der ATTO-BM macht einen sequentiellen Schreib.- und Lesetest mit nur einem Worker und der entsprechenden Warteschlangentiefe (Queue Depth/Default 4) die eingestellt wurde über eine Dateigösse von 256 MB mit einer Blockgrösse von 512 Bytes bis 256 Mbytes.
Genau dieselben Test-Patterns kann man übrigens auch mit z.B. IOmeter und auch diskspd durchmessen, was jedoch deutlich aufwendiger ist, als mit dem ATTO-BM.

Und wenn der ATTO-BM, sprich, ein Single-Worker-Benchmark schon derart „abkackt“, dann kann man sich die Mühen mit einem umfangreicheren und meist auch viel komplizierteren Benchmark, eigentlich auch gleich sparen.

Ähm, ja, da du ja zu sehr auf die 1,4 Millionen IO’s fixiert bist … hast du auch schon gesehen, mit welcher durchschnittlichen Latenz die Unit das packt? 🤨
Wenn nein, dann schau mal genauer hin, den das ist eigentlich das viel Entscheidendere. 😉

Und wie du bei dem anderen Beitrag siehst, ist ATTO auch nicht unbedingt unsere erste Wahl, weil er eben nur sequentiell und nur einem Worker messen kann. Damit der TO jedoch seine Messungen auch mal mit der Performance eines richtigen SANs vergleichen kann, habe ich der Einfachheit halber eben auch den ATTO-BM mal über eins durchflitzen lassen.

Ich konnte ja nicht ahnen, dass du wegen einer solchen Banalität, gleich einen Herzkasper bekommst. 🙃

Gruss Alex

Moin @haudegen93,

na ja und welcher Workload bindet bei dir gleichzeitig 16 VM's und erzeugt auf diesen auch gleichzeitig eine Storage-Last mit einer Warteschlangentiefe von 512 oI/Os bei 4K, oder 432 oI/Os bei 8K, oder 128 oI/Os bei 256K?

Sprich, wenn vSAN technisch bei dir alles OK währe, da sollte auch der ATTO-BM's deutlich bessere Ergebnisse liefern.

Zum Thema HPE Aruba Switches, das sollte eher als Test dazu dienen ob der Unifi Switch nicht evtl. einen weg hat. Denn seit heute Nacht erkennt er die Unifi 25GB SFP+ DAC nicht mehr auf den 25Gbit Ports, warum auch immer...

Einen Hardware-Defekt kann hier natürlich auch eine Rolle spielen.
Ich denke jedoch, dass sich der Switch wegen was ganz anderem "weggeschossen" hat und zwar eher wegen "Bufferoverflows".

Um das zu vermeiden, solltest du wie schon angesprochen, wenigstens auf den 25G Ports des Switches worüber momentan das vSAN läuft, unbedingt Flow-Control aktivieren.

https://docs.vmware.com/en/VMware-vSphere/8.0/vsan-network-design-guide/ ...
😉

Gruss Alex

Einen Hardware-Defekt kann hier natürlich auch eine Rolle spielen.
Ich denke jedoch, dass sich der Switch wegen was ganz anderem "weggeschossen" hat und zwar eher wegen "Bufferoverflows".

Um das zu vermeiden, solltest du wie schon angesprochen, wenigstens auf den 25G Ports des Switches worüber momentan das vSAN läuft, unbedingt Flow-Control aktivieren.

Hab grad aktuell n ganz anderes Problem :D
Heut morgen meinte die Verbindung der 25Gbit Ports mir nichts dir nichts abzureißen, sodass dass vSAN erstmal natürlich eskalierte und jetzt nen Sync angestoßen hat oO - wäre nicht das Problem, müsste ich nicht auf 10Gbit ausweichen und jetzt läuft alles noch langsamer - Kaum nutzbar
und das, obwohl ich schon den sync auf 1mb je host begrenzt habe (was ja fast n witz ist)
Die DAC von den Host zum Switch funktionieren im 10GBit Port, aber nicht im 25GBit Port - komisch.
via esxcli vsan resync throttle set --level=1

Moin @haudegen93,

na ja, in dem einen oder anderen Punkt hat Trinatrium nicht ganz unrecht, vor allem bei dem, was den Support deiner Konfiguration angeht, den diese ist so nicht wirklich empfohlen.

Denn wenn man ein vSAN, auch beim Hyper-V, korrekt implementieren möchte, dann sollte die Netzwerkanbindung +- folgend aussehen.
(One Site)

Und zwar um genau das zu vermeiden, was bei dir aktuell passiert ist. 😔

müsste ich nicht auf 10Gbit ausweichen und jetzt läuft alles noch langsamer - Kaum nutzbar

Ist das ein ESA vSAN?

Wenn ja, dann benötigst du dafür laut VMware schon mindestens 25G.
https://docs.vmware.com/en/VMware-vSphere/8.0/vsan-planning/GUID-AFF133B ...

und das, obwohl ich schon den sync auf 1mb je host begrenzt habe (was ja fast n witz ist)

Dadurch zögerst du nur den Sync heraus und solange das vSAN nicht synchronisiert ist, kriecht es eben noch langsamer durch die Gegend rum, vor allem dann, wenn es noch über einen langsameren Uplink läuft.

Die DAC von den Host zum Switch funktionieren im 10GBit Port, aber nicht im 25GBit Port - komisch.

Hast du den Switch schon rebootet?
Bitte nicht vergessen Flow-Control bei dieser Gelegenheit zu aktivieren.

Gruss Alex

Moin @haudegen93,

Und nein nen Supportvertrag an sich haben wir nicht. Wir haben einen Dienstleister der uns dabei n bissl. unterstützt mit vSAN an sich aber auch noch nix groß zu tun hatte.

ähm, nochmals zu dem Punkt.
Habt ihr unbedingt die Hardware so haben wollen oder hat euch euer Dienstleister das so angedreht?

Ich habe mich nun mit der Sache einbisschen genauer befasst und die Lage sieht nicht wirklich gut aus, aber auch noch nicht ganz schlimm. 😔

Denn, entweder ihr bekommt eure Umgebung mit iWARP zum Laufen und dann könnt ihr +- die bisherigen Switche auch weiterhin behalten, ich würde dann jedoch noch mindestens zwei davon anschaffen, damit auch eine "Pfad-Redundanz" hergestellt werden kann.

Oder ihr wechselt die bestehenden Switche gegen welche aus die RoCE offiziell supporten, doch der Spass wird ganz sicher nicht günstig, vor allem wenn man berücksichtigt, das bei 2 Sites und Pfad-Redundanz, mindestens 4 davon fällig sind. 😬
Ich habe mal geschaut ob die "günstigeren" Switch-Anbieter hier etwas passendes im Petto haben, Netgear kann man jedoch gleich knicken und DLINK bietet lediglich die beiden hier an ...
https://www.dlink.com/de/de/products/dxs-3610-layer-3-stackable-10g-mana ...
... die kosten jedoch auch > 10K das Stück.

Oder du holst dir ein anständiges SAN, wie z.B. das folgende hier ...
https://www.infortrend.com/de/products/families/esds/4000u
... und sparst dir das obere Theater und hast zudem dann auch ordentlich bessere Leistung.

Gruss Alex

So um dich der Reihe nach zu beantworten

Groß und teure Anschaffungen stehen so gut wie außer Frage, das bekomme ich nie durch, da die Switches / Server max. n 3/4 Jahr insgesamt alt sind.
Was ich noch durch bekäme und gut verargumentieren kann sind natürlich die Switche für Redundanz. (Wobei die teuren RoCE dabei auch eher raus fallen

Ich habe 4 nutzbare LWL Verbindungen zwischen den beiden Serverräumen (derzeit für die 4x10GBit LAC Links zwischen den beiden Aggregation Pro Switches genutzt)

Das hieße doch ich könnte mir noch 2 Aggregation Pro anschaffen und es folgendermaßen verkabeln.

Svr links
Aggregation Pro 1
Aggregation Pro 2
Host 1
Host 2
USW Pro 1
USW Pro 2
USW Pro 3

Svr rechts
Aggregation Pro 3
Aggregation Pro 4
Host 3
Host 4
USW Pro 4
USW Pro 5

Dann gehts jeweils von Aggregation Pro 1 in 3 und 2 in 4 mit 2x25Gbit LAC
Die Hosts 1 und 2 werden an Aggregation Pro 1 und 2 sowie die Hosts 3 und 4 in Aggregation Pro 3 und 4 mit je 1x 25 Gbit angeschlossen.
Und dann noch von den Aggregation Switches jeweils 1x in jeden Switch oder? Oder habe ich da grade nen Denkfehler.

Ist das ein ESA vSAN?
Wenn ja, dann benötigst du dafür laut VMware schon mindestens 25G.

Das 25Gbit Voraussetzung bei nem 4 Node sind ist mir bewusst. Aber ich wollte jetzt erstmal das Resync abschließen lassen, bevor ich da Hosts / Switches neu starte etc. (von gestern knapp 30TB sind noch 800GB übrig, sollte also heut Abend durch sein) :D

Das diente erstmal dazu, dass die Standorte die paar Stunden arbeiten konnten, am Nachmittag habe ich die Begrenzung raus genommen, wobei im Schnitt statt 1MBps jetzt 9-10 je Host heut nach rum kamen oO

Hast du den Switch schon rebootet?
Bitte nicht vergessen Flow-Control bei dieser Gelegenheit zu aktivieren.

Das haben wir tatsächlich gestern gemacht, erkennen wollte der Switch die DAC in den 25Gbit Ports jedoch trotzdem nicht. Aber da teste ich in Ruhe durch wenn der Resync durch ist und man in Ruhe mal kurz alles aus machen kann.
Flow Control lässt sich leider nur Netzwerkseitig, statt Portseitig einschalten. Aber das mach ich nachher dann auch an.

ähm, nochmals zu dem Punkt.
Habt ihr unbedingt die Hardware so haben wollen oder hat euch euer Dienstleister das so angedreht?

vSAN und die Hosts an sich kamen von uns die Idee. Wir hatten halt vorher 2 von den oben genannten Huawei Hosts mit nem Huawei SAN, was mehr schlecht als recht lief und der SAN sogar noch Vendor locked war, sodass das vSAN alles in allem auf dem Papier zu gut klang. - Im nachhinein denk ich mir, man hätte einfach iwie nen ThinkSystem DE4000F dazu bestellt und weniger Kopfschmerzen gehabt.

Denn, entweder ihr bekommt eure Umgebung mit iWARP zum Laufen und dann könnt ihr +- die bisherigen Switche auch weiterhin behalten, ich würde dann jedoch noch mindestens zwei davon anschaffen, damit auch eine "Pfad-Redundanz" hergestellt werden kann.

Das mit iWARP schaue ich auch gleich zwecks Firmware Updates etc.

Oder du holst dir ein anständiges SAN, wie z.B. das folgende hier ...
https://www.infortrend.com/de/products/families/esds/4000u
... und sparst dir das obere Theater und hast zudem dann auch ordentlich bessere Leistung.

Jetzt nochmal zusätzlich nen neues SAN, vor allem inkl. Speicher weil: "Supported Drives
2.5” U.2 NVMe SSD (must be purchased from Infortrend)"
Das bekomme ich niemals durch.

Zwei weitere Switches für die Redundanz bekomm ich noch durch und dann würde mir halt auch schon ne adäquate Leistung die annähernd an die Anbindung kommt schon reichen.

Wir hatten halt vorher 2 von den oben genannten Huawei Hosts mit nem Huawei SAN, was mehr schlecht als recht lief und der SAN

Wer hat euch denn damals das Equipment verkauft?
Ihr selbst werdet es vermutlich nicht direkt von Huawei bezogen haben, da die nur ChannelPartner Sales machen.
Wenn da ein vernünftiger Partner zwischen hängt, hätte er euch hier zweifelsfrei unterstützen können. Und zwar soweit, dass ihr bei bestehender Maintenance direkt auf das EntwicklerTeam bei Huawei zugreifen könnt, wenn die vorderste Front von Huawei nicht helfen kann.

Und nein nen Supportvertrag an sich haben wir nicht. Wir haben einen Dienstleister der uns dabei n bissl. unterstützt mit vSAN an sich aber auch noch nix groß zu tun hatte.

Das heißt, ihr habt keine VMware Subscription?
Was macht ihr, wenn euch da was um die Ohren fliegt und euer DL auch nicht weiter weiß?
Bei uns kam es vor zwei oder drei Jahren mal vor, dass das vCenter nicht mehr hoch kam. Mit unserem Partner 3h rumgedoktert (ja, die sind fit in VMware). Am Ende hat es der Support in 10 Minuten gelöst. Die Startreihenfolge der Dienste passte nicht ganz…

=> zieh VMware hinzu und lass die deine Probleme lösen. Mein Tipp

Wer hat euch denn damals das Equipment verkauft?

Das weiß ich leider nicht, das war lange vor meiner Zeit

Das heißt, ihr habt keine VMware Subscription?

Bis jetzt nicht, vor der vSAN Geschichte hat sich der DL bei Problemen um das vCenter und die ESXI gekümmert.

Aber er hat uns angeraten, ob wir nicht ne Subscription für den Fall der Fälle abschließen wollen / sollten.
Das ist aber wohl untergegangen, da werde ich aber Montag nochmal nach haken was da jetzt ist.

Kurzes Update,
Der Resync ist durch, Flow Control aktiviert und NIC Firmware aktuell.
Zwecks der 25Gbit DAC fahre ich morgen nochmal in die Firma und schaue mir das an.

Auch mit Firmware Update bekomme ich nur folgende Meldung:

Der Link: https://docs.vmware.com/de/VMware-vSphere/8.0/vsphere-networking/GUID-48 ... führt mich dann auf eine Hilfeseite wo steht, ESXI erkennt automatisch, dass ein RDMA fähiger NIC installiert ist...

Komisch finde ich, dass ich in dem VMware Compatibility Guide für ESXI 8 nur folgendes finde:
https://www.vmware.com/resources/compatibility/detail.php?deviceCategory ...
und dort nichts von RDMA oder RoCEv2 steht.

In dem Datenblatt https://www.intel.de/content/www/de/de/products/sku/184820/intel-etherne ... steht aber, dass das alles unterstützt würde.

Moin @haudegen93,

Groß und teure Anschaffungen stehen so gut wie außer Frage, das bekomme ich nie durch, da die Switches / Server max. n 3/4 Jahr insgesamt alt sind.

das habe ich mir schon halber so gedacht. 🙃

Was ich noch durch bekäme und gut verargumentieren kann sind natürlich die Switche für Redundanz.

👍

(Wobei die teuren RoCE dabei auch eher raus fallen

Für die 40K die die Switche mindestens kosten, kannst du dir auch gleich ein SAN kaufen.

Also +- so ...

... ja, das erschein mir momentan auch am Sinnvollsten.

Und dann noch von den Aggregation Switches jeweils 1x in jeden Switch oder? Oder habe ich da grade nen Denkfehler.

😬 ... das eher nicht, denn so wie oben Abgebildet, sind das zunächst mal zwei getrennte Strecken, sprich zwei eigenständige Sync-Verbindungen mit je einem eigenen IP-Bereich.

Sprich, das Frontend für die VM's, läuft dann entweder über die eine oder andere Strecke, aber nicht über beide.

Das würde zwar auch funktionieren, dann müsste man die 4 Main-Switche aber noch über Kreuz miteinander, verkabeln und sich auch mit STP & Co beschäftigen, was die Sache um einiges komplizierter macht und denn Nachteil mit sich bringt, dass die Site to Site Strecken, "nur" mit 25G ...

... anstelle von 50G laufen. Und ob man die untere Konfiguration so mit diesen Switchen auch umsetzten kann, wage ich mal zu bezweifeln, die obere geht auf jeden Fall.

Also ESA. 🙃
Willst du die Umgebung später eigentlich als richtiges "Stretched Cluster" betreiben?

Wenn ja, dann bitte berücksichtigen, dass dafür die Anforderungen nochmals um einiges höher sind als nur bei einem One-Site vSAN.

https://core.vmware.com/api/checkuseraccess?referer=/sites/default/files ...

Bitte berücksichtigen, dass die 4 SFP28 Ports deiner Switche, entweder alle mit 25G laufen müssen oder mit 1/10G.

Sprich, die E810er, dürfen ihre Geschwindigkeit auf keinen Fall z.B. von 25G auf 10G "drosseln".

Flow Control lässt sich leider nur Netzwerkseitig, statt Portseitig einschalten. Aber das mach ich nachher dann auch an.

👍👍👍

Jetzt nochmal zusätzlich nen neues SAN, vor allem inkl. Speicher weil: "Supported Drives
2.5” U.2 NVMe SSD (must be purchased from Infortrend)"

Ja das mit "must be purchased from Infortrend" ist bei den U.2 Units schon richtig, bei allen anderen Units kann man nach HQL auch selber bestücken. Aber, der Aufpreis den Infortrend im Vergleich zu der eigenen Beschaffung für die SSD verlangt, ist sehr sehr überschaubar und ist absolut kein Vergleich zu HPE, DELL & Co.

Das bekomme ich niemals durch.

Das hat mir meine Kristallkugel so auch schon zugeflüstert.
Daher versuche ich primär ja auch das Beste aus deiner jetzigen Umgebung herauszukratzen. 😉

Zwei weitere Switches für die Redundanz bekomm ich noch durch und dann würde mir halt auch schon ne adäquate Leistung die annähernd an die Anbindung kommt schon reichen.

Pack am Besten noch einen dritten dazu, quasi als "Cold-Standby", dann hast du sofort auch Ersatz wenn was passiert.

Gruss Alex

Moin @haudegen93,

Kurzes Update,
Der Resync ist durch, Flow Control aktiviert und NIC Firmware aktuell.

👍

Zwecks der 25Gbit DAC fahre ich morgen nochmal in die Firma und schaue mir das an.

Siehe Bemerkung in meinem vorherigen Post. 😉😉

Auch mit Firmware Update bekomme ich nur folgende Meldung:

Ist den Global SR-IOV im BIOS des Mainboards der Server aktiviert?

Des weiteren muss man eventuell bei den E810 auch noch im BIOS der NIC's das SR-IOV aktivieren.
Bei den X7xx war das noch nicht notwendig, eine E810 hatte ich jedoch noch nicht.

Das ist nur die Doku für RoCE.

Komisch finde ich, dass ich in dem VMware Compatibility Guide für ESXI 8 nur folgendes finde:
https://www.vmware.com/resources/compatibility/detail.php?deviceCategory ...
und dort nichts von RDMA oder RoCEv2 steht.

In dem Datenblatt https://www.intel.de/content/www/de/de/products/sku/184820/intel-etherne ... steht aber, dass das alles unterstützt würde.

Das steht doch SR-IOV und wie ich schon mehrfach geschrieben habe, steht SR-IOV, sowohl für RoCE, als auch für iWARP und auch bei DCB wird SR-IOV verwendet. 🙃

Jedoch finde ich genau so wie du, ausser dem oberen Hinweis, ansonsten überhaupt keine Dokus, in denen eine explizite iWARP Konfiguration beschrieben wird. 😬

Sprich, ich fürchte, die können noch nach wie vor nur RoCE.

Aber ... die E810 kann zum Glück ja auch RoCE und mit aktiviertem Flow-Control und deaktiviertem DCB (da die Switche das nicht supporten), könnte das dennoch funktionieren. 🤪

Gruss Alex

Bzgl. RDMA, RoCE und iWarp (selbst keine Ahnung von der Praxis dahinter, lese aber gespannt mit

), hat VMware hier ein paar mehr Infos:
https://core.vmware.com/resource/basics-remote-direct-memory-access-rdma ...

iWarp sollte also klappen. Recherchiert mal nach vRDMA weiter…
Und auch schauen, ob RDMA überhaupt aktiviert wurde:
https://docs.vmware.com/de/VMware-vSphere/8.0/vsphere-storage/GUID-F4B42 ...

Ist den Global SR-IOV im BIOS des Mainboards der Server aktiviert?

Des weiteren muss man eventuell bei den E810 auch noch im BIOS der NIC's das SR-IOV aktivieren.
Bei den X7xx war das noch nicht notwendig, eine E810 hatte ich jedoch noch nicht.

Das habe ich auch nachgeschaut sowohl im Bios als in der Netzwerkkarte ist SR-IOV an.

Sprich, die E810er, dürfen ihre Geschwindigkeit auf keinen Fall z.B. von 25G auf 10G "drosseln".

In dem Unifi hab ich die Ports auf 25Gbit fest gesetzt und im vSphere dann auch.

Hier ist noch n anderer Eintrag von nem E810er aber andere SID von ESXI 7
https://www.vmware.com/resources/compatibility/detail.php?deviceCategory ...
da steht z.b was von ROcEv2
komisch...

Und auch schauen, ob RDMA überhaupt aktiviert wurde:

Darum gehts ja, lässt sich net aktivieren :D

Welcher Treiber ist geladen:
https://www.vmware.com/resources/compatibility/detail.php?deviceCategory ...

Für die 810er Karten braucht es den irdman driver

Moin @haudegen93,

Und auch schauen, ob RDMA überhaupt aktiviert wurde:

Darum gehts ja, lässt sich net aktivieren :D

dank des Hinweises von @em-pie, bekommen wir den Wurm glaube ich so langsam raus.

Denn bei VMware heisst RoCE auch "NVMe over RDMA" und iWARP heisst "NVMe over TCP". 🙃
Dabei steht RDMA sowohl für RoCE als auch für iWARP, was für ein Krampf. 😖

Na ja, VMware eben, sprich, kein Plan vom wahren Leben und jetzt erst recht als Broadcom. 🤪
(Sorry, aber der musste jetzt irgendwie raus.)

Und mit diesem "wirren" Wissen habe ich dann auch recht schnell das folgende gefunden.
https://docs.vmware.com/de/VMware-vSphere/8.0/vsphere-storage/GUID-5F776 ...
😉

Gruss Alex

Zitat von @haudegen93:
Hier ist noch n anderer Eintrag von nem E810er aber andere SID von ESXI 7
https://www.vmware.com/resources/compatibility/detail.php?deviceCategory ...
da steht z.b was von ROcEv2
komisch...

Schaue dir den Link hier an:
https://www.vmware.com/resources/compatibility/detail.php?deviceCategory ...

Für die 810er Karten braucht es den irdman driver

In dem Zusammenhang bitte unbedingt das folgende beachten!

https://knowledge.broadcom.com/external/article/313796/enabling-and-disa ...

Installiert ist icen 1.5.2.12

Und mit diesem "wirren" Wissen habe ich dann auch recht schnell das folgende gefunden.
https://docs.vmware.com/de/VMware-vSphere/8.0/vsphere-storage/GUID-5F776 ...
😉

Also hieße das, ich weise dem vsan vmkernel noch nvme over tcp zu bzw. erstelle einfach noch nen zusätzlichen vmnic?

Bzw. erstmal die icen und irdman treiber wie in https://knowledge.broadcom.com/external/article/313796/enabling-and-disa ... angezeigt installieren?

Na ja, VMware eben, sprich, kein Plan vom wahren Leben und jetzt erst recht als Broadcom. 🤪
(Sorry, aber der musste jetzt irgendwie raus.)

Ganz ehrlich, durch die neue Lizensierung seitens Broadcom.. da tut es auch eig Hyper V - und das was ich in Kombination mit Storage Spaces Direct gelesen hab.... - naja jetzt ist egal, jetzt ist jetzt :D

Btw. hab grad mal auf unseren Veeam Server geschaut - da gehen knapp 6-7 Gbit grad rein (laut Task Manager) von vSAN Richtung Veeam (physische Maschine)

Schaue dir den Link hier an:
https://www.vmware.com/resources/compatibility/detail.php?deviceCategory ...

Jedoch steht da nur Firmware 4.1 und 4.2 - ich hatte vorher 4.3 jetzt 4.5 auf den NICs - hmm

Hab grad mal geschaut.
In dem Addon Pack Lenovo Customization Addon for Lenovo ThinkSystem LVO.803.12.1 sollen die irdman 1.4.4 Treiber enthalten sein.

Dann müsste ich doch eig nur die Firmware über die Lenovo Firmware mit dem Addon Pack aktualisieren oder?

Links derzeit, rechts Update

Moin @haudegen93,

Also hieße das, ich weise dem vsan vmkernel noch nvme over tcp zu bzw. erstelle einfach noch nen zusätzlichen vmnic?

du solltest unbedingt zuerst die Firmware/BIOS aktualisieren, danach die Treiber und dann die Konfiguration in VMware wie hier beschrieben ...
https://docs.vmware.com/de/VMware-vSphere/8.0/vsphere-storage/GUID-5F776 ...
... vornehmen.

Und sorry, dass ich dir hier nicht detaillierter helfen kann. Das ganze ist für mich jedoch bei VMware ein absolutes Trockenschwimmen, da ich schon seit Jahren nur noch Hyper-V mache.

Ja, mit S2D könntest du dasselbe nachbauen und ich meine sprichwörtlich dasselbe, sprich, mit denselben Nachteilen. 😔

Schaue dir den Link hier an:
https://www.vmware.com/resources/compatibility/detail.php?deviceCategory ...

Jedoch steht da nur Firmware 4.1 und 4.2 - ich hatte vorher 4.3 jetzt 4.5 auf den NICs - hmm

Eine höhere Firmware ist meistens nicht schlimm, eine niedrigere hingegen schon.

Gruss Alex

Moin @haudegen93,

die folgende Doku ist meiner Ansicht nach auch ganz interessant.

https://core.vmware.com/api/checkuseraccess?referer=/sites/default/files ...

Gruss Alex

Jedoch steht da nur Firmware 4.1 und 4.2 - ich hatte vorher 4.3 jetzt 4.5 auf den NICs - hmm

Wie hattest du eigentlich die Lenovos aktualisiert? Per Bootable Media Creator (meine erste Wahl, bei 3 Systemen aber auch OK) oder per XClarity Administrator?
Oder über den XClarity Controller im Host und einer manuell heruntergeladenen Intel Firmware (wäre die ungünstigste Variante).

Ob/ wie die Reihenfolge der Updates für die NIC Firmware und ESXi Treiber aussieht, kann ich dir leider auch nicht sagen. Bin dann zu weit weg.
Wir packen halt immer direkt die ESXi-OEM-Version drauf, ziehen vorher den Server selbst per BoMC hoch und haben im Unterbau ein IBM SAN im HA laufen… bin daher, was vSAN angeht, raus

Wie hattest du eigentlich die Lenovos aktualisiert? Per Bootable Media Creator (meine erste Wahl, bei 3 Systemen >aber auch OK) oder per XClarity Administrator?
Oder über den XClarity Controller im Host und einer manuell heruntergeladenen Intel Firmware (wäre die >ungünstigste Variante).

Über die von der Lenovo Seite für unseren Server heruntergeladene Firmware und dann im XClarity Controller unter Repository eingespielt.

Für nächstes WE ist mit dem uns betreuenden DL geplant, die Hosts auf 8.3b zu upgraden und in dem Zuge die Treiber über das LVO Pack mit einzuspielen.

Moin @haudegen93,

Für nächstes WE ist mit dem uns betreuenden DL geplant, die Hosts auf 8.3b zu upgraden und in dem Zuge die Treiber über das LVO Pack mit einzuspielen.

👍

wie ist eigentlich aktuell die Lage?
Laufen die 25G Links wieder mit 25G?

Wenn ja, kannst du dann bitte den ATTO-DB nochmals auf dem vSAN laufen lassen,
um zu sehen was das Folw-Control bereits bewirk, danke.

Gruss Alex

P.S.
So lange unterstützt VMware RDMA beim vSAN ja auch noch gar nicht. 🙃
https://blogs.vmware.com/virtualblocks/2021/03/24/vsan-7-update-2-rdma/

P.S.P.S.
Microsoft war übrigens schon 5 Jahre vor VMware "RDMA Ready". 😄
https://techcommunity.microsoft.com/t5/networking-blog/the-evolution-of- ...

wie ist eigentlich aktuell die Lage?
Laufen die 25G Links wieder mit 25G?

War ganz chaotisch gestern :D - DAC angeschlossen, schienen nen Link zu haben.
Ok aufs vcenter gegangen um zu schauen und gesehen, waren erstmal Meldungen wegen HA Verfügbarkeit etc.
Da ich die Switche etc. eh alle einmal neu starten wollte, habe ich das Cluster heruntergefahren wie hier beschrieben.
https://docs.vmware.com/de/VMware-vSphere/7.0/com.vmware.vsphere.vsan-mo ...
Herunterfahren lief.

Switche neugestartet.

Cluster wieder hoch gefahren und dann hatte ich den Salat... vSAN war tot... :D

Bis ich dann nach iwie 2-3h endlich die Lösung in folgender KB fand: https://knowledge.broadcom.com/external/article/326833/inaccessible-obje ...

Das war Aufregung genug gestern

In der Zwischenzeit hatte der Link der DAC sich aber iwie wieder verabschiedet, sodass das Cluster aktuell weiter mit 10Gbit läuft und wir beschlossen haben nochmal nachzuordern und auf sfp Module zu setzen.

Von oben gabs jetzt das OK für 2 weitere Aggregation Pro inkl. nötiger SFP Module und LWL Kabel

Wenn ja, kannst du dann bitte den ATTO-DB nochmals auf dem vSAN laufen lassen,
um zu sehen was das Folw-Control bereits bewirk, danke.

Zwar nicht mit 25Gbit Link sondern nur 10Gbit. Dafür ist der Unterschied zu vorher iwie sehr gering.

Moin @haudegen93,

Das war Aufregung genug gestern

mit einem SAN wäre das so nicht passiert.
Auf der anderen Seite hättest du dann auch mindestens ein Abenteuer weniger auf dem Kerbholz. 😁
Sprich, wie heisst es so schön, "Was uns nicht tötet, härtet uns ab!". 🤪

🤔 ... das kling mir irgendwie nach Link-Speed Aushandlungsfehlern zwischen NIC und Switch.
Ich würde hier sowohl auf der Swich-Seite als auch auf der NIC Seite, als nächstes den Link-Speed mal fix auf 25G stellen.

Von oben gabs jetzt das OK für 2 weitere Aggregation Pro inkl. nötiger SFP Module und LWL Kabel

👍👍👍

Wenn ja, kannst du dann bitte den ATTO-DB nochmals auf dem vSAN laufen lassen,
um zu sehen was das Folw-Control bereits bewirk, danke.

Zwar nicht mit 25Gbit Link sondern nur 10Gbit. Dafür ist der Unterschied zu vorher iwie sehr gering.

Na ja, mit 10G anstatt 25G und ohne RDMA, kann Flow-Control auch nicht viel ausrichten. 😔
Und ganz so nichtssagend ist die Messung ja auch nicht, denn man sieht schon sehr deutlich, das das vSAN mit 10G, deulich langsamer läuft als unter 25G.

Ähm, besonders 😖 finde ich übrigens den Effekt, dass dein vSAN so ab einer Blockgrösse von 1 bis 2MB, auf einmal zum Teil extrem viel schneller Schreiben wie Lesen kann. 🙃

Gruss Alex

... das kling mir irgendwie nach Link-Speed Aushandlungsfehlern zwischen NIC und Switch.
Ich würde hier sowohl auf der Swich-Seite als auch auf der NIC Seite, als nächstes den Link-Speed mal fix auf 25G >stellen.

Das habe ich damals schon als erstes gemacht, also Link Speed stand auf beiden Seiten auf 25Gbit eingestellt.

Moin @haudegen93,

Das habe ich damals schon als erstes gemacht, also Link Speed stand auf beiden Seiten auf 25Gbit eingestellt.

wie lange sind den die DAC's?

Gruss Alex

wie lange sind den die DAC's?

5 Meter

Genau genommen waren es folgende DAC:
5m UC-DAC-SFP28 also die von Ubiquiti selber.

Aber wie gesagt die DACs werden jetzt eh durch Module ersetzt.

Update:
Die Updates und Treiberinstallationen sind durch.
RDMA ließ sich auch aktivieren.
Unterschied bisher aber 0, noch immer langsam.

Hier auch noch einmal ein direkter Vergleich mit Crystaldiskmark.
Und anbei das Datenblatt der SSD: https://download.semiconductor.samsung.com/resources/white-paper/PM1743_ ...
Ich weiß net ob es einen Unterschied macht, aber wir haben die Read Intensive Version der SSD.
Settings: NVME SSD
Profil: Real World Performance + Mix

Lokale SSD

vSAN

Ok das verwirrt mich jetzt noch mehr,
meine eigene Samsung 980 (non Pro) 1TB (pcie gen 3 x4 ssd) kommt auf folgende Werte:
Wie kann die denn bitte bis auf die Sequentielle R/W Rate in allem anderen schneller sein, als die lokale einzelne PM1743?

Moin...

also wenn du PM1743 NVMes hast, frage ich mich grade wo du die NVMe eingebaut hast für dein vSAN?!?!
kann das Gerät den PCI5?... wenn ich die Leistung so sehe, würde ich sagen PCI3.

Frank

Die PM1743 sind in den Lenovo Servern in den Drive Bays vorne verbaut.
Und wenn Lenovo mit Gen5 wirbt etc. gehe ich mal davon aus, dass auch Gen5 unterstützt wird.

Anzumerken sei, der Test mit der einzelnen PM1743 - da läuft auch das ESXI des entsprechenden Hosts drauf, wobei das jetzt kein großen Impact auf die Leistung haben sollte.

Zumal das erstmal nur als Vergleichspunkt zum vSAN dienen soll, denn hauptsächlich geht es ums vSAN was unterirdisch performt.

Zitat von @haudegen93:

Die PM1743 sind in den Lenovo Servern in den Drive Bays vorne verbaut.
Und wenn Lenovo mit Gen5 wirbt etc. gehe ich mal davon aus, dass auch Gen5 unterstützt wird.

hm... das tue ich nicht!

Anzumerken sei, der Test mit der einzelnen PM1743 - da läuft auch das ESXI des entsprechenden Hosts drauf, wobei das jetzt kein großen Impact auf die Leistung haben sollte.

Zumal das erstmal nur als Vergleichspunkt zum vSAN dienen soll, denn hauptsächlich geht es ums vSAN was unterirdisch performt.

ja.. aber selbst deine Lokale SSD macht nur eine schlechte Gen4 leistung! da sollte etwa 7300 Mbps stehen!
da ist irgendwas nicht ok mit deiner Hardware.

Frank

Die sind via PCIe 5.0 x4 angeschlossen. So gibt es zumindest das Bios aus.
Und soweit ich das erkennen kann, ist auch kein HBA oder Raid Controller dazwischen.
Auch der Anleitung von Lenovo zu entnehmen: https://pubs.lenovo.com/sr650-v3/cabling_12nvme_g5

Moin @haudegen93,

die lokale SSD ist schon etwas lahm. 😬
Wir haben in den letzten Wochen vier Server mit je einer PM9A3 als Boot-SSD ausgeliefert und die waren deutlich/mehrfach schneller als die Samsungs von dir. 🤔

Wie sieht den genau die RAM Bestückung dieses Systems aus und kannst du auch mal schauen, ob im BIOS der Server Sub-NUMA-Clustering aktiviert ist?

Wenn aktiviert und deine RAM-Bänke sind nicht entweder halb oder ganz voll, dann deaktiviere bitte SNC.

Gruss Alex

Hmm entweder bin ich zu doof, oder im bios steht nichts zu snc.
PS: Die Ram Bänke sind voll bestückt - 32x64GB (2Rx4) 10x4 RDIMM

2024-10-14 10_55_02-esxi-01 - lenovo xclarity controller 2 und 57 weitere seiten - persönlich – micr

Moin...

also wenn du schon lokal nicht auf 7K kommst hast du ein Hardware problem !
du kannst ja mal mit 128 GB ram testen und nur einer Samsung NVMe!
oder dein Blech kann kein PCIe5
Frank

Moin @haudegen93,

Hmm entweder bin ich zu doof, oder im bios steht nichts zu snc.
PS: Die Ram Bänke sind voll bestückt - 32x64GB (2Rx4) 10x4 RDIMM

wenn ich das richtig verstehe, dann ist diese Option bei dir aktiviert und zwar ist das "Socket Interleave".
Da du aber alle RAM Bänke voll hast, sollte das eigentlich keinen negativen Effekt haben, sondern eher einen positiven.

Ich mache bei solchen Dingen immer vor einer Änderung einen Performancetest z.B. mit PassMark PerformanceTest und dann nochmals nach der Änderung und dann sieht man eigentlich gleich, ob die Anpassung etwas gebracht hat.

By the Way, schau dir mal die folgende Doku an ...

https://lenovopress.lenovo.com/lp1836-tuning-uefi-settings-4th-gen-intel ...

... und stelle bitte alles so ein wie für "Maximum Performance" empfohlen wird.

Hast du im ESXi die Energieoptionen auch schon auf "Hochleistung" gesetzt?

Gruss Alex

German solved Question VMware Windows Server Virtualization

Hotly discussed

Web server tuning: display WebP images directly in the browserFrank

Intel Screwed Up Again: Core Ultra 200SFrank