[storage-discuss] COMSTAR and the current iSCSI target

[John Forte]

Ben Rockwood wrote:
> Thank you for the PDF with illustrations, it helped convey the concepts.
>
> While offhand I can't think of any advantages to have control via the 
> view layer I do like the flexibility to have that control if I see 
> fit.  This is a feature commonly missing from iSCSI Target 
> implementations and I'm glad to see it.
>
> My concern would be with how it's managed, particularly via the CLI.  
> Managing these views, while more flexible, could become very confusing 
> and introduce significant human error and/or frustration.
We hope that the CLI, stmfadm, is simple enough for managing view 
entries. You can take a look at the manpage that we currently have. It's 
stmfadm.pdf at the project website.

>
> To that end, do you intent to bring forward the existing iSCSI Target 
> CLI interface?  And if so, how to you intend to weave views into the 
> command structure?  My only request would be that the interface would 
> not require you to manage views by default; a given I would think.
In current iSCSI CLI terms, when a new target and logical unit is 
created, that logical unit is accessible by any initiator by default. 
Setting a target ACL changes that behavior. It is likely that for 
COMSTAR, the default will no longer be 'accessible by all' but rather 
'accessible by none'. However, it is simple enough to get that 
'accessible by all' behavior with one command on the logical unit:

# stmfadm add-view <lu-name>

This command would add a view entry indicating all initiators have 
access and the logical unit is to be exported via all target ports with 
the logical unit number being assigned by the system. So, in terms of 
managing views, if there are any requirements that go beyond 'accessible 
by all' for the logical unit, view entries would definitely need to be 
managed. The document on view entries explains some of that management 
via examples and illustrations.

As for the existing iscsitadm, it will not have this concept of view 
entries or anything related to the logical unit for that matter. The 
thought is that the existing iscsitadm will be more of a set-and-forget 
tool rather than one that required frequent usage to manage your 
storage. In order for iscsitadm usage to decrease, there would have to 
be fewer targets created. For example, in our opinion there really 
shouldn't be much of a need to create more than a few targets from which 
the logical units are exported. In COMSTAR, for iSCSI at least, once the 
targets are created and tied to the IP addresses via the target portal 
group tags, the assignment to export the logical units via a given 
target would be done using stmfadm. And for fibre channel, excluding 
NPIV support, there will be 1 target for each fibre channel port WWN, so 
the ability to create a target for each logical unit will not be 
available. Even with NPIV, it's not likely that it would ever be used to 
have the target ports map to the logical units in a 1:1 relationship.

And just to expand on the 'fewer targets' idea, in our view, more 
targets means more management complexity. Each target that gets added 
for iSCSI, as an example, requires discovery to be updated. When using 
SendTargets, I would agree there isn't much to do there if the IP 
address is already discovered, but enter iSNS and it means having to add 
each newly created target to the discovery domain. Additionally, 
consider the other benefits of having multiple logical units on a single 
target. If the target is already discovered by the initiator, there is a 
SCSI mechanism in place for discovering new logical units. Granted, it's 
not asynchronous, but providing there is some I/O going to one of the 
existing logical units on that target, the initiator will receive a 
check condition with sense data indicating that the REPORT LUN data has 
changed. And at least for the Solaris iSCSI initiator, your new device 
would automatically be onlined. If you were using SendTargets discovery 
and a new target was added, the discovery process would need to be 
initiated in order to discover the new target even if you had I/O going 
to an existing logical unit on another target. I'm sure there are 
benefits that could be realized in using 1 target for each logical unit 
and there is nothing COMSTAR is doing that will remove that ability. 
It's just our viewpoint that, in most environments, it creates more 
complexity than necessary.

- John
>
> Great idea.  I'm very excited about COMSTAR.
>
> benr.
>