Jump to content
Melde dich an, um diesen Inhalt zu abonnieren  
Leuchtkondom

ESXi 6.0 - iSCSI HBA erneut prüfen

Empfohlene Beiträge

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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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 von magheinz

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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 von zahni

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden
Melde dich an, um diesen Inhalt zu abonnieren  

×