[ClusterLabs] pacemaker remote configuration on ubuntu 14.04

[Ken Gaillot]

On 03/07/2016 09:10 PM, Сергей Филатов wrote:
> Thanks for an answer. Turned out the problem was not in ipv6.
> Remote node is listening on 3121 port and it’s name is resolving fine.
> Got authkey file at /etc/pacemaker on both remote and cluster nodes.
> What can I check in addition? Is there any walkthrough for ubuntu?

Nothing specific to ubuntu, but there's not much distro-specific to it.

If you "ssh -p 3121" to the remote node from a cluster node, what do you
get?

pacemaker_remote will use the usual log settings for pacemaker (probably
/var/log/pacemaker.log, probably configured in /etc/default/pacemaker on
ubuntu). You should see "New remote connection" in the remote node's log
when the cluster tries to connect, and "LRMD client connection
established" if it's successful.

As always, check for firewall and SELinux issues.

> 
>> On 07 Mar 2016, at 09:40, Ken Gaillot <kgaillot at redhat.com> wrote:
>>
>> On 03/06/2016 07:43 PM, Сергей Филатов wrote:
>>> Hi,
>>> I’m trying to set up pacemaker_remote resource on ubuntu 14.04
>>> I followed "remote node walkthrough” guide (http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html-single/Pacemaker_Remote/#idm140473081667280 <http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html-single/Pacemaker_Remote/#idm140473081667280>)
>>> After creating ocf:pacemaker:remote resource on cluster node, remote node doesn’t show up as online.
>>> I guess I need to configure remote agent to listen on ipv4, where can I configure it?
>>> Or is there any other steps to set up remote node besides the ones mentioned in guide?
>>> tcp6       0      0 :::3121                 :::*                    LISTEN      21620/pacemaker_rem off (0.00/0/0)
>>>
>>> pacemaker and pacemaker_remote are 1.12 version
>>
>>
>> pacemaker_remote will try to bind to IPv6 addresses first, and only if
>> that fails, will it bind to IPv4. There is no way to configure this
>> behavior currently, though it obviously would be nice to have.
>>
>> The only workarounds I can think of are to make IPv6 connections work
>> between the cluster and the remote node, or disable IPv6 on the remote
>> node. Using IPv6, there could be an issue if your name resolution
>> returns both IPv4 and IPv6 addresses for the remote host; you could
>> potentially work around that by adding an IPv6-only name for it, and
>> using that as the server option to the remote resource.