2x 10Gb SFP+ Verbindung

[qiller]

Hu zusammen,

Wollte mal Eure Meinung hören, ob das vernünftig funktionieren wird:

https://geizhals.de/cisco-10g-3m-lan-dac-sfp-h10gb-cu3m-a1227580.html
https://geizhals.de/hp-officeconnect-1950-24g-rackmount-gigabit-smart-switch-jg960a-a1273433.html?hloc=at&hloc=de
https://geizhals.de/intel-x710-da2-x710da2blk-a1163659.html?hloc=at&hloc=de

Geplant ist, den Server mit obiger SFP+-Karte per 2xTwinax-DAC Kabel an die beiden SFP+ Ports des HP-Switchs anzuklemmen - und zwar per Link Aggregation/LACP/Bonding bzw. switchabhängiges Teaming (auf dem Windows Server). Auf dem Server laufen dann mehrere virtuelle Server, die dann an die geteamte NIC angeklemmt werden.

An die beiden RJ45-10Gb Ports des Switches werden wohl 1 Poweruser mit 10Gb-Karte und 1 Uplink zu nem weiteren Switch angeschlossen. Ich wollte das ursprünglich andersrum machen (Server per 2x 10Gb RJ45 + anderer RJ45-10Base-T-Karte und Poweruser/Uplink per SFP+). Hab aber gelesen, dass die DAC-Twinax-Verbindung nur eine halb so große Latenz gegenüber normales 10Base-T haben soll und außerdem bräuchte ich nicht unbedingt eine optische Verbindung zum Poweruser/Uplink, da die Entfernungen nicht sehr groß sind. Eine kleinere Latenz zum Hauptanschluss des Servers würde ich daher gern mitnehmen.

Es wird keinen 2. Server oder 3. Switch geben, das Netzwerk bleibt eher klein.

Hab ich nen Denkfehler oder kann man das so machen?

[konkretor]

sowas ähnliches wurde hier schon diskutiert

https://www.forum-3dcenter.org/vbulletin/showthread.php?t=591809


Noch kurz zur Info du nimmst Hyper-V für die Virtualisierung?


https://www.windowspro.de/marcel-kueppers/statt-nic-teaming-switch-embedded-teaming-set-hyper-v-2016



Beim ESXI brauchst du eine Enterprise für LACP

[qiller]

Thx für die Links, ja es wird Hyper-V verwendet. Das SET kannt ich noch gar nicht - wird aber bei der NIC nicht viel bringen, da sie kein RDMA kann. Außerdem ist das nen Single-Server ohne getrennte Cluster/Storage-Geschichten. Ich denke die geringsten Latenzen hat man wohl immer noch mit lokalem Storage (eingesetzt werden u.a. auch NVMe-SSDs) :>.

[myMind]

Geplant ist, den Server mit obiger SFP+-Karte per 2xTwinax-DAC Kabel an die beiden SFP+ Ports des HP-Switchs anzuklemmen - und zwar per Link Aggregation/LACP/Bonding bzw. switchabhängiges Teaming (auf dem Windows Server). Auf dem Server laufen dann mehrere virtuelle Server, die dann an die geteamte NIC angeklemmt werden.
...
Hab ich nen Denkfehler oder kann man das so machen?
Kann man meiner Meinung nach so machen.

Bei einem kleinen Server lohnt sich die 2. SFP+ Verbindung wahrscheinlich aber nicht. 10 Gbps müssen deine Speichermedien erst einmal wuppen. Ich würde mir den Aufwand mit der 2. Verbindung erst einmal sparen. Das spart dir etwas Rechenleistung auf deinem vSwitch.

[qiller]

Wollte nur mal Rückmeldung geben, dass der neue Server (AMD Epyc 24-Kerner, 8x8GB DDR4-2666 ECC-Registered-RAM) erfolgreich am HP-Switch angeschlossen werden konnte. Es läuft wie geplant Hyper-V drauf. Die Dual-10Gb-SFP-Karte wurde als Switch Embedded Teaming konfiguriert, was ebenfalls problemlos läuft. Ich hatte zwischendurch auch normales, switchabhängiges Teaming per Link Aggregation getestet. Auch das funktioniert. Da dann aber einige Funktionen am Switch nicht mehr zur Verfügung stehen und ich eh Hyper-V einsetzen wollte, kann man ja auch direkt SET einrichten.

Die meiste Bastelei gabs letztendlich beim IPMI des Supermicro-Mainboards (Lüftersteuerung übers BIOS? Hat Supermicro wohl noch nichts von gehört -> umständliches Gefummel per ipmitool notwendig) und der Umstellung des Netzwerks auf verschiedene VLANs (feste IP-Adressen anpassen, Firewall-Regeln anpassen, Proxy anpassen, Routen hinterlegen) und der Einrichtung der DHCP-Scopes auf dem Windows-DHCP-Server bzw. DHCP-Relays auf dem Switch.

Im Grunde ist so ein managebarer Switch ne feine Sache. Endlich kann man zentral rogue DHCP-Server oder ARP-Angriffe unterbinden. Sogar Firewall-Regeln (inkl. UDP/TCP-Ports) lassen sich erstellen. Denke Layer-4-Switch trifft es bei solch einem Gerät wohl eher :>.