Re: [Gluster-devel] RFC - "Connection Groups" concept

[Ian Latter]

Sure, except;

  1) UX-wise, historically at least, there doesn't seem to be any intent to 
share gluster internal UUID management with users;
  http://supercolony.gluster.org/pipermail/gluster-devel/2012-April/007769.html

  2) Multi-homing for performance and security is the norm.  See (for example);

  MySQL Reference Architectures for
Massively Scalable Web Infrastructure 
  MySQL Best Practices for Innovating on the Web
  
http://www.oracle.com/us/products/mysql/wp-high-availability-webrefarchs-362556.pdf

  Under "The Perfect MySQL Server" (p25);
  "It is recommended to deploy the data and application nodes on a dedicated 
network (i.e.
IP addresses starting at 10.0.1.0), using 1 Gigabit Ethernet as a minimum 
transport. The MySQL servers would then also be attached to the public 
network." 

  Thus not all interfaces on a host are equal, even if you uniquely identify 
the host via your random hash, randomly picking an address assigned to that 
host will randomly fail connections, as will consistently picking a single 
interface for all client contexts (the backup network is a damn fine example, 
as are dedicated storage networks per the example above and out of band 
management networks - six NICs on a perimeter host is not uncommon). 

  3) DNS entries are used to define uniqueness in a client context in 
enterprise networks (corporate network context versus backup network context 
versus public network context).  In Enterprise Ops, working with native tools 
like DNS is natural, per Stephan's message on this thread and Mike's natural 
response to this obvious user "barrier";
  http://funwithlinux.net/2013/02/glusterfs-tips-and-tricks-centos/

  In Mike's case, in particular, you can see the type of kludgery that you 
force on users when you deny the existence of multi-homed devices (for example, 
amongst other common practices).

  An internal UUIID that determines the connection path/interface, that isn't 
controlled via hosts/DNS (or routing), that can't be administered via the 
native administration tool is what would trend toward problematic.



  FYI - I'm not up to it yet, but I know the multi-homing issue is coming for 
me - my code binds the gluster instance/share to the interface - but I intend 
to run up a dedicated storage network and I'm not sure how yet; its good to see 
this being discussed.





----- Original Message -----
>From: "Jeff Darcy" <address@hidden>
>To: "Stephan von Krawczynski" <address@hidden>
>Subject:  Re: [Gluster-devel] RFC - "Connection Groups" concept
>Date: Wed, 26 Jun 2013 11:46:36 -0400
>
> On 06/27/2013 09:37 AM, Stephan von Krawczynski wrote:
> > On Wed, 26 Jun 2013 11:04:07 -0400 Jeff Darcy <address@hidden>
> > wrote:
> >
> >> [Jeff on UUIDs]
> >
> > I generally vote against using UUIDs and for IPs. In runtime I can
> > easily switch an IP in a replacement situation, but can I switch a
> > UUID in the same easy manner?
> 
> I don't see why that would be problematic.  The UUIDs we're talking
> about aren't tied to hardware.  They're essentially big random numbers
> we assign ourselves.  IIRC they're just stored in a file, so they can be
> trivially copied from a system to its replacement.  The problem is
> precisely that DNS names and IP addresses aren't good *system*
> identifiers.  For one thing, they refer to interfaces rather than
> systems (which might have many interfaces).  For another, even that
> association is too transient.  Such IDs are convenient for referring to
> a system *at a specific point in time* but not permanently, and a
> permanent ID for the whole system is something we really need.  It sure
> would be nice if the networking community would stop ****ing around when
> it comes to multi-homed or mobile hosts, but they don't seem inclined to
> so the rest of us have to fall back on other established patterns for
> identifying hosts separately from their addresses.
> 
> 
> _______________________________________________
> Gluster-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
> 


--
Ian Latter
Late night coder ..
http://midnightcode.org/