Hallo!
Folgendes Problem:
Auf einem SGI-SAN mit zwei Controllern laufen drei Raids.
Raid1 lläuft auf Controller A
Raid2 läuft auf Controller A (soll aber auf B laufen)
Raid3 läuft auf Controller B
Das zweite Raid springt immer wieder um auf den Controller A.
Wenn ich es über den Storage-Manager von SGI wieder umswitche auf B bleibt dieses nicht lange so und switcht wieder zurück auf Controller A.
Ich habe deshalb ein Ticket bei SGI aufgemacht aufgemacht.
Diese meinen nun, daß es an VMware liegt und man solle den Pfad darüber einstellen.
Leider habe ich nicht die geringste Ahnung wie das funktioniert.
OS ist Windows Server 2008 R2. Vspehre 5/ESX 5.0
Da Vmware oftmals lange auf Antwort warten lässt, wollte ich auch hier einmal nachfragen.
Kann mir Jemand helfen?
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
SAN-Controller - falscher Pfad
-
irix
- King of the Hill
- Beiträge: 13058
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Es waere toll gewesen den Typenbezeichnung/Name des SANs mit anzugeben. Die alte Firma SGI hat wie viele andere auch OEM Produkte verkauft wo hinter gesteckt hat LSI Engenio, welche nun zu NetApp gehoeren. Wenn es das Storage ist was ich meine dann kennen das viele andere als IBM DS3500, Dell PVT 32x0 usw.
Vor 1.5 Jahren gabs nen FW Upgrade fuer das Storage, welches es VMware erlaubt ein SATP zu verwenden welches ALUA beherscht. Das sollte das Problem verringern oder ganz eleminieren.
Was das zurueck anspringen angeht ist es so das ein Lun Transfer ueber die GUI nur erstmal einen Job erstellt und sofort wieder auf Status "Gruen" geht. Der Job wird aber spaeter abgearbeitet bzw. es gibt was den LUN Transfer angeht noch einen Timeout und er merkt spaeter erst das wegen IO der Transfer nicht ausgefuehrt wird und springt wieder in den "Fehler".
Default SATP Plug-in is changed for ALUA supported LSI Arrays in ESXi 5.0 Update 1
http://kb.vmware.com/kb/2016753
Gruss
Joerg
Vor 1.5 Jahren gabs nen FW Upgrade fuer das Storage, welches es VMware erlaubt ein SATP zu verwenden welches ALUA beherscht. Das sollte das Problem verringern oder ganz eleminieren.
Was das zurueck anspringen angeht ist es so das ein Lun Transfer ueber die GUI nur erstmal einen Job erstellt und sofort wieder auf Status "Gruen" geht. Der Job wird aber spaeter abgearbeitet bzw. es gibt was den LUN Transfer angeht noch einen Timeout und er merkt spaeter erst das wegen IO der Transfer nicht ausgefuehrt wird und springt wieder in den "Fehler".
Default SATP Plug-in is changed for ALUA supported LSI Arrays in ESXi 5.0 Update 1
http://kb.vmware.com/kb/2016753
Gruss
Joerg
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo,
über wie viele Pfade sehen deine ESXi Server denn dein Array?
Diese Information kannst du dem Output des Befehls esxcfg-mpath -b entnehmen.
Dabei erhältst du neben den naa Identifiern deiner LUN's auch die WWPN's/WWNN's der FrontEnd Ports deines Arrays.
Identifiziere den naa Identifier deines "Raid2" und verwende ihn im Anschluß mit folgendem Befehl.
esxcli storage nmp device list -d <naa Identifier von Raid2>
Damit erhältst du die Übersicht, welche Policy dein ESX Server für dieses Device einsetzt und welcher Pfad zu diesem Device aktiv verwendet wird.
Diese Einstellung muß mit der Array Konfiguration übereinstimmen, sonst wird der Host das Device über den falschen Array StoragePort kontaktieren und damit über kurz oder lang zum Trespass der LUN führen.
Beim Einsatz von mehreren ESXi Servern muß diese Einstellung auf jedem Server überprüft und ggf. angepasst werden.
Gruß,
Ralf
über wie viele Pfade sehen deine ESXi Server denn dein Array?
Diese Information kannst du dem Output des Befehls esxcfg-mpath -b entnehmen.
Dabei erhältst du neben den naa Identifiern deiner LUN's auch die WWPN's/WWNN's der FrontEnd Ports deines Arrays.
Identifiziere den naa Identifier deines "Raid2" und verwende ihn im Anschluß mit folgendem Befehl.
esxcli storage nmp device list -d <naa Identifier von Raid2>
Damit erhältst du die Übersicht, welche Policy dein ESX Server für dieses Device einsetzt und welcher Pfad zu diesem Device aktiv verwendet wird.
Diese Einstellung muß mit der Array Konfiguration übereinstimmen, sonst wird der Host das Device über den falschen Array StoragePort kontaktieren und damit über kurz oder lang zum Trespass der LUN führen.
Beim Einsatz von mehreren ESXi Servern muß diese Einstellung auf jedem Server überprüft und ggf. angepasst werden.
Gruß,
Ralf
http://www.vmware.com/resources/compati ... tOrder=Asc
VMW_SATP_LSI VMW_PSP_MRU
Das sagt die HCL, wenn es die Storage passt.
Es kommt aber ebenso auch auf den FW Stand an.
VMW_SATP_LSI VMW_PSP_MRU
Das sagt die HCL, wenn es die Storage passt.
Es kommt aber ebenso auch auf den FW Stand an.
Ausgabe nach esxcfg-mpath -b
Ausgabe esxcli storage nmp device list -d:
Was mache ich nun?
[/code]
Code: Alles auswählen
naa.600a0b8000753c95000001314c60e3ac : LSI Fibre Channel Disk (naa.600a0b8000753 c95000001314c60e3ac)
vmhba1:C0:T0:L0 LUN:0 state:active fc Adapter: WWNN: 20:00:00:00:c9:98:a1:57 WWPN: 10:00:00:00:c9:98:a1:57 Target: WWNN: 20:05:00:a0:b8:49:b0:7c WWPN: 20:25 :00:a0:b8:49:b0:7c
vmhba1:C0:T1:L0 LUN:0 state:active fc Adapter: WWNN: 20:00:00:00:c9:98:a1:57 WWPN: 10:00:00:00:c9:98:a1:57 Target: WWNN: 20:04:00:a0:b8:49:b0:7c WWPN: 20:24 :00:a0:b8:49:b0:7c
vmhba2:C0:T0:L0 LUN:0 state:active fc Adapter: WWNN: 20:00:00:00:c9:98:92:2a WWPN: 10:00:00:00:c9:98:92:2a Target: WWNN: 20:05:00:a0:b8:49:b0:7c WWPN: 20:35 :00:a0:b8:49:b0:7c
vmhba2:C0:T1:L0 LUN:0 state:active fc Adapter: WWNN: 20:00:00:00:c9:98:92:2a WWPN: 10:00:00:00:c9:98:92:2a Target: WWNN: 20:04:00:a0:b8:49:b0:7c WWPN: 20:34 :00:a0:b8:49:b0:7c
naa.600a0b800049b07c000001d34c60c982 : LSI Fibre Channel Disk (naa.600a0b800049b 07c000001d34c60c982)
vmhba1:C0:T0:L7 LUN:7 state:active fc Adapter: WWNN: 20:00:00:00:c9:98:a1:57 WWPN: 10:00:00:00:c9:98:a1:57 Target: WWNN: 20:05:00:a0:b8:49:b0:7c WWPN: 20:25 :00:a0:b8:49:b0:7c
vmhba1:C0:T1:L7 LUN:7 state:active fc Adapter: WWNN: 20:00:00:00:c9:98:a1:57 WWPN: 10:00:00:00:c9:98:a1:57 Target: WWNN: 20:04:00:a0:b8:49:b0:7c WWPN: 20:24 :00:a0:b8:49:b0:7c
vmhba2:C0:T0:L7 LUN:7 state:active fc Adapter: WWNN: 20:00:00:00:c9:98:92:2a WWPN: 10:00:00:00:c9:98:92:2a Target: WWNN: 20:05:00:a0:b8:49:b0:7c WWPN: 20:35 :00:a0:b8:49:b0:7c
vmhba2:C0:T1:L7 LUN:7 state:active fc Adapter: WWNN: 20:00:00:00:c9:98:92:2a WWPN: 10:00:00:00:c9:98:92:2a Target: WWNN: 20:04:00:a0:b8:49:b0:7c WWPN: 20:34 :00:a0:b8:49:b0:7c
naa.600508b1001030383935433335300300 : HP Serial Attached SCSI Disk (naa.600508b 1001030383935433335300300)
vmhba0:C0:T0:L0 LUN:0 state:active sas Adapter: 500143800895c350 Target: 143 800895c350
mpx.vmhba3:C0:T0:L0 : Local Optiarc CD-ROM (mpx.vmhba3:C0:T0:L0)
vmhba3:C0:T0:L0 LUN:0 state:active Local HBA vmhba3 channel 0 target 0
naa.600a0b800049b07c0000050a50877604 : LSI Fibre Channel Disk (naa.600a0b800049b 07c0000050a50877604)
vmhba1:C0:T0:L2 LUN:2 state:active fc Adapter: WWNN: 20:00:00:00:c9:98:a1:57 WWPN: 10:00:00:00:c9:98:a1:57 Target: WWNN: 20:05:00:a0:b8:49:b0:7c WWPN: 20:25 :00:a0:b8:49:b0:7c
vmhba1:C0:T1:L2 LUN:2 state:active fc Adapter: WWNN: 20:00:00:00:c9:98:a1:57 WWPN: 10:00:00:00:c9:98:a1:57 Target: WWNN: 20:04:00:a0:b8:49:b0:7c WWPN: 20:24 :00:a0:b8:49:b0:7c
vmhba2:C0:T0:L2 LUN:2 state:active fc Adapter: WWNN: 20:00:00:00:c9:98:92:2a WWPN: 10:00:00:00:c9:98:92:2a Target: WWNN: 20:05:00:a0:b8:49:b0:7c WWPN: 20:35 :00:a0:b8:49:b0:7c
vmhba2:C0:T1:L2 LUN:2 state:active fc Adapter: WWNN: 20:00:00:00:c9:98:92:2a WWPN: 10:00:00:00:c9:98:92:2a Target: WWNN: 20:04:00:a0:b8:49:b0:7c WWPN: 20:34 :00:a0:b8:49:b0:7c
naa.600a0b800049b07c000001ef4c60e3ae : LSI Fibre Channel Disk (naa.600a0b800049b 07c000001ef4c60e3ae)
vmhba1:C0:T0:L1 LUN:1 state:active fc Adapter: WWNN: 20:00:00:00:c9:98:a1:57 WWPN: 10:00:00:00:c9:98:a1:57 Target: WWNN: 20:05:00:a0:b8:49:b0:7c WWPN: 20:25 :00:a0:b8:49:b0:7c
vmhba1:C0:T1:L1 LUN:1 state:active fc Adapter: WWNN: 20:00:00:00:c9:98:a1:57 WWPN: 10:00:00:00:c9:98:a1:57 Target: WWNN: 20:04:00:a0:b8:49:b0:7c WWPN: 20:24 :00:a0:b8:49:b0:7c
vmhba2:C0:T0:L1 LUN:1 state:active fc Adapter: WWNN: 20:00:00:00:c9:98:92:2a WWPN: 10:00:00:00:c9:98:92:2a Target: WWNN: 20:05:00:a0:b8:49:b0:7c WWPN: 20:35 :00:a0:b8:49:b0:7c
vmhba2:C0:T1:L1 LUN:1 state:active fc Adapter: WWNN: 20:00:00:00:c9:98:92:2a WWPN: 10:00:00:00:c9:98:92:2a Target: WWNN: 20:04:00:a0:b8:49:b0:7c WWPN: 20:34 :00:a0:b8:49:b0:7c
Ausgabe esxcli storage nmp device list -d:
Code: Alles auswählen
naa.600a0b8000753c95000001314c60e3ac
Device Display Name: LSI Fibre Channel Disk (naa.600a0b8000753c95000001314c60e3ac)
Storage Array Type: VMW_SATP_DEFAULT_AA
Storage Array Type Device Config: SATP VMW_SATP_DEFAULT_AA does not support device configuration.
Path Selection Policy: VMW_PSP_MRU
Path Selection Policy Device Config: Current Path=vmhba2:C0:T1:L0
Path Selection Policy Device Custom Config:
Working Paths: vmhba2:C0:T1:L0
Was mache ich nun?
[/code]
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo,
laut esxcli storage nmp device list -d naa.600a0b8000753c95000001314c60e3ac verwendet dein ESX Server zur Kommunikation mit dem Device den Front End Storage Port deines Arrays mit der WWPN 20:34:00:a0:b8:49:b0:7c.
Zunächst einmal solltest du prüfen, ob es sich hierbei nicht doch um einen FrontEnd Port vom Controller B handelt.
Auf Grund deiner Problembeschreibung gehe ich aber im folgenden davon aus, das es sich hier um einen FrontEnd Port des Controllers A handelt.
Da die VMware NMP Policy MRU sich nicht konfigurieren läßt, kannst du da auch keinen "prefered path" einstellen.
Um den Server nun zu zwingen, einen der Pfade zum Controller B zu verwenden, kannst du temporär Pfade deaktivieren.
Mit dem folgenden Befehl wird der derzeit verwendete Pfad zu deinem Device deaktiviert.
Da noch ein weiterer Pfad zum selben Controller vorhanden ist, besteht die Möglichkeit, das der ESXi Server nun mit diesem arbeiten.
Somit könnte es erforderlich sein, noch einen weiteren Pfad zu deaktivieren.
Im Anschluß an diese Befehle solltest du je HBA noch einen Pfad zum Controller A zur Verfügung haben, einer davon sollte dann auch aktiv verwendet werden.
Da der Host jetzt dieses Device nur noch über den Controller B erreichen kann, sollte das Array dieses Device nun auch über den Controller B präsentieren.
Nichts desto trotz solltest du in der Araay Konfiguration überprüfen, ob das Device auch dauerhaft über diesen Controller bereitgestellt wird.
Ich kenne jetzt das Array nicht, aber als Default Owner der LUN sollte im Array der Controller B eingestellt sein.
Nachdem du sowohl auf dem ESXi Server und auf dem Array alles überprüft hast kannst du die Pfade wieder aktivieren.
Im Anschluß an diese Maßnahmen sollte die LUN dauerhaft über Controller B verwendet werden, sofern nicht anderweitige Zugriffsprobleme übers SAN auftreten.
Das ist nämlich der entscheidende Nachteil, das ich bei MRU nicht sagen kann, welchen der Pfade er verwenden soll, wenn alle problemlos verwendet werden können.
Ich empfehle übrigends dringend, solche Aktivitäten nur während eines angekündigten Wartungsfenster durchzuführen.
Es sollte zwar auch problemlos im laufenden Betrieb durchgeführt werden können, allerdings kann ich weder etwas bezüglich der IO Last noch der generellen Stabilität der Umgebung etwas sagen.
Gruß,
Ralf
laut esxcli storage nmp device list -d naa.600a0b8000753c95000001314c60e3ac verwendet dein ESX Server zur Kommunikation mit dem Device den Front End Storage Port deines Arrays mit der WWPN 20:34:00:a0:b8:49:b0:7c.
Code: Alles auswählen
naa.600a0b8000753c95000001314c60e3ac
Device Display Name: LSI Fibre Channel Disk (naa.600a0b8000753c95000001314c60e3ac)
Storage Array Type: VMW_SATP_DEFAULT_AA
Storage Array Type Device Config: SATP VMW_SATP_DEFAULT_AA does not support device configuration.
Path Selection Policy: VMW_PSP_MRU
Path Selection Policy Device Config: Current Path=vmhba2:C0:T1:L0 <<<<------
Path Selection Policy Device Custom Config:
Working Paths: vmhba2:C0:T1:L0Code: Alles auswählen
naa.600a0b8000753c95000001314c60e3ac : LSI Fibre Channel Disk (naa.600a0b8000753c95000001314c60e3ac)
vmhba1:C0:T0:L0 LUN:0 state:active fc Adapter: WWNN: 20:00:00:00:c9:98:a1:57 WWPN: 10:00:00:00:c9:98:a1:57 Target: WWNN: 20:05:00:a0:b8:49:b0:7c WWPN: 20:25:00:a0:b8:49:b0:7c
vmhba1:C0:T1:L0 LUN:0 state:active fc Adapter: WWNN: 20:00:00:00:c9:98:a1:57 WWPN: 10:00:00:00:c9:98:a1:57 Target: WWNN: 20:04:00:a0:b8:49:b0:7c WWPN: 20:24:00:a0:b8:49:b0:7c
vmhba2:C0:T0:L0 LUN:0 state:active fc Adapter: WWNN: 20:00:00:00:c9:98:92:2a WWPN: 10:00:00:00:c9:98:92:2a Target: WWNN: 20:05:00:a0:b8:49:b0:7c WWPN: 20:35:00:a0:b8:49:b0:7c
vmhba2:C0:T1:L0 LUN:0 state:active fc Adapter: WWNN: 20:00:00:00:c9:98:92:2a WWPN: 10:00:00:00:c9:98:92:2a Target: WWNN: 20:04:00:a0:b8:49:b0:7c WWPN: 20:34:00:a0:b8:49:b0:7c <<<<------Zunächst einmal solltest du prüfen, ob es sich hierbei nicht doch um einen FrontEnd Port vom Controller B handelt.
Auf Grund deiner Problembeschreibung gehe ich aber im folgenden davon aus, das es sich hier um einen FrontEnd Port des Controllers A handelt.
Da die VMware NMP Policy MRU sich nicht konfigurieren läßt, kannst du da auch keinen "prefered path" einstellen.
Um den Server nun zu zwingen, einen der Pfade zum Controller B zu verwenden, kannst du temporär Pfade deaktivieren.
Mit dem folgenden Befehl wird der derzeit verwendete Pfad zu deinem Device deaktiviert.
Code: Alles auswählen
esxcli storage core path --state=off -p fc.20000000c998922a:10000000c998922a-fc.200400a0b849b07c:203400a0b849b07c-naa.600a0b8000753c95000001314c60e3acDa noch ein weiterer Pfad zum selben Controller vorhanden ist, besteht die Möglichkeit, das der ESXi Server nun mit diesem arbeiten.
Somit könnte es erforderlich sein, noch einen weiteren Pfad zu deaktivieren.
Code: Alles auswählen
esxcli storage core path --state=off -p fc.20000000c998a157:10000000c998a157-fc.200400a0b849b07c:202400a0b849b07c-naa.600a0b8000753c95000001314c60e3acIm Anschluß an diese Befehle solltest du je HBA noch einen Pfad zum Controller A zur Verfügung haben, einer davon sollte dann auch aktiv verwendet werden.
Da der Host jetzt dieses Device nur noch über den Controller B erreichen kann, sollte das Array dieses Device nun auch über den Controller B präsentieren.
Nichts desto trotz solltest du in der Araay Konfiguration überprüfen, ob das Device auch dauerhaft über diesen Controller bereitgestellt wird.
Ich kenne jetzt das Array nicht, aber als Default Owner der LUN sollte im Array der Controller B eingestellt sein.
Nachdem du sowohl auf dem ESXi Server und auf dem Array alles überprüft hast kannst du die Pfade wieder aktivieren.
Code: Alles auswählen
esxcli storage core path --state=on -p fc.20000000c998a157:10000000c998a157-fc.200400a0b849b07c:202400a0b849b07c-naa.600a0b8000753c95000001314c60e3ac
esxcli storage core path --state=on -p fc.20000000c998922a:10000000c998922a-fc.200400a0b849b07c:203400a0b849b07c-naa.600a0b8000753c95000001314c60e3acIm Anschluß an diese Maßnahmen sollte die LUN dauerhaft über Controller B verwendet werden, sofern nicht anderweitige Zugriffsprobleme übers SAN auftreten.
Das ist nämlich der entscheidende Nachteil, das ich bei MRU nicht sagen kann, welchen der Pfade er verwenden soll, wenn alle problemlos verwendet werden können.
Ich empfehle übrigends dringend, solche Aktivitäten nur während eines angekündigten Wartungsfenster durchzuführen.
Es sollte zwar auch problemlos im laufenden Betrieb durchgeführt werden können, allerdings kann ich weder etwas bezüglich der IO Last noch der generellen Stabilität der Umgebung etwas sagen.
Gruß,
Ralf
Zurück zu „vSphere 5 / ESXi 5 und 5.1“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 13 Gäste