99
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...
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 668459
Url: https://administrator.de/contentid/668459
Ausgedruckt am: 21.11.2024 um 21:11 Uhr
99 Kommentare
Neuester Kommentar
Also bevor es hier gleich völlig wild wird und ganz viele Leute ganz viel Zeugs Posten und Raten...
Was hast du bisher systematisch untersucht und an Beweisen gesammelt?
Was hast du bisher systematisch untersucht und an Beweisen gesammelt?
Moin...
dein ERB ist ein Singel Core Programm, deine alte CPU war im grunde schneller mit 3,2 GHz... die neue CPU ist mit 2,7 GHz. langsamer....
wann und wie lange braucht die neue CPU bis der Turbo auf 3,8 GHz kommt?
da wird der hund begraben liegen....
Frank
dein ERB ist ein Singel Core Programm, deine alte CPU war im grunde schneller mit 3,2 GHz... die neue CPU ist mit 2,7 GHz. langsamer....
wann und wie lange braucht die neue CPU bis der Turbo auf 3,8 GHz kommt?
da wird der hund begraben liegen....
Frank
2
Im Prinzip als allererstes erstmal quer getestet wie im Eingangspost.
Ausserdem, High Performance mode im Bios als auch ESXI eingestellt
Testweise CPU Profil 2 eingestellt (24 statt 32 Kerne aktiv - dafür Basetakt auf 3,0Ghz statt 2,8Ghz)
Eine identisch ausgestattete TestVM mit lokalem Datastore (1x Samsung PM1743 4TB) um VSAN als Ursache auszuschließen.
Und zu guter letzt ein paar Benchmarks gemacht. Und dort ist ersichtlich, dass die CPU irgendwie nicht die Leitung liefert wie erwartet.
Xeon Platinum Profile 2 @3ghz
https://browser.geekbench.com/v6/cpu/8040414
vergleich andere
https://browser.geekbench.com/search?utf8=%E2%9C%93&q=xeon+platinum+ ...
Xeon Gold
https://browser.geekbench.com/v6/cpu/8040417
vergleich andere
https://browser.geekbench.com/search?utf8=%E2%9C%93&q=xeon+gold+6134 ...
27 Punkte Single Thread Unterschied bei iwie 5 CPU Generationen, ich glaube eher nicht.
Ausserdem, High Performance mode im Bios als auch ESXI eingestellt
Testweise CPU Profil 2 eingestellt (24 statt 32 Kerne aktiv - dafür Basetakt auf 3,0Ghz statt 2,8Ghz)
Eine identisch ausgestattete TestVM mit lokalem Datastore (1x Samsung PM1743 4TB) um VSAN als Ursache auszuschließen.
Und zu guter letzt ein paar Benchmarks gemacht. Und dort ist ersichtlich, dass die CPU irgendwie nicht die Leitung liefert wie erwartet.
Xeon Platinum Profile 2 @3ghz
https://browser.geekbench.com/v6/cpu/8040414
vergleich andere
https://browser.geekbench.com/search?utf8=%E2%9C%93&q=xeon+platinum+ ...
Xeon Gold
https://browser.geekbench.com/v6/cpu/8040417
vergleich andere
https://browser.geekbench.com/search?utf8=%E2%9C%93&q=xeon+gold+6134 ...
27 Punkte Single Thread Unterschied bei iwie 5 CPU Generationen, ich glaube eher nicht.
Moin,
Was ja noch nicht aus deinem vorherigen Post hervorgeht:
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?
Alles auf aktuellem Stand
Kerne sind auf 1 Sockel um NUMA möglichst zu vermeiden
Aber ich hab grad mal aus Verzweiflung im Bios auf einem Host testweise alles auf Max gestellt ohne Rücksicht auf Verbrauch und danach die VM auf dem entsprechenden Host getestet - Ergebnisse sahen erstmal gut genug aus, dass ich die anderen 3 Hosts nachziehe und dann nochmal ausgiebig teste.
Kerne sind auf 1 Sockel um NUMA möglichst zu vermeiden
Aber ich hab grad mal aus Verzweiflung im Bios auf einem Host testweise alles auf Max gestellt ohne Rücksicht auf Verbrauch und danach die VM auf dem entsprechenden Host getestet - Ergebnisse sahen erstmal gut genug aus, dass ich die anderen 3 Hosts nachziehe und dann nochmal ausgiebig teste.
Kurzes Update
es hing tatsächlich mit Bios Einstellungen zusammen.
Jetzt läuft alles wie erwartet
es hing tatsächlich mit Bios Einstellungen zusammen.
Jetzt läuft alles wie erwartet
2
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
1
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
1
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
3
Hi ALex,
um deine ganzen Beiträge etwas ausführlicher zu beantworten:
Aktuell sieht die Konfig noch so aus:
Serverraum 1
Unifi Aggregation Pro
4x Lenovo Server jeweils mit 1x 25Gbit und 1x 10Gbit an oben genanntem Unifi Switch angeschlossen
vMotion, vSAN und Bereitstellung laufen auf dem 25Gbit Port, Management Network auf dem 10Gbit Port.
2x USW Pro 48 PoE im Serverraum angeschlossen an oben genanntem Unifi Switch via 10GBit SFP
1x USW Pro 48 PoE in anderem Raum des Gebäudes angeschlossen an oben genanntem Unifi Switch via 10Gbit SFP
Serverraum 2 (gut 300m am anderen Ende des Gebäudes)
Unifi Aggregation Pro - angeschlossen an Aggregation Pro in Serverraum 1 via 4x10Gbit Link Aggregation
1x USW Pro 48 PoE im Serverraum angeschlossen an oben genanntem Unifi Switch via 10Gbit SFP
1x USW Pro 24 PoE in anderem Raum des Gebäudes angeschlossen an oben genanntem Unifi Switch via 10Gbit SFP
Divers verteilt im gesamten Gebäude sind knapp 20 Unifi UAP AC M Pro und U6 Pro
Kurzum, derzeit bis alles vernünftig läuft sind die 4 Server noch in einem Serverraum angeschlossen - später soll aber die Aufteilung 2:2 sein
Also quasi
Unifi Aggregation Pro 4x10Gbit SFP LAG <--> Unifi Aggregation Pro 4x10Gbit SFP LAG
2x Lenovo Server ----- 2x Lenovo Server
je 2x25Gbit SFP für vSAN ----- je 2x25Gbit SFP für vSAN
je 2x10Gbit SFP für Rest ----- je 2x10Gbit SFP für Rest
PS: Die neuen Lenovo Server haben Intel(R) E810-DA4 10/25GbE SFP28 4-port
Der alte Huawei Server hatte ne Intel X722 2x10GBit / 2x GBit Karte verbaut.
Zu dem Thema lags der VMs, das hat sich mit dem Entfernen sämtlicher Energiesparmechanismen (auch in den Vcenter Einstellungen bei den Hosts) deutlich gebessert. Zwar immer noch nicht zu vergleichen mit nem physischen PC wo ich mich via RDP drauf schalte, aber deutlich besser.
um deine ganzen Beiträge etwas ausführlicher zu beantworten:
Aktuell sieht die Konfig noch so aus:
Serverraum 1
Unifi Aggregation Pro
4x Lenovo Server jeweils mit 1x 25Gbit und 1x 10Gbit an oben genanntem Unifi Switch angeschlossen
vMotion, vSAN und Bereitstellung laufen auf dem 25Gbit Port, Management Network auf dem 10Gbit Port.
2x USW Pro 48 PoE im Serverraum angeschlossen an oben genanntem Unifi Switch via 10GBit SFP
1x USW Pro 48 PoE in anderem Raum des Gebäudes angeschlossen an oben genanntem Unifi Switch via 10Gbit SFP
Serverraum 2 (gut 300m am anderen Ende des Gebäudes)
Unifi Aggregation Pro - angeschlossen an Aggregation Pro in Serverraum 1 via 4x10Gbit Link Aggregation
1x USW Pro 48 PoE im Serverraum angeschlossen an oben genanntem Unifi Switch via 10Gbit SFP
1x USW Pro 24 PoE in anderem Raum des Gebäudes angeschlossen an oben genanntem Unifi Switch via 10Gbit SFP
Divers verteilt im gesamten Gebäude sind knapp 20 Unifi UAP AC M Pro und U6 Pro
Kurzum, derzeit bis alles vernünftig läuft sind die 4 Server noch in einem Serverraum angeschlossen - später soll aber die Aufteilung 2:2 sein
Also quasi
Unifi Aggregation Pro 4x10Gbit SFP LAG <--> Unifi Aggregation Pro 4x10Gbit SFP LAG
2x Lenovo Server ----- 2x Lenovo Server
je 2x25Gbit SFP für vSAN ----- je 2x25Gbit SFP für vSAN
je 2x10Gbit SFP für Rest ----- je 2x10Gbit SFP für Rest
PS: Die neuen Lenovo Server haben Intel(R) E810-DA4 10/25GbE SFP28 4-port
Der alte Huawei Server hatte ne Intel X722 2x10GBit / 2x GBit Karte verbaut.
Zu dem Thema lags der VMs, das hat sich mit dem Entfernen sämtlicher Energiesparmechanismen (auch in den Vcenter Einstellungen bei den Hosts) deutlich gebessert. Zwar immer noch nicht zu vergleichen mit nem physischen PC wo ich mich via RDP drauf schalte, aber deutlich besser.
Moin @haudegen93,
danke für die ganzen Infos, deine Hauptprobleme bezüglich der Performance, liegen wahrscheinlich jedoch weniger an den Switchen ... wobei du auf diesen auf jeden Fall FlowControl aktivieren solltest, sondern meiner bisherigen Erfahrung nach eher an den Servern und auch den Einstellungen der NIC's. 😔
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
danke für die ganzen Infos, deine Hauptprobleme bezüglich der Performance, liegen wahrscheinlich jedoch weniger an den Switchen ... wobei du auf diesen auf jeden Fall FlowControl aktivieren solltest, sondern meiner bisherigen Erfahrung nach eher an den Servern und auch den Einstellungen der NIC's. 😔
Flow Control ist tatsächlich aus. Aber macht das überhaupt Sinn? Ich dachte Flow Controll braucht man nur wenn man über unterschiedliche Portbandbreiten geht. Der einzige Traffic ausserhalb der VMs / des Aggregation Switches ist ja nur der RDP Zugriff
Anders gefragt, hätte es einen negativen Effekt das zu aktivieren?
Also Geschwindigkeit zwischen den einzelnen VMS ist bei uns eigentlich das allerwichtigste, da wir zu 99% auf Terminalservern arbeiten
Wobei ich jetzt mal nen einfachen Atto Benchmark einmal VM mit Disk auf vSAN und einmal VM mit Disk auf lokaler einzelnen SSD des Hosts und die einzelne SSD gut doppelt so schnell war oO - da muss ich auch noch nachforschen was da los ist.
Zu dem Thema lags der VMs, das hat sich mit dem Entfernen sämtlicher Energiesparmechanismen (auch in den Vcenter Einstellungen bei den Hosts) deutlich gebessert.
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 habe ich tatsächlich getan, was am Ende auch im Eingang erwähnte Probleme behoben hat.
Geekbench von anfänglich knapp 1050 Pkt Single Thread auf gut 1900 Punkte
Das 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
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
Kleine Info/Frage am Rande, bevor wieder in der Wortklauberei des Fuchsbaus sind: Können die Switches überhaupt DCB?
Ich empfehle weiterhin eine systematische Arbeitsweise, wenn es mit Fachwissen nicht so gut aussieht.
Ich empfehle weiterhin eine systematische Arbeitsweise, wenn es mit Fachwissen nicht so gut aussieht.
Ich empfehle weiterhin eine systematische Arbeitsweise, wenn es mit Fachwissen nicht so gut aussieht.
Mit dem Fachwissen sieht es tatsächlich nicht top aus.
Ist mein erstes mal mit mehreren Hosts und dann noch vSAN.
Die Lösung der oben genannten Lenovo Hosts ist hier seit gut 3 Monaten im Einsatz und die Performance dieser war halt bisher immer unterirdisch bzw. weniger als erwartet, weshalb ich mich hier hin wandte.
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.
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.
Das Software Raid im Vergleich zu Hardware Raid schlechter ist, ist mir bewusst, jedoch sollte doch ein Software Raid nicht so arg schlechter Performen als eine einzelne Platte
Hier mal zwei Beispiele (identisch konfigurierte VMs, einmal mit lokal Datastore SSD und einmal mit vSAN)
lokaler Datastore
vSAN
Aber, bevor du das auf dem produktiven System aktivierst, solltest du dich etwas Detailierter mit dem Thema befassen, den es ist technisch nicht ohne, bringt jedoch wie ich geschrieben habe, zum Teil um Faktoren bessere Leistung.
Ja das würde ich sowieso vorher machen, da dient der alte Huawei Server derzeit ganz gut als Testsystem
Kleine Info/Frage am Rande, bevor wieder in der Wortklauberei des Fuchsbaus sind: Können die Switches überhaupt DCB?
Ich denke nicht, dass die Switches das können.
Was die Optionen angeht, sieht es tatsächlich echt mau aus.
Trotzdem bin ich euch für sämtliche Tipps und Hilfen dankbar
Ich meine das System an sich läuft ja jetzt und ist tausendmal bessere als vor den Einstellungen und nochmal deutlich besser als mit dem Huawei Server (der am Limit lief xD), aber wenn es noch Möglichkeiten zur Verbesserung gibt, will man das natürlich nicht liegen lassen.
Ich Frage noch mal:
1. Hat es eine systematische Untersuchung zur Ursache (root case) der Problematik gegeben? Es wirkt nicht so.
2. DCB ist nicht zwingend nötig. Aber sollte als Mindest-Featureset vorhanden sein. sonst macht es wenig Sinn über Funktionen und Protokolle zu diskutieren, wie geschehen.
Beide deine Screenshots laufen offensichtlich in ein Limit, wenn auch unterschiedlicher Herkunft. (Die Benchmarksoftware ist aber auch nciht optimal.)
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 @150631,
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 @150631,
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
lokaler Datastore
vSAN
vSAN
😧 ... 😭 ... ja, das sieht schon etwas gruselig aus. 😬
Hast du denn wie bereits angesprochen, das LRO/GRO schon hostseitig deaktiviert?
Gruss Alex
Zitat von @MysticFoxDE:
Du hast aber schon gelesen, dass der TO nicht nur zwei, sondern vier Hosts hat?
Lass bitte mal das DCB in Ruhe, das bringt bei der Bandbreite die niemals eine Überlast erzeugt, genau gar nichts.
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.
War heut den ganzen Tag unterwegs...
Fangen wir von oben an:
Damit sagst du das offensichtliche auf, weshalb ich hier nach Rat frage oO
Aktuell ist das generische Build 8.0.2 auf den Lenovo Hosts.
Noch nicht, bin bei Änderungen was die Hardware / VMs angeht eher überfürsorglich und mache sowas wenn dann eher am WE wenn die ganzen Standorte nicht arbeiten (falls doch was schief gehen sollte) - Oder kann ich das bedenkenlos im Live Betrieb deaktivieren?
Ich kann doch jetzt nicht einfach das vSAN "ausseinander reißen" Das ist wie gesagt unser Live System - den Usern fällt es nicht auf, dass es langsamer ist als es eig sein sollte - mich stört das aber.
Der Umstieg auf die Lenovo Firmware ist zeitnah geplant. XClarity Integrator mit der Firmware etc. ist soweit vorbereitet. - Eine SSD lässt sich leider nicht in der Firmware auf den seiten VMware unterstützten Stand upgraden (da warten wir noch auf die RMA Antwort seitens Lenovo)
Und ja sonst schmeißt er mir die Meldungen raus, weil das UEFI / BMC neurer als in dem Image ist.
Oder kann ich die Meldung ignorieren, bzw. wie würde das "Update" dann verlaufen? downgraded er die bemängelten Versionen auf die im Image hinterlegten?
Fangen wir von oben an:
Du solltest primär klären woher das Limit kommt.
stammte das Image von Lenovo oder ist es ein generisches Image?
stammte das Image von Lenovo oder ist es ein generisches Image?
Damit sagst du das offensichtliche auf, weshalb ich hier nach Rat frage oO
Aktuell ist das generische Build 8.0.2 auf den Lenovo Hosts.
Hast du denn wie bereits angesprochen, das LRO/GRO schon hostseitig deaktiviert?
Noch nicht, bin bei Änderungen was die Hardware / VMs angeht eher überfürsorglich und mache sowas wenn dann eher am WE wenn die ganzen Standorte nicht arbeiten (falls doch was schief gehen sollte) - Oder kann ich das bedenkenlos im Live Betrieb deaktivieren?
Ja, deshalb kann es ja mit zwei der vier Hosts, das in in Minuten testen.
Ich kann doch jetzt nicht einfach das vSAN "ausseinander reißen" Das ist wie gesagt unser Live System - den Usern fällt es nicht auf, dass es langsamer ist als es eig sein sollte - mich stört das aber.
OEM Images haben angepasste Treiber, Konfigs usw.... Besonders bei vSAN macht es viel Sinn eine explizit unterstützte Umgebung zu haben, weil sonst kein Hersteller-Support in der Subscription möglich ist.
Der Umstieg auf die Lenovo Firmware ist zeitnah geplant. XClarity Integrator mit der Firmware etc. ist soweit vorbereitet. - Eine SSD lässt sich leider nicht in der Firmware auf den seiten VMware unterstützten Stand upgraden (da warten wir noch auf die RMA Antwort seitens Lenovo)
Und ja sonst schmeißt er mir die Meldungen raus, weil das UEFI / BMC neurer als in dem Image ist.
Oder kann ich die Meldung ignorieren, bzw. wie würde das "Update" dann verlaufen? downgraded er die bemängelten Versionen auf die im Image hinterlegten?
Hast Du auf den ESXi und das vSAN Support?
Moin @150631,
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
Und hier liegt glaube ich auch schon der Großteil des Hundes begraben, denn meine Kristallkugel sagt mir, dass deine E810er NIC's, über die ja auch das vSAN läuft, ohne RDMA laufen.
Laut https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-storage/GUID-F4B42 ... soll man das einfach in dem jeweiligen Host aktivieren können, jedoch habe ich den Menüpunkt gar nicht. Muss ich erst auf die neuste Firmware von den NICs aktuallisieren oder das gar im BIOS aktivieren?
Aber, wenn zwei Server links stehen und zwei rechts, dann hast du pro Unifi Aggregation Pro Switch ja zwei SFP28 Ports frei. 😁
Sprich, darüber kannst du die beiden Serverräume ja dann mit einem 2x25G LAG koppeln und dann ist die Sache mit dem oben angesprochenem Bottleneck auch wieder vom Tisch.
Sprich, darüber kannst du die beiden Serverräume ja dann mit einem 2x25G LAG koppeln und dann ist die Sache mit dem oben angesprochenem Bottleneck auch wieder vom Tisch.
Das wäre tatsächlich die andere Alternative die ich im Kopf hatte
Und nein nen Supportvertrag an sich haben wir nicht. Wir haben einen Dienstleister der uns dabei n bissl. unterstützt mit vSAN an sich aber auch noch nix groß zu tun hatte.
Ähm ja, gerade bei einem vSAN ist es mehr als nur wichtig, nur "supportete" Komponenten zu benutzen, sonst kann man jegliche Supportanfrage, auch gleich wieder knicken, vor allem bei Broadcom. 😔
Die Hardware an sich ist ja supported, das einzige wo er noch meckert ist die 1 SSD die sich net upgraden lassen will Firmware OPPA3 - supported sind aber nur 2 4 und 6 ... :D
Moin @150631,
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
Noch mal für RDMA ist DCB Voraussetzung. Für iWARP wäre es optional, aber sehr empfehlenswert.
Moin @150631,
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 @150631,
😯 ... 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
Moin,
LRO habe ich deaktiviert, was aber keine wirkliche Auswirkung hatte.
Ich werde mal schauen, wir haben noch "ältere" HPE Aruba 10Gbit Switches im Büro wie sich die Performance da dran verhält.
NIC Firmware Update etc. ist am WE geplant.
LRO habe ich deaktiviert, was aber keine wirkliche Auswirkung hatte.
Ich werde mal schauen, wir haben noch "ältere" HPE Aruba 10Gbit Switches im Büro wie sich die Performance da dran verhält.
NIC Firmware Update etc. ist am WE geplant.
Alex, ich habe tatsächlich bis InfiniBand gelesen.
@topic: Wir wissen weiterhin nichts. Wir wissen nichts über die Konfig des vSANS. Selbst triviale Logs haben wir ncht gesehen. Ein "esxcli network nic..." usw alles nichts da.
Wir wissen nur, dass es nicht gut läuft. Die IOPS Richtung Storage im verdacht stehen nicht gut zu sein, aber ohne vSAN Policys zu kennen, schaffen es die Bilder nur in den Fuchsbau. Es gibt Switches die sehr eingeschränkt sind und nicht viel Forward können ohne hochlatenz zu zeigen. Wir kennen (sinnlose) BEnchmarks aus einer VM, aber der Hypervisor ist nicht untersucht worden. Das wäre ein fall für systematisches Arbeiten. Wir haben viele "Ratschläge" gehört, etwas zu verstellen. Ganz wundersame Dinge, die aber mit dem Ansatz, dass das Lesen und Scheiben in ein verteiltes Blockleveldateissystem NICHTS zu tun haben. Man dreht sich im Kreis.
Lange Rede Kurzer Sinn. Die Umgebung ist weit weg von einer supporteten Umgebung. Wo überall die Best Practices verlassen sind können wir nciht einschätzen.
Somit kommt jeder IT-Pro eigentlich immer an den Punkt Systematisch die Vitalparameter zu untersuchen.
Gut, ich bin raus. Ich würde die Zeit dann doch eher in unsere Cluster stecken, die laufen.
Kleine Info noch. Wenn man mit ESXi gut kann, vielleicht ein Zertifikat hat, dann kann man das Zertifikat zum vSAN Specialist in drei Stunden machen. Weil es wirklich keine große Sache ist. Wie alle VMWare Zertifikate die im Feld einen Einsatz finden würden, geht es um systemtisches Arbeiten. Noch NIE ist in einer Zertifizierung ein Disk Benchmark gemacht worden und wenn es jemand macht, dann würde man dem keine Bedeutung beimessen. Und in der völligen Unkenntnis eines vSANs macht dann jemand, auf Kundenhardware ^^, eine Diskbenchmark - obwohl das nichts zur Sache beiträgt und absolut keine Aussagekraft hat. Um dann noch was von 1,4Mio IOPS zu erzählen. wirklich völlig irrer Thread hier. Ich sollte es auch Screenshoten und bei Reddit posten, zum kaputtlachen. Ich würde mir Gedanken machen, dass ein Kunde hier mit liest. Das Verhalten ist Treu und Glauben zu wieder.
@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 @150631,
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
Die vSAN Speicherrichtlinien sind die vorgegebenen vSAN-Cluster - Optimal Datastore Default Policy - RAID5.
Da das Thema HCIBench angesprochen wurde, hier 4 PDFs mit Tests. Getestet wurde mit der aktuellen HCIBench Version und Eaysrun / FIO Benchmark. Hier kann man leider keine PDFs hochladen.
https://drive.google.com/file/d/1KcOH40Q6XybUFtKzPpKD-LAZPZQloZFk/view?u ...
https://drive.google.com/file/d/1w36sYSyBHrvR59VEcd3FNuJU3HrZozj6/view?u ...
https://drive.google.com/file/d/1kZ7w5bhyx6p8-UllrFuthTQknBXIp7Ck/view?u ...
https://drive.google.com/file/d/1g277iJdc6REGgNz3Ude-mHy0TyP0Tlaf/view?u ...
Zum Thema HPE Aruba Switches, das sollte eher als Test dazu dienen ob der Unifi Switch nicht evtl. einen weg hat. Denn seit heute Nacht erkennt er die Unifi 25GB SFP+ DAC nicht mehr auf den 25Gbit Ports, warum auch immer...
Das vSAN macht grad noch eine Neusynchronisieren von Objekten weshalb ich die Hosts heute Nacht mal in den Wartungsmodus versetze und den Switch mal neu starte?
Da das Thema HCIBench angesprochen wurde, hier 4 PDFs mit Tests. Getestet wurde mit der aktuellen HCIBench Version und Eaysrun / FIO Benchmark. Hier kann man leider keine PDFs hochladen.
https://drive.google.com/file/d/1KcOH40Q6XybUFtKzPpKD-LAZPZQloZFk/view?u ...
https://drive.google.com/file/d/1w36sYSyBHrvR59VEcd3FNuJU3HrZozj6/view?u ...
https://drive.google.com/file/d/1kZ7w5bhyx6p8-UllrFuthTQknBXIp7Ck/view?u ...
https://drive.google.com/file/d/1g277iJdc6REGgNz3Ude-mHy0TyP0Tlaf/view?u ...
Zum Thema HPE Aruba Switches, das sollte eher als Test dazu dienen ob der Unifi Switch nicht evtl. einen weg hat. Denn seit heute Nacht erkennt er die Unifi 25GB SFP+ DAC nicht mehr auf den 25Gbit Ports, warum auch immer...
Das vSAN macht grad noch eine Neusynchronisieren von Objekten weshalb ich die Hosts heute Nacht mal in den Wartungsmodus versetze und den Switch mal neu starte?
Moin @150631,
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
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".
Ich denke jedoch, dass sich der Switch wegen was ganz anderem "weggeschossen" hat und zwar eher wegen "Bufferoverflows".
Um das zu vermeiden, solltest du wie schon angesprochen, wenigstens auf den 25G Ports des Switches worüber momentan das vSAN läuft, unbedingt Flow-Control aktivieren.
Hab grad aktuell n ganz anderes Problem :D
Heut morgen meinte die Verbindung der 25Gbit Ports mir nichts dir nichts abzureißen, sodass dass vSAN erstmal natürlich eskalierte und jetzt nen Sync angestoßen hat oO - wäre nicht das Problem, müsste ich nicht auf 10Gbit ausweichen und jetzt läuft alles noch langsamer - Kaum nutzbar
und das, obwohl ich schon den sync auf 1mb je host begrenzt habe (was ja fast n witz ist)
Die DAC von den Host zum Switch funktionieren im 10GBit Port, aber nicht im 25GBit Port - komisch.
via esxcli vsan resync throttle set --level=1
Moin @haudegen93,
na ja, in dem einen oder anderen Punkt hat Trinatrium nicht ganz unrecht, vor allem bei dem, was den Support deiner Konfiguration angeht, den diese ist so nicht wirklich empfohlen.
Denn wenn man ein vSAN, auch beim Hyper-V, korrekt implementieren möchte, dann sollte die Netzwerkanbindung +- folgend aussehen.
(One Site)
Und zwar um genau das zu vermeiden, was bei dir aktuell passiert ist. 😔
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
So um dich der Reihe nach zu beantworten
Groß und teure Anschaffungen stehen so gut wie außer Frage, das bekomme ich nie durch, da die Switches / Server max. n 3/4 Jahr insgesamt alt sind.
Was ich noch durch bekäme und gut verargumentieren kann sind natürlich die Switche für Redundanz. (Wobei die teuren RoCE dabei auch eher raus fallen
Ich habe 4 nutzbare LWL Verbindungen zwischen den beiden Serverräumen (derzeit für die 4x10GBit LAC Links zwischen den beiden Aggregation Pro Switches genutzt)
Das hieße doch ich könnte mir noch 2 Aggregation Pro anschaffen und es folgendermaßen verkabeln.
Svr links
Aggregation Pro 1
Aggregation Pro 2
Host 1
Host 2
USW Pro 1
USW Pro 2
USW Pro 3
Svr rechts
Aggregation Pro 3
Aggregation Pro 4
Host 3
Host 4
USW Pro 4
USW Pro 5
Dann gehts jeweils von Aggregation Pro 1 in 3 und 2 in 4 mit 2x25Gbit LAC
Die Hosts 1 und 2 werden an Aggregation Pro 1 und 2 sowie die Hosts 3 und 4 in Aggregation Pro 3 und 4 mit je 1x 25 Gbit angeschlossen.
Und dann noch von den Aggregation Switches jeweils 1x in jeden Switch oder? Oder habe ich da grade nen Denkfehler.
Das 25Gbit Voraussetzung bei nem 4 Node sind ist mir bewusst. Aber ich wollte jetzt erstmal das Resync abschließen lassen, bevor ich da Hosts / Switches neu starte etc. (von gestern knapp 30TB sind noch 800GB übrig, sollte also heut Abend durch sein) :D
Das diente erstmal dazu, dass die Standorte die paar Stunden arbeiten konnten, am Nachmittag habe ich die Begrenzung raus genommen, wobei im Schnitt statt 1MBps jetzt 9-10 je Host heut nach rum kamen oO
Flow Control lässt sich leider nur Netzwerkseitig, statt Portseitig einschalten. Aber das mach ich nachher dann auch an.
Das mit iWARP schaue ich auch gleich zwecks Firmware Updates etc.
Jetzt nochmal zusätzlich nen neues SAN, vor allem inkl. Speicher weil: "Supported Drives
2.5” U.2 NVMe SSD (must be purchased from Infortrend)"
Das bekomme ich niemals durch.
Zwei weitere Switches für die Redundanz bekomm ich noch durch und dann würde mir halt auch schon ne adäquate Leistung die annähernd an die Anbindung kommt schon reichen.
Groß und teure Anschaffungen stehen so gut wie außer Frage, das bekomme ich nie durch, da die Switches / Server max. n 3/4 Jahr insgesamt alt sind.
Was ich noch durch bekäme und gut verargumentieren kann sind natürlich die Switche für Redundanz. (Wobei die teuren RoCE dabei auch eher raus fallen
Ich habe 4 nutzbare LWL Verbindungen zwischen den beiden Serverräumen (derzeit für die 4x10GBit LAC Links zwischen den beiden Aggregation Pro Switches genutzt)
Das hieße doch ich könnte mir noch 2 Aggregation Pro anschaffen und es folgendermaßen verkabeln.
Svr links
Aggregation Pro 1
Aggregation Pro 2
Host 1
Host 2
USW Pro 1
USW Pro 2
USW Pro 3
Svr rechts
Aggregation Pro 3
Aggregation Pro 4
Host 3
Host 4
USW Pro 4
USW Pro 5
Dann gehts jeweils von Aggregation Pro 1 in 3 und 2 in 4 mit 2x25Gbit LAC
Die Hosts 1 und 2 werden an Aggregation Pro 1 und 2 sowie die Hosts 3 und 4 in Aggregation Pro 3 und 4 mit je 1x 25 Gbit angeschlossen.
Und dann noch von den Aggregation Switches jeweils 1x in jeden Switch oder? Oder habe ich da grade nen Denkfehler.
Ist das ein ESA vSAN?
Wenn ja, dann benötigst du dafür laut VMware schon mindestens 25G.
Wenn ja, dann benötigst du dafür laut VMware schon mindestens 25G.
Das 25Gbit Voraussetzung bei nem 4 Node sind ist mir bewusst. Aber ich wollte jetzt erstmal das Resync abschließen lassen, bevor ich da Hosts / Switches neu starte etc. (von gestern knapp 30TB sind noch 800GB übrig, sollte also heut Abend durch sein) :D
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.
Das diente erstmal dazu, dass die Standorte die paar Stunden arbeiten konnten, am Nachmittag habe ich die Begrenzung raus genommen, wobei im Schnitt statt 1MBps jetzt 9-10 je Host heut nach rum kamen oO
Hast du den Switch schon rebootet?
Bitte nicht vergessen Flow-Control bei dieser Gelegenheit zu aktivieren.
Das haben wir tatsächlich gestern gemacht, erkennen wollte der Switch die DAC in den 25Gbit Ports jedoch trotzdem nicht. Aber da teste ich in Ruhe durch wenn der Resync durch ist und man in Ruhe mal kurz alles aus machen kann.Bitte nicht vergessen Flow-Control bei dieser Gelegenheit zu aktivieren.
Flow Control lässt sich leider nur Netzwerkseitig, statt Portseitig einschalten. Aber das mach ich nachher dann auch an.
ähm, nochmals zu dem Punkt.
Habt ihr unbedingt die Hardware so haben wollen oder hat euch euer Dienstleister das so angedreht?
vSAN und die Hosts an sich kamen von uns die Idee. Wir hatten halt vorher 2 von den oben genannten Huawei Hosts mit nem Huawei SAN, was mehr schlecht als recht lief und der SAN sogar noch Vendor locked war, sodass das vSAN alles in allem auf dem Papier zu gut klang. - Im nachhinein denk ich mir, man hätte einfach iwie nen ThinkSystem DE4000F dazu bestellt und weniger Kopfschmerzen gehabt.Habt ihr unbedingt die Hardware so haben wollen oder hat euch euer Dienstleister das so angedreht?
Denn, entweder ihr bekommt eure Umgebung mit iWARP zum Laufen und dann könnt ihr +- die bisherigen Switche auch weiterhin behalten, ich würde dann jedoch noch mindestens zwei davon anschaffen, damit auch eine "Pfad-Redundanz" hergestellt werden kann.
Das mit iWARP schaue ich auch gleich zwecks Firmware Updates etc.
Oder du holst dir ein anständiges SAN, wie z.B. das folgende hier ...
https://www.infortrend.com/de/products/families/esds/4000u
... und sparst dir das obere Theater und hast zudem dann auch ordentlich bessere Leistung.
https://www.infortrend.com/de/products/families/esds/4000u
... und sparst dir das obere Theater und hast zudem dann auch ordentlich bessere Leistung.
Jetzt nochmal zusätzlich nen neues SAN, vor allem inkl. Speicher weil: "Supported Drives
2.5” U.2 NVMe SSD (must be purchased from Infortrend)"
Das bekomme ich niemals durch.
Zwei weitere Switches für die Redundanz bekomm ich noch durch und dann würde mir halt auch schon ne adäquate Leistung die annähernd an die Anbindung kommt schon reichen.
Wir hatten halt vorher 2 von den oben genannten Huawei Hosts mit nem Huawei SAN, was mehr schlecht als recht lief und der SAN
Wer hat euch denn damals das Equipment verkauft?Ihr selbst werdet es vermutlich nicht direkt von Huawei bezogen haben, da die nur ChannelPartner Sales machen.
Wenn da ein vernünftiger Partner zwischen hängt, hätte er euch hier zweifelsfrei unterstützen können. Und zwar soweit, dass ihr bei bestehender Maintenance direkt auf das EntwicklerTeam bei Huawei zugreifen könnt, wenn die vorderste Front von Huawei nicht helfen kann.
Und nein nen Supportvertrag an sich haben wir nicht. Wir haben einen Dienstleister der uns dabei n bissl. unterstützt mit vSAN an sich aber auch noch nix groß zu tun hatte.
Das heißt, ihr habt keine VMware Subscription?Was macht ihr, wenn euch da was um die Ohren fliegt und euer DL auch nicht weiter weiß?
Bei uns kam es vor zwei oder drei Jahren mal vor, dass das vCenter nicht mehr hoch kam. Mit unserem Partner 3h rumgedoktert (ja, die sind fit in VMware). Am Ende hat es der Support in 10 Minuten gelöst. Die Startreihenfolge der Dienste passte nicht ganz…
=> zieh VMware hinzu und lass die deine Probleme lösen. Mein Tipp
Wer hat euch denn damals das Equipment verkauft?
Das weiß ich leider nicht, das war lange vor meiner ZeitDas heißt, ihr habt keine VMware Subscription?
Bis jetzt nicht, vor der vSAN Geschichte hat sich der DL bei Problemen um das vCenter und die ESXI gekümmert.Aber er hat uns angeraten, ob wir nicht ne Subscription für den Fall der Fälle abschließen wollen / sollten.
Das ist aber wohl untergegangen, da werde ich aber Montag nochmal nach haken was da jetzt ist.
Kurzes Update,
Der Resync ist durch, Flow Control aktiviert und NIC Firmware aktuell.
Zwecks der 25Gbit DAC fahre ich morgen nochmal in die Firma und schaue mir das an.
Auch mit Firmware Update bekomme ich nur folgende Meldung:
Der Link: https://docs.vmware.com/de/VMware-vSphere/8.0/vsphere-networking/GUID-48 ... führt mich dann auf eine Hilfeseite wo steht, ESXI erkennt automatisch, dass ein RDMA fähiger NIC installiert ist...
Komisch finde ich, dass ich in dem VMware Compatibility Guide für ESXI 8 nur folgendes finde:
https://www.vmware.com/resources/compatibility/detail.php?deviceCategory ...
und dort nichts von RDMA oder RoCEv2 steht.
In dem Datenblatt https://www.intel.de/content/www/de/de/products/sku/184820/intel-etherne ... steht aber, dass das alles unterstützt würde.
Der Resync ist durch, Flow Control aktiviert und NIC Firmware aktuell.
Zwecks der 25Gbit DAC fahre ich morgen nochmal in die Firma und schaue mir das an.
Auch mit Firmware Update bekomme ich nur folgende Meldung:
Der Link: https://docs.vmware.com/de/VMware-vSphere/8.0/vsphere-networking/GUID-48 ... führt mich dann auf eine Hilfeseite wo steht, ESXI erkennt automatisch, dass ein RDMA fähiger NIC installiert ist...
Komisch finde ich, dass ich in dem VMware Compatibility Guide für ESXI 8 nur folgendes finde:
https://www.vmware.com/resources/compatibility/detail.php?deviceCategory ...
und dort nichts von RDMA oder RoCEv2 steht.
In dem Datenblatt https://www.intel.de/content/www/de/de/products/sku/184820/intel-etherne ... steht aber, dass das alles unterstützt würde.
Moin @haudegen93,
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 ...
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. 😉😉
Auch mit Firmware Update bekomme ich nur folgende Meldung:
Ist den Global SR-IOV im BIOS des Mainboards der Server aktiviert?
Des weiteren muss man eventuell bei den E810 auch noch im BIOS der NIC's das SR-IOV aktivieren.
Bei den X7xx war das noch nicht notwendig, eine E810 hatte ich jedoch noch nicht.
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 ...
), 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 ...
1Ist 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.
Bei den X7xx war das noch nicht notwendig, eine E810 hatte ich jedoch noch nicht.
Das habe ich auch nachgeschaut sowohl im Bios als in der Netzwerkkarte ist SR-IOV an.
Sprich, die E810er, dürfen ihre Geschwindigkeit auf keinen Fall z.B. von 25G auf 10G "drosseln".
In dem Unifi hab ich die Ports auf 25Gbit fest gesetzt und im vSphere dann auch.Hier ist noch n anderer Eintrag von nem E810er aber andere SID von ESXI 7
https://www.vmware.com/resources/compatibility/detail.php?deviceCategory ...
da steht z.b was von ROcEv2
komisch...
Und auch schauen, ob RDMA überhaupt aktiviert wurde:
Darum gehts ja, lässt sich net aktivieren :D
Welcher Treiber ist geladen:
https://www.vmware.com/resources/compatibility/detail.php?deviceCategory ...
Für die 810er Karten braucht es den irdman driver
https://www.vmware.com/resources/compatibility/detail.php?deviceCategory ...
Für die 810er Karten braucht es den irdman driver
1
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 ...
Installiert ist icen 1.5.2.12
Bzw. erstmal die icen und irdman treiber wie in https://knowledge.broadcom.com/external/article/313796/enabling-and-disa ... angezeigt installieren?
Ganz ehrlich, durch die neue Lizensierung seitens Broadcom.. da tut es auch eig Hyper V - und das was ich in Kombination mit Storage Spaces Direct gelesen hab.... - naja jetzt ist egal, jetzt ist jetzt :D
Btw. hab grad mal auf unseren Veeam Server geschaut - da gehen knapp 6-7 Gbit grad rein (laut Task Manager) von vSAN Richtung Veeam (physische Maschine)
Jedoch steht da nur Firmware 4.1 und 4.2 - ich hatte vorher 4.3 jetzt 4.5 auf den NICs - hmm
Und mit diesem "wirren" Wissen habe ich dann auch recht schnell das folgende gefunden.
https://docs.vmware.com/de/VMware-vSphere/8.0/vsphere-storage/GUID-5F776 ...
😉
Also hieße das, ich weise dem vsan vmkernel noch nvme over tcp zu bzw. erstelle einfach noch nen zusätzlichen vmnic?https://docs.vmware.com/de/VMware-vSphere/8.0/vsphere-storage/GUID-5F776 ...
😉
Bzw. erstmal die icen und irdman treiber wie in https://knowledge.broadcom.com/external/article/313796/enabling-and-disa ... angezeigt installieren?
Na ja, VMware eben, sprich, kein Plan vom wahren Leben und jetzt erst recht als Broadcom. 🤪
(Sorry, aber der musste jetzt irgendwie raus.)
(Sorry, aber der musste jetzt irgendwie raus.)
Ganz ehrlich, durch die neue Lizensierung seitens Broadcom.. da tut es auch eig Hyper V - und das was ich in Kombination mit Storage Spaces Direct gelesen hab.... - naja jetzt ist egal, jetzt ist jetzt :D
Btw. hab grad mal auf unseren Veeam Server geschaut - da gehen knapp 6-7 Gbit grad rein (laut Task Manager) von vSAN Richtung Veeam (physische Maschine)
Schaue dir den Link hier an:
https://www.vmware.com/resources/compatibility/detail.php?deviceCategory ...
https://www.vmware.com/resources/compatibility/detail.php?deviceCategory ...
Jedoch steht da nur Firmware 4.1 und 4.2 - ich hatte vorher 4.3 jetzt 4.5 auf den NICs - hmm
Hab grad mal geschaut.
In dem Addon Pack Lenovo Customization Addon for Lenovo ThinkSystem LVO.803.12.1 sollen die irdman 1.4.4 Treiber enthalten sein.
Dann müsste ich doch eig nur die Firmware über die Lenovo Firmware mit dem Addon Pack aktualisieren oder?
Links derzeit, rechts Update
In dem Addon Pack Lenovo Customization Addon for Lenovo ThinkSystem LVO.803.12.1 sollen die irdman 1.4.4 Treiber enthalten sein.
Dann müsste ich doch eig nur die Firmware über die Lenovo Firmware mit dem Addon Pack aktualisieren oder?
Links derzeit, rechts Update
Moin @haudegen93,
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
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).
Oder über den XClarity Controller im Host und einer manuell heruntergeladenen Intel Firmware (wäre die >ungünstigste Variante).
Über die von der Lenovo Seite für unseren Server heruntergeladene Firmware und dann im XClarity Controller unter Repository eingespielt.
Für nächstes WE ist mit dem uns betreuenden DL geplant, die Hosts auf 8.3b zu upgraden und in dem Zuge die Treiber über das LVO Pack mit einzuspielen.
Moin @haudegen93,
👍
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- ...
wie ist eigentlich aktuell die Lage?
Laufen die 25G Links wieder mit 25G?
Laufen die 25G Links wieder mit 25G?
War ganz chaotisch gestern :D - DAC angeschlossen, schienen nen Link zu haben.
Ok aufs vcenter gegangen um zu schauen und gesehen, waren erstmal Meldungen wegen HA Verfügbarkeit etc.
Da ich die Switche etc. eh alle einmal neu starten wollte, habe ich das Cluster heruntergefahren wie hier beschrieben.
https://docs.vmware.com/de/VMware-vSphere/7.0/com.vmware.vsphere.vsan-mo ...
Herunterfahren lief.
Switche neugestartet.
Cluster wieder hoch gefahren und dann hatte ich den Salat... vSAN war tot... :D
Bis ich dann nach iwie 2-3h endlich die Lösung in folgender KB fand: https://knowledge.broadcom.com/external/article/326833/inaccessible-obje ...
Das war Aufregung genug gestern
In der Zwischenzeit hatte der Link der DAC sich aber iwie wieder verabschiedet, sodass das Cluster aktuell weiter mit 10Gbit läuft und wir beschlossen haben nochmal nachzuordern und auf sfp Module zu setzen.
Von oben gabs jetzt das OK für 2 weitere Aggregation Pro inkl. nötiger SFP Module und LWL Kabel
Wenn ja, kannst du dann bitte den ATTO-DB nochmals auf dem vSAN laufen lassen,
um zu sehen was das Folw-Control bereits bewirk, danke.
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.
1
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
... 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.
Ich würde hier sowohl auf der Swich-Seite als auch auf der NIC Seite, als nächstes den Link-Speed mal fix auf 25G >stellen.
Das habe ich damals schon als erstes gemacht, also Link Speed stand auf beiden Seiten auf 25Gbit eingestellt.
Moin @haudegen93,
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
wie lange sind den die DAC's?
5 MeterGenau genommen waren es folgende DAC:
5m UC-DAC-SFP28 also die von Ubiquiti selber.
Aber wie gesagt die DACs werden jetzt eh durch Module ersetzt.
Update:
Die Updates und Treiberinstallationen sind durch.
RDMA ließ sich auch aktivieren.
Unterschied bisher aber 0, noch immer langsam.
Die Updates und Treiberinstallationen sind durch.
RDMA ließ sich auch aktivieren.
Unterschied bisher aber 0, noch immer langsam.
Hier auch noch einmal ein direkter Vergleich mit Crystaldiskmark.
Und anbei das Datenblatt der SSD: https://download.semiconductor.samsung.com/resources/white-paper/PM1743_ ...
Ich weiß net ob es einen Unterschied macht, aber wir haben die Read Intensive Version der SSD.
Settings: NVME SSD
Profil: Real World Performance + Mix
Lokale SSD
vSAN
Und anbei das Datenblatt der SSD: https://download.semiconductor.samsung.com/resources/white-paper/PM1743_ ...
Ich weiß net ob es einen Unterschied macht, aber wir haben die Read Intensive Version der SSD.
Settings: NVME SSD
Profil: Real World Performance + Mix
Lokale SSD
vSAN
Ok das verwirrt mich jetzt noch mehr,
meine eigene Samsung 980 (non Pro) 1TB (pcie gen 3 x4 ssd) kommt auf folgende Werte:
Wie kann die denn bitte bis auf die Sequentielle R/W Rate in allem anderen schneller sein, als die lokale einzelne PM1743?
meine eigene Samsung 980 (non Pro) 1TB (pcie gen 3 x4 ssd) kommt auf folgende Werte:
Wie kann die denn bitte bis auf die Sequentielle R/W Rate in allem anderen schneller sein, als die lokale einzelne PM1743?
Moin...
also wenn du PM1743 NVMes hast, frage ich mich grade wo du die NVMe eingebaut hast für dein vSAN?!?!
kann das Gerät den PCI5?... wenn ich die Leistung so sehe, würde ich sagen PCI3.
Frank
also wenn du PM1743 NVMes hast, frage ich mich grade wo du die NVMe eingebaut hast für dein vSAN?!?!
kann das Gerät den PCI5?... wenn ich die Leistung so sehe, würde ich sagen PCI3.
Frank
Die PM1743 sind in den Lenovo Servern in den Drive Bays vorne verbaut.
Und wenn Lenovo mit Gen5 wirbt etc. gehe ich mal davon aus, dass auch Gen5 unterstützt wird.
Anzumerken sei, der Test mit der einzelnen PM1743 - da läuft auch das ESXI des entsprechenden Hosts drauf, wobei das jetzt kein großen Impact auf die Leistung haben sollte.
Zumal das erstmal nur als Vergleichspunkt zum vSAN dienen soll, denn hauptsächlich geht es ums vSAN was unterirdisch performt.
Und wenn Lenovo mit Gen5 wirbt etc. gehe ich mal davon aus, dass auch Gen5 unterstützt wird.
Anzumerken sei, der Test mit der einzelnen PM1743 - da läuft auch das ESXI des entsprechenden Hosts drauf, wobei das jetzt kein großen Impact auf die Leistung haben sollte.
Zumal das erstmal nur als Vergleichspunkt zum vSAN dienen soll, denn hauptsächlich geht es ums vSAN was unterirdisch performt.
Zitat von @haudegen93:
Die PM1743 sind in den Lenovo Servern in den Drive Bays vorne verbaut.
Und wenn Lenovo mit Gen5 wirbt etc. gehe ich mal davon aus, dass auch Gen5 unterstützt wird.
hm... das tue ich nicht!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
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
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
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
Moin...
also wenn du schon lokal nicht auf 7K kommst hast du ein Hardware problem !
du kannst ja mal mit 128 GB ram testen und nur einer Samsung NVMe!
oder dein Blech kann kein PCIe5
Frank
also wenn du schon lokal nicht auf 7K kommst hast du ein Hardware problem !
du kannst ja mal mit 128 GB ram testen und nur einer Samsung NVMe!
oder dein Blech kann kein PCIe5
Frank
Moin @haudegen93,
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
Ok beim Stöbern im Bios habe ich SNC gefunden
folgende Optionen habe ich zur Auswahl:
Disabled (Default)
The LLC is treated as one cluster when this option is disabled.
SNC2
2-way Sub-NUMA Clustering partitions the last level cache (LLC) into two clusters called NUMA nodes that contain an equal number of cores, equal number of LLC slices in close proximity to the cores, an equal amount of socket address space, and with each cluster bound to a subset of the memory controllers in the socket.
This requires left-to-right DIMM symmetry. If there is not left-to-right DIMM symmetry, SNC will be forced to Disabled.
When SNC2 is selected, the OS sees two NUMA nodes per physical CPU package.
Laut dem oben verlinkten Artikel von Lenovo müsste ich aber unter Processors im UEFI noch folgende Einstellungen haben wenn SNC deaktiviert ist (was es aktuell ist) - Die Option UMA Based Clustering ist aber nicht aufzufinden.
UMA-Based Clustering
UMA-Based Clustering options are only available when SNC is Disabled.
This setting is accessed as follows:
System setup: System Settings → Processors → UMA-Based Clustering
OneCLI/ASU variable: Processors.UMA-BasedClustering
Redfish attribute: Processors_UMA-BasedClustering
Possible values are:
Disabled
No clustering and no LLC to memory controller affinitization.
Hemisphere
Two clusters per socket that reduces latency due to proximity of LLC and memory controllers. Requires symmetry in memory configuration between the left side and the right side of the processor.
Quadrant (Default)
Works the same as Hemisphere but divides the die up into four clusters and only works on XCC processors. This mode affinitizes LLC slices to memory controllers based on proximity. Requires full symmetry in memory configuration between the left side and the right side, and between the top half and the bottom half of the processor.
folgende Optionen habe ich zur Auswahl:
Disabled (Default)
The LLC is treated as one cluster when this option is disabled.
SNC2
2-way Sub-NUMA Clustering partitions the last level cache (LLC) into two clusters called NUMA nodes that contain an equal number of cores, equal number of LLC slices in close proximity to the cores, an equal amount of socket address space, and with each cluster bound to a subset of the memory controllers in the socket.
This requires left-to-right DIMM symmetry. If there is not left-to-right DIMM symmetry, SNC will be forced to Disabled.
When SNC2 is selected, the OS sees two NUMA nodes per physical CPU package.
Laut dem oben verlinkten Artikel von Lenovo müsste ich aber unter Processors im UEFI noch folgende Einstellungen haben wenn SNC deaktiviert ist (was es aktuell ist) - Die Option UMA Based Clustering ist aber nicht aufzufinden.
UMA-Based Clustering
UMA-Based Clustering options are only available when SNC is Disabled.
This setting is accessed as follows:
System setup: System Settings → Processors → UMA-Based Clustering
OneCLI/ASU variable: Processors.UMA-BasedClustering
Redfish attribute: Processors_UMA-BasedClustering
Possible values are:
Disabled
No clustering and no LLC to memory controller affinitization.
Hemisphere
Two clusters per socket that reduces latency due to proximity of LLC and memory controllers. Requires symmetry in memory configuration between the left side and the right side of the processor.
Quadrant (Default)
Works the same as Hemisphere but divides the die up into four clusters and only works on XCC processors. This mode affinitizes LLC slices to memory controllers based on proximity. Requires full symmetry in memory configuration between the left side and the right side, and between the top half and the bottom half of the processor.
By the Way, schau dir mal die folgende Doku an ...
... und stelle bitte alles so ein wie für "Maximum Performance" empfohlen wird.
Hast du im ESXi die Energieoptionen auch schon auf "Hochleistung" gesetzt?
Bis auf die Option: MONITOR/ MWAIT war schon alles inkl. der ESXI Einstellungen gesetzt.
1
Ich weiß jetzt nicht wo genau der Unterschied in den einzelnen Profilen liegt, aber habe nochmal einen Run mit dem Default Profil gemacht. und da kommen für die einzelne SSD schon eher schönere Ergebnisse raus, fürs vSAN jedoch unterirdisch.
local datastore ssd:
vsan:
Thema RDMA:
nach Installation der Treiber war RDMA auch verfügbar. Jedoch als default nur RoCEv2.
Damit ließ sich RDMA Unterstützung im vSAN auch einschalten, was jedoch auf Fehlermeldungen stieß weil die restliche Netzwerk Konfig das ja nicht unterstützt.
Mit dem Befehl: esxcli system module parameters set -m irdman -p "ROCE=0,0,0,0" ließ sich iWARP statt RoCEv2
nach einem Neustart aktivieren.
Darufhin wird die Option RDMA Unterstützung aber ausgegraut mit folgender Meldung:
local datastore ssd:
vsan:
Thema RDMA:
nach Installation der Treiber war RDMA auch verfügbar. Jedoch als default nur RoCEv2.
Damit ließ sich RDMA Unterstützung im vSAN auch einschalten, was jedoch auf Fehlermeldungen stieß weil die restliche Netzwerk Konfig das ja nicht unterstützt.
Mit dem Befehl: esxcli system module parameters set -m irdman -p "ROCE=0,0,0,0" ließ sich iWARP statt RoCEv2
nach einem Neustart aktivieren.
Moin @haudegen93,
hätte mich auch gewundert, wenn dieses System das nicht anbieten würde. 🙃
Das sollte in deinem Fall auch unbedingt auf "Disabled" bleiben, denn ...
... SNC2 dürftest du eigentlich gar nicht zu Gesicht bekommen, da du in diesem System Gen. 4 Xeon's verbaut hast und diese unterstützen nicht SNC2 wie die Vorgänger (Gen. 3), sondern SNC4!
Sprich, da hat wohl auch Lenovo ordentlich was verpennt. 😔😭
Und ich wette, dass es bei deren Gen. 5 Systemen genauso bescheiden aussieht, sprich, die ebenfalls nur SNC2 beherrschen. 🙃
Genau deshalb habe ich auch gefragt, ob deine RAM-Bänke halb oder voll belegt sind.
Ausserdem sollte man insbesondre bei den neueren XEON's, den RAM eh immer entweder halb oder voll bestücken, zumindest dann, wenn man auch deren volle RAM, aber auch CPU Performance haben möchte. 🙃
Und falls jetzt jemand aus dem AMD Lager seine Chance zum Lästern wittert ... ganz entspannt bleiben ... denn dasselbe gilt auch für die AMD CPU's. 😉 Zumindest das mit Performance und halb oder voll bestückt ... wie das bei AMD mit SNC aussieht weiss ich jedoch nicht, da wir in die von uns ausgelieferten Systeme, bisher nur Xeons verbaut haben und damit auch ganz glücklich sind.
Gruss Alex
Ok beim Stöbern im Bios habe ich SNC gefunden
hätte mich auch gewundert, wenn dieses System das nicht anbieten würde. 🙃
folgende Optionen habe ich zur Auswahl:
Disabled (Default)
Disabled (Default)
Das sollte in deinem Fall auch unbedingt auf "Disabled" bleiben, denn ...
The LLC is treated as one cluster when this option is disabled.
SNC2
2-way Sub-NUMA Clustering partitions the last level cache (LLC) into two clusters called NUMA nodes that contain an equal number of cores, equal number of LLC slices in close proximity to the cores, an equal amount of socket address space, and with each cluster bound to a subset of the memory controllers in the socket.
SNC2
2-way Sub-NUMA Clustering partitions the last level cache (LLC) into two clusters called NUMA nodes that contain an equal number of cores, equal number of LLC slices in close proximity to the cores, an equal amount of socket address space, and with each cluster bound to a subset of the memory controllers in the socket.
... SNC2 dürftest du eigentlich gar nicht zu Gesicht bekommen, da du in diesem System Gen. 4 Xeon's verbaut hast und diese unterstützen nicht SNC2 wie die Vorgänger (Gen. 3), sondern SNC4!
Sprich, da hat wohl auch Lenovo ordentlich was verpennt. 😔😭
Und ich wette, dass es bei deren Gen. 5 Systemen genauso bescheiden aussieht, sprich, die ebenfalls nur SNC2 beherrschen. 🙃
This requires left-to-right DIMM symmetry. If there is not left-to-right DIMM symmetry, SNC will be forced to Disabled.
Genau deshalb habe ich auch gefragt, ob deine RAM-Bänke halb oder voll belegt sind.
Ausserdem sollte man insbesondre bei den neueren XEON's, den RAM eh immer entweder halb oder voll bestücken, zumindest dann, wenn man auch deren volle RAM, aber auch CPU Performance haben möchte. 🙃
Und falls jetzt jemand aus dem AMD Lager seine Chance zum Lästern wittert ... ganz entspannt bleiben ... denn dasselbe gilt auch für die AMD CPU's. 😉 Zumindest das mit Performance und halb oder voll bestückt ... wie das bei AMD mit SNC aussieht weiss ich jedoch nicht, da wir in die von uns ausgelieferten Systeme, bisher nur Xeons verbaut haben und damit auch ganz glücklich sind.
Gruss Alex
Moin @haudegen93,
du hast definitiv mehrere Probleme mit diesem System, bevor du jedoch mit RDMA/iWARP weiter machst, solltest du zuerst sicherstellen, dass das BIOS korrekt eingestellt ist und danach sieht es mir momentan noch nicht ganz aus.
Aber mach dir keinen Kopf, das liegt zu > 99,9 % nicht an dir, sondern eher an deinem Serverhersteller.
Die anderen sind was das angeht, momentan jedoch auch nicht besser unterwegs. 😔
Ähm, ja, so was ähnliches habe ich bei den letzten Systemen die ich zur Auslieferung für einen unserer Kunden vorbereitet habe auch schon erlebt. 😬
Und zwar ist die Performance des Systems, nachdem ich dieses von Default, sprich, von "Energy-Efficient" auf "Performance" umgestellt habe, nicht wirklich besser geworden, sondern eher schlechter. 😭
Nach einigen Tagen der Forschung habe ich den Grund zum Glück finden können. Und zwar wurde in meinem Fall, durch die Aktivierung des "Performance" Profils auch das SNC mit aktiviert und zwar mit SNC2. In diesem System waren jedoch bereits Gen. 5 Xeons verbaut, die, wie ich oben schon geschrieben haben, nicht SNC2 sondern SNC4 unterstützen. 🙃
Und nein, auch bei unseren Systemen konnte ich kein SNC4 Konfiguration im BIOS wählen, hatte bisher aber auch noch keine Zeit, bei dem entsprechenden Hersteller (Gigabyte) ein Supportticket diesbezüglich aufzumachen.
Sprich, ich weiss nicht genau ob du das oben bereits schon herausgelesen hast ... wenn nicht ... ja, du musst dein BIOS wahrscheinlich auch in einer bestimmten Reihenfolge konfigurieren, damit das was du einstellst, später auch wirklich so greift. 😔
Denn in meinem Fall habe ich bei der BIOS Konfiguration der entsprechenden Server z.B. als aller erstes das Performance Profil aktiviert, danach das SNC wieder deaktiviert und diverse weitere Einstellungen (~ 15 bis 20 Schritte) noch vornehmen müssen, damit die Server auch wirklich deren volle Leistung bringen können. 😩
Und da so gut wie jeder Hersteller bei den Performanceprofilen ein eigenes Süppchen kocht, musst du fürchte ich die richtigen Settings und auch Konfigurationsreihenfolge des BIOS, wahrscheinlich selber herausfinden.
Und nein, das ist jetzt ... leider, leider, leider ... kein Scherz 😭
Gruss Alex
du hast definitiv mehrere Probleme mit diesem System, bevor du jedoch mit RDMA/iWARP weiter machst, solltest du zuerst sicherstellen, dass das BIOS korrekt eingestellt ist und danach sieht es mir momentan noch nicht ganz aus.
Aber mach dir keinen Kopf, das liegt zu > 99,9 % nicht an dir, sondern eher an deinem Serverhersteller.
Die anderen sind was das angeht, momentan jedoch auch nicht besser unterwegs. 😔
Ich weiß jetzt nicht wo genau der Unterschied in den einzelnen Profilen liegt, aber habe nochmal einen Run mit dem Default Profil gemacht. und da kommen für die einzelne SSD schon eher schönere Ergebnisse raus, fürs vSAN jedoch unterirdisch.
local datastore ssd:
local datastore ssd:
Ähm, ja, so was ähnliches habe ich bei den letzten Systemen die ich zur Auslieferung für einen unserer Kunden vorbereitet habe auch schon erlebt. 😬
Und zwar ist die Performance des Systems, nachdem ich dieses von Default, sprich, von "Energy-Efficient" auf "Performance" umgestellt habe, nicht wirklich besser geworden, sondern eher schlechter. 😭
Nach einigen Tagen der Forschung habe ich den Grund zum Glück finden können. Und zwar wurde in meinem Fall, durch die Aktivierung des "Performance" Profils auch das SNC mit aktiviert und zwar mit SNC2. In diesem System waren jedoch bereits Gen. 5 Xeons verbaut, die, wie ich oben schon geschrieben haben, nicht SNC2 sondern SNC4 unterstützen. 🙃
Und nein, auch bei unseren Systemen konnte ich kein SNC4 Konfiguration im BIOS wählen, hatte bisher aber auch noch keine Zeit, bei dem entsprechenden Hersteller (Gigabyte) ein Supportticket diesbezüglich aufzumachen.
Sprich, ich weiss nicht genau ob du das oben bereits schon herausgelesen hast ... wenn nicht ... ja, du musst dein BIOS wahrscheinlich auch in einer bestimmten Reihenfolge konfigurieren, damit das was du einstellst, später auch wirklich so greift. 😔
Denn in meinem Fall habe ich bei der BIOS Konfiguration der entsprechenden Server z.B. als aller erstes das Performance Profil aktiviert, danach das SNC wieder deaktiviert und diverse weitere Einstellungen (~ 15 bis 20 Schritte) noch vornehmen müssen, damit die Server auch wirklich deren volle Leistung bringen können. 😩
Und da so gut wie jeder Hersteller bei den Performanceprofilen ein eigenes Süppchen kocht, musst du fürchte ich die richtigen Settings und auch Konfigurationsreihenfolge des BIOS, wahrscheinlich selber herausfinden.
Und nein, das ist jetzt ... leider, leider, leider ... kein Scherz 😭
Gruss Alex
Moin Zusammen.
noch ein kleiner Nachtrag dazu.
Die Info, dass es so ist, sprich, dass die Xeon's ab Gen.4 nicht 2fach SNC sondern 4fach SNC unterstützen, ist für "Normalsterbliche" leider auch nicht wirklich einfach zu finden, da diese Infos normalerweise nur für die Hersteller/OEM's wichtig/verfügbar sind. 😔
Ich habe jedoch ein offenes Loch gefunden, wo es jeder nachlesen kann ...
https://www.intel.cn/content/www/cn/zh/developer/articles/technical/four ...
... gerne auch die Hersteller/OEM's, die diese Info bisher verpasst/verpennt haben, sprich, so gut wie alle davon. 😭
Gruss Alex
... SNC2 dürftest du eigentlich gar nicht zu Gesicht bekommen, da du in diesem System Gen. 4 Xeon's verbaut hast und diese unterstützen nicht SNC2 wie die Vorgänger (Gen. 3), sondern SNC4!
noch ein kleiner Nachtrag dazu.
Die Info, dass es so ist, sprich, dass die Xeon's ab Gen.4 nicht 2fach SNC sondern 4fach SNC unterstützen, ist für "Normalsterbliche" leider auch nicht wirklich einfach zu finden, da diese Infos normalerweise nur für die Hersteller/OEM's wichtig/verfügbar sind. 😔
Ich habe jedoch ein offenes Loch gefunden, wo es jeder nachlesen kann ...
https://www.intel.cn/content/www/cn/zh/developer/articles/technical/four ...
... gerne auch die Hersteller/OEM's, die diese Info bisher verpasst/verpennt haben, sprich, so gut wie alle davon. 😭
Gruss Alex
Moin @Vision2015,
wir müssen mit den Messungen des TO's etwas vorsichtig umgehen, da er nicht wirklich über das native OS, sprich, ESXi testet, sondern über eine Windows-VM und wegen der Virtualisierungsschicht bekommt er eh nicht wirklich 1:1 die volle HW Leistung. Zudem muss auch die VM korrekt konfiguriert sein, damit diese so viel es geht von der Hardware abkratzen kann.
Ich habe dem Letzt erst irgendwo aufgeschnappt, dass man bei VMware, bei einem "NVME-Storage-Unterbau" bei den VM's einen bestimmten Controller-Typ wählen muss, damit man auch in diesen einen höhere Storage-Performance erzielen kann. Welcher Typ das jetzt genau ist, kann ich auf die Schnelle jedoch nicht sagen und zum Nachforschen fehlt mir momentan auch etwas die Zeit, da ich gleich zum Termin flitzen muss.
Gruss Alex
also wenn du schon lokal nicht auf 7K kommst hast du ein Hardware problem !
wir müssen mit den Messungen des TO's etwas vorsichtig umgehen, da er nicht wirklich über das native OS, sprich, ESXi testet, sondern über eine Windows-VM und wegen der Virtualisierungsschicht bekommt er eh nicht wirklich 1:1 die volle HW Leistung. Zudem muss auch die VM korrekt konfiguriert sein, damit diese so viel es geht von der Hardware abkratzen kann.
Ich habe dem Letzt erst irgendwo aufgeschnappt, dass man bei VMware, bei einem "NVME-Storage-Unterbau" bei den VM's einen bestimmten Controller-Typ wählen muss, damit man auch in diesen einen höhere Storage-Performance erzielen kann. Welcher Typ das jetzt genau ist, kann ich auf die Schnelle jedoch nicht sagen und zum Nachforschen fehlt mir momentan auch etwas die Zeit, da ich gleich zum Termin flitzen muss.
Gruss Alex
Moin,
@MysticFoxDE
Immer wieder ein Freude, dein Wissen über Storage & Co. hier zu lesen.
Bzgl. Des Controllers:
Thomas Krenn hat dazu Infos im „Gepäck“
https://www.thomas-krenn.com/en/wiki/VMware_Performance_Comparison_SCSI_ ...
Bringt mich auch dazu, das mal bei uns zu checken / ob es sinnvoll ist. Wir Haben zwar noch kein Fullflash-System im SAN (FC), aber ggf. müssen wir das ab nächstes Jahr mal checken
@MysticFoxDE
Immer wieder ein Freude, dein Wissen über Storage & Co. hier zu lesen.
Bzgl. Des Controllers:
Thomas Krenn hat dazu Infos im „Gepäck“
https://www.thomas-krenn.com/en/wiki/VMware_Performance_Comparison_SCSI_ ...
Bringt mich auch dazu, das mal bei uns zu checken / ob es sinnvoll ist. Wir Haben zwar noch kein Fullflash-System im SAN (FC), aber ggf. müssen wir das ab nächstes Jahr mal checken
1
Moin @em-pie,
danke und sehr gerne ... jedoch ärgere ich mich in letzter Zeit immer zunehmender darüber, dass wir und damit meine ich sowohl die Endkunden, Administratoren und auch Systemintegratoren, uns mittlerweile in diese abartigen Tiefe in die entsprechende Materie einarbeiten müssen, um irgendwie auch nur halbwegs an die insbesondere von dem Marketing und oder Vertrieb gerne bejubelte/versprochene und meist natürlich auch legändere Leistung der entsprechenden Komponenten heranzukommen. 😔😭
👍👍👍
Nice, danke, genau das habe ich gemeint.
Wir haben seit über 10 Jahren kein einziges Primär-SAN's mit HDD Bestückung verkauft und ich wüsste auch nicht, dass einer unserer Kunden das, sprich sich ein AllFlash-SAN zu holen, jemals irgendwie bereut hätte. 😁
Gruss Alex
Immer wieder ein Freude, dein Wissen über Storage & Co. hier zu lesen.
danke und sehr gerne ... jedoch ärgere ich mich in letzter Zeit immer zunehmender darüber, dass wir und damit meine ich sowohl die Endkunden, Administratoren und auch Systemintegratoren, uns mittlerweile in diese abartigen Tiefe in die entsprechende Materie einarbeiten müssen, um irgendwie auch nur halbwegs an die insbesondere von dem Marketing und oder Vertrieb gerne bejubelte/versprochene und meist natürlich auch legändere Leistung der entsprechenden Komponenten heranzukommen. 😔😭
Bzgl. Des Controllers:
Thomas Krenn hat dazu Infos im „Gepäck“
https://www.thomas-krenn.com/en/wiki/VMware_Performance_Comparison_SCSI_ ...
Thomas Krenn hat dazu Infos im „Gepäck“
https://www.thomas-krenn.com/en/wiki/VMware_Performance_Comparison_SCSI_ ...
👍👍👍
Nice, danke, genau das habe ich gemeint.
Bringt mich auch dazu, das mal bei uns zu checken / ob es sinnvoll ist. Wir Haben zwar noch kein Fullflash-System im SAN (FC), aber ggf. müssen wir das ab nächstes Jahr mal checken
Wir haben seit über 10 Jahren kein einziges Primär-SAN's mit HDD Bestückung verkauft und ich wüsste auch nicht, dass einer unserer Kunden das, sprich sich ein AllFlash-SAN zu holen, jemals irgendwie bereut hätte. 😁
Gruss Alex
Moin @haudegen93,
das muss ich mir in Ruhe mal genauer anschauen, sprich, wird wahrscheinlich erst am WE möglich sein.
RDMA ist wie schon geschrieben, für mich beim ESXi jedoch weitestgehend reines "Trockenschwimmen", da ich schon seit Jahren so gut wie keine VMware/ESXi Systeme betreue und als ich das noch aktiv gemacht habe, war RDMA wiederum noch kein Thema. 🙃
Dafür rupfe ich RDMA, respektive SR-IOV, bei Windows gerade ordentlich auseinander. 🤪
So, jetzt zu dem Wichtigsten, was ich eigentlich kurz schreiben wollte.
Bevor du dich um RDMA & Co. kümmerst, solltest du unbedingt sicherstellen, dass das System, insbesondere die CPU's und auch der RAM, mit der bestmöglichen Leistung läuft!
Denn, die PCI-E Lanes, an denen sowohl deine NIC's hängen als auch die NVME-SSD's (und auch HBA's, GPU's, u.s.w.), werden von den CPU's bereitgestellt und wenn die CPU's nicht mit voller Leistung, sprich, "gedrosselt" laufen, dann gilt dasselbe auch für die PCI-E Lanes, die diese bereitstellen. 😔
Daher musst du auch unbedingt als erstes sicherstellen, dass dein System, insbesondere BIOS seitig, optimal eingestellt ist und zwar auf Performance/Low Latency getrimmt und nicht zum Energiesparren, wie es per Default bei so gut wie allen aktuellen Servern, leider der Fall ist. 😭🤮
So jetzt muss ich aber weiterflitzen.
Wünsche allen einen schönen und erfolgreichen Freitag.
Gruss Alex
Thema RDMA:
nach Installation der Treiber war RDMA auch verfügbar. Jedoch als default nur RoCEv2.
Damit ließ sich RDMA Unterstützung im vSAN auch einschalten, was jedoch auf Fehlermeldungen stieß weil die restliche Netzwerk Konfig das ja nicht unterstützt.
Mit dem Befehl: esxcli system module parameters set -m irdman -p "ROCE=0,0,0,0" ließ sich iWARP statt RoCEv2
nach einem Neustart aktivieren.
Darufhin wird die Option RDMA Unterstützung aber ausgegraut mit folgender Meldung:
nach Installation der Treiber war RDMA auch verfügbar. Jedoch als default nur RoCEv2.
Damit ließ sich RDMA Unterstützung im vSAN auch einschalten, was jedoch auf Fehlermeldungen stieß weil die restliche Netzwerk Konfig das ja nicht unterstützt.
Mit dem Befehl: esxcli system module parameters set -m irdman -p "ROCE=0,0,0,0" ließ sich iWARP statt RoCEv2
nach einem Neustart aktivieren.
das muss ich mir in Ruhe mal genauer anschauen, sprich, wird wahrscheinlich erst am WE möglich sein.
RDMA ist wie schon geschrieben, für mich beim ESXi jedoch weitestgehend reines "Trockenschwimmen", da ich schon seit Jahren so gut wie keine VMware/ESXi Systeme betreue und als ich das noch aktiv gemacht habe, war RDMA wiederum noch kein Thema. 🙃
Dafür rupfe ich RDMA, respektive SR-IOV, bei Windows gerade ordentlich auseinander. 🤪
So, jetzt zu dem Wichtigsten, was ich eigentlich kurz schreiben wollte.
Bevor du dich um RDMA & Co. kümmerst, solltest du unbedingt sicherstellen, dass das System, insbesondere die CPU's und auch der RAM, mit der bestmöglichen Leistung läuft!
Denn, die PCI-E Lanes, an denen sowohl deine NIC's hängen als auch die NVME-SSD's (und auch HBA's, GPU's, u.s.w.), werden von den CPU's bereitgestellt und wenn die CPU's nicht mit voller Leistung, sprich, "gedrosselt" laufen, dann gilt dasselbe auch für die PCI-E Lanes, die diese bereitstellen. 😔
Daher musst du auch unbedingt als erstes sicherstellen, dass dein System, insbesondere BIOS seitig, optimal eingestellt ist und zwar auf Performance/Low Latency getrimmt und nicht zum Energiesparren, wie es per Default bei so gut wie allen aktuellen Servern, leider der Fall ist. 😭🤮
So jetzt muss ich aber weiterflitzen.
Wünsche allen einen schönen und erfolgreichen Freitag.
Gruss Alex
Oh da kamen ja ein paar Beiträge ohne, dass ich eine Email Benachrichtigung bekam (oder hab sie übersehen xD)
Das kannte ich bereits und genutzt wird natürlich nvme controller für die VMs
Im Bios habe ich jedoch nur die oben genannte Option zur Auswahl mit 2fach SNC oder diabled, was aktuell halt auf disabled steht.
Und weiter oben hatte ich bereits erwähnt, dass ich die BIOS als auch ESXI Einstellungen nach Vorgabe von Lenovo eingerichtet habe.
Bin aber grade dabei diese noch einmal Punkt für Punkt zu kontrollieren.
PS: Die 25Gbit Module hatte ich bei unserem Dienstleister zsm mit 2 weiteren Aggregation Pro Switches geordert ist aber leider noch unterwegs, weshalb derzeit noch 10Gbit im Einsatz sind. - Aber wie man oben sieht, werden auch die 10Gbit nicht ansatzweise ausgereizt, weshalb das Problem nicht an den derzeit fehlenden 25Gbit Uplink liegt.
Das kannte ich bereits und genutzt wird natürlich nvme controller für die VMs
Die Info, dass es so ist, sprich, dass die Xeon's ab Gen.4 nicht 2fach SNC sondern 4fach SNC unterstützen, ist für "Normalsterbliche" leider auch nicht wirklich einfach zu finden, da diese Infos normalerweise nur für die Hersteller/OEM's wichtig/verfügbar sind. 😔
Im Bios habe ich jedoch nur die oben genannte Option zur Auswahl mit 2fach SNC oder diabled, was aktuell halt auf disabled steht.
Und weiter oben hatte ich bereits erwähnt, dass ich die BIOS als auch ESXI Einstellungen nach Vorgabe von Lenovo eingerichtet habe.
Bin aber grade dabei diese noch einmal Punkt für Punkt zu kontrollieren.
PS: Die 25Gbit Module hatte ich bei unserem Dienstleister zsm mit 2 weiteren Aggregation Pro Switches geordert ist aber leider noch unterwegs, weshalb derzeit noch 10Gbit im Einsatz sind. - Aber wie man oben sieht, werden auch die 10Gbit nicht ansatzweise ausgereizt, weshalb das Problem nicht an den derzeit fehlenden 25Gbit Uplink liegt.
Bin mittlerweile echt am überlegen, ob es nicht besser wäre die VMs temporär umzuziehen und das vSAN komplett neu anzulegen - direkt neu installieren mit ISO von Lenovo selber.
Kurzes Update,
Die Einstellungen bis auf MWAIT sind soweit alle wie in dem Lenovo Dokument vorgegeben eingestellt - Sobald ich MWAIT deaktiviere starten die vCLS Maschinen nicht mehr und dann geht kein HA / DRS.
Die 25Gbit Module und die beiden Switches sollen wohl im laufe der Woche bei uns eintrudeln.
Die Einstellungen bis auf MWAIT sind soweit alle wie in dem Lenovo Dokument vorgegeben eingestellt - Sobald ich MWAIT deaktiviere starten die vCLS Maschinen nicht mehr und dann geht kein HA / DRS.
Die 25Gbit Module und die beiden Switches sollen wohl im laufe der Woche bei uns eintrudeln.
Moin @haudegen93,
👍
Wie schon geschrieben, eigentlich sollte du hier bei deinen CPU's SNC4 wählen können. 😔
Du solltest die Einstellungen mittels eines Benchmarks auch nachkontrollieren, sprich, ob die bei deinem System auch wirklich eine Verbesserung bringen, bei einem ESXi ist das jedoch gar nicht so einfach wie z.B. beim Hyper-V.
Wir überprüfen die CPU, RAM und die GPU Leistung der Systeme die wir ausliefern, immer mindestens mit Passmark Performancetest. Diesen gibt es für ESXi jedoch nicht wirklich und durch eine VM zu testen, ist in dem Fall eher suboptimal.
Gruss Alex
Das kannte ich bereits und genutzt wird natürlich nvme controller für die VMs
👍
Im Bios habe ich jedoch nur die oben genannte Option zur Auswahl mit 2fach SNC oder diabled, was aktuell halt auf disabled steht.
Wie schon geschrieben, eigentlich sollte du hier bei deinen CPU's SNC4 wählen können. 😔
Und weiter oben hatte ich bereits erwähnt, dass ich die BIOS als auch ESXI Einstellungen nach Vorgabe von Lenovo eingerichtet habe.
Bin aber grade dabei diese noch einmal Punkt für Punkt zu kontrollieren.
Bin aber grade dabei diese noch einmal Punkt für Punkt zu kontrollieren.
Du solltest die Einstellungen mittels eines Benchmarks auch nachkontrollieren, sprich, ob die bei deinem System auch wirklich eine Verbesserung bringen, bei einem ESXi ist das jedoch gar nicht so einfach wie z.B. beim Hyper-V.
Wir überprüfen die CPU, RAM und die GPU Leistung der Systeme die wir ausliefern, immer mindestens mit Passmark Performancetest. Diesen gibt es für ESXi jedoch nicht wirklich und durch eine VM zu testen, ist in dem Fall eher suboptimal.
Gruss Alex
Du solltest die Einstellungen mittels eines Benchmarks auch nachkontrollieren
Naja indirekt habe ich das ja damals getestet - Das war ja das ursprüngliche Problem der allgemein schlechten Performance - wo Programmstarts etc. gut 2-3x so lange dauerten wie sie sollten.
Dort war ja das Problem, dass im Bios Energy Saving - Prefer Power eingestellt war. Daraufhin habe ich ja im Bios auf Custom gestellt und alles was mit Energiesparen zu tun hat ausgestellt.
War dann bis auf den Punkt MWAIT 1:1 identisch mit den Vorgaben seitens Lenovo
Moin @haudegen93,
ähm ja, so wie es aussieht ...
https://knowledge.broadcom.com/external/article/326217/vcls-vms-fail-to- ...
... benötigen die vCLS VM's tatsächlich MWAIT.
Interessant, habe ich bis jetzt auch noch nicht gewusst.
By the way, du hast den Post als gelöst markiert ... was war den nun genau die Lösung?
Gruss Alex
Die Einstellungen bis auf MWAIT sind soweit alle wie in dem Lenovo Dokument vorgegeben eingestellt - Sobald ich MWAIT deaktiviere starten die vCLS Maschinen nicht mehr und dann geht kein HA / DRS.
ähm ja, so wie es aussieht ...
https://knowledge.broadcom.com/external/article/326217/vcls-vms-fail-to- ...
... benötigen die vCLS VM's tatsächlich MWAIT.
Interessant, habe ich bis jetzt auch noch nicht gewusst.
By the way, du hast den Post als gelöst markiert ... was war den nun genau die Lösung?
Gruss Alex
Moin @haudegen93,
Naja indirekt habe ich das ja damals getestet - Das war ja das ursprüngliche Problem der allgemein schlechten Performance - wo Programmstarts etc. gut 2-3x so lange dauerten wie sie sollten.
ja schon und das du das überhaupt so gemacht hast, finde ich übrigens 1A, denn die meisten beschäftigen sich in der Tiefe so wie es aussieht wohl eher nicht mit ihren Systemen. 😔
Jedoch eignet sich dieser Test eher nicht um die RAM, CPU und GPU Leistung zu ermitteln und an der letzteren merke ich z.B. ganz schnell, ob die PCIe Lanes auch mit ihrer vollen Performance laufen. Denn sobald die PCIe Lanes nicht optimal laufen, z.B. wegen irgendwelchen Energiespareinstellungen, merkt man das ganz schnell an einer bescheidenen GPU Leistung. 😉
Ist das jetzt die Lösung?
Sprich, hat das "Prefer Power" Profil von Lenovo etwa auch einen Schaden/BUG?
Gruss Alex
Du solltest die Einstellungen mittels eines Benchmarks auch nachkontrollieren
Naja indirekt habe ich das ja damals getestet - Das war ja das ursprüngliche Problem der allgemein schlechten Performance - wo Programmstarts etc. gut 2-3x so lange dauerten wie sie sollten.
ja schon und das du das überhaupt so gemacht hast, finde ich übrigens 1A, denn die meisten beschäftigen sich in der Tiefe so wie es aussieht wohl eher nicht mit ihren Systemen. 😔
Jedoch eignet sich dieser Test eher nicht um die RAM, CPU und GPU Leistung zu ermitteln und an der letzteren merke ich z.B. ganz schnell, ob die PCIe Lanes auch mit ihrer vollen Performance laufen. Denn sobald die PCIe Lanes nicht optimal laufen, z.B. wegen irgendwelchen Energiespareinstellungen, merkt man das ganz schnell an einer bescheidenen GPU Leistung. 😉
Dort war ja das Problem, dass im Bios Energy Saving - Prefer Power eingestellt war. Daraufhin habe ich ja im Bios auf Custom gestellt und alles was mit Energiesparen zu tun hat ausgestellt.
War dann bis auf den Punkt MWAIT 1:1 identisch mit den Vorgaben seitens Lenovo
War dann bis auf den Punkt MWAIT 1:1 identisch mit den Vorgaben seitens Lenovo
Ist das jetzt die Lösung?
Sprich, hat das "Prefer Power" Profil von Lenovo etwa auch einen Schaden/BUG?
Gruss Alex
Das mit als Lösung makiert war glaub ganz am Anfang, wo ich braindead dachte die drei Punkte beinhalten den Punkt "antworten" :D
Aber ja das generelle VM Performance Problem, was die Lösung die Bios Energieeinstellungen
Das vSAN Problem besteht weiterhin, das werde ich nochmal dann genau in Angriff nehmen, sobald die beiden Switches und die 25Gbit Module da sind.
Wenn einen das wurmt, warum 40k € Server so unterirdisch performen, dann will man ja schon rausfinden was da los ist. - denn im grunde liefert das all Flash vSAN aktuell nicht mal HDD performance...
Aber ja das generelle VM Performance Problem, was die Lösung die Bios Energieeinstellungen
Das vSAN Problem besteht weiterhin, das werde ich nochmal dann genau in Angriff nehmen, sobald die beiden Switches und die 25Gbit Module da sind.
ja schon und das du das überhaupt so gemacht hast, finde ich übrigens 1A, denn die meisten beschäftigen sich in der Tiefe so wie es aussieht wohl eher nicht mit ihren Systemen.
Wenn einen das wurmt, warum 40k € Server so unterirdisch performen, dann will man ja schon rausfinden was da los ist. - denn im grunde liefert das all Flash vSAN aktuell nicht mal HDD performance...
Moin @haudegen93,
du hast nur den Hauptpost auf gelöst gesetzt, jedoch nicht den entsprechenden Beitrag der zur Lösung beigetragen hat, als solches markiert.
😖 ... das darf echt nicht war sein. 😭
Macht ihr diesbezüglich bei Lenovo noch ein Ticket auf?
Halte uns hier diesbezüglich bitte auf dem laufenden, denn gemäss der Anzahl der Mitlesenden, interessieren sich wohl doch auch einige andere für dieses Thema. 😉
Sehr gute Einstellung und auch genau die richtige Fragestellung! 👍👍👍
Ich denke hier wird dir iWARP noch ein Stückchen mehr Leistung bringen, wenn der ESXi das auch wirklich sauber kann.
Gruss Alex
Das mit als Lösung makiert war glaub ganz am Anfang, wo ich braindead dachte die drei Punkte beinhalten den Punkt "antworten" :D
du hast nur den Hauptpost auf gelöst gesetzt, jedoch nicht den entsprechenden Beitrag der zur Lösung beigetragen hat, als solches markiert.
Aber ja das generelle VM Performance Problem, was die Lösung die Bios Energieeinstellungen
😖 ... das darf echt nicht war sein. 😭
Macht ihr diesbezüglich bei Lenovo noch ein Ticket auf?
Das vSAN Problem besteht weiterhin, das werde ich nochmal dann genau in Angriff nehmen, sobald die beiden Switches und die 25Gbit Module da sind.
Halte uns hier diesbezüglich bitte auf dem laufenden, denn gemäss der Anzahl der Mitlesenden, interessieren sich wohl doch auch einige andere für dieses Thema. 😉
Wenn einen das wurmt, warum 40k € Server so unterirdisch performen, dann will man ja schon rausfinden was da los ist. - denn im grunde liefert das all Flash vSAN aktuell nicht mal HDD performance...
Sehr gute Einstellung und auch genau die richtige Fragestellung! 👍👍👍
Ich denke hier wird dir iWARP noch ein Stückchen mehr Leistung bringen, wenn der ESXi das auch wirklich sauber kann.
Gruss Alex
du hast nur den Hauptpost auf gelöst gesetzt, jedoch nicht den entsprechenden Beitrag der zur Lösung beigetragen hat, als solches markiert.
Hmm keine Ahnung wie das passieren konnte - ist jetzt wieder raus
Halte uns hier diesbezüglich bitte auf dem laufenden, denn gemäss der Anzahl der Mitlesenden, interessieren sich wohl doch auch einige andere für dieses Thema
Das werde ich natürlich tun
