On 04/05/2013, at 1:16 AM, Christine Caulfield <[email protected]> wrote:
> Here's a patch you might like to try
Doesn't seem to be sufficient I'm afraid...
May 07 00:56:04 debug [MAIN ] No configured qb.ipc_type. Using native ipc
May 07 00:56:04 info [QB ] server name: quorum
May 07 00:56:04 notice [TOTEM ] adding new UDPU member {10.16.16.61}
CC: binding 2 to INADDR_ANY
May 07 00:56:04 notice [TOTEM ] adding new UDPU member {10.16.16.62}
CC: binding 2 to INADDR_ANY
May 07 00:56:04 notice [TOTEM ] adding new UDPU member {10.16.16.63}
CC: binding 2 to INADDR_ANY
May 07 00:56:04 notice [TOTEM ] adding new UDPU member {10.16.16.64}
CC: binding 2 to INADDR_ANY
May 07 00:56:04 debug [TOTEM ] entering GATHER state from 15.
May 07 00:56:06 debug [TOTEM ] The consensus timeout expired.
May 07 00:56:06 debug [TOTEM ] entering GATHER state from 3.
May 07 00:56:08 debug [TOTEM ] The consensus timeout expired.
May 07 00:56:08 debug [TOTEM ] entering GATHER state from 3.
May 07 00:56:10 debug [TOTEM ] The consensus timeout expired.
May 07 00:56:10 debug [TOTEM ] entering GATHER state from 3.
May 07 00:56:12 debug [TOTEM ] The consensus timeout expired.
May 07 00:56:12 debug [TOTEM ] entering GATHER state from 3.
May 07 00:56:13 warning [MAIN ] Totem is unable to form a cluster because of
an operating system or network fault. The most common cause of this message is
that the local firewall is configured improperly.
May 07 00:56:14 warning [MAIN ] Totem is unable to form a cluster because of
an operating system or network fault. The most common cause of this message is
that the local firewall is configured improperly.
May 07 00:56:15 debug [TOTEM ] The consensus timeout expired.
May 07 00:56:15 debug [TOTEM ] entering GATHER state from 3.
May 07 00:56:16 warning [MAIN ] Totem is unable to form a cluster because of
an operating system or network fault. The most common cause of this message is
that the local firewall is configured improperly.
I confirmed iptables was NOT running or started at boot.
If you send me an ssh key I can give you access to these machines for testing.
>
> Xx
> Chrissie
>
>
> On 01/03/13 15:26, Steven Dake wrote:
>> On 03/01/2013 05:26 AM, Jan Friesse wrote:
>>> Steven Dake napsal(a):
>>>> Hi,
>>>>
>>>> Speaking with Angus who spoke with Andrew about the problem of getting
>>>> Corosync to run inside cloud guests, specially OpenStack, spawned this
>>>> conversation...
>>>>
>>>> Currently the problem is that with UDPU mode and a bindnetaddr set, the
>>>> interface binding code first searches for the ip address, then once
>>>> found, determines the interface which that ip address is connected to.
>>>>
>>>> This would work great if cloud guests had static ip addresses which they
>>>> are assigned, but in most cases this is not the case. IP addresses are
>>>> assigned dynamically from an address pool. This means on restart,
>>>> without detailed knowledge of the cloud deployment, it is not possible
>>>> to set a bindnetaddr up that works consistently. Further complicating
>>>> matters is that the target node list IP addresses change in the
>>>> non-floating-ip model.
>>>>
>>>> One simple solution is to use the following config model:
>>>> 1. obtain a floating ip address from OpenStack
>>>> 2. configure the guest vms with the floating IPs
>>>> 3. hold floating IP for lifetime of application
>>>>
>>>> The way floating IPs work (atleast in OpenStack) is that they create
>>>> iptables on the host to represent the ip address. As a result, using
>>>> floating IPs with the current totemip behavior doesn't solve the problem
>>>> because totemip will still desire to bind to a specific address.
>>>> Unfortunately the floating IPs don't present a physical interface inside
>>>> the guest VM, but are handled externally by iptables. This makes
>>>> binding impossible.
>>>>
>>>> One solution to this problem is to add a new mode "inaddr_any" for
>>>> bindnetaddr. Then when corosync starts, it will bind to INADDR_ANY
>>>> interface and the udpu traffic will be routed properly by iptables.
>>>>
>>> I've found following problems with your solution:
>>> - Corosync is inserting bind IP address (system_from filed) of all rings
>>> to every packet. So it's needed to know WHAT IP address is in use. How
>>> we will find it with inaddr_any? (Ignoring fact that this field may be
>>> ignored because it should be used in multiring which is not implemented)
>>> - Because we don't know IP addresses, how we will fill udpu members
>>> list? How will corosync know what are other nodes to contact them?
>>>
>>
>> Totem trusts all "system_from" fields in each message header, meaning it
>> doesn't actually look at the receipt address from the kernel IP system.
>> One solution to this problem is to put the host's floating IP address in t
>>
>> This all starts out at instance->my_id which is set in:
>> https://github.com/corosync/corosync/blob/needle-2.2/exec/totemsrp.c#L4549
>>
>> Which comes from totemip.
>>
>> Regards
>> -steve
>>
>>>> Any thoughts on a simpler solution or on this solution?
>>>>
>>> Actually I believe only way to achieve correct functionality will be
>>> much harder solution of proper OpenStack integration... Hopefully I'm
>>> wrong in there.
>>>
>>>> Regards
>>>> -steve
>>> Regards,
>>> Honza
>>
>> _______________________________________________
>> discuss mailing list
>> [email protected]
>> http://lists.corosync.org/mailman/listinfo/discuss
>
> <corosync_inaddr_any.patch>_______________________________________________
> discuss mailing list
> [email protected]
> http://lists.corosync.org/mailman/listinfo/discuss
_______________________________________________
discuss mailing list
[email protected]
http://lists.corosync.org/mailman/listinfo/discuss
