[openstack-dev] 【openstack-dev】【nova】discussion about add support to SSD ephemeral storage
Daniel P. Berrange
berrange at redhat.com
Wed Apr 16 08:48:12 UTC 2014
On Wed, Apr 16, 2014 at 02:17:13AM +0000, Yuzhou (C) wrote:
> Hi Daniel,
>
> Thanks for your comments about this BP:https://review.openstack.org/#/c/83727/
>
> My initial thoughts is to do little changes then get better performance of guest vm. So it is a bit too narrowly focused.
>
> After review SSD use case, I totally agree with your comments. I think if I want to implement the broader picture, there are many work items that need to do.
>
> 1. Add support to create flavor with SSD ephemeral storage.
> The cloud adminstrator create the flavor that indicate which backend should be used per instance. e.g.
> nova flavor-key m1.ssd set quota:ephemeral_storage_type=ssd
> (root_disk ephemeral_disk and swap_disk are placed onto a ssd)
> Or more fine grained, e.g.
> nova flavor-key m1.ssd set quota:root_disk_type=ssd
> nova flavor-key m1.ssd set quota:ephemeral_disk_type=hd
> nova flavor-key m1.ssd set quota:swap_disk_type=ssd
> (root_disk and swap_disk are placed onto a ssd, ephemeral_disk is placed onto a harddisk)
I don't think you should be using the term 'ssd' here, or indeed anywhere.
We should just be letting the admin configure multiple local image types,
and given them each a name. Then just refer to the image types by name.
We don't need to care whether they're SSD backed or not - just that the
admin can configure whatever backends they want to. I've already seen
people asking for ability to have a choice of local image backends per
flavour even before you raised the SSD idea.
> 2. When config nova,the deployer of openstack configure <ephemeral_storage_pools>
> e.g.
> if libvirt_image_type=default (local disk)
> ephemeral_storage_pools=<path1>,<path2>
> if libvirt_image_type=RBD
> ephemeral_storage_pools=rdb1,rdb2
We have to bear in mind existing config parameters:
raw/qcow2 - instances_path
lvm - images_volume_group
rbd - images_rbd_pool
I think each of those needs to be extended to allow a list of values,
instead of a single value.
Then libvirt_image_type would need to allow a list of names + types
eg if we wanted to have 2 instances of the raw backend you could
perhaps do
libvirt_image_type=default:raw, fast:raw
instances_path=default:/var/novaimages/hdd, fast:/var/nova/images/ssd
Or if you wanted to do a choice of local qcow2 and two rbd pools,
one of which is fast ssd backed you could do
libvirt_image_type=default:qcow2, fast:qcow2, shared:rbd, sharedfast:rbd
instance_path=default:/var/nova/images/hdd, fast:/var/nova/imges/ssd
images_rbd_pool=shared:main,sharedfast:mainssd
The tags 'defualt', 'fast', 'shared', 'sharedfast' would be what you'd
use in the flavour to tag storage.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
More information about the OpenStack-dev
mailing list