[Gluster-users] ec2 peers

Gerry Reno greno at verizon.net
Wed Jan 19 18:38:35 UTC 2011


To test what would happen, on the primary I probed by external DNS name
for the secondary server and verified that peer status was ok and
connected. 

I then stopped and started both servers.

And we have ugliness!

First, I reassociated the elastic ips to the servers.

Next, I found that the assigned internal IP did change for each server.

I logged into both servers and tried to ping $HOSTNAME:  FAILED

    # ping $HOSTNAME
    PING ip-10-XXX-58-95.ec2.internal (10.XXX.58.95) 56(84) bytes of data.
    ^C
    --- ip-10-XXX-58-95.ec2.internal ping statistics ---
    10 packets transmitted, 0 received, 100% packet loss, time 9014ms


Well, this is because HOSTNAME is still set to the OLD internal IP.  
Not good.  EC2 PROBLEM.

So I then queried peer status:
On the primary:

    # gluster peer status
    Number of Peers: 1

    Hostname: ec2-184-XXX-226-135.compute-1.amazonaws.com
    Uuid: c4740018-7098-4947-b636-95bd7d4ab50f
    State: Peer in Cluster (Disconnected)


Has the right hostname and UUID.  But shows disconnected.

On the secondary:

    # gluster peer status
    Number of Peers: 1

    Hostname: 10.XXX.142.178
    Uuid: a39c5d2f-dac2-436b-b715-425becf9075c
    State: Peer in Cluster (Disconnected)


Has the WRONG hostname (it's the OLD internal IP of the primary), UUID
is right.


So this idea of using elastic IP's and external DNS names for peering
does NOT appear to work in practice.


Regards,
Gerry







On 01/19/2011 12:27 PM, Gerry Reno wrote:
> Ok, so I attached elastic ips and then probed the secondary server from
> the primary using the external dns name.  And the probe succeeds and I
> see the external DNS name along with a UUID.  However, on the secondary
> server if I query peer status it is now showing the Internal IP of the
> primary server.  So where did that peer entry come from?  I did not
> probe from the secondary?  Can I safely detach this IP and then probe
> from the secondary to the primary based on external DNS name?   Or is
> this IP entry going to continue to happen automatically?
>
> Regards,
> Gerry
>
>
>
> On 01/19/2011 12:09 PM, Gerry Reno wrote:
>   
>> That's exactly what I was thinking as well.  Unless glusterfs has some
>> magic discovery mechanism based on UUID's.
>>
>> And I believe that within the EC2 network even external EC2 DNS names
>> get resolved to the internal IP so no add'l network charges should be
>> incurred.
>>
>> Regards,
>> Gerry
>>
>>
>>
>> On 01/19/2011 11:52 AM, Rafiq Maniar wrote:
>>   
>>     
>>> Hi,
>>>
>>> For "reboots", instances keep the same internal and external IP.
>>>
>>> If you stop and start them, they get a new IP.
>>>
>>> What I did to get around this problem was I used ElasticIPs for the 2
>>> GlusterFS
>>> servers, to ensure they always had the same DNS address. I then use
>>> the full
>>> external DNS name when setting up Gluster.
>>>
>>> Rafiq
>>>
>>> On Wed, Jan 19, 2011 at 4:45 PM, Gerry Reno <greno at verizon.net
>>> <mailto:greno at verizon.net>> wrote:
>>>
>>>     I have glusterfs running on ec2.
>>>
>>>     I am able to successfully probe for the peer, but considering this
>>>     is on
>>>     ec2 and the internal IP could possibly change later on if say the AMI
>>>     got hung and had to be restarted then how does glusterfs react in that
>>>     situation?  Can it still find the peers?
>>>
>>>
>>>     Regards,
>>>     Gerry
>>>
>>>     _______________________________________________
>>>     Gluster-users mailing list
>>>     Gluster-users at gluster.org <mailto:Gluster-users at gluster.org>
>>>     http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
>>>
>>>
>>>     
>>>       
>> _______________________________________________
>> Gluster-users mailing list
>> Gluster-users at gluster.org
>> http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
>>
>>   
>>     
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
>
>   




More information about the Gluster-users mailing list