The COMSTAR project team is beginning discussions around how COMSTAR will impact the user experience for the current iSCSI target. While we don't have all of the designs in place for the iSCSI target under COMSTAR, we have a feel for some items that will differ slightly from the existing iSCSI target implementation.
One of the goals of COMSTAR is to provide as much configuration flexibility as possible while attempting to balance that with simplicity in its CLI and library interfaces. This goal of flexibility and simplicity also holds true for the framework logical unit and target provider interfaces within COMSTAR but since the focus here is on current iSCSI target consumers, we can leave that discussion for another time, one that probably targets framework provider interface clients rather than clients of the CLI and library. For the purposes of this and future discussions, the existing iSCSI target will be referred to as the current iSCSI target. References to the future implementation under COMSTAR will be referred to as COMSTAR or the COMSTAR iSCSI target. With that out of the way, here are some of the high level items that we know differ: 1) Targets and Logical units These items are combined here simply because they were combined within the iSCSI target. Tying them tightly together in the CLI, or anywhere for that matter, when you have more than one transport (i.e. iSCSI + fibre channel), can be somewhat limiting. Management of the logical units themselves should be completely independent of the target. Association of the logical unit with the target is only done for purposes of exporting that logical unit via one or more target ports. Those target ports can be of any of the supported transport protocol types that can transport SCSI (iSCSI, fibre channel, SAS, etc). The stmf framework within COMSTAR does not limit the type of protocol that can be implemented as a target provider. To that end, this existing coupling of the target and logical unit will no longer exist with COMSTAR. COMSTAR will treat each of these logical units as separate entities. The association between the logical unit and the target will be represented using objects te rmed "view entries". A logical unit that is exported via one or more target ports will have one or more associated view entries, with each describing how that logical unit is exported. 2) Target Access Control Lists The current iSCSI target uses ACLs on the target to control which initiators have access to the target and subsequently to the logical units behind that target. While the target ACL provides an authorization scheme at the transport level (iSCSI), it does not provide any authorization granularity at the logical unit level. In this fashion, it is an all-or-nothing approach to logical unit access control. As for the benefits of target level access control, this is one of the items that we will need to discuss further and it would be interesting to understand in what environments this feature might be useful. Logical unit access control is well understood in the storage industry as logical unit masking and we will use this terminology moving forward to describe it. Since COMSTAR's approach is to treat the logical units as separate entities, this logical unit masking strategy will change from the current iSCSI target. As indicated in the first item above, "Targets and Logical unit s", view entries will be used to describe how the logical unit is exported. These same view entries will also be used to describe the masking that is applied to the logical unit thereby describing which initiators have access to the logical unit. 3) Target Logical Unit Numbers The current iSCSI target provides the ability to create a logical unit with a specified logical unit number. This logical unit number cannot be modified without destroying the logical unit. While for most scenarios, this approach is likely sufficient, there are scenarios that require greater flexibility in logical unit number assignment for a given logical unit. This becomes particularly important when exporting the logical unit via multiple target ports and to multiple initiators. COMSTAR will move this logical unit number assignment, generally referred to as logical unit mapping, to the view entry on the logical unit. In this way, there can be multiple logical unit mapping definitions associated with a single logical unit. This concept of using a view entry to describe the logical unit export, masking and mapping attributes is described in a document on the OpenSolaris COMSTAR project page. http://www.opensolaris.org/os/project/comstar/files/ve_description.pdf Other than the above 3 items, the current iSCSI target largely remains the same since the rest of the features in the current iSCSI target are iSCSI specific rather than SCSI specific, so the lines of separation with the COMSTAR stmf framework functionality are fairly clean. We certainly welcome discussion in this area. And if you have any further interest in COMSTAR, the complete project materials are available at the OpenSolaris project website mentioned above. Thanks, John This message posted from opensolaris.org _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
