Hi Erlon, hi Philipp thank you for your answers. I will try to explain with a real case:
@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". 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. 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. My ideas: - 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. - WIth this solution I can think to remove the openstack-cinder-volume dedicated node (in small environments) - I thought that this can be a support in the open source world for the people who built a san with drbd + lvm + targetcli Anyway, I only tried to propose a new idea.... @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. Thank you Marco 2017-02-01 12:39 GMT+01:00 Philipp Marek <[email protected]>: > 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 > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
