[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