Jason Shamberger wrote: > Hannes, > > Thanks for the feedback. I looked through the spec you mentioned, and the logical block dependent ALUA > functionality is similar to what we are trying to accomplish, however it is not a good fit with our storage > array architecture. Our storage array exposes all LUNs through a single Target Port Group, whereas multiple > TPGs are needed for the ALUA functionality. The design choice of a single TPG was made to simplify the > logic on the initiator side. The client does not need to decide which TPG(s) to connect to, it always > connects to the single Target Port Group and the storage array decides where to place the connections > through use of iSCSI redirection. > I still think it should be possible to use the ALUA infrastructure here. As you are using iSCSI redirection _all_ nodes in you storage cluster already will have to have an iSCSI interface. To have your proposed functionality mapped on LB-ALUA you only have to expose each of these interfaces, and have the mapping shared between all of these nodes (which you have to do anyway). Assume two nodes A and B with iSCSI interfaces A1 and B1 both serving LUN1. One part LUN1a residing on node A and the other part LUN1b residing on node B. Each node (and every interface on that node) would reside in it's own SCSI Target Port Group, exposing _the entire_ LUN as LB-ALUA capable. Node A would mark LUN1a as 'active/optimized' and LUN1b as 'active/non-optimized', node B would mark LUN1b as 'active/optimized' and LUN1a as 'active/non-optimized'. Any accesses to the 'non-optimized' sections would be forwarded to the other nodes via iSCSI redirection. In effect access would work even when connecting to a single node, and a good speedup would be observed when using an LB-ALUA capable initiator. Yes, you would have to expose several TPGs (basically one group per node), but each LUN would be present in each TPG. So it wouldn't matter much to the functionality here. > Our goal with this project is to keep the simplicity aspects of our storage array architecture, > but add a path selector on the linux initiator to choose the optimal path for each IO. > In this framework, we need additional information to be passed to the path selector to > aid it in choosing the optimal path. > But you have to fight for it, as you're the only one using this infrastructure. If you would support LB-ALUA you wouldn't be alone in this, as we (as the linux community) would have to support it eventually. Plus it's simply is more fun to code against an official standard; proprietary interfaces are a pain to support properly. And I'd be glad to help in converting multipathing to make it LB-ALUA capable, but my interest in proprietary interfaces is close to zero :-) Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
