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

[Anand Avati]

On Thu, Jun 27, 2013 at 11:43 AM, Justin Clift <address@hidden> 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