MPIO with Centos or RHEL

[logicmate]

Anyone have any experience or idea on how to setup MPIO with Centos or RHEL to work with StarWind?

Thanks,
Ara

[Anatoly (staff)]

Hello logicmate,

Actually the procedure of setting up shared storage provided by starwind with Centos is pretty similar to using StaRWind with XenServer. You can download the corresponding documentation by using the link below:
http://www.starwindsoftware.com/providi ... -xenserver

Also the links below should be useful for you too.
http://www.centos.org/docs/5/html/5.1/D ... rview.html
http://storagefoo.blogspot.com/2006/08/ ... evice.html

In our test lab we are just starting the corresponding service and using default settings.

[logicmate]

Thank you for the links, helpful. I found this additional documentation which is great because it shows you step by step on what you need to do to successfully establish MPIO. I got it working.

http://www.equallogic.com/WorkArea/Down ... px?id=8727

Ara

[Anatoly (staff)]

Your document is good as well.

OK, your welcome and thank you for your cooperation!

[logicmate]

I came across this thread, is it something I need to consider changing the settings?


http://www.starwindsoftware.com/forums/ ... nux#p14690

changes should be already there

StarWind Servers Registry (HKEY_LOCAL_MACHINE/System/ControlSet001/Control/Class/{4D36E97B-E325-11CE-BFC1-08002BE10318}/0000/Parameters):
MaxBurstLength - 0x00040000(262144)
MaxRecvDataSegmentLength 0x00040000(262144)
MaxTransferLength 0x0080000 (524288)

->Restart the server
Highly recommend to doublecheck these values
CentOS servers which will be using HA:
Enable multipathing

edit etc/iscsi/iscsid.conf -> set the
maxburstlength - 262144
maxreceivedatasegmentlength - 131072

edit etc/multipath.conf - add these lines into the uncommented defaults section:
user_friendly_names no
polling_interval 10
path_grouping_policy group_by_prio /multibus

[logicmate]

I just noticed the following messages in the log that is there continuously. What would cause this?

Thanks,
Ara

Apr 8 12:35:14 vzlcos58x64cn02 iscsid: connection2:0 is operational after recovery (1 attempts)
Apr 8 12:35:14 vzlcos58x64cn02 iscsid: connection3:0 is operational after recovery (1 attempts)
Apr 8 12:35:14 vzlcos58x64cn02 iscsid: connection1:0 is operational after recovery (1 attempts)
Apr 8 12:35:14 vzlcos58x64cn02 iscsid: connection4:0 is operational after recovery (1 attempts)
Apr 8 12:35:14 vzlcos58x64cn02 iscsid: connection6:0 is operational after recovery (1 attempts)
Apr 8 12:35:15 vzlcos58x64cn02 kernel: [73246.104676] connection4:0: detected conn error (1020)
Apr 8 12:35:15 vzlcos58x64cn02 kernel: [73246.104685] connection3:0: detected conn error (1020)
Apr 8 12:35:15 vzlcos58x64cn02 kernel: [73246.105813] connection6:0: detected conn error (1020)
Apr 8 12:35:15 vzlcos58x64cn02 kernel: [73246.106181] connection1:0: detected conn error (1020)
Apr 8 12:35:15 vzlcos58x64cn02 kernel: [73246.108780] connection2:0: detected conn error (1020)
Apr 8 12:35:16 vzlcos58x64cn02 iscsid: Kernel reported iSCSI connection 4:0 error (1020) state (3)
Apr 8 12:35:16 vzlcos58x64cn02 iscsid: Kernel reported iSCSI connection 3:0 error (1020) state (3)
Apr 8 12:35:16 vzlcos58x64cn02 iscsid: Kernel reported iSCSI connection 6:0 error (1020) state (3)
Apr 8 12:35:16 vzlcos58x64cn02 iscsid: Kernel reported iSCSI connection 1:0 error (1020) state (3)
Apr 8 12:35:16 vzlcos58x64cn02 iscsid: Kernel reported iSCSI connection 2:0 error (1020) state (3)
Apr 8 12:35:19 vzlcos58x64cn02 iscsid: connection6:0 is operational after recovery (1 attempts)
Apr 8 12:35:19 vzlcos58x64cn02 iscsid: connection4:0 is operational after recovery (1 attempts)
Apr 8 12:35:19 vzlcos58x64cn02 iscsid: connection3:0 is operational after recovery (1 attempts)
Apr 8 12:35:19 vzlcos58x64cn02 iscsid: connection2:0 is operational after recovery (1 attempts)
Apr 8 12:35:19 vzlcos58x64cn02 iscsid: connection1:0 is operational after recovery (1 attempts)
Apr 8 12:35:21 vzlcos58x64cn02 kernel: [73251.616319] connection4:0: detected conn error (1020)
Apr 8 12:35:21 vzlcos58x64cn02 kernel: [73251.616332] connection3:0: detected conn error (1020)
Apr 8 12:35:21 vzlcos58x64cn02 kernel: [73251.617459] connection1:0: detected conn error (1020)
Apr 8 12:35:21 vzlcos58x64cn02 kernel: [73251.617483] connection6:0: detected conn error (1020)
Apr 8 12:35:21 vzlcos58x64cn02 kernel: [73251.618665] connection2:0: detected conn error (1020)
Apr 8 12:35:22 vzlcos58x64cn02 iscsid: Kernel reported iSCSI connection 4:0 error (1020) state (3)
Apr 8 12:35:22 vzlcos58x64cn02 iscsid: Kernel reported iSCSI connection 3:0 error (1020) state (3)
Apr 8 12:35:22 vzlcos58x64cn02 iscsid: Kernel reported iSCSI connection 1:0 error (1020) state (3)
Apr 8 12:35:22 vzlcos58x64cn02 iscsid: Kernel reported iSCSI connection 6:0 error (1020) state (3)
Apr 8 12:35:22 vzlcos58x64cn02 iscsid: Kernel reported iSCSI connection 2:0 error (1020) state (3)
Apr 8 12:35:25 vzlcos58x64cn02 iscsid: connection4:0 is operational after recovery (1 attempts)
Apr 8 12:35:25 vzlcos58x64cn02 iscsid: connection6:0 is operational after recovery (1 attempts)
Apr 8 12:35:25 vzlcos58x64cn02 iscsid: connection1:0 is operational after recovery (1 attempts)
Apr 8 12:35:25 vzlcos58x64cn02 iscsid: connection2:0 is operational after recovery (1 attempts)
Apr 8 12:35:25 vzlcos58x64cn02 iscsid: connection3:0 is operational after recovery (1 attempts)
Apr 8 12:35:26 vzlcos58x64cn02 kernel: [73257.124953] connection4:0: detected conn error (1020)
Apr 8 12:35:26 vzlcos58x64cn02 kernel: [73257.124997] connection1:0: detected conn error (1020)
Apr 8 12:35:26 vzlcos58x64cn02 kernel: [73257.126165] connection2:0: detected conn error (1020)
Apr 8 12:35:26 vzlcos58x64cn02 kernel: [73257.126189] connection6:0: detected conn error (1020)
Apr 8 12:35:26 vzlcos58x64cn02 kernel: [73257.128800] connection3:0: detected conn error (1020)

[Max (staff)]

Is there any chance you can show us the messages from the StarWind log for the appropriate period of time?

[logicmate]

Attached is a snippet of the log file from one of the HA nodes, I just noticed the log files are huge and repeated with the same information over and over again.

Thanks,
Ara

[Max (staff)]

Please go to etc/iscsi/nodes/SAN-IQN/SAN IP/
and edit the maxburstlength and firstburstlength to be less or equal than 262144
There is also a setting named tcp_windows_size, please make sure that it is set to a value lower or equal than 262144 as well.
Also, please check that etc/iscsi/iscsid.conf has the following parameters changed
maxburstlength - 262144
maxreceivedatasegmentlength - 131072

I think this should help since the log file shows that there is a parameter conflict.

[logicmate]

Hi Max,
I believe I finally resolved the issue, we had setup a 2 node Centos cluster. We created the first node and then we cloned the second node from the first node. What we did not realize was that both nodes were setup to use the same iSCSI Initiator name since it was a clone, I changed it on the second node and so far it seems that we are no longer experience the timeout/reconnect issues.

What a wild goose chase

Thanks,
Ara

[Max (staff)]

Glad to hear that your issue is resolved!
In future be careful when cloning, it can still lead to unforeseen consequences