On Thu, Jun 27, 2013 at 11:43 AM, Justin Clift <[email protected]> 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 > >
_______________________________________________ Gluster-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/gluster-devel
