Hi Avishay-san, Thank you for your review and comments for my proposal. I commented in-line.
>>So the way I see it, the value here is a generic driver that can work with >>any storage. The downsides: A generic driver for any storage is an one of benefit. But main benefit of proposed driver is as follows. - Reduce hardware based storage workload by offloading the workload to software based volume operation. Conventionally, operations to an enterprise storage such as volume creation, deletion, snapshot, etc are only permitted system administrator and they handle these operations after carefully examining. In OpenStack cloud environment, every user have a permission to execute these storage operations via cinder. As a result, workloads of storages have been increasing and it is difficult to manage the workloads. If we have two drivers in regards to a storage, we can use both way as the situation demands. Ex. As for "Standard" type storage, use proposed software based LVM cinder driver. As for "High performance" type storage, use hardware based cinder driver. As a result, we can offload the workload of standard type storage from physical storage to cinder host. >>1. The admin has to manually provision a very big volume and attach it to the >>Nova and Cinder hosts. >> Every time a host is rebooted, I thinks current FC-based cinder drivers using scsi scan to find created LU. # echo "- - -" > /sys/class/scsi_host/host#/scan The admin can find additional LU using this, so host reboot are not required. >> or introduced, the admin must do manual work. This is one of the things >> OpenStack should be trying >> to avoid. This can't be automated without a driver, which is what you're >> trying to avoid. Yes. Some admin manual work is required and can’t be automated. I would like to know whether these operations are acceptable range to enjoy benefits from my proposed driver. >>2. You lose on performance to volumes by adding another layer in the stack. I think this is case by case. When user use a cinder volume for DATA BASE, they prefer raw volume and proposed driver can’t provide raw cinder volume. In this case, I recommend "High performance" type storage. LVM is a default feature in many Linux distribution. Also LVM is used many enterprise systems and I think there is not critical performance loss. >>3. You lose performance with snapshots - appliances will almost certainly >>have more efficient snapshots >> than LVM over network (consider that for every COW operation, you are >> reading synchronously over the network). >> (Basically, you turned your fully-capable storage appliance into a dumb JBOD) I agree that storage has efficient COW snapshot feature, so we can create new Boot Volume from glance quickly. In this case, I recommend "High performance" type storage. LVM can’t create nested snapshot with shared LVM now. Therefore, we can’t assign writable LVM snapshot to instances. Is this answer for your comment? >> In short, I think the cons outweigh the pros. Are there people deploying >> OpenStack who would deploy >> their storage like this? Please consider above main benefit. Regards, Mitsuhiro Tanino <[email protected]> HITACHI DATA SYSTEMS c/o Red Hat, 314 Littleton Road, Westford, MA 01886 From: Avishay Traeger [mailto:[email protected]] Sent: Wednesday, May 21, 2014 4:36 AM To: OpenStack Development Mailing List (not for usage questions) Cc: Tomoki Sekiyama Subject: Re: [openstack-dev] [Cinder] Support LVM on a shared LU So the way I see it, the value here is a generic driver that can work with any storage. The downsides: 1. The admin has to manually provision a very big volume and attach it to the Nova and Cinder hosts. Every time a host is rebooted, or introduced, the admin must do manual work. This is one of the things OpenStack should be trying to avoid. This can't be automated without a driver, which is what you're trying to avoid. 2. You lose on performance to volumes by adding another layer in the stack. 3. You lose performance with snapshots - appliances will almost certainly have more efficient snapshots than LVM over network (consider that for every COW operation, you are reading synchronously over the network). (Basically, you turned your fully-capable storage appliance into a dumb JBOD) In short, I think the cons outweigh the pros. Are there people deploying OpenStack who would deploy their storage like this? Thanks, Avishay On Tue, May 20, 2014 at 6:31 PM, Mitsuhiro Tanino <[email protected]<mailto:[email protected]>> wrote: Hello All, I’m proposing a feature of LVM driver to support LVM on a shared LU. The proposed LVM volume driver provides these benefits. - Reduce hardware based storage workload by offloading the workload to software based volume operation. - Provide quicker volume creation and snapshot creation without storage workloads. - Enable cinder to any kinds of shared storage volumes without specific cinder storage driver. - Better I/O performance using direct volume access via Fibre channel. In the attachment pdf, following contents are explained. 1. Detail of Proposed LVM volume driver 1-1. Big Picture 1-2. Administrator preparation 1-3. Work flow of volume creation and attachment 2. Target of Proposed LVM volume driver 3. Comparison of Proposed LVM volume driver Could you review the attachment? Any comments, questions, additional ideas would be appreciated. Also there are blueprints, wiki and patches related to the slide. https://blueprints.launchpad.net/cinder/+spec/lvm-driver-for-shared-storage https://blueprints.launchpad.net/nova/+spec/lvm-driver-for-shared-storage https://wiki.openstack.org/wiki/Cinder/NewLVMbasedDriverForSharedStorageInCinder https://review.openstack.org/#/c/92479/ https://review.openstack.org/#/c/92443/ Regards, Mitsuhiro Tanino <[email protected]<http://[email protected]>> HITACHI DATA SYSTEMS c/o Red Hat, 314 Littleton Road, Westford, MA 01886 _______________________________________________ OpenStack-dev mailing list [email protected]<mailto:[email protected]> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
