Hostcrash durch iSCSI Setup > Wie ändern?

[djbreezer]

Hi,
ich habe gestern Mittag eine weitere LUN auf unserer EQL erstellt. Dies hatte zur Folge, dass sich auf den ESXi-Hosts der hostd Prozess komplett verabschiedet hat und auch nicht mehr starten wollte.

Nach dem wir alle VMs wie RDP, Remote Shutdown usw. endlich aus hatten und das View-Cluster deaktivieren konnten, kam heraus, dass unser aktuelles iSCSI Setup, welches nun drei Jahre lang lief, an der Misere schuld war.

Durch das Hinzufügen einer weitern LUN gab es beim HBA-Scan wohl zuviele Timeouts, sodass der Dienst auf den Hosts einfach nicht mehr wollte.


2016-04-07T10:40:43.074Z cpu44:33633)WARNING: iscsi_vmk: iscsivmk_ConnReceiveAtomic: vmhba45:CH:0 T:19 CN:0: Failed to receive data: Connection closed by peer
2016-04-07T10:40:43.078Z cpu44:33633)WARNING: iscsi_vmk: iscsivmk_ConnReceiveAtomic: Sess [ISID: TARGET: (null) TPGT: 0 TSIH: 0]
2016-04-07T10:40:43.078Z cpu44:33633)WARNING: iscsi_vmk: iscsivmk_ConnReceiveAtomic: Conn [CID: 0 L: 10.10.14.17:38283 R: 10.10.14.100:3260]
2016-04-07T10:40:43.078Z cpu44:33633)iscsi_vmk: iscsivmk_ConnRxNotifyFailure: vmhba45:CH:3 T:19 CN:0: Connection rx notifying failure: Failed to Receive. State=Bound
2016-04-07T10:40:43.078Z cpu44:33633)iscsi_vmk: iscsivmk_ConnRxNotifyFailure: Sess [ISID: TARGET: (null) TPGT: 0 TSIH: 0]


Bekommt keine Antwort ueber den Pfad zurueck / Storage hat die Verbindung geschlossen.

Dann das Resultat:

2016-04-07T12:00:01.877Z cpu37:2981041)ALERT: hostd detected to be non-responsive

Uns ist auch in der Vergangenheit aufgefallen, dass der iSCSI Scan beim booten der ESXi sehr lange dauert - bis zu 30 Minuten. Ich denke das rührt wohl auch daher.

Wir haben zwei Arrays im Einsatz:

1x MSA P2000 G3 (active/active) < Raid 10 Exchange & SQL
1x EQL PS6100XS (active/passive) < Raid 6 Accelerated VMWare View Cluster + File-Server

Diese beiden sind via 4 pSwitches (2x HP ProCurve 2848 2x Dell 6224) an die ESXi angebunden. Auf den ESXi sind 8 vmk an 8 vSwitches wie via Port-Bonding an 8 Nics.





Beißt sich komplett mit den aktuellen Anforderungen von VMWare:

https://kb.vmware.com/selfservice/micro ... Id=2038869

Dort steht:

Port Binding

Port binding is used in iSCSI when multiple VMkernel ports for iSCSI reside in the same broadcast domain and IP subnet to allow multiple paths to an iSCSI array that broadcasts a single IP address. When using port binding, you must remember that:

-Array Target iSCSI ports must reside in the same broadcast domain and IP subnet as the VMkernel port. < FAIL
-All VMkernel ports used for iSCSI connectivity must reside in the same broadcast domain and IP subnet. < FAIL
-All VMkernel ports used for iSCSI connectivity must reside in the same vSwitch. < FAIL
-Currently, port binding does not support network routing. < CHECK

Jetzt habe ich das Problem, dass wir ein active/active und ein active/passive Array haben. Kann ich (wegen der Switch Config usw.) die HP direkt ohne Switches an die ESXi anbinden?

Hat jemand vielleicht eine andere Idee, wie man das ganze jetzt VMWare-Konform bekommt?

VG

Alex

[djbreezer]

Keine Ideen? Oder is die Frage so blöd?

[irix]

Nein ist sie nicht..... ich habe das gleiche Problem welches ich seit > 3 Jahren aussitze und die extrem langen Bootphasen ertrage.

Wir hatten aber niemals nen Absturz des des ESXi wobei ich sagen muss das wir 90% des Storage allokiert haben und da auch wenig Aenderungen passieren auf dieser Seite.


Ich muss echt sagen das ich mir da garnicht bewusst drum war. Ich habe zwar in anderen Guides gesehen (Lefthand) das hier aus mir unverstaendlichen Gruenden kein Binding haben in der Anleitung. Aber wenn man 20 Installation mit EqualLogic hat seit 8 Jahren dann macht man div. Dinge halt automatisch und das mit dem Binding ist ja mit vSphere 4 im Jahre 2009 gekommen.

Ich glaube das sich dieses Problem auch so nicht loesen lassen wird sondern das man drauf achten muss das man nur gleichartige iSCSI SANs da an sein swISCSI bringt. Was hat denn der VMware Support gesagt zu dem Thema?

Gruss
Joerg

[Schimmi]

Was spricht denn dagegen, die beiden SAN in das gleiche Netz zu hängen?

Also z.B: die HP-SAN an die DELL-Switche.

Dann sind es halt zwei verschiedene Targets im selben Subnetz auf dem selben pSwitch. Diese Konstellation haben wir während unseres Storage-Umbaus problemlos einige Zeit so betrieben. Lange Bootzeiten konnte ich dabei nicht beobachten.

[irix]

Was spricht denn dagegen, die beiden SAN in das gleiche Netz zu hängen? Also z.B: die HP-SAN an die DELL-Switche.

Die Frage ob eine HP MSA so eine IP Config vorsieht oder ob die Ports in unterschiedlichen Subnetzen sein muessen.

Auf EQL Seite waere keine anderen IP Adressierung zulaessig.

Gruss
Joerg

[Schimmi]

Da bin ich mir auch nicht ganz sicher. Bei unseren alten MSA war das kein Problem. Ist aber schon ein paar Tage her

[djbreezer]

Der VMWare Support sagt dazu:

"Bitte klären Sie die Möglichen Setups mit Ihren Storage Anbietern ab. Wir kennen diesen Fehler - hostd ist nicht darauf ausgelegt soviele timeouts zu verarbeiten. "

Ich bin mir recht sicher, dass es damals (2008/2009) einen Bug gab, der uns gezwungen hatte pro vmk und nic einen vSwitch einzurichten. Und dieses Setup wurde dann einfach weitergeführt - weil es lief.


Das bedeutet für unser aktuelles Setup:

Mit genau 18 LUNs ist bei 4 pNICs das maximum an Timeouts erreicht.

Die Frage ist, was wäre wenn ich die Verkabelung lasse wie Sie ist, Kernelports an einen vSwitch hänge. MSA auf MTU 9000 und das Subnetz einfach auf 16-Bit umstelle. Ist zwar nicht die beste Lösung, aber es wäre eine.