gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] How do we identify peers?


From: Justin Clift
Subject: Re: [Gluster-devel] How do we identify peers?
Date: Thu, 27 Jun 2013 19:43:35 +0100

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.


> 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). :)


> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]