On 10/29/2015 12:18 PM, Venky Shankar wrote:
On Thu, Oct 29, 2015 at 11:36 AM, Pranith Kumar Karampuri
<pkara...@redhat.com> wrote:
hi,
I want to understand how are you guys planning to integrate NSR
volumes to the existing CLIs. Here are some thoughts I had, wanted to know
your thoughts:
At the heart of both the replication/ec schemes we have
1) synchronization mechanisms
a) afr,ec does it using locks
b) nsr does it using leader election
2) Metadata to figure out the healing/reconciliation aspects
a) afr,ec does it using xattrs
b) nsr does it using journals
I want to understand if there is a possibility of exposing these as
different modules that we can mix and match, using options. If the users
Do you mean abstracting it out during volume creation? At a high level
this could be in the form of client or server
side replication. Not that AFR cannot be used on the server side
(you'd know better than me), but, if at all this level
of abstraction is used, we'd need to default to what fits best in what
use case (as you already mentioned below)
but still retaining the flexibility to override it.
precisely. I think switching is not that difficult once we make sure
healing is complete. Switching is a rare operation IMO so we can
probably ask the users to do stop/choose-new-value/start the volume
after choosing the options. This way is simpler than to migrate between
the volumes where you have to probably copy the data.
Pranith
choose 1b, 2b it becomes nsr and 1a, 2a becomes afr/ec. In future if we come
up with better metadata journals/stores it should be easy to plug them is
what I'm thinking. The idea I have is based on the workload, users should be
able to decide which pair of synchronization/metadata works best for them
(Or we can also recommend based on our tests). Wanted to seek your inputs.
Pranith
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
