I'm facing a problem with the corosync and pacemaker cluster software. I've two virtual nodes (Scientific Linux 6.4) and corosync/pacemaker installed on them:

corosync-1.4.1-17.el6.x86_64 pacemaker-1.1.10-14

The corosync's configuration file is:

compatibility: whitetank

totem {
    token: 5000
    token_retransmits_before_loss_const: 4
    vsftype: none
    version: 2
    secauth: off
    threads: 0
    interface {
        ringnumber: 0
        mcastport: 4000
        ttl: 1

logging {
    fileline: off
    to_stderr: no
    to_logfile: yes
    to_syslog: yes
    logfile: /var/log/cluster/corosync.log
    debug: off
    timestamp: on
    logger_subsys {
        subsys: AMF
        debug: off

amf {
    mode: disabled

service {
        # Load the Pacemaker Cluster Resource Manager
        name: pacemaker
        ver:  1

aisexec {
        user:   root
        group:  root

Pacemaker is configured to ignore the missing quorum, and with other 2 things:

crm configure property no-quorum-policy="ignore" pe-warn-series-max="1000" pe-input-series-max="1000" pe-error-series-max="1000" cluster-recheck-interval="1min"
crm configure rsc_defaults resource-stickiness=100
crm configure property stonith-enabled=false

I've created a IPAddr2 resource in the pacemaker configuration:

$ ~>crm configure show p_api-ip
INFO: object cli-prefer-p_api-ip cannot be represented in the CLI notation
INFO: object cli-prefer-g_openstack cannot be represented in the CLI notation
primitive p_api-ip ocf:heartbeat:IPaddr2 \
    params ip="" cidr_netmask="24" nic="eth0" \
    op monitor interval="15s"

Then I've created another resource p_myres which manages a server daemon. The p_api-ip and p_myres resources are grouped:

[root@openstack1 ~]# crm configure show g_myres
INFO: object cli-prefer-p_api-ip cannot be represented in the CLI notation
INFO: object cli-prefer-g_myres cannot be represented in the CLI notation
group g_myres p_api-ip p_myres

When I start the resource group g_myres everything works fine, but the fact that I can't migrate the g_myres group to the other node; the command "crm resource migrate g_myres node2" just doesn't do anything and I do not see anything relevant in the syslog.

But that is not the worst problem I got...

If I just reboot or power off one of the two nodes, the cluster behaves correctly: the resource is migrated to the other node, the crm_mon shows that the rebooted/powered-off node is OFFLINE.

If I interrupt the communication between them for a while, for example I issue "service network stop" and after 3 minutes "service network start" on the first node, the second node migrates the resource group g_myres (including the Virtual IP) to itself after a while; and if I try to connect to the Virtual IP I correctly land on the second node, as expected. When the first node returns back online, the second one doesn't realise that; crm_mon continues to show the first node as OFFLINE, the resource group g_myres continues to stay on the second node, but also on the first one! the Virtual IP is on both nodes too!

Is there something in the configuration of corosync (and/or pacemaker) I've to check ?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.