Bug 1242546 - Peer not recognized after IP address change
Summary: Peer not recognized after IP address change
Keywords:
Status: CLOSED DUPLICATE of bug 1241963
Alias: None
Product: GlusterFS
Classification: Community
Component: glusterd
Version: 3.7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: bugs@gluster.org
QA Contact:
URL:
Whiteboard:
Depends On: 1241274
Blocks: 1241275 1241904 1241963
TreeView+ depends on / blocked
 
Reported: 2015-07-13 14:40 UTC by Jeff Darcy
Modified: 2015-07-13 14:41 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1241274
Environment:
Last Closed: 2015-07-13 14:41:59 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)

Description Jeff Darcy 2015-07-13 14:40:20 UTC
+++ This bug was initially created as a clone of Bug #1241274 +++

In a user environment, a server might be migrated/restarted with a different IP address than it had before.  DNS has been updated to point the old name at the new address, and thus clients can still reconnect to it OK, but other servers fail to recognize it as a cluster member because of the address change.  In this particular case, the problem is related to containerization of the servers, but it can also occur with bare-metal failover solutions.  The key factor is really that the user is unable/unwilling to configure their routing so that a floating service address can be reassigned to a new physical machine in case of failover or migration.

Extra detail: the problem occurs because the *recipient* of a "peer probe" message initially stores the sender's string-valued IP address instead of its name.  If we then probe in the other direction using that peer's name, we update our peer record with that as well, but that's a total hack and doesn't seem totally foolproof either.  A better solution is to store and subsequently compare against reverse-resolved host names for probes we receive, whenever such names are available.  Such an approach would be effectively immune to such address changes (though it doesn't solve the general problem of DNS errors or misconfiguration).

Comment 1 Jeff Darcy 2015-07-13 14:41:59 UTC
Didn't realize we already have a 3.7 clone for this.  Never mind.

*** This bug has been marked as a duplicate of bug 1241963 ***


Note You need to log in before you can comment on or make changes to this bug.