<div dir="ltr"><div><div><div><div><div>Hi Erlon, hi Philipp thank you for your answers.<br></div>I will try to explain with a real case:<br><br></div>@Erlon:
 I have 2 nodes that works as a SAN with targetcli and DRBD for a raid 
over network. This cluster can be seen as an "ISCSI node".<br></div>Furthermore,
 I have 2 nodes with openstack-cinder-volume (with pacemaker). Basically
 I have N iscsi devices here (from the ISCSI node) and on top of those 
there is the cinder-volumes VG.<br></div>So, when a new volume in cinder
 is created, a new loigical volume will be allocated in the 
cinder-volumes group. Using my solution I can merge the cinder-volumes 
VG in the ISCSI node and move (for example) the openstack-cinder-volume 
service on the controller because less power is needed here. <br></div>My ideas:<br><div><div><div>-
 When I need to upgrade openstack, I can have problems with 
drbd/kernel/targetcli packages that I'd like to avoid during an 
openstack upgrade.<br></div><div>- WIth this solution I can think to remove the openstack-cinder-volume dedicated node (in small environments)<br></div><div>- I thought that this can be a support in the open source world for the people who built a san with drbd + lvm + targetcli<br></div><div>Anyway, I only tried to propose a new idea....<br></div><div><br></div><div>@Philipp:
 thank you, but at the moment drbd9 has little documentation and the 
solution with openstack is really lacking of guides/tutorials/examples 
and performance analysis. Actually I'm using drbd 8.4.6 in production 
and without a lot of tests and examples I won't switch to the next 
version. <br></div><div><br>  <br></div><div>Thank you<br></div><div>Marco<br></div><div><div><br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-02-01 12:39 GMT+01:00 Philipp Marek <span dir="ltr"><<a href="mailto:philipp.marek@linbit.com" target="_blank">philipp.marek@linbit.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everybody,<br>
<span class=""><br>
> > Hi, I'd like to know if it is possible to use openstack-cinder-volume with<br>
> > a remote LVM. This could be a new feature proposal if the idea is good.<br>
> > More precisely, I'm thinking a solution where openstack-cinder-volume runs<br>
> > on a dedicated node and LVM on another node (called "storage node").  On<br>
> > the storage node I need to have a volume group (normally named<br>
> > cinder-volumes) and the targetcli package, so the iscsi_ip_address in<br>
> > cinder.conf should be an address associated with the storage node.<br>
> > Advantages of this solution are: 1) When I need to upgrade openstack I can<br>
> > leave out the storage node from the process (because it has only LVM and<br>
> > targetcli or another daemon used for iscsi targets). 2) Down on the<br>
> > cinder-volume node cannot creates problems to the iscsi part exposed to<br>
> > vms. 3) Support to the open source world in cinder: LVM is the common<br>
> > solution for cinder in low budget environment but performance are good if<br>
> > the storage node is powerful enough<br>
> ><br>
> > In my idea, the "interface" between openstack-cinder-volume and lvm can be<br>
> > SSH. Basically we need to create/remove/manage logical volumes on a remote<br>
> > node and the same for the iscsi targets<br>
> ><br>
> > Please, let me know if this can be a valid solution.<br>
</span><span class="">> What you are proposing is almost like to create an LVM storage box. I<br>
> haven't seen any real benefit from the advantages you listed. For 1), the<br>
> same problems you can have upgrading the services within the same node will<br>
> happen if the LVM services are not in the same host. For, 2), now you have<br>
> 2 nodes to manage instead of 1, which double the changes of having<br>
> problems. And for 3), I really didn't get the advantage related to the<br>
> solution you are proposing.<br>
><br>
> If you have real deployments cases where this could help (or if there are<br>
> other people interested), please list it here so people can see more<br>
> concrete benefits of using this solution.<br>
<br>
</span>please let me suggest to look at the DRBD Cinder driver that's already<br>
upstream.<br>
Basically, this allows to use one or more storage boxes, and to export<br>
their storage (via LV and DRBD) to the Compute nodes.<br>
<br>
If you're using the DRBD protocol instead of iSCSI (and configure the DRBD<br>
Cinder driver to store 2 copies of the data), you'll even benefit from<br>
redundancy - you can maintain one of the storage nodes while the other is<br>
serving data, and (as soon as the data is synchronized up again) then do<br>
your maintenance on the other storage node.<br>
<br>
<br>
See here for more details:<br>
    <a href="http://www.drbd.org/en/doc/users-guide-90/ch-openstack" rel="noreferrer" target="_blank">http://www.drbd.org/en/doc/<wbr>users-guide-90/ch-openstack</a><br>
<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>