[Gluster-devel] How do we identify peers?

Joe Julian joe at julianfamily.org
Wed Jun 26 21:00:02 UTC 2013


On 06/25/2013 11:37 PM, Kaushal M wrote:
> Forgot the link to the bug,
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=890502
> Comment 2 in particular shows all the described problems
>
> On Wed, Jun 26, 2013 at 12:06 PM, Kaushal M <kshlmster at gmail.com> wrote:
>> Hi all,
>> We have a problem with how we identify peers in GlusterFS which we
>> need to solve.
>>
>> Peers in GlusterFS are currently identified using two keys.
>>   - the address of the peer (hostname/ip)
>>   - a UUID
>> The address is used as an identifier in the gluster cli commands and
>> is the key visible to the users of glusterfs. The UUID is used
>> internally by glusterd to identify peers.
>> This approach works well when we are using glusterfs on systems with
>> single network interfaces and when we are using a hostname as the
>> address. We run into problems when we multiple network interfaces are
>> involved or if hostname and ips are mixed in gluster cli commands.
>> Bug-890502 [1] is a good example of the problems we have. This bug
>> involves usage of multiple interfaces as well as mixing of
>> hostname/ip.
>>
>> We need to come up with a good solution to this which would solve this.
>>
>> Some of the solutions that have been thought of are below.
>>
>> 1. Continue with the current implementation of using UUID internally
>> and addresses externally, but provide a good translation interface
>> which will translate a given address into UUID correctly. The
>> translation interface might involve some network requests which could
>> increase the time taken for command execution.
>>
>> 2. Use the UUID itself both internally and externally, and have a
>> command for associating a list of addresses with a UUID. The downside
>> is that typing out UUIDs is unwieldy and users will need users to
>> execute more commands.
>>
>> 3. Similar to 2, but use an alias for the peer externally instead of
>> the UUID. This will need an additional mechanism to specify the alias
>> for a peer. This approach will need users one additional command
>> compared to approach 2, but the other commands will be simpler to
>> type.
>>
>>
>>
>> What are your thoughts about the problem and the proposed solutions?
>> If anyone has any questions regarding the problem or the solutions, or
>> if there is a better solution, please sound off.
>>
Here's my opinion on that from pre-acquisition:

https://bugzilla.redhat.com/show_bug.cgi?id=765437

[FEAT] Use uuid in volume info file for servers instead of hostname or 
ip address

In the volume info file, if the servers were referenced by uuid if the 
hostnames or ip addresses of the hosts change, the bricks would still 
reference the correct machine.

In the IRC channel [on 2011-10-05], we had someone whose network had 
been renumbered. He had created his volumes using IP addresses instead 
of hostnames. He was able to peer probe which changed the host 
information to accurately reflect the new ip addresses, but the volumes 
still pointed at the old addresses. They could not run replace-brick to 
update the addresses of their bricks.

If the bricks were referenced by host uuid, the peer probe would have 
allowed the bricks to resolve to the new information without further 
changes.




More information about the Gluster-devel mailing list