OpenSolaris Forums : [storage-discuss] comstar iscsi ...

Home » OpenSolaris Forums » storage » discuss

Thread: [storage-discuss] comstar iscsi sendtargets vlans

Welcome, Guest

Guest Settings

Reply to this Thread

Search Forum

Back to Thread List

	Replies: 10 - Last Post: Dec 4, 2009 12:01 PM by: splot

splot

Posts: 13
From:

Registered: 2/25/09

[storage-discuss] comstar iscsi sendtargets vlans
Posted: Nov 24, 2009 12:17 PM

Hello,

In my research about stmfadm/itadm I have encountered an issue that I would like to discuss. We have multiple VLANs in which iscsi storage is delivered. If a host contacts comstar via sendtargets, it will receive a listing of all targets and including those with portal group ip addresses that the client cannot reach. Example client like open-iscsi will then attempt to connect to all target received and hang on a target for which the client cannot reach - it will hang and timeout after a while (sometimes a long while and this becomes painful when rebooting a host).

What I would like is that if an initiator is a member of a host group and the host group is associated with a view which has an association with a target group, then the initator should only see those targets that are in the associated target group. Of course this logic has to be evaluated for each view that the initiator is a member of a host group and then the union of resulting targets needs to be exposed.

I understand that isns can resolve this issue, however with older iscsi clients that is not option and honestly introduces another layer of complexity.
I understand the theory behind comstar that there is no 1:1 relationship lun and target.

There have been some discussion about this issue - I am trying to see what people have thought about. (Reference: http://www.mail-archive.com/storage-discuss at opensolaris dot org/msg06614.html)

Thank you for your feedback.

Steffen

_______________________________________________________________________________ ________________
Steffen Plotner                          &n bsp; Amherst College            Tel (413) 542-2348
Systems/Network Administrator/Programmer   PO BOX 5000            &nb sp;   Fax (413) 542-2626
Systems & Networking           &nb sp;           Amherst, MA 01002-5000     swplotner at amherst dot edu

_______________________________________________ storage-discuss mailing list storage-discuss at opensolaris dot org http://mail.opensolaris.org/mailman/listinfo/storage-discuss

dilidolo

Posts: 94
From: CA

Registered: 1/2/07

Re: [storage-discuss] comstar iscsi sendtargets vlans
Posted: Nov 24, 2009 1:49 PM

in response to: splot
To: Communities » storage » discuss

You can create multiple Target Portal Groups, and assign IPs you want to those TPGs. Client can connect to specific TPG with IPs accessible for them.

splot

Posts: 13
From:

Registered: 2/25/09

Re: [storage-discuss] comstar iscsi sendtargets vlans
Posted: Nov 24, 2009 6:08 PM

in response to: dilidolo

Hi Chris,

I have configured distinct Target Portal Groups and assigned them unique IP addresses. Clients connecting to a target group still see all targets. A lot clients will then attempt to connect to targets that they cannot reach possibly because the IP is in a different VLAN.

Steffen

______________________________________________________________________ _________________________
Steffen Plotner                          &n bsp; Amherst College            Tel (413) 542-2348
Systems/Network Administrator/Programmer   PO BOX 5000            &nb sp;   Fax (413) 542-2626
Systems & Networking           &nb sp;           Amherst, MA 01002-5000     swplotner at amherst dot edu

<HR tabIndex=-1> From: storage-discuss-bounces at opensolaris dot org on behalf of Chris Du
Sent: Tue 11/24/2009 4:49 PM
To: storage-discuss at opensolaris dot org
Subject: Re: [storage-discuss] comstar iscsi sendtargets vlans

You can create multiple Target Portal Groups, and assign IPs you want to those TPGs. Client can connect to specific TPG with IPs accessible for them.
--
This message posted from opensolaris.org
_______________________________________________
storage-d iscuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss

_______________________________________________ storage-discuss mailing list storage-discuss at opensolaris dot org http://mail.opensolaris.org/mailman/listinfo/storage-discuss

mlaspina

Posts: 158
From: CA

Registered: 6/20/08

Re: [storage-discuss] comstar iscsi sendtargets vlans
Posted: Nov 25, 2009 10:18 AM

in response to: splot
To: Communities » storage » discuss

Hi,

I have multiple VLANs with multiple targets assigned to separate portals and I don't have any of those issues. Can you show an example of how your targets are defined?

Regards,

Mike

splot

Posts: 13
From:

Registered: 2/25/09

Re: [storage-discuss] comstar iscsi sendtargets vlans
Posted: Nov 26, 2009 6:31 PM

in response to: mlaspina

Hi Mike,

The problem I have is that if a client does a SendTargets TEXT command, the comstar iscsi port returns all targets that the host hosts. Do you in your environment have a way to limit the targets visible to the client (specifically when doing target discovery via SendTargets)?

Lets say I have a target for vlan 100 and another target for vlan 200.

>itadm create-tpg tpg_100 192.168.100.1

>itadm create-tpg tpg_200 192.168.200.1

>itadm create-target -n iqn.1990-01.edu.amherst:target100 -t tpg_100

>itadm create-target -n iqn.1990-01.edu.amherst:target200 -t tpg_200

Let's take a linux open-iscsi client and do a discovery via sendtargets (the portal IP could be any IP that the target has been configured with)

>iscsiadm --mode discovery --type sendtargets --portal 192.168.100.1

192.168.100.1:3260,2 iqn.1990-01.edu.amherst:target100

192.168.200.1:3260,2 iqn.1990-01.edu.amherst:target200

Looking at the source code of comstar/port/iscsit/iscsi_text.c line 550 there are comments in the code that indicate

* Add all the targets to the response list.

Looking at the code, all targets are enumerated and only those that are online or are about to become online are emitted to the initiator.

The algorithm for this should be:

Remember the current initiator name contacting us. Enumerate all host groups (stmfadm) and find a single host group where the initiator is a member, now we have a host group to key on.

Enumerate all views (stmfadm) and look at those where the host group matches the one we found before. If we have that, look at the target group of that view and enumerate over the targets of the target group. Those targets are to be visible. As you enumerate all views and perform these steps, accumulate the target list.

Now emit the resulting target list - the initiator would only see those targets that the initiator has been configured to see.

Steffen

_______________________________________________ storage-discuss mailing list storage-discuss at opensolaris dot org http://mail.opensolaris.org/mailman/listinfo/storage-discuss

mlaspina

Posts: 158
From: CA

Registered: 6/20/08

Re: [storage-discuss] comstar iscsi sendtargets vlans
Posted: Nov 27, 2009 2:41 PM

in response to: splot
To: Communities » storage » discuss

Hi Steffen,

I understand now. What you are experiencing is the correct behavior based of RFC3270. The iSCSI text cmd SendTargets=All is required to send all targets that all defined on the serving host regardless of the Target Portal Group IP list. Target Portals do not control access, the define what interfaces will participate in the I_T nexus session on the target side.

The only thing I can suggest is that you use a static mapping instead of a dynamic discovery for establishing an I_T session.

Regards,

Mike

splot

Posts: 13
From:

Registered: 2/25/09

Re: [storage-discuss] comstar iscsi sendtargets vlans
Posted: Nov 27, 2009 3:09 PM

in response to: mlaspina

Hi Mike,

Static mappings makes sense and I have done that with some of my systems. However, vmware esx will not let me do that with the software iscsi initiator that they have. In fact that initiator, will senselessly reconnect every 2 seconds with a target due to a previous connection failure (the target portal IP is simply not reachable from that vlan's perspective, for example). Unfortunately, vmware esx 3 and 4 do not support isns which would have then solved this problem also.

Steffen

_______________________________________________ storage-discuss mailing list storage-discuss at opensolaris dot org http://mail.opensolaris.org/mailman/listinfo/storage-discuss

mlaspina

Posts: 158
From: CA

Registered: 6/20/08

Re: [storage-discuss] comstar iscsi sendtargets vlans
Posted: Nov 30, 2009 10:42 PM

in response to: splot
To: Communities » storage » discuss

Steffen,

ESX 4 does allow you to configure static iSCSI target mappings. ESX 3.x does not support static mappings.I'm not sure the RFE is the best solution at this point, I think moving forward with ESX 4 and static maps makes the most sense in this case.

Regards,

Mike

pwc

Posts: 64
From: US

Registered: 1/5/07

Re: [storage-discuss] comstar iscsi sendtargets vlans
Posted: Nov 29, 2009 5:57 AM

in response to: mlaspina

Here is the relevant paragraph from Appendix D of RFC 3270:
> A system that contains targets MUST support discovery sessions on
> each of its iSCSI IP address-port pairs, and MUST support the
> SendTargets command on the discovery session. In a discovery
> session, a target MUST return all path information (target name and
> IP address-port pairs and portal group tags) for the targets on the
> target network entity which the requesting initiator is authorized to
> access.
>
As Mike says, the COMSTAR model is that all initiators are implicitly
"authorized to access" all targets. TPGs can be used to restrict which
IP portals each target is accessible over, but do not restrict which
initiator nodes can connect via those IP portals. COMSTAR Views are
used to restrict and define which LUNs are visible to which initiators
via each target node, but once again do not restrict which initiators
can connect to the targets node itself.

There has been a request that COMSTAR add the ability to do
initiator-based access control. This request is being tracked in the
following RFE:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6878539 .

Peter

Mike La Spina wrote:
> Hi Steffen,
>
> I understand now. What you are experiencing is the correct behavior based of RFC3270. The iSCSI text cmd SendTargets=All is required to send all targets that all defined on the serving host regardless of the Target Portal Group IP list. Target Portals do not control access, the define what interfaces will participate in the I_T nexus session on the target side.
>
> The only thing I can suggest is that you use a static mapping instead of a dynamic discovery for establishing an I_T session.
>
> Regards,
>
> Mike
>
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss

splot

Posts: 13
From:

Registered: 2/25/09

Re: [storage-discuss] comstar iscsi sendtargets vlans
Posted: Dec 1, 2009 6:10 PM

in response to: pwc

Hi Peter,

Thank you for finding the bug_id about this issue. I will let you know if I can find a way around it.

Steffen

<HR tabIndex=-1> From: storage-discuss-bounces at opensolaris dot org on behalf of Peter Cudhea
Sent: Sun 11/29/2009 8:57 AM
To: Mike La Spina
Cc: storage-discuss at opensolaris dot org
Subject: Re: [storage-discuss] comstar iscsi sendtargets vlans

...
There has been a request that COMSTAR add the ability to do
initiator-based access control. This request is being tracked in the
following RFE:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6878539 .

Peter
...

_______________________________________________ storage-discuss mailing list storage-discuss at opensolaris dot org http://mail.opensolaris.org/mailman/listinfo/storage-discuss

splot

Posts: 13
From:

Registered: 2/25/09

Re: [storage-discuss] comstar iscsi sendtargets vlans - itportal
Posted: Dec 4, 2009 12:01 PM

in response to: pwc

Hello

I see there is an existing RFE to control which targets an iscsi initiator gets to see. I have decided to write code to resolve the issue at least in our environment. The code is an iscsi portal which answers to initiators's SendTargets=All command and responds only with those targets the initiator should see. The iscsi portal is not involed in the actual iscsi data traffic.

I understand it would have probably made more sense to modify the kernel code, however at this stage, I don't understand all the details of the solaris kernel to make such changes. However, having said that, I would think someone who is working on the RFE could use the algorithm of this code as starting point.

Have a look at the following URL: https://www3.amherst.edu/~swplotner/comstar/

There is a README document explaining the details. Configure etc/config.pm with the listen port of the portal and target port and IP of comstar's iscsi target. Launch the itportal.plx via the command line switches below.

./itportal.plx [-h] [-v] [-d] -i iqn | -f | -b | -k

-h help

no command line options queries 127.0.0.1:860 SendTargets=All

-i      initiator target query (computes the effective SendTargets=All for initiator)
-b      run the iscsi portal in the background (daemon)
-f      run the iscsi portal in the foreground
-k      kill background daemon
-v      verbose
-d      debug PDUs

If you have questions/ideas, feel free to let me know.

Steffen

As Mike says, the COMSTAR model is that all initiators are implicitly
"authorized to access" all targets. TPGs can be used to restrict which
IP portals each target is accessible over, but do not restrict which
initiator nodes can connect via those IP portals. COMSTAR Views are
used to restrict and define which LUNs are visible to which initiators
via each target node, but once again do not restrict which initiators
can connect to the targets node itself.

There has been a request that COMSTAR add the ability to do
initiator-based access control. This request is being tracked in the
following RFE:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6878539 .

Peter

_______________________________________________ storage-discuss mailing list storage-discuss at opensolaris dot org http://mail.opensolaris.org/mailman/listinfo/storage-discuss

Back to Thread List