1
Blog. Infiniband Mysterien
Soderle nun geht es so langsam mal weiter mit meinen Infiniband Experimenten unter ESX 6.7
Vorab mal bemerkt, unter Ubuntu laufen ALLE Infinibandkarten von Mellanox egal, was für einen Firmwarestand sie haben. Aber nicht unter ESX und Windows.
Ich hatte also zunächst zwei IBM 46M2205 (eigentlich Singeport Mellanox ConnectX2 VPI)
Hab 5 Infiniband Kabel ausprobiert... lag aber nicht daran.
Und Infinibandkabel lassen sich direkt von Karte zu Karte verwenden. Der Switch wird vom Prinzip her nur gebraucht, wenn man mehr als 2 oder 3 Geräte miteinander vernetzen will.
Hab einen unmanaged Switch Mellanox IS5030 probiert... der meldet daß der Transceiver ok ist, Kabel umgedreht, immer noch ok, also 2 heile Transceiver. Mit allen 5 Kabeln , die ich hab. Der IS5030 ist wieder zurückgegangen, weil als managed verkauft, 36 Ports und 40 GBit, hat aber ohne die Lizenz nur 20 GBit, 18 der 36 Ports freigeschaltet und keinerlei Management Funktion. Mellanox kann aber auch nicht mehr auf Kulanz was machen, weil schlichtweg der License Generator dazu nicht mehr existiert. Die 5030er haben eine ausziehbare Gummizunge, und wenn auf der Rückseite nichts steht, dann hat das Ding vermutlich keine Lizenz, und wenn im Webinterface nichts zu sehen ist unter Licesnes... forget it. Die Lizenzen sind ans Gerät gebunden, und wenn der Vorbesitzer die löscht, dann ist die unwiderruflich weg. Hab alles probiert... aber der Anbieter war kulant und hat ihn zurückgenommen.
Windows war so ehrlich , mir den Grund zu nennen, warum der Treiber nicht geladen wurde. Firmware zu alt.
ABER die Tools.... die flashen nur vom Betriebsystem erkannte Geräte. Selbiges unter ESX. Der Verkäufer war super kulant und hat die Karten zurückgenommen. Danke...
Nächster Kauf 593412-001 MHQH29B-XTR HP INFINIBAND 4X QDR CONNECTX-2 VPI DP 40GB/s HCA (Dualport)
Viier gekauft, 16 Euro aus China incl Versand. Drei werden vom ESX erkannt, die vierte Karte meldet als Mac Addresse 00:00:00:00:00:01 und 00:00:00:00:00:02.
Glücklicherweise waren die drei benutzbaren Karten im VPI-Modus und als Ethernet konfiguriert. Ob es 10 oder 40 Gigabit sind, weiß ich zwar noch nicht, hab aber einen Switch und eine Portgruppe auf meinen beiden Hosts gebaut, ein Interface der VM hinzugefügt, und siehe da - automatisch vergebene IP Addressen im 169.154/16 Bereich. Pingbar. Nutzbar. Nur nach einem Reboot sind die Addressen anders.
Die Gäste haben den VMXNET3 Treiber, und der HRPing...
Auf den Ethernetkarten : 380-600 Mikrosekunden, extrem stark schwankend.
Auf den Infinibandkarten: 220 Mikrosekunden
End-to-End Test mit einer latenzsensitiven und datenhungrigen Applikation, die eine Myriade an Mikrotransaktionen laufen läßt:
30 % Performancegewinn. Natürlich Smartscreen und firewall aus, in meinem Lab gehe ich barfüßig durchs Leben. Auf meim Xeon E5 v2 erreiche ich dieselbe Performance wie der Kunde mit Xeon E5 v4 bei verglleichbarem Takt und Backbone (Kunde hat aber nur 25 Gbit, ich hab 40)
Da die Datenbank auf einem Datastore mit PCIE3 / NVME Adapter liegt (Samsung 970 Evo 1 TB) hab ich beim Cold Read fast dieselbe Performance wie mit Cache. Adieu InMemory, Adieu Ram-Overprovisioning. A propos InMemory: hat mein Brötchengeber gebaut und Vergleiche gemacht
- 100% Memoryabdeckung für 100% Cache Trefferquote, warmer Cache
vs
- In Memory. InMemory bedeutet daß man 225% der zu erwartenden Datenbankgröße (Daten plus Indizes) zur Verfügung stellen muß.
Und siehe da... lesende Transaktionen waren 20% langsamer, bei schreibenden Transaktionen waren keine Vorteile gegenüber einem Storage mit Allflash / Write back Puffer meßbar. Also für den MS SQL Server nur Speichervergeudung.
Nun ja... Google meinte, für IP Addressen auf IB Adaptern bruacht man einen Managed Switch mit "subnet manager" oder eine ESX App die auch so heißt.
Weit gefehlt... in den Gästen hab ich dreisterweise feste IP Addressen vergeben, und auch das hat funktioniert.
Bleibt also noch der Mellanox SX6036 Switch, den mir DHL 2 Wochen zurückgehalten hat, weil ich deren Verzollungsgebühr von 16 Euro nicht bezahlen wollte... Wofür der gut ist, werde ich wohl nächste Woche mal irgendwann erfahren.
Wer noch etwas tiefer gräbt... mein SQL Server läuft auf dem "großen" Host, das ist ein Dual CPU System. Ich hab herausgefunden, welche CPU mit welchem PCIE Steckplatz direkt über PCIE Lanes verbunden ist, und hab der VM eine Affinität zugewiesen, daß sie auf der CPU läuft, an der auch der IB Adapter hängt. Evtl ist dann der NVME Adapter nur über die CPU-to-CPU Bridge erreichbar, check ich aber später noch mal. Ohne diese Affinität hatte ich nur ca. 300 Mikrosekunden Latenz beim Netzwerkadapter, und mit 220 bin ich sehr nah dran an dem, was man aktuell kriegen kann. Sprich besser ist es nur noch hyperconverged, also alles auf einem Host. Aber das ist dann wieder nicht ganz so realistiisch...
Noch ein Tip wegen den Kabeln... es müssen QSFP+ Kabel sein. Viele Anbieter schummeln und wollen einem ein SFP oder QSFP Kabel unterjubeln. QSFP sind effektiv 4 Gigabit, und nicht 40. Bzw SFP ist 1 Gigabit. Also ordentlich bestellen solange die 45 Euro Freimengenregelung für Zoll noch gilt.
Die einzige sonstige Alternative für eine Direktverbindung per TCP IP wäre eine QLogic 2460 Fibrechannel-Karte - aber nur der Treiber unter Server 2003R2 zeigt die als Netzwerkkarte, neuere Windows-Versionen nicht mehr. Bei der 8 und 16 Gigabit-Variante gab es nie TCP-IP.
Vorab mal bemerkt, unter Ubuntu laufen ALLE Infinibandkarten von Mellanox egal, was für einen Firmwarestand sie haben. Aber nicht unter ESX und Windows.
Ich hatte also zunächst zwei IBM 46M2205 (eigentlich Singeport Mellanox ConnectX2 VPI)
Hab 5 Infiniband Kabel ausprobiert... lag aber nicht daran.
Und Infinibandkabel lassen sich direkt von Karte zu Karte verwenden. Der Switch wird vom Prinzip her nur gebraucht, wenn man mehr als 2 oder 3 Geräte miteinander vernetzen will.
Hab einen unmanaged Switch Mellanox IS5030 probiert... der meldet daß der Transceiver ok ist, Kabel umgedreht, immer noch ok, also 2 heile Transceiver. Mit allen 5 Kabeln , die ich hab. Der IS5030 ist wieder zurückgegangen, weil als managed verkauft, 36 Ports und 40 GBit, hat aber ohne die Lizenz nur 20 GBit, 18 der 36 Ports freigeschaltet und keinerlei Management Funktion. Mellanox kann aber auch nicht mehr auf Kulanz was machen, weil schlichtweg der License Generator dazu nicht mehr existiert. Die 5030er haben eine ausziehbare Gummizunge, und wenn auf der Rückseite nichts steht, dann hat das Ding vermutlich keine Lizenz, und wenn im Webinterface nichts zu sehen ist unter Licesnes... forget it. Die Lizenzen sind ans Gerät gebunden, und wenn der Vorbesitzer die löscht, dann ist die unwiderruflich weg. Hab alles probiert... aber der Anbieter war kulant und hat ihn zurückgenommen.
Windows war so ehrlich , mir den Grund zu nennen, warum der Treiber nicht geladen wurde. Firmware zu alt.
ABER die Tools.... die flashen nur vom Betriebsystem erkannte Geräte. Selbiges unter ESX. Der Verkäufer war super kulant und hat die Karten zurückgenommen. Danke...
Nächster Kauf 593412-001 MHQH29B-XTR HP INFINIBAND 4X QDR CONNECTX-2 VPI DP 40GB/s HCA (Dualport)
Viier gekauft, 16 Euro aus China incl Versand. Drei werden vom ESX erkannt, die vierte Karte meldet als Mac Addresse 00:00:00:00:00:01 und 00:00:00:00:00:02.
Glücklicherweise waren die drei benutzbaren Karten im VPI-Modus und als Ethernet konfiguriert. Ob es 10 oder 40 Gigabit sind, weiß ich zwar noch nicht, hab aber einen Switch und eine Portgruppe auf meinen beiden Hosts gebaut, ein Interface der VM hinzugefügt, und siehe da - automatisch vergebene IP Addressen im 169.154/16 Bereich. Pingbar. Nutzbar. Nur nach einem Reboot sind die Addressen anders.
Die Gäste haben den VMXNET3 Treiber, und der HRPing...
Auf den Ethernetkarten : 380-600 Mikrosekunden, extrem stark schwankend.
Auf den Infinibandkarten: 220 Mikrosekunden
End-to-End Test mit einer latenzsensitiven und datenhungrigen Applikation, die eine Myriade an Mikrotransaktionen laufen läßt:
30 % Performancegewinn. Natürlich Smartscreen und firewall aus, in meinem Lab gehe ich barfüßig durchs Leben. Auf meim Xeon E5 v2 erreiche ich dieselbe Performance wie der Kunde mit Xeon E5 v4 bei verglleichbarem Takt und Backbone (Kunde hat aber nur 25 Gbit, ich hab 40)
Da die Datenbank auf einem Datastore mit PCIE3 / NVME Adapter liegt (Samsung 970 Evo 1 TB) hab ich beim Cold Read fast dieselbe Performance wie mit Cache. Adieu InMemory, Adieu Ram-Overprovisioning. A propos InMemory: hat mein Brötchengeber gebaut und Vergleiche gemacht
- 100% Memoryabdeckung für 100% Cache Trefferquote, warmer Cache
vs
- In Memory. InMemory bedeutet daß man 225% der zu erwartenden Datenbankgröße (Daten plus Indizes) zur Verfügung stellen muß.
Und siehe da... lesende Transaktionen waren 20% langsamer, bei schreibenden Transaktionen waren keine Vorteile gegenüber einem Storage mit Allflash / Write back Puffer meßbar. Also für den MS SQL Server nur Speichervergeudung.
Nun ja... Google meinte, für IP Addressen auf IB Adaptern bruacht man einen Managed Switch mit "subnet manager" oder eine ESX App die auch so heißt.
Weit gefehlt... in den Gästen hab ich dreisterweise feste IP Addressen vergeben, und auch das hat funktioniert.
Bleibt also noch der Mellanox SX6036 Switch, den mir DHL 2 Wochen zurückgehalten hat, weil ich deren Verzollungsgebühr von 16 Euro nicht bezahlen wollte... Wofür der gut ist, werde ich wohl nächste Woche mal irgendwann erfahren.
Wer noch etwas tiefer gräbt... mein SQL Server läuft auf dem "großen" Host, das ist ein Dual CPU System. Ich hab herausgefunden, welche CPU mit welchem PCIE Steckplatz direkt über PCIE Lanes verbunden ist, und hab der VM eine Affinität zugewiesen, daß sie auf der CPU läuft, an der auch der IB Adapter hängt. Evtl ist dann der NVME Adapter nur über die CPU-to-CPU Bridge erreichbar, check ich aber später noch mal. Ohne diese Affinität hatte ich nur ca. 300 Mikrosekunden Latenz beim Netzwerkadapter, und mit 220 bin ich sehr nah dran an dem, was man aktuell kriegen kann. Sprich besser ist es nur noch hyperconverged, also alles auf einem Host. Aber das ist dann wieder nicht ganz so realistiisch...
Noch ein Tip wegen den Kabeln... es müssen QSFP+ Kabel sein. Viele Anbieter schummeln und wollen einem ein SFP oder QSFP Kabel unterjubeln. QSFP sind effektiv 4 Gigabit, und nicht 40. Bzw SFP ist 1 Gigabit. Also ordentlich bestellen solange die 45 Euro Freimengenregelung für Zoll noch gilt.
Die einzige sonstige Alternative für eine Direktverbindung per TCP IP wäre eine QLogic 2460 Fibrechannel-Karte - aber nur der Treiber unter Server 2003R2 zeigt die als Netzwerkkarte, neuere Windows-Versionen nicht mehr. Bei der 8 und 16 Gigabit-Variante gab es nie TCP-IP.
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: 667103
Url: https://administrator.de/contentid/667103
Ausgedruckt am: 23.11.2024 um 10:11 Uhr
1 Kommentar
Zitat von @GrueneSosseMitSpeck:
Soderle nun geht es so langsam mal weiter mit meinen Infiniband Experimenten unter ESX 6.7
...
Glücklicherweise waren die drei benutzbaren Karten im VPI-Modus und als Ethernet konfiguriert. Ob es 10 oder 40 Gigabit sind, weiß ich zwar noch nicht, hab aber einen Switch und eine Portgruppe auf meinen beiden Hosts gebaut, ein Interface der VM hinzugefügt, und siehe da - automatisch vergebene IP Addressen im 169.154/16 Bereich. Pingbar. Nutzbar. Nur nach einem Reboot sind die Addressen anders.
...
Soderle nun geht es so langsam mal weiter mit meinen Infiniband Experimenten unter ESX 6.7
...
Glücklicherweise waren die drei benutzbaren Karten im VPI-Modus und als Ethernet konfiguriert. Ob es 10 oder 40 Gigabit sind, weiß ich zwar noch nicht, hab aber einen Switch und eine Portgruppe auf meinen beiden Hosts gebaut, ein Interface der VM hinzugefügt, und siehe da - automatisch vergebene IP Addressen im 169.154/16 Bereich. Pingbar. Nutzbar. Nur nach einem Reboot sind die Addressen anders.
...
Dir ist aber schon bewußt, daß der Adressbereich 169.154.0.0/16 der Nasa gehört?.
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2021, American Registry for Internet Numbers, Ltd.
#
NetRange: 169.154.0.0 - 169.154.255.255
CIDR: 169.154.0.0/16
NetName: GSFC-ATM
NetHandle: NET-169-154-0-0-1
Parent: NET169 (NET-169-0-0-0-0)
NetType: Direct Allocation
OriginAS:
Organization: National Aeronautics and Space Administration (NASA)
RegDate: 1994-12-15
Updated: 2009-07-09
Ref: https://rdap.arin.net/registry/ip/169.154.0.0
OrgName: National Aeronautics and Space Administration
OrgId: NASA
Address: IS05/Office of the Chief Information Officer
City: MSFC
StateProv: AL
PostalCode: 35812
Country: US
RegDate:
Updated: 2020-04-09
Ref: https://rdap.arin.net/registry/entity/NASA
Aber Spaß beiseite:Du hast vermutlich einen Vertipper meinst 169.254.0.0/16. Der ist so gedacht, daß sich der Host nach jedem Start einen neue IP-würfelt, die nicht im Konflikt mit anderen im Netz steht. Daher sollte es einen Netzwerker eigentlich nicht verwundern, dß die IP-Adressen aus dem bereich 169.254 einen reboot nicht überstehen.
Ansonsten ist das ganze etwas wirr geschrieben, auch wenn man doch einige Infos daraus herauslesen kann.
Du solltest das Ganze Dir nochmal anschauen und villeicht aufhübschen.
lks
