ESXi 6.0 - iSCSI HBA erneut prüfen

[Leuchtkondom 17]

Hallo Leute,

 

ich habe nur eine ganz ganz kurze, vermutlich einfache Frage.

Unsere Server sind alle über iSCSI mit mehreren NetAPPs (über MPIO Round Robin) verbunden, funktioniert alles bestens.

Allerdings habe ich das bisher immer "offline" eingerichtet, dass heißt wenn auf dem Host grade keine VMs aktiv waren.

 

Jetzt muss ich aber ein weiteres Storage einbinden, "offline" ist diesmal aber nicht möglich.

Wenn ich das iSCSI Ziel eingebe erkennt er alle Pfade wie es soll. Dann aber die entscheidende Frage: Soll der HBA erneuert geprüft werden?

 

Bisher habe ich mir da nie Gedanken darüber gemacht, weil ich bisher wie gesagt immer "offline" eingerichtet habe. Aber jetzt ... was passiert wenn ich JA drücke? Werden die vorhandenen iSCSI Verbindungen dabei kurz unterbrochen, oder bleiben die komplett unberührt? Da über die vorhandenen iSCSI Verbindungen ja der Traffic der aktuell laufenden VMs läuft... Ich nehme an das man das ohne Sorge bestätigen kann, wollte mich aber vergewissern. Lange Frage, vermutlich ganz kurze Antwort. :-) Danke an euch

[djmaker 95]

Die vorhandenen Verbindungen werden nicht unterbrochen. Ich habe das bereits oft gemacht.

[Leuchtkondom 17]

Vielen Dank :-)

[djmaker 95]

Gern. Denke daran vorab die Support Matrix zu prüfen (Netapp Ontap Release, Firmware der Serverkomponenten etc. pp., ESXi-Version, zu prüfen im IMT)

[zahni 554]

Rescan-HBA ist harmlos.

Übrigens würde ich die Volumes mit der Netapp VSC einrichten.

Die werden dann automatisch an alle Hosts im Cluster präsentiert und gemountet und mit den richten Parametern für VmWare versehen.

In wie Weit das mit ISCSI geht, musst Du ausprobieren. Bei FC war das aber sehr einfach.

[magheinz 110]

ist bei iscsi das gleiche. wenns die Lizenzen zulassen würde ich aber wh NFS machen...

[djmaker 95]

ist bei iscsi das gleiche. wenns die Lizenzen zulassen würde ich aber wh NFS machen...

 

Bei NFS kannst Du bei die Netapp pro Datastore für de ESXi nur eine IP zur Anbindung nehmen. Dann musst Du zwingend für die Redundanz auf der Netapp einen LACP-trunk einrichten. Bei iSCSI kannst Du mehrere Datenpfade angeben. Ich bevorzuge allerdings trotzdem  auch NFS.

[zahni 554]

Gilt das auch für Ontap 9.3?

pnfs wird laut dem Guide unterstützt: https://library.netapp.com/ecm/ecm_download_file/ECMLP2496255

 

Wie immer: Die coolen Sachen muss bei der Netapp auf der Shell einrichten...

[magheinz 110]

wer sich ne netapp fas leistet, der sollte nicht am LACP scheitern.

[zahni 554]

Da geht es aber auch um Lastverteilung, nicht nur Ausfallsicherheit. Lies mal bei pNfs nach...

[magheinz 110]

Das geht ja auch dann bei NFS: https://library.netapp.com/ecm/ecm_download_file/ECMP1401193

 

Load balancing in multimode interface groups

You can ensure that all interfaces of a multimode interface group are equally utilized for outgoing

traffic by using the IP address, MAC address, round-robin, or port-based load balancing methods to

distribute network traffic equally over the network ports of a multimode interface group.

The load balancing method for a multimode interface group can be specified only when the interface

group is created

bearbeitet 3. Januar 2018 von magheinz

[zahni 554]

Das meine ich nicht. So eine Netapp hat oder sollte 2 mindestens 2 Cluster-Nodes (HA) verwenden. Mach mal LACP zu einer 2-Node Netapp...

Schaue Dir pNFS mal genauer an.

 

Mal am Beispiel mit FC:

- Du hast mehr als ein Volume bzw. LUNs 

- Die Volumes sind auf deine Nodes verteilt (Aggregate = Node)

- Du hast 2 Nodes und vier Pfade. 

- Jede LUN ist über 4 Pfade erreichbar, davon sind aber nur 2 "Optimal" 

 

Es kommt darauf an, dass VmWare die LUN über die "optimalen" Pfade erreicht. Du möchtest Dich als Admin nicht damit beschäftigen.

Daher haben sich schlaue Jungs und Mädels (?) das ALUA-Protokoll ausgedacht. Sowohl für FC als auch für ISCSI

Wann sind Pfade nicht optimal? Wenn auf die LUN über einen anderen Controller als den "Heim-Controller" zugriffigen  wird.

Dann geht es nämlich intern über den Cluster Interconnect.

 

pNFS hat ähnliche Funktionen implementiert:

 

https://whyistheinternetbroken.wordpress.com/tag/pnfs/

 

Unsere kleine Netapp hat u.a. je Node 2 10G-Ports, die per LACP am Switch hängen. Aber nur wegen der Ausfallsicherheit auf Netzwerk-Ebene  (jeder Link geht auf einen anderen Switch).

Ansonsten noch FC-Karten.

Im HA-Fall werden die entsprechenden lokalen LIFs auf die Ports den anderen Nodes migriert. LIFs sind immer Node-Lokal.

Hier wird derzeit nur CIFS/SMB gemacht. Da das normale SMB (nicht SMB 3 für Hyper-V Cluster) kein Multipathing kann, gehen die SMB-Verbindungen bei einem HA-Failover kurz verloren.

Da hilft auch kein LACP. Das wollen wir halt bei pNFS, ISCSI und FC vermeiden.

Kannst Du ausprobieren: Wenn bei einem cDot-Update im Betrieb (funktionierender HA-Cluster) die VMs nichts mitbekommen (keine DISK-Errors) und nur das VC was von Path Down labert, ist alles in Ordnung.

bearbeitet 4. Januar 2018 von zahni

[djmaker 95]

Hi Zahni,

 

danke für die Infos. pNFS hatte ich noch nicht im Fokus. Wird Zeit, das ich mich näher damit beschäftige.Wäre auch einen Thread in Tipps &Tricks wert.