Open Stack

Hi everybody,

> > Hi, I'd like to know if it is possible to use openstack-cinder-volume with
> > a remote LVM. This could be a new feature proposal if the idea is good.
> > More precisely, I'm thinking a solution where openstack-cinder-volume runs
> > on a dedicated node and LVM on another node (called "storage node").  On
> > the storage node I need to have a volume group (normally named
> > cinder-volumes) and the targetcli package, so the iscsi_ip_address in
> > cinder.conf should be an address associated with the storage node.
> > Advantages of this solution are: 1) When I need to upgrade openstack I can
> > leave out the storage node from the process (because it has only LVM and
> > targetcli or another daemon used for iscsi targets). 2) Down on the
> > cinder-volume node cannot creates problems to the iscsi part exposed to
> > vms. 3) Support to the open source world in cinder: LVM is the common
> > solution for cinder in low budget environment but performance are good if
> > the storage node is powerful enough
> >
> > In my idea, the "interface" between openstack-cinder-volume and lvm can be
> > SSH. Basically we need to create/remove/manage logical volumes on a remote
> > node and the same for the iscsi targets
> >
> > Please, let me know if this can be a valid solution.
> What you are proposing is almost like to create an LVM storage box. I
> haven't seen any real benefit from the advantages you listed. For 1), the
> same problems you can have upgrading the services within the same node will
> happen if the LVM services are not in the same host. For, 2), now you have
> 2 nodes to manage instead of 1, which double the changes of having
> problems. And for 3), I really didn't get the advantage related to the
> solution you are proposing.
> 
> If you have real deployments cases where this could help (or if there are
> other people interested), please list it here so people can see more
> concrete benefits of using this solution.

please let me suggest to look at the DRBD Cinder driver that's already 
upstream.
Basically, this allows to use one or more storage boxes, and to export 
their storage (via LV and DRBD) to the Compute nodes.

If you're using the DRBD protocol instead of iSCSI (and configure the DRBD 
Cinder driver to store 2 copies of the data), you'll even benefit from 
redundancy - you can maintain one of the storage nodes while the other is 
serving data, and (as soon as the data is synchronized up again) then do 
your maintenance on the other storage node.


See here for more details:
    http://www.drbd.org/en/doc/users-guide-90/ch-openstack