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.ma...@linbit.com>
To: openstack-dev@lists.openstack.org,
Cc: Ronen Kat/Haifa/IBM@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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
