[DRBD-user] [Iscsitarget-devel] Reconnect LUN's with MS iSCSI Initiator?

Ross S. W. Walker RWalker at medallion.com
Tue Jun 8 20:00:49 CEST 2010

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

Caspar Smit [mailto:c.smit at truebit.nl] wrote:
> Hi All,
> In addition to my previous post below, i am experimenting a little bit
> further. I'm using IET in an HeartbeatV3/Pacemaker/DRBD setup
> now.
> I noticed that when I use the lsb:iscsi-target init script the connection
> reinstatement is working fine. But when I use the
> ocf:heartbeat:iSCSITarget and ocf:heartbeat:iSCSILogicalUnit scripts (created by Florian Haas)
> for failover the connection reinstatement works only one time (failover
> from node1 to node2). When i then issue another failover (from node2 back
> to node1) the iscsi connection in MS iSCSI Initiator goes Inactive again.

Some log messages from initiator/target from the failed failover would
be helpful.

> I would really like to use those scripts from Florian because then I can
> create 4 individual iscsi luns which can run on node1 or node2 seperately.
> (like two on node1 and two on node2, to create a semi active-active setup).
> When I use the iscsi-target lsb init script I have to run ALL targets/luns
> on one node.
> Any idea why the connection reinstatement does not work correctly with
> those scripts and does work with the LSB script?
> I attached both my pacemaker setups (LSB vs OCF Scripts) for
> investigation. I also included both OCF scripts.
> I also noticed that for the OCF scripts to work you have to start
> iscsi-target via the init script at boot using an EMPTY ietd.conf because
> for the scripts to work /usr/sbin/ietd has to be running otherwise the
> scripts give a "Connection refused" error and all hell breaks loose in
> pacemaker saying that the scripts/monitors are not installed etc. Maybe
> this can be incorperated in an updated version of the scripts that it
> start ietd if it is not running at all.
> SOMETIMES the scripts even let ietd crash when stopping/migrating a
> resource(group) leaving the resource(group) in an unmanaged state.

Some log messages of the crash would be helpful. IET shouldn't crash
if it does then it's a bug.

> Finally the scripts do need the /etc/initiators.allow /etc/initiators.deny
> files when using allowed initiators. Since IET version 1.4.18
> initiators.allow is deprecated and the base IET directory moved to /etc/iet.
> I had to manually create /etc/initiators.allow /etc/initiators.deny for
> the OCF scripts because without them they crashed.

Don't create /etc/initiators.allow/deny re-work the scripts for
the new location, files and functionality.

Currently IET 1.4.20 uses:

	- if it's missing it will start with blank config

	- no .deny file needed, there is an implicit deny all, use ALL
	  keyword to apply for all, (ALL ALL = all targets, all initiators)
	- processing ends at first target match
	- if missing there is an implicit allow all

	- determines what targets are available on what portal addresses
	- implicit deny all, use ALL keyword to apply for all
	- processing ends at first target match
	- if missing there is an implicit allow all

Also IET 1.4.20 can now:

- remove live connections/sessions
- provide NOP-In heartbeat to detect dead connections
- doesn't need to have port 3260 blocked
- can utilize temporary target redirection, to redirect initiators
  to another portal IP if the primary target is down

You can have others do it for you, or you can work it out for
yourself, fix it and own it. Then submit the updates to DRBD list.

The files are pretty well commented and you only need to work on
the iet sections.

It is better to fully understand these files so you can quickly
fix things if there is a problem. Otherwise you could experience
extended down time waiting for someone else to diagnose and fix
it for you.


This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.

More information about the drbd-user mailing list