[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" <jdarcy at redhat.com>
>To: "Stephan von Krawczynski" <skraw at ithnet.com>
>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 <jdarcy at redhat.com>
> > 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
> Gluster-devel at nongnu.org
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
> 


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