On Tue, Mar 18, 2014 at 5:33 PM, Zhangleiqiang (Trump) <[email protected]> wrote: >> From: Huang Zhiteng [mailto:[email protected]] >> Sent: Tuesday, March 18, 2014 4:40 PM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [Nova][Cinder] Feature about Raw Device >> Mapping >> >> On Tue, Mar 18, 2014 at 11:01 AM, Zhangleiqiang (Trump) >> <[email protected]> wrote: >> >> From: Huang Zhiteng [mailto:[email protected]] >> >> Sent: Tuesday, March 18, 2014 10:32 AM >> >> To: OpenStack Development Mailing List (not for usage questions) >> >> Subject: Re: [openstack-dev] [Nova][Cinder] Feature about Raw Device >> >> Mapping >> >> >> >> On Tue, Mar 18, 2014 at 9:40 AM, Zhangleiqiang (Trump) >> >> <[email protected]> wrote: >> >> > Hi, stackers： >> >> > >> >> > With RDM, the storage logical unit number (LUN) can be >> >> > directly >> >> connected to a instance from the storage area network (SAN). >> >> > >> >> > For most data center applications, including Databases, CRM >> >> > and >> >> ERP applications, RDM can be used for configurations involving >> >> clustering between instances, between physical hosts and instances or >> >> where SAN-aware applications are running inside a instance. >> >> If 'clustering' here refers to things like cluster file system, which >> >> requires LUNs to be connected to multiple instances at the same time. >> >> And since you mentioned Cinder, I suppose the LUNs (volumes) are >> >> managed by Cinder, then you have an extra dependency for multi-attach >> >> feature: >> https://blueprints.launchpad.net/cinder/+spec/multi-attach-volume. >> > >> > Yes. "Clustering" include Oracle RAC, MSCS, etc. If they want to work in >> instance-based cloud environment, RDM and multi-attached-volumes are both >> needed. >> > >> > But RDM is not only used for clustering, and haven't dependency for >> multi-attach-volume. >> >> Set clustering use case and performance improvement aside, what other >> benefits/use cases can RDM bring/be useful for? > > Thanks for your reply. > > The advantages of Raw device mapping are all introduced by its capability of > "pass" scsi command to the device, and the most common use cases are > clustering and performance improvement mentioned above. > As mentioned in earlier email, I doubt the performance improvement comes from 'virtio-scsi' interface instead of RDM. We can actually test them to verify. Here's what I would do: create one LUN(volume) on the SAN, attach the volume to instance using current attach code path but change the virtual bus to 'virtio-scsi' and then measure the IO performance using standard IO benchmark; next, attach the volume to instance using 'lun' device for 'disk' and 'virtio-scsi' for bus, and do the measurement again. We shall be able to see the performance difference if there is any. Since I don't have a SAN to play with, could you please do the test and share the results?
> And besides these two scenarios, there is another use case: running SAN-aware > application inside instances, such as: > 1. SAN management app Yes, that is possible if RDM is enable. But I wonder what is the real use case behind this. Even though SAN mgmt app inside instance is able to manage the LUN directly, but it is just a LUN instead of a real SAN, what the instance can do is *limited* to the specific LUN, which doesn't seem very useful IMO. Or are you thinking about creating a big enough LUN for user so they can treat it like a 'virtual' SAN and do all kinds of management stuff to it and even maybe resell it for PaaS use cases? > 2. Apps which can offload the device related works, such as snapshot, backup, > etc, to SAN. Not sure I follow this use cases either, nor do I understand why end users want to do all those operations _inside_ instance instead of utilizing existing infrastructure like Cinder. If the goal behind this is to make traditional IT users happy, I tend to agree with what Duncan said in another thread (http://osdir.com/ml/openstack-dev/2014-03/msg01395.html) > > >> > >> >> > RDM, which permits the use of existing SAN commands, is >> >> generally used to improve performance in I/O-intensive applications >> >> and block locking. Physical mode provides access to most hardware >> >> functions of the storage system that is mapped. >> >> It seems to me that the performance benefit mostly from virtio-scsi, >> >> which is just an virtual disk interface, thus should also benefit all >> >> virtual disk use cases not just raw device mapping. >> >> > >> >> > For libvirt driver, RDM feature can be enabled through the "lun" >> >> device connected to a "virtio-scsi" controller: >> >> > >> >> > <disk type='block' device='lun'> >> >> > <driver name='qemu' type='raw' cache='none'/> >> >> > <source >> >> dev='/dev/mapper/360022a110000ecba5db427db00000023'/> >> >> > <target dev='sdb' bus='scsi'/> >> >> > <address type='drive' controller='0' bus='0'/> >> >> > </disk> >> >> > >> >> > <controller type='scsi' index='0' model='virtio-scsi'/> >> >> > >> >> > Currently，the related works in OpenStack as follows: >> >> > 1. block-device-mapping-v2 extension has already support >> >> > the >> >> "lun" device with "scsi" bus type listed above, but cannot make the >> >> disk use "virtio-scsi" controller instead of default "lsi" scsi >> >> controller. >> >> > 2. libvirt-virtio-scsi-driver BP ([1]) whose milestone >> >> > target is >> >> icehouse-3 is aim to support generate a virtio-scsi controller when >> >> using an image with "virtio-scsi" property, but it seems not to take >> >> boot-from-volume and attach-rdm-volume into account. >> >> > >> >> > I think it is meaningful if we provide the whole support >> >> > for RDM >> >> feature in OpenStack. >> >> > >> >> > Any thoughts? Welcome any advices. >> >> > >> >> > >> >> > [1] >> >> > https://blueprints.launchpad.net/nova/+spec/libvirt-virtio-scsi-dri >> >> > ver >> >> > ---------- >> >> > zhangleiqiang (Trump) >> >> > >> >> > Best Regards >> >> > >> >> > _______________________________________________ >> >> > OpenStack-dev mailing list >> >> > [email protected] >> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> >> >> >> -- >> >> Regards >> >> Huang Zhiteng >> >> >> >> _______________________________________________ >> >> OpenStack-dev mailing list >> >> [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 >> >> >> >> -- >> Regards >> Huang Zhiteng >> >> _______________________________________________ >> OpenStack-dev mailing list >> [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 -- Regards Huang Zhiteng _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
