ISCSI Multipathing oder Teaming
Hallo,
stehe Gerade vor der Frage ob ich meine Storage Verbindung (2x10G) entweder zusammenlege (LACP) oder Getrennt lasse und iSCSI Multipathing verwende.
Die Server und der Storage hängen an 2 Cisco SG550xg-24f die im Stack laufen.
Was würdet ihr machen?
Gruß
Phill93
stehe Gerade vor der Frage ob ich meine Storage Verbindung (2x10G) entweder zusammenlege (LACP) oder Getrennt lasse und iSCSI Multipathing verwende.
Die Server und der Storage hängen an 2 Cisco SG550xg-24f die im Stack laufen.
Was würdet ihr machen?
Gruß
Phill93
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 373636
Url: https://administrator.de/forum/iscsi-multipathing-oder-teaming-373636.html
Ausgedruckt am: 28.04.2025 um 14:04 Uhr
5 Kommentare
Neuester Kommentar
Im Endeffekt ist es doch nur die Frage auf welche ebene du es umsetzt.
Ich bevorzuge LACP da dies ersteinmal Software seidig unabhängig ist.
ISCSI multipathing habe ich noch nie im live betrieb gesehen.
Ich bevorzuge LACP da dies ersteinmal Software seidig unabhängig ist.
ISCSI multipathing habe ich noch nie im live betrieb gesehen.
Wir nutzen iSCSI Multipathing unter VMware mit einer HP SAN, allerdings derzeit nur 1G Verbindungen. Kann mich nicht beklagen. Nur die Paketsize wurde im ESX runter gesetzt.
Moin,
Ansonsten hab ich schon mehrere Implementation mit VMWare und HPE MSAs gemacht, und kann dir sagen: das klappt gut. Vor allem kannst du so auch die Switches redundant auslegen
Unter Hyper-V... würde ich auch lieber auf LACP setzen :P
lg,
Slainte
Nur die Paketsize wurde im ESX runter gesetzt.
Warum runter? IdR setzt man die rauf (falls alle HW mit Jumbo Paketen kann)Ansonsten hab ich schon mehrere Implementation mit VMWare und HPE MSAs gemacht, und kann dir sagen: das klappt gut. Vor allem kannst du so auch die Switches redundant auslegen
Unter Hyper-V... würde ich auch lieber auf LACP setzen :P
lg,
Slainte
Packetsize ist wohl eher das falsche Wort, die steht natürlich auf Jumbo Frames.
https://kb.vmware.com/s/article/2069356
Stimmt wir haben es eingeführt weil zwei Switches den Verkehr abgewickelt haben. Die waren dafür günstig und haben auch tadellos funktioniert.
https://kb.vmware.com/s/article/2069356
Stimmt wir haben es eingeführt weil zwei Switches den Verkehr abgewickelt haben. Die waren dafür günstig und haben auch tadellos funktioniert.
Hi
ich würde auch eher auf Multipath wie Teaming gehen, so kannst du auch auf verschiedenen Switche einen Uplink haben und im Backend nicht zwingend MCT fähige Geräte haben um mehrere Pfade zu ermöglichen. Jumbo-Frames auch immer wieder eine Sache - der eine Hersteller macht 9k Blöcke der andere 9,2k dann wieder einer 10k (Brocade/extreme VDX Serien) ... das muss aufeinander abgestimmt werden.
Ich würde zu dem Karten verbauen die für iSCSI optimiert sind - ist zwar nicht zwingend erforderlich bringt aber ein paar % mehr Leistung.
ISCSI würde ich immer über dedizierte Switche laufen lassen, es sein denn die Geräte können DCB oder vergleichbares, vor allem wenn VoIP mit im Spiel ist
.
Gruß
@clSchak
ich würde auch eher auf Multipath wie Teaming gehen, so kannst du auch auf verschiedenen Switche einen Uplink haben und im Backend nicht zwingend MCT fähige Geräte haben um mehrere Pfade zu ermöglichen. Jumbo-Frames auch immer wieder eine Sache - der eine Hersteller macht 9k Blöcke der andere 9,2k dann wieder einer 10k (Brocade/extreme VDX Serien) ... das muss aufeinander abgestimmt werden.
Ich würde zu dem Karten verbauen die für iSCSI optimiert sind - ist zwar nicht zwingend erforderlich bringt aber ein paar % mehr Leistung.
ISCSI würde ich immer über dedizierte Switche laufen lassen, es sein denn die Geräte können DCB oder vergleichbares, vor allem wenn VoIP mit im Spiel ist
.Gruß
@clSchak
