Hi John-san, Thank you for your review of my summit suggestion and I understand your indication. Could you see my following comments?
------------- http://summit.openstack.org/cfp/details/166 There's a lot here, based on conversations in IRC and the excellent wiki you put together I'm still trying to get a clear picture here. Let's start by taking transport protocol out of the mix; I believe what you're proposing is a shared, multi-attach LV (over iscsi, fibre or whatever). That seems to fall under the multi-attach feature. ------------- So both my BP and BP of "multi-attach-volume" need multi attach feature, but in my understanding, the target layer and goals are different . Let me explain the additional point. * "multi-attach-volume": Implement the volume multi attach feature. Main target layers is Nova layer. (and a little cinder layer implement?). * My BP : Implement a generic LVM volume driver using LVM on a storage volume(over iscsi, fibre or whatever) attached to multi compute nodes. Target layers are both Nova and Cinder layer. The different point is the former case, the cinder volume is needed to create by other cinder storage driver with supported storage, and after that the feature can attach a volume to multiple instances.(and also hosts) On the other hands, my BP targets generic LVM driver and not depends on specific vendor storage. The driver just provide features to create/delete/snapshot volume, etc from a volume group on multi attached storage. The point is user needs to create a storage volume using own storage management tool, attach the created volume to multiple compute nodes, create VG on the volume and configure it to cinder.conf as a "volume_group". So, multi-attach feature is not a target feature to implement. The driver just requires an environment of LVM on a storage attached to multi compute nodes. I think my proposed LVM driver is orthogonal to the "multi-attach-volume" and we can use "multi-attach-volume" and my BP in combination. Here is my additional understanding for both BPs. [A] My BP https://blueprints.launchpad.net/cinder/+spec/lvm-driver-for-shared-storage The goal of my BP is supporting a volume group on a volume which is attached to multiple compute nodes. So the proposed driver just provide a feature to create/delete/snapshot, etc from volume group same as existing LVMiSCSI driver. But the difference from LVMiSCSI driver, the prepared volume group on a storage volume is required to be attached to multiple compute nodes in order to recognize multiple compute nodes simultaneously instead of using iSCSI target. The multi attached storage and volume group on it is needed to prepare before cinder configuration by user without any cinder features because the target of my driver is generic LVM driver and my driver targets to support a storages environment which does not have cinder storage driver. [Preparation of volume_group] (a) An user create a storage volume using "storage management tool".(not cinder feature) (b) Export a created volume to multiple compute nodes.(using FC host group or iSCSI target feature) (c) Create volume group on a exported storage volume. (d) Configure the volume group for the cinder "volume_group". [B] BP of multi-attach-volume https://blueprints.launchpad.net/cinder/+spec/multi-attach-volume The goal of this BP is attaching a cinder volume to multiple instances. In my understanding, providing a cinder volume multi-attach feature is a goal of this BP. Steps to multi attach (1) Create a volume using "cinder volume driver" with "supported storage". Driver and supported driver is required. (2) Export a created volume to multiple compute nodes via FC, iSCSI, etc. (3) Attach a created volume to multiple instances with RO/RW mode. (4) As a result, multiple instances can recognize a single cinder volume simultaneously. ------------- I'm also trying to understand your statements about improved performance. Could you maybe add some more detail or explanation around this things or maybe grab me on IRC when convenient? ------------- This explains a comparison between LVMiSCSI and my BP driver. Current LVMiSCSI driver uses a cinder node as a "virtual storage" using software iSCSI target. This is useful and not depends on storage arrangement, but we have to access a volume group via network even if we have FC environment. If we have multi attached FC volume, it is better to access the volume via FC instead of iSCSI target. As a result, we expect better I/O performance and latency to access multi attached FC volume to compute nodes. This is a point which I mentioned. Regards, Mitsuhiro Tanino <mitsuhiro.tan...@hds.com> HITACHI DATA SYSTEMS c/o Red Hat, 314 Littleton Road, Westford, MA 01886
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
