[Gluster-devel] How do we identify peers?

[Anand Avati]

On Thu, Jun 27, 2013 at 11:43 AM, Justin Clift <jclift at redhat.com> wrote:

> On 27/06/2013, at 6:53 PM, Anand Avati wrote:
> > Using UUIDs as the identifier for all internal management communication
> is a good idea. The CLI commands could still use hosts or IPs, but that
> should be translated to UUIDs as an alias as superficially as possible
> (ideally in the CLI itself, glusterd only communicates by UUID). The
> translation of UUID to host IPs should really be dynamic/discovery based.
> Each host must present all its IPs to all its peers.
>
> Seriously bad idea (after thinking about it). :)
>
> In corporate environments, the "backup network" which most places have
> for their servers is *only* for backup traffic.  Applications on the
> server (such as Gluster) get their own dedicated nics and switches.


Backup networks can be flagged as private on a per server level (and just
not get exposed) if you want the network isolation to happen at the
application level (rather than at the network / routing level).


> > Volgen and protocol/client must be enhanced to accept multiple IPs for
> each brick and auto select the right/routed address at runtime (or accept a
> preferred interface as input).
>
> Have you looked at the connection group stuff?  I think that would be
> a more flexible approach for most corporate/enterprise level environments.
>
> That being said, an auto selection mechanism might really be the way to
> go for cloud scale stuff (unsure). :)


(replying the rest in that thread..)

Avati


>
> > We should even start identifying bricks by UUID and self-discovered
> (independent of host and backend mount-point). This way if an EBS volume is
> detached and attached to a different node at a different backend mount,
> configuration must get auto reconfigured (either completely using udev, or
> with partial/limited input from admin). Converting to UUID would be partial
> if bricks are not pulled in to the scheme.
>
> Hmmm, interesting thought.  Prob want SSL certificates in use for this,
> but that wouldn't be a blocker.
>
> Not see-ing this approach as being easily code-able in the near future
> though?  More a longer term thing?
>
> Regards and best wishes,
>
> Justin Clift
>
> --
> Open Source and Standards @ Red Hat
>
> twitter.com/realjustinclift
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130627/e15bb1d9/attachment-0001.html>