[openstack-dev] [Nova][Cinder] Feature about Raw Device Mapping

Duncan Thomas duncan.thomas at gmail.com
Fri Mar 21 19:15:27 UTC 2014


In general, abstracting the offload of snapshot, backup etc the a SAN
is exactly the job of cinder.

RDM has, in the general cloud case, a bunch of security issues (raw
sector reads outside of what is being presented, firmware updates,
etc) that need carefully looking at.

On 18 March 2014 09:33, Zhangleiqiang (Trump) <zhangleiqiang at huawei.com> wrote:
>> From: Huang Zhiteng [mailto:winston.d at gmail.com]
>> 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)
>> <zhangleiqiang at huawei.com> wrote:
>> >> From: Huang Zhiteng [mailto:winston.d at gmail.com]
>> >> 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)
>> >> <zhangleiqiang at huawei.com> 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.
>
> And besides these two scenarios, there is another use case: running SAN-aware application inside instances, such as:
> 1. SAN management app
> 2. Apps which can offload the device related works, such as snapshot, backup, etc, to SAN.
>
>
>> >
>> >> >         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
>> >> > OpenStack-dev at lists.openstack.org
>> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >>
>> >>
>> >> --
>> >> Regards
>> >> Huang Zhiteng
>> >>
>> >> _______________________________________________
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev at lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> --
>> Regards
>> Huang Zhiteng
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Duncan Thomas



More information about the OpenStack-dev mailing list