VMware-Forum

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?

Offenbar wechselt das Storagesystem den LUN-Owner, wenn zu viel IO über den falschen Controller hereinkommt. In diesem Fall musst du die Pfade unter ESXi auf den passenden Controller wechseln.

Welches PSP kommt bei dir zum Einsatz? VMW_PSP_FIXED oder VMW_PSP_MRU?

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

Also das SAN heisst SGI InfiniteStorage 220.
PSP ist FIXED (VMW_SATP_DEFAULT_AA)

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

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.

Ausgabe nach esxcfg-mpath -b



Ausgabe esxcli storage nmp device list -d:



Was mache ich nun?

[/code]

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

vielen Dank für die ausführliche Antwort. Ich werde dann mal schauen ob ich dieses Wartungsfenster bekomme.
Leider sind ja oftmals Arbeitszeiten und die Zeiten in denen man so etwas machen könnte nicht übereinstimmend