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...
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
Moin,
Was ja noch nicht aus deinem vorherigen Post hervorgeht:
Und wie habt ihr die VMs migriert? die neuen Hosts ins vCenter eingebunden und dann rüber?
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?
Moin @haudegen93,
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
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...
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,
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
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
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:
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
es hing tatsächlich mit Bios Einstellungen zusammen.
Jetzt läuft alles wie erwartet
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
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. 😔
Oh, E810, lecker, die haben ordentlich Bums und auch ordentlich Ressourcen für Virtualisierung. 😁
Die Intel X7xx sind auch nicht schlecht, auf jeden Fall um Welten besser als 10G NIC's von Broadcom.
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. 😉
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. 😔
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
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. 😉
Eher einen positiven.
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.
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. 🙃
Glaub mir, ich kann ganz viele solcher Lieder mittlerweile singen.
Folgend eines der letzten ...
NVIDIA L40S - Die erste Erfahrung ist etwas bescheiden
😔
Ä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
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
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
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.)
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,
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. 😉
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
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?
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,
ja, bisher sogar nur die Samtpfote. 😁
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. 🤪
Jup, so ist das bei manchem Wissen auch und irgendwann wirst du das warum dahinter, vielleicht auch mal verstehen.
Natürlich, deshalb sind auch 133 meiner Kommentare, bereits als Lösung getagt. 🙃
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.
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.
Was soll den nun das Image damit zu tun haben?
Gruss Alex
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?
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,
😧 ... 😭 ... ja, das sieht schon etwas gruselig aus. 😬
Hast du denn wie bereits angesprochen, das LRO/GRO schon hostseitig deaktiviert?
Gruss Alex
😧 ... 😭 ... 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.
Was soll den nun das Image damit zu tun haben?
Gruss Alex
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?
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.
Moin @Trinatrium,
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
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. 🙃
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.
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 ...
... 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
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
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
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
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,
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. 🙃
Das sollte man grundsätzlich immer machen.
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 ...
Ich schreib jetzt lieber nicht, was meiner Kristallkugel darauf gerade ausgespuckt hat. 🙃
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
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
Moin @Trinatrium,
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.
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
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.
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
😯 ... 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
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.
@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.
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,
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 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. 😔
👍👍👍
Gruss Alex
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.
😉
😩 ... 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.
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". 🙃
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.
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. 🙃
Ä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
also, bei dem hier ...
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.
@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.
... 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."
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
Moin @Trinatrium,
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
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.
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
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 ...
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 ...
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
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. 😔
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 ...
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.
Hast du den Switch schon rebootet?
Bitte nicht vergessen Flow-Control bei dieser Gelegenheit zu aktivieren.
Gruss Alex
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
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
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,
ä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
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
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
Moin @haudegen93,
das habe ich mir schon halber so gedacht. 🙃
👍
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.
😬 ... 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".
👍👍👍
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 hat mir meine Kristallkugel so auch schon zugeflüstert.
Daher versuche ich primär ja auch das Beste aus deiner jetzigen Umgebung herauszukratzen. 😉
Pack am Besten noch einen dritten dazu, quasi als "Cold-Standby", dann hast du sofort auch Ersatz wenn was passiert.
Gruss Alex
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.
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.
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.
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.
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
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 ...
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.
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)"
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,
👍
Siehe Bemerkung in meinem vorherigen Post. 😉😉
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.
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
Kurzes Update,
Der Resync ist durch, Flow Control aktiviert und NIC Firmware aktuell.
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. 😉😉
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.
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...
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.
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 ...
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 ...
Welcher Treiber ist geladen:
https://www.vmware.com/resources/compatibility/detail.php?deviceCategory ...
Für die 810er Karten braucht es den irdman driver
https://www.vmware.com/resources/compatibility/detail.php?deviceCategory ...
Für die 810er Karten braucht es den irdman driver
Moin @haudegen93,
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
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: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...
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 ...
Moin @haudegen93,
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. 😔
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
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.
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
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 ...
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
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
Moin @haudegen93,
👍
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- ...
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- ...
Moin @haudegen93,
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.
👍👍👍
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 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!". 🤪
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.
🤔 ... 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.
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
Moin @haudegen93,
wie lange sind den die DAC's?
Gruss Alex
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
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!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.
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
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
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
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
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
Moin @haudegen93,
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
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
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