ISCSI Konfiguration HP MSA

Moin Andy,

habe das Thema gerade selbst durch, deshalb kann ich vielleicht ein wenig weiterhelfen


Ja, absolut!


Auffallend korrekt.
Dran denken, für die iSCSI-Netzwerkschnittstellen ALLE Bindungen außer TCP aufzuheben! Alles andere erzeugt unnütze Last.

Ist sogar eigentlich Pflicht, besser noch beidseitig.

Na und?

Korrekt. Muss an allen beteiligten Geräten aktiviert sein.

Gruß

Im Prinzip ist das nicht falsch, wenn alle in 10.10.10.x liegen. Habe aber beim Recherchieren gelesen, dass das Probleme machen KANN oder seltsame Effekte hervorruft. Definitiv hast Du jedenfalls die Netze getrennt, wenn Du nach dem Beispiel vorgehst.

Supportet diese Maschine kein 802.3ad Link Aggregation (Teaming, Bonding) mit LACP ??
Wenn nicht wäre das ja sehr ungewöhnlich und dann wäre die obige Vorgehensweise mit Einzel IPs schlicht falsch !
Normal fasst man ja entweder 2mal 2 oder alle 4 Links in einen virtuellen zusammen (Link Aggregation) um bei SCSI erheblich mehr Performance rauszuholen aus solch einem Anschluss. Das wäre der übliche Weg. Bei GiG Anschlüssen wären das dann 2 mal 2Gig oder ein 4 Gig LAG.
Klar ist dann auch das die Switch Infrastruktur das auch supporten muss, was aber alle heutigen aktuellen Billigswithces supporten sofern managebar. Markenswitches sowieso.

Wenn die ein Link Aggregation supporte ist das Konfigurieren von einzelnen IPs auf den Ports aber kontraproduktiv und auch falsch, denn eine Link Aggregation klappt immer nur im Layer 2 ! Die zentrale IP sitzt dann auf dem virtuellen Bonding Interface !
Das wäre dann eine State of the Art Installation für eine performante iSCSI Anbindung und solltest du zwingend überprüfen bevor du mit einer falschen Netzwerk Installation in Performanceengpässe kommst.
Denk immer dran das du erheblich verwöhnt bist von FC Performance und Zuverlässigkeit. Mit IP und einem Ethernet sieht die Welt da ganz anders aus wenn man es falsch macht !
Hiesige Forums Threads zum Thema Link Aggregation findest du hier:
Grunsatzfrage LAG
Link Aggregation zur Speederhöhung zwischen 2 Switches herstellen
Motherboard mit 2 Onboard LAN Anschlüssen
Traffic am Server auf 2 NICs verteilen
Kann man einen Server zur Performacesteigerung mit 2 Netzwerkkarten parallel an einem Switch betreiben? Wenn ja mit welcher Konfiguration ?
Bonding mit Broadcom - SLB
Link Aggregation - Frage zur Hash Configuration

Moin,
wenn Switches zum Einsatz kommen, welche Stackable sind kannst du ein Subnetz konfigurieren. Auf den Uplinks (Switch-Storages) LACP konfiguieren und jeweils ein Controllerport auf den anderen Switch. Falls das nicht machbar ist, solltest du zwei (physikalische) getrennte Netze aufbauen. Somit ha jeder Controllerport eine seperate IP-Adresse. In beiden Fällen sollst du Switches mit hoher Buffersize nutzen, nicht das es dort zum Engpass kommt.


Gruß,
Dani

Das ganze ist Abhängig von den Hostsystemen die mit der Storage verbunden werden sollen.

Die getrennten Subnetze macht mann u.A. deswegen weil z.B. VMware nur 8 Pfade zur gleichen LUN "kann". Dabei muss kann man die Pfade aber auch trennen indem man 2 Switche ungestackt verwedentet und jeden mit jeweils nur einem Port pro Controller verbindet.

Richtig. Wobei dann natürlich (A-1/B-1) und (A-2/B-2) auch auf separaten Switches stecken müssen.

Was genau meinst du?

Vielleicht wär's auch sinnvoll wann du mal deine komplette SAN/Switch/Host Infrastruktur aufzeigtst, dann bekommst du auch bessere Tipps

Wenn du VMWare einsetzt solltest Du eher mit MPIO arbeiten als mit LACP.

BP von VMware gibts hier: http://www.vmware.com/files/pdf/iSCSI_design_deploy.pdf (ist dein Google eigentlich kapput? )

TL;DR:
Kein LACP sondern MPIO, Alle Pfade auf Round Robin umstellen, und Pfadswitch nach jedem IO

Nein - LACP / 802.3ad muss auf BEIDEN SEITEN konfiguriert sein.

Was meinst du damit genau ??
Der "Pfad" in einem reinen L2 Netz ist immer fest vorgegeben durch Mac Adresse oder Uplink. Es kann in einem L2 Ethernet niemals mehrere Pfade geben !
Oder war das gemeint auf einen LACP Trunk bezogen ??
Auch da können so gut wie alle Switches nie mehr als 8 Links bündeln. Billighersteller supporten oft nur 4. Dort hast du also durch die Infrastruktur schon identische Vorgaben.
Oder meintest du jetzt was ganz anderes mit den "Pfaden" ??

Warum ? Man definiert doch unterschiedliche Trunk Group IDs dafür auf dem Switch und trennt so sicher die LAGs !
Die fast man zusammen mit einem LACP Trunk. Wie das geht unter VmWare ESXi kannst du hier nachlesen bzw. auch optisch sehen:
https://www.youtube.com/watch?v=VRZJL5QDBCU

Auf der Switch Seite musst du das natürlich auch einrichten. Wie das bei den HP Billiggurken geht sagt dir dieses Tutorial:
Netzwerk Management Server mit Raspberry Pi
Für dich sind da nur die gezeigten Switch Konfigs relevant !

Das ist doch ein simples, klassisches Trunking Design im iSCSI Umfeld ?!

@acqi
Beispiel:
Pfad = Initiator-NIC/Target-NIC Kombination.
Beispiel:
1 ESXi mit 2 ISCSI NICs (E1, E2) und 1 SAN mit 4 NICS (S1-S4) ergiebt 8 Pfade:
E1-S1, E1-S2, E1-S3, E1-S4
E2-S1, E2-S2, E2-S3, E2-S4
hat einer von beiden mehr NICs müssen die auf (L2 od. L3) getrennt werden, sonst erkennt VMware nicht mehr

Wg. Redundanz?

/EDIT:

Richtig. MPIO ist mE im SAN Umfeld (v.A. mit VMs) allerdings LACP überlegen.
Bei LACP fliest idR jeder einzelne Link (zur LUN) immer über den gleichen (Ethernet) Pfad.
Bei MPIO wird (falls korrekt konfiguriert) jeder einzelne IO über einen anderen Pfad ausgeführt. Die verfügbaren Pfade werden so also besser ausgelastet. Auch ist der Impact im falle eines Pfadausfalles um einiges kleiner.

OK, sorry, ich hatte die NUR Netzwerker Scheuklappen auf und die Endgeräte ignoriert. So macht es natürlich Sinn.
Richtig, bei Billigswitches wie vermutlich die vom TO macht das Sinn. Verantwortugsvolle RZ Netzwerker setzen dafür Fabric fähige Switches ein oder solche die virtuelle LAGs supporten. (VCS oder VPC etc.) Mindestens aber welche die sich horizontal stacken lassen.
So kann man auch die Trunks in sich aufsplitten um noch mehr Sicherheit und auch Felxibilität zu bekommen um nur mal die wichtigstens Vorteile zu nennen.
Bei solchen Banal Installationen wie der obigen ist das aber ggf. zuviel des Guten. Zumal auch die dort verwendete billige Infrastruktur es gar nicht hergibt.

Da geb ich dir Recht. Nachdem allerdings eine MSA eingesetzt wird würde ich auch die Swtiche eher im ProCurve 2920er Bereich sehen - Was übrigens im SMB Bereich bis 3 Hosts / 10-15 VMs völlig ausreicht.