[openstack-dev] [cinder][replication-api] extra_specs too constant

Ronen Kat RONENKAT at il.ibm.com
Fri Jul 11 19:09:30 UTC 2014


Philipp,

Thanks for the feedback, below if my view, and I would like to hear what 
others think.

I would typically expect the "replication_partners" to be created/computed 
by the driver from the underlaying replication mechanism.
I assume DRBD know with whom he is current enabled for replication - I 
don't think this should be kept in the Cinder DB (in the extra specs of 
the volume-type).

In the extra specs we may find "replica_volume_backend_name", but I expect 
it to be a short list.

As for the case of multiple "appropriate" replication targets, the current 
plan is to choose the 1st eligible , but we can change it to be a random 
entry from the list, if you think that is appropriate.

Regarding actual "replication_rpo_range" and network bandwidth, I think 
the current suggestion is a reasonable 1st step.
Multiple considerations will of course impact the actual RPO, but I think 
this is outside the scope of this 1st revision - I would like to see this 
mechanism enhanced in the next revision.

Ronen,



From:   Philipp Marek <philipp.marek at linbit.com>
To:     openstack-dev at lists.openstack.org, 
Cc:     Ronen Kat/Haifa/IBM at IBMIL
Date:   11/07/2014 04:10 PM
Subject:        [openstack-dev][cinder][replication-api] extra_specs too 
constant



I think that "extra_specs" in the database is too static, too hard to 
change.


In the case of eg. DRBD, where many nodes may provide some storage space, 
the 
list "replication_partners" is likely to change often, even if only newly 
added nodes have to be done[1]

This means that
  a) the admin has to add each node "manually"
  b) volume_type_extra_specs:value is a VARCHAR(255), which can only 
provide 
                  a few host names. (With FQDN even more so.)

What if the list of hosts would be matched by each one saying "I'm product 
XYZ 
version compat N-M" (eg. via get_volume_stats), and all nodes that report 
the same product with an overlapping version range are considered eligible 

for replication?


Furthermore, "replication_rpo_range" might depend on other circumstances 
too... if the network connection to the second site is heavily loaded, the 

RPO will vary, too - from a few seconds to a few hours.

So, should we announce a range of (0,7200)?


Ad 1: because Openstack sees by itself which nodes are available.


-- 
: Ing. Philipp Marek
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting                 http://www.linbit.com :

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140711/086cdbf1/attachment.html>


More information about the OpenStack-dev mailing list