|
From: | Joe Landman |
Subject: | Re: [Gluster-devel] RFC - "Connection Groups" concept |
Date: | Thu, 27 Jun 2013 10:37:23 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 |
On 06/27/2013 10:30 AM, Stephan von Krawczynski wrote:
On Wed, 26 Jun 2013 11:46:36 -0400 Jeff Darcy <address@hidden> wrote: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.Now the exact reason why IPs are always better than your idea of UUIDs is because they are linked to interfaces. You _want_ your fs node to use exactly _this_ interface and not _some_ interface because you then have a real chance to direct your traffic like you want it and not like glusterfs currently thinks could be best.
No. One of the largest issues we and our customers have been having for years has been tightly tying gluster volume creation to single IP addresses. This makes multihomed usage, well, problematic, at best. Worse than this, is the use of the DNS name (or other name) which, exactly as Jeff indicates, tightly ties the brick/mount point to a particular interface.
What you want is an abstraction which represents a group of connections on a brick or set of bricks. UUID does this.
FWIW: we'd been using split horizon/multi-horizon DNS to try to work around these issues for multihomed systems, and inevitably, they break some aspect of the file system.
UUID with connection groups, and even better, primary/secondary, or even weights on each connection, would be quite nice ... a breath of fresh air.
-- Joseph Landman, Ph.D Founder and CEO Scalable Informatics, Inc. email: address@hidden web : http://scalableinformatics.com http://scalableinformatics.com/siflash phone: +1 734 786 8423 x121 fax : +1 866 888 3112 cell : +1 734 612 4615
[Prev in Thread] | Current Thread | [Next in Thread] |