Debian + Pacemaker + Corosync: Start von Pacemaker und cLVM Problem

Hi, gerade bin ich dabei auf Basis von Debian Wheezy ein KVM Cluster mit pacemaker und corosync hochzuziehen. Dabei haben sich bisher einiges Probleme ergeben zu denen ich jetzt Rat brauche.

Fangen wir mal langsam und genüsslich an :D

Beide Knoten sind aus, nun schalte ich einen davon ein. Gleich nach dem Hochfahren ist corosync an, pacemaker noch aus:

Code:
root@kvm00:~# service corosync status
corosync is running.
root@kvm00:~# service pacemaker status
pacemakerd is stopped

Passt soweit, das soll so sein. Wenn ich jetzt versuche pacemaker zu starten, passiert folgendes:

Code:
root@kvm00:~# service pacemaker start
Starting Pacemaker Cluster Manager: [FAILED]
root@kvm00:~# tail -f /var/log/syslog 
Nov 28 11:49:49 kvm00 pacemakerd: [4313]: info: get_config_opt: Found 'openais_msg' for option: name
Nov 28 11:49:49 kvm00 pacemakerd: [4313]: info: config_find_next: Processing additional service options...
Nov 28 11:49:49 kvm00 pacemakerd: [4313]: info: get_config_opt: Found 'openais_lck' for option: name
Nov 28 11:49:49 kvm00 pacemakerd: [4313]: info: config_find_next: Processing additional service options...
Nov 28 11:49:49 kvm00 pacemakerd: [4313]: info: get_config_opt: Found 'openais_tmr' for option: name
Nov 28 11:49:49 kvm00 pacemakerd: [4313]: info: config_find_next: No additional configuration supplied for: service
Nov 28 11:49:49 kvm00 pacemakerd: [4313]: info: config_find_next: Processing additional quorum options...
Nov 28 11:49:49 kvm00 pacemakerd: [4313]: info: get_config_opt: Found 'quorum_cman' for option: provider
Nov 28 11:49:49 kvm00 pacemakerd: [4313]: info: get_cluster_type: Detected an active 'cman' cluster
Nov 28 11:49:49 kvm00 pacemakerd: [4313]: CRIT: get_cluster_type: This installation of Pacemaker does not support the 'cman' cluster infrastructure.  Terminating.
^C
root@kvm00:~#

Ich habe allerdings herausgefunden, dass sich das Problem in Luft auflöst, wenn ich corosync nochmals stoppe und wieder starte:

Code:
root@kvm00:~# service corosync stop
Stopping corosync daemon: corosync.
root@kvm00:~# service corosync start
Starting corosync daemon: corosync.
root@kvm00:~# service pacemaker start
Starting Pacemaker Cluster Manager: [  OK  ]

Hmm, naja, nicht schön, aber damit kann ich leben wenn es sein muss. Falls mit hier aber jemand helfen kann, wäre super!

So weiter gehts: Ich habe pacemaker gestartet und schau mir mal das Cluste ran:

Code:
root@kvm00:~# crm_mon --inactive -1
============
Last updated: Thu Nov 28 11:52:40 2013
Last change: Thu Nov 28 11:50:14 2013 via cibadmin on kvm00
Stack: openais
Current DC: kvm00 - partition WITHOUT quorum
Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff
2 Nodes configured, 2 expected votes
13 Resources configured.
============

Online: [ kvm00 ]
OFFLINE: [ kvm01 ]

Full list of resources:

 p_clusterip    (ocf::heartbeat:IPaddr2):       Stopped 
 Clone Set: c_clvm [p_clvm]
     Stopped: [ p_clvm:0 p_clvm:1 ]
 Clone Set: c_dlm_controld [p_dlm_controld]
     Stopped: [ p_dlm_controld:0 p_dlm_controld:1 ]
 Clone Set: c_gfs_controld [p_gfs_controld]
     Stopped: [ p_gfs_controld:0 p_gfs_controld:1 ]
 Clone Set: c_iscsi [p_iscsi]
     Stopped: [ p_iscsi:0 p_iscsi:1 ]
 Clone Set: c_libvirt [p_libvirt]
     Stopped: [ p_libvirt:0 p_libvirt:1 ]
 Clone Set: c_shared_gfs2 [p_shared_gfs2]
     Stopped: [ p_shared_gfs2:0 p_shared_gfs2:1 ]

Failed actions:
    p_iscsi:0_start_0 (node=kvm00, call=9, rc=5, status=complete): not installed
root@kvm00:~#

Die Meldung "not installed" trifft es nicht ganz, es liegt einfach daran, dass open-iscsi noch gestartet werden muss bevor er versucht diese iSCSI Resource zu starten.

Code:
root@kvm00:~# /etc/init.d/open-iscsi start
Starting iSCSI initiator service: iscsid.
Setting up iSCSI targets:
Logging in to [iface: default, target: iqn.2004-04.com.qnap:ts-421u:iscsi.qnap00.d66cae, portal: 172.16.20.20,3260] (multiple)
Login to [iface: default, target: iqn.2004-04.com.qnap:ts-421u:iscsi.qnap00.d66cae, portal: 172.16.20.20,3260] successful.
.
Mounting network filesystems:.
root@kvm00:~# 

root@kvm00:~# crm resource cleanup c_iscsi
root@kvm00:~# crm resource start c_iscsi

root@kvm00:~# crm_mon --group-by-node --inactive -1
============
Last updated: Thu Nov 28 11:53:58 2013
Last change: Thu Nov 28 11:53:30 2013 via crmd on kvm00
Stack: openais
Current DC: kvm00 - partition WITHOUT quorum
Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff
2 Nodes configured, 2 expected votes
13 Resources configured.
============

Node kvm01: OFFLINE
Node kvm00: online
        p_dlm_controld:0        (ocf::pacemaker:controld) Started 
        p_gfs_controld:0        (ocf::pacemaker:controld) Started 
        p_clvm:0        (ocf::lvm2:clvmd) Started 
        p_iscsi:0       (ocf::heartbeat:iscsi) Started 

Inactive resources:

 p_clusterip    (ocf::heartbeat:IPaddr2):       Stopped 
 Clone Set: c_clvm [p_clvm]
     Started: [ kvm00 ]
     Stopped: [ p_clvm:1 ]
 Clone Set: c_dlm_controld [p_dlm_controld]
     Started: [ kvm00 ]
     Stopped: [ p_dlm_controld:1 ]
 Clone Set: c_gfs_controld [p_gfs_controld]
     Started: [ kvm00 ]
     Stopped: [ p_gfs_controld:1 ]
 Clone Set: c_iscsi [p_iscsi]
     Started: [ kvm00 ]
     Stopped: [ p_iscsi:1 ]
 Clone Set: c_libvirt [p_libvirt]
     Stopped: [ p_libvirt:0 p_libvirt:1 ]
 Clone Set: c_shared_gfs2 [p_shared_gfs2]
     Stopped: [ p_shared_gfs2:0 p_shared_gfs2:1 ]

Failed actions:
    p_shared_gfs2:0_start_0 (node=kvm00, call=19, rc=5, status=complete): not installed
root@kvm00:~#

Auch das lässt sich beheben indem ich dem Cluster noch eine LSB Resource mitgeben die auf das init-Script von open-iscsi verweist. Gut, aber jetzt kommt das nächste Problem:


Code:
Failed actions:
    p_shared_gfs2:0_start_0 (node=kvm00, call=19, rc=5, status=complete): not installed

Auch hier trifft "not installed" es wieder nicht wirklich, denn wie ich herausgefunden habe, liegt es daran, dass das cLVM logical volume auf "inactive" steht:

Code:
root@kvm00:~# lvscan
  inactive          '/dev/vg0/shared-gfs2' [5.00 GiB] inherit
root@kvm00:~# 

root@kvm00:~# lvchange -aly vg0/shared-gfs2
root@kvm00:~# lvscan
  ACTIVE            '/dev/vg0/shared-gfs2' [5.00 GiB] inherit
root@kvm00:~# 

root@kvm00:~# crm resource cleanup c_shared_gfs2
Cleaning up p_shared_gfs2:0 on kvm00
Cleaning up p_shared_gfs2:1 on kvm00
Waiting for 3 replies from the CRMd... OK
root@kvm00:~# crm resource start c_shared_gfs2

root@kvm00:~# crm_mon --group-by-node --inactive  -1
============
Last updated: Thu Nov 28 11:55:54 2013
Last change: Thu Nov 28 11:55:45 2013 via cibadmin on kvm00
Stack: openais
Current DC: kvm00 - partition WITHOUT quorum
Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff
2 Nodes configured, 2 expected votes
13 Resources configured.
============

Node kvm01: OFFLINE
Node kvm00: online
        p_dlm_controld:0        (ocf::pacemaker:controld) Started 
        p_clusterip     (ocf::heartbeat:IPaddr2) Started 
        p_gfs_controld:0        (ocf::pacemaker:controld) Started 
        p_clvm:0        (ocf::lvm2:clvmd) Started 
        p_libvirt:0     (lsb:libvirt-bin) Started 
        p_iscsi:0       (ocf::heartbeat:iscsi) Started 
        p_shared_gfs2:0 (ocf::heartbeat:Filesystem) Started 

Inactive resources:

 Clone Set: c_clvm [p_clvm]
     Started: [ kvm00 ]
     Stopped: [ p_clvm:1 ]
 Clone Set: c_dlm_controld [p_dlm_controld]
     Started: [ kvm00 ]
     Stopped: [ p_dlm_controld:1 ]
 Clone Set: c_gfs_controld [p_gfs_controld]
     Started: [ kvm00 ]
     Stopped: [ p_gfs_controld:1 ]
 Clone Set: c_iscsi [p_iscsi]
     Started: [ kvm00 ]
     Stopped: [ p_iscsi:1 ]
 Clone Set: c_libvirt [p_libvirt]
     Started: [ kvm00 ]
     Stopped: [ p_libvirt:1 ]
 Clone Set: c_shared_gfs2 [p_shared_gfs2]
     Started: [ kvm00 ]
     Stopped: [ p_shared_gfs2:1 ]
root@kvm00:~#

Und "schon" ist das GFS2 gemountet :D

Also um es nochmal zusammen zu fassen:

  1. Pacemaker startet nur wenn ich corosync nochmal durchstartet und
  2. cLVM bringt die LVs als inactive hoch.
Kann mir hier jemand helfen?
 
Ach, es wäre vllt nützlich gewesen euch meine Cluster Konfiguration zu zeigen:

Code:
node kvm00
node kvm01

property expected-quorum-votes="2"
property stonith-enabled="false"
property no-quorum-policy="ignore"
property cluster-infrastructure="corosync"

rsc_defaults resource-stickiness="100"
op_defaults interval="0"

primitive p_openiscsi lsb:open-iscsi \
        op monitor interval="120" timeout="30"

primitive p_iscsi ocf:heartbeat:iscsi \
        params portal="172.16.20.20:3260" target="iqn.2004-04.com.qnap:ts-421u:iscsi.qnap00.d66cae" \
        op monitor interval="120" timeout="30" depth="0"

primitive p_dlm_controld ocf:pacemaker:controld \
        params daemon="dlm_controld.pcmk" \
        op start interval="0" timeout="90" \
        op stop interval="0" timeout="100" \
        op monitor interval="10"

primitive p_gfs_controld ocf:pacemaker:controld \
        params daemon="gfs_controld.pcmk" \
        op start interval="0" timeout="90" \
        op stop interval="0" timeout="100" \
        op monitor interval="10"

primitive p_clvm ocf:lvm2:clvmd \
        params daemon_timeout="30" daemon_options="-I corosync" \
        op monitor interval="60" timeout="30" \
        op start interval="0" timeout="90" \
        op stop interval="0" timeout="100"

primitive p_vg0 ocf:heartbeat:LVM \
        params volgrpname="vg0" \
        op monitor interval="60" timeout="60"

primitive p_shared_gfs2 ocf:heartbeat:Filesystem \
        params device="/dev/vg0/shared-gfs2" directory="/shared00" fstype="gfs2" \
        op monitor interval="120s" \
        meta target-role="Started"

primitive p_libvirt lsb:libvirt-bin \
        op monitor interval="120" timeout="30"

group g_storage p_openiscsi p_iscsi p_dlm_controld p_gfs_controld p_clvm p_vg0 p_shared_gfs2 p_libvirt

clone c_storage g_storage \
        params cluster-node-max="1" \
        meta target-role="Started"

Sorry.
 
Zeig mal bitte deine corosync.conf Datei. Ich vermute dort einen Fehler, der den sauberen Start von Pacemaker verhindert.

Zu den inaktiven LVs habe ich auf Anhieb leider keine Idee. So ein Setup hatte ich bisher noch nicht. Was steht denn in den Logs wenn du die Ressource restartest bzw. aufräumst?

Code:
crm resource restart c_clvm
crm resource cleanup c_clvm
 
Hi, hier meine corosync.conf:

Code:
root@kvm00:~# cat /etc/corosync/corosync.conf
# Please read the corosync.conf.5 manual page
compatibility: whitetank

totem {
        cluster_name: kvm-cluster00
        version: 2
        secauth: off
        threads: 0
        interface {
                ringnumber: 0
                bindnetaddr: 172.16.1.0
                mcastaddr: 239.255.1.1
                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
}

quorum {
        provider: corosync_votequorum
        expected_votes: 1
}
root@kvm00:~#

Zu den inaktiven LVs habe ich auf Anhieb leider keine Idee. So ein Setup hatte ich bisher noch nicht.

Das Problem mit cLVM habe ich "geloest" worbei ich nicht weiss ob es die Loesung ist, da das Verhalten normal ist, oder mehr als Workaround zu sehen ist:

Code:
primitive p_clvm ocf:lvm2:clvmd \
        params daemon_timeout="30" daemon_options="-I corosync" \
        op monitor interval="60" timeout="30" \
        op start interval="0" timeout="90" \
        op stop interval="0" timeout="100"

primitive p_vg0 ocf:heartbeat:LVM \
        params volgrpname="vg0" \
        op monitor interval="60" timeout="60"

group g_storage ... p_clvm p_vg0 ...

Wie hast Du es bisher gemacht? Ich dachte cLVM waere eine Loesung, die noch am ehesten gute Performance bietet. An sich bin ich aber frei in der Umsetzung.

Gruesse
serow
 
Du hast keine Service-Definition in deiner Corosync-Config. Hast du stattdessen ein Serviceplugin in "/etc/corosync/service.d/" angelegt? Falls nicht, würde ich vermuten, dass er das cman-PLugin anstatt pcmk verwendet.

Siehe:
Code:
get_cluster_type: Detected an active 'cman' cluster
get_cluster_type: This installation of Pacemaker does not support the 'cman' cluster infrastructure.  Terminating.

Falls du noch kein Plugin geladen hast, füge folgenden Block in deine corosync.conf ein:
Code:
service {
        ver:       1
        name:      pacemaker
}

Der Parameter "ver" legt fest, wie Pacemaker gestartet werden soll. Ob du nun bei "ver:" 0 oder 1 setzt musst du schauen. Ich bin bisher mit 1 besser gefahren. Damit wird Pacemaker ganz normal über das Init-Script gestartet. Wobei es aber u.U. zu nem kleinen Bug kommen kann, da evtl. die Runlevel falsch gesetzt sind. Corosync muss vor Pacemaker starten und Pacemaker muss vor Corosync beendet werden.
Hier gibts von Clusterlabs noch ein Blogpost dazu: Introducing the Pacemaker Master Control Process for Corosync-based Clusters - The Cluster Guy

Wie hast Du es bisher gemacht? Ich dachte cLVM waere eine Loesung, die noch am ehesten gute Performance bietet. An sich bin ich aber frei in der Umsetzung.
Wir setzen bei uns im RZ ausschließlich VMWare ein. Ich hab daher mit anderen Virtualisierungsplattformen kaum Berührungspunkte und musste mich bisher nie mit so einem Setup auseinandersetzen. Wir verwenden Pacemaker und Corosync eher als kleine, kostengünstige Lösung um bestimmte Anwendungen oder Dienste hochverfügbar zu machen. Und meist benötigen wir innerhalb des Clusters kein Shared-Storage und wenn doch setzen wir DRBD ein. Also eher simple Sachen. :)
 
Haha, ja VMware waere mir auch lieber wobei VMware HA zwar funktioniert aber es ist doch eher als Wunder zu sehen, dass das ohne Fencing so gut funktioniert ;)

Und ja ich habe in der Tat unter /etc/corosync/service.d/ eine Datei angelegt:
Code:
root@kvm00:~# cat /etc/corosync/service.d/pcmk 
service {
name: pacemaker
ver: 1
}
root@kvm00:~#

Da ist aber noch eine, die ich da nicht hingelegt habe:

Code:
root@kvm00:~# cat /etc/corosync/service.d/ckpt-service 
service {
        ver:    0
        name:   openais_ckpt
}
root@kvm00:~#

Ne Idee was die macht?

Ich denke aber das Problem gefunden zu haben: Mit der Installation von gfs2-tools kam auch CMAN mit, welches bei Systemstart autmatisch hochgefahren wird. Nehme ich CMAN aus dem Bootprozess raus klappts.

Ich kriege immer mehr das Gefuehl, das diese Linux Cluster Software gemacht wurde um Schmerzen zu verursachen :D

Benutzt ihr GFS2 oder OCFS2 in euren Linux Clustern?

Gruesse
serow
 
Haha, ja VMware waere mir auch lieber wobei VMware HA zwar funktioniert aber es ist doch eher als Wunder zu sehen, dass das ohne Fencing so gut funktioniert ;)
Naja, VMFS ist auch kein Cluster-Dateisystem und war auch nie dafür gedacht und VMWare HA ist auch kein Active-Active-Setup. Von daher seh ich an dieser Stelle keine wirkliche Notwendigkeit für Fencing-Mechanismen. Normalerweise greifen mehrere VMs ja auch nicht auf dieselben VMDKs zu.

Ne Idee was die macht?
cpkt kommt noch vom OpenAIS-Stack. Hab ich aber nie verwendet. Kann ich nix zu sagen.

Ich denke aber das Problem gefunden zu haben: Mit der Installation von gfs2-tools kam auch CMAN mit, welches bei Systemstart autmatisch hochgefahren wird. Nehme ich CMAN aus dem Bootprozess raus klappts.
Ah ok. Das war mit nicht bewusst, dass CMAN mit gfs2-tools mitinstalliert wird.

Ich kriege immer mehr das Gefuehl, das diese Linux Cluster Software gemacht wurde um Schmerzen zu verursachen :D
Seh ich genau anders rum. Mit Corosync/Pacemaker ist Clusterbau unter Linux endlich mal halbwegs angenehm und flexibel. :)

Benutzt ihr GFS2 oder OCFS2 in euren Linux Clustern?
Weder noch. GFS2, OCFS2 oder GlusterFS bieten für unsere Anwendungsfälle nicht ausreichend Performance. Wir versuchen daher entweder Shared-Nothing-ähnliche Cluster zu bauen oder die Daten werden in Datenbank-Systemen abgelegt oder die Anwendung kümmert sich selbst um die Replizierung der Daten in Echtzeit. Wenn doch mal ein zentraler bzw. geteilter Speicher benötigt wird, setzen wir einen hochverfügbaren NFS-Server ein. Allerdings muss sich dann die Applikation wiederum um das File-Locking kümmern und diese Informationen austauschen.
 
Code:
Naja, VMFS ist auch kein Cluster-Dateisystem und war auch nie dafür  gedacht und VMWare HA ist auch kein Active-Active-Setup. Von daher seh  ich an dieser Stelle keine wirkliche Notwendigkeit für  Fencing-Mechanismen. Normalerweise greifen mehrere VMs ja auch nicht auf  dieselben VMDKs zu.

Da muss ich dir wiedersprechen. VMFS ist ein Cluster Dateisystem, denn es greifen ja mehrere ESXi Server gleichzeitig lesend und schreibend darauf zu. Sollten VMs auf dasselbe VMDK zugreifen (SCSI bus sharing) ist das Problem des Dateisystems innerhalb des VMDKs, nicht das des ESXi Servers. VMware verlaesst sich einfach auf die Heartbeats (Netzwerk und Datastore).

Code:
Ah ok. Das war mit nicht bewusst, dass CMAN mit gfs2-tools mitinstalliert wird.

Ja, ich verstehs auch nicht. Man kann CMAN nichtmal deinstallieren, weil er dann die gfs2-tools wieder mit nimmt. :(

Aber wuede das das Verhalten / die Fehlermeldung erklaeren?

Gruesse
serow
 
Da muss ich dir wiedersprechen. VMFS ist ein Cluster Dateisystem, denn es greifen ja mehrere ESXi Server gleichzeitig lesend und schreibend darauf zu. Sollten VMs auf dasselbe VMDK zugreifen (SCSI bus sharing) ist das Problem des Dateisystems innerhalb des VMDKs, nicht das des ESXi Servers. VMware verlaesst sich einfach auf die Heartbeats (Netzwerk und Datastore).
Stimmt. Da war ich wohl etwas durcheinander. Aber ich kann ja innerhalb eines Datastores mehrere VMs ablegen, die gleichzeitig auf mehreren ESXi-Hosts laufen. vSphere setzt dafür auf ein VMDK-basierten Locking-Mechanismus, damit eine VM nicht zeitgleich auf mehreren ESXi-Hosts gestartet werden kann. Im Failover-Fall entfernt HA den Lock und damit kann die VM auf einem anderen Host gestartet werden. Also eine ziemlich einfach Form des Resource Fencings.

Aber wuede das das Verhalten / die Fehlermeldung erklaeren?
Mir fällt gerade noch ein, dass sowohl GFS, als auch CMAN maßgeblich durch Red Hat weiterentwickelt und gefördert werden und Red Hat bei seinen Clustern auf CMAN setzt. Vermutlich kommen daher diese Abhängigkeiten. Da du aber die Debian-Version von Pacemaker einsetzt, fehlt dort wohl der CMAN-Support und ob nun CMAN zwingend erforderlich für GFS ist, kann ich dir nicht sagen. CMAN ist halt älter und kümmert sich ums Quorum und kontrolliert somit die Mitgliedschaft der Knoten im Cluster. Wobei dies Pacemaker in neueren Versionen auch kann. Von daher wäre es unter den Gesichtspunkten egal ob man CMAN gestoppt lässt.
 
Zurück
Oben