Pacemaker: Abhängigkeiten von KVM Domains zu Storage

Hi, ich habe gerade gemerkt, dass meine aktuelle Cluster Konfiguration noch diverse Schwächen hat:

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"

Das funktioniert bisher ganz gut. Nur wenn jetzt Domains dazu kommen (KVM), dann starten die VMs nicht wenn die Gruppe g_storage auf _beiden_ Knoten hoch kommt. Ist also zB ein Knoten nicht da (weil zB kaputt) kommen die VMs garnicht.

Code:
primitive p_vm_test1 ocf:heartbeat:VirtualDomain \
        params \
        config="/shared00/test1.xml" \
        hypervisor="qemu:///system" \
        meta allow-migrate="true" \
        op start timeout="120s" \
        op stop timeout="120s" \
        op monitor depth="0" timeout="30" interval="10"

group g_vm  p_vm_test1

order storage-before-vms inf: g_storage p_vm

Meine Vorstellung wäre, dass die VMs zeitlich gesehen nach dem Storage starten, aber dann halt einfach dort, wo der Storage Stack wirklich funktioniert - egal wo das ist.

Wie kann ich das umsetzen? Zwischen Order, Collocation, Location und anderen Objekten sehe ich den Wald nicht mehr ;)

Grüße
serow
 
Du verwendest als Order Parameter "inf:". Dies bedeutet, dass die übrigen Ressourcen _nicht_ gestartet werden, wenn der Start einer vorherigen Ressource fehlschlägt.
Und für die Gruppe g_storage sehe ich auf Anhieb keine Einschränkungen wo sie laufen soll. Wenn die Ressourcen in der Gruppe g_storage also nicht ordentlich hochkommen, wird p_vm nicht gestartet.
Du könntest nun statt "inf:" "0:" verwenden, aber dann würde p_vm auch gestartet werden, wenn g_storage nicht gestartet werden kann (kA ob du das so haben willst).

Damit nun noch g_storage und p_vm immer zusammen laufen, müsstest du eine "Colocation" definieren und da das GFS vermutlich auf allen Knoten zur Verfügung stehen soll, müsstest du zusätzlich bei Colocation und Order die Clone-Ressourcen verwenden. Aber bist du sicher, dass du den Storage-Klon wirklich nur auf einem Knoten haben willst? Ich würde es eher so machen:

Code:
clone c_storage g_storage
    meta interleave="true"
colocation storage-with-vms inf: c_storage p_vm
order storage-before-vms inf: c_storage p_vm
 
Zuletzt bearbeitet:
Hi, danke für deine schnelle Antwort :) Ich denke ich muss die Situation noch etwas genauer erläutern: Meine VMs benutzen Logical Volumes auf cLVM als Festplatten. Das cLVM läuft auf einem über iSCSI bereitgestellten LUN. Von daher macht es keinen Sinn eine VM auf einem Knoten zu starten auf dem der Storage Stack nicht richtig hochgekommen ist.

Vom Konzept her:

1. Storage Stack:

  1. open-iscsi daemon
  2. iscsi (Kontakt zum LUN herstellen)
  3. das DLM Gedöns
  4. cLVM
  5. Volume Group vg0
2. Libvirt-bin
3. VMs


Der Storage Stack soll auf allen Knoten unabhängig voneinander gestartet werden. Natürlich in der Reihenfolge, wie oben angegeben und mit Abbruch falls eine Resource nicht funktioniert hat.


Dann soll Libvirt-bin kommen, denn um den Storage Pool starten zu können muss cLVM da sein. Libvirt soll auf allen Knoten gestartet werden auf denen der Storage Stack hochgekommen ist.



Dann zuletzt die VMs, die auf allen Knoten laufen dürfen die bis zu Libvirt-bin fehlerfrei gekommen sind.





Grüße
serow
 
Wie in deinem anderen Thread geschrieben, hatte ich so ein Setup bisher nie. Daher bin ich gerade nicht ganz sicher wie man das am Sinnvollsten lösen könnte.

Zuerst einmal würde ich die einzelnen Primitive Ressourcen nur bedingt gruppieren, damit man sie bei Order in die entsprechende Reihenfolge setzen kann. Zudem musst du mit Clone-Ressourcen arbeiten, damit die Storage-Ressourcen überall gestartet werden.

Du hast also deine einzelnen Primitive Ressourcen: p_iscsi, p_dlm_controld, p_clvm, usw. Davon erstellst du von den einzelnen Primitives jeweils einen Klon. Danach definierst du eine Colocation mit den ganzen Klonen, damit nicht eine Resource hier hoch kommt und eine andere auf einem anderen Knoten. Zum Schluss gibst du noch eine Order an, in welcher Reihenfolge die einzelnen Ressourcen starten sollen.

Damit hast du schonmal den kompletten Storage-Stack abgefrühstückt. Diese Ressourcen werden auf jedem aktiven Knoten gestartet und wenn eine Ressource nicht gestartet werden kann, kommt auf dem Knoten gar nichts hoch.

Wichtig ist dabei nur, dass du bei Colocation und Order die Clone-Ressourcen angibst und nicht die Primitives und immer "inf:" verwendest um eine Abhängigkeitskette zu erstellen.

Wo ich gerade keine Idee habe oder aufm Schlauch stehe ist das Problem mit den VMs. Wenn ich dich richtige verstehe sollen die VMs zwar in Abhängigkeit der Storage-Ressourcen starten, aber eben nicht auf allen Knoten, sondern nur auf Irgendeinem, auf dem alles funktioniert.

Bei DRBD löst man das Problem mit Multistate-Ressourcen (ms). Da kann man Master- und Slave-Rollen definieren und somit ist klar geregelt wer der Primäre Host ist und bestimmte Ressourcen hat (z.B. das Filesystem, ClusterIP, etc.). Ob das auch mit den VMs funktioniert, weiß ich nicht.
 
Bevor ich jetzt versuche das so umzusetzen noch keine Frage: Wenn man mit Klonen arbeitet, kann man dann eine Resource nur auf einem Knoten stoppen? Ich habe naemlich gemerkt, dass wenn irgendwas auf einem Knoten nicht so laeuft wie geplant und ich mit

crm resource stop c_storage
crm resource cleanup c_storage
crm resource start c_storage

an die Sache rangehe, auch der funktionierende Knoten die Resource erstmal verliert bevor sie neugestartet wird. Ist natuerlich bloed wenn gerade VMs laufen ;)

Gruesse
serow
 
Ja, das geht aber nicht so wie du es versuchst.

Wenn du Befehle mit der CRM-Shell ausführst gelten die grundsätzlich für den kompletten Cluster. Wenn eine Ressource also von Pacemaker verwaltet wird (das ist i.d.R. der Fall) und du stoppst diese Ressource, stoppst du sie überall.

Es gibt aber andere Wege. Eine Möglichkeit wäre beispielsweise die Ressource in den "unmanaged mode" zu setzen. Dann läuft sie erst mal weiter, aber Pacemaker kümmert sich nicht mehr darum. So kannst du sie auf jedem Knoten gesondert stoppen. Der Nachteil dabei ist, dass deine anderen Constraints (Colocation, Order, usw.) nicht mehr greifen und du dich selbst darum kümmern musst.
Das bedeutet, dass du zwar den iscsi-daemon stoppen kannst, aber clvm, usw. weiterlaufen und vermutlich in Fehler rennen. Dein Order-Constraint greift also nicht mehr. Im Managed-Mode würde er mit "inf:" die komplette Order-Kette durchlaufen. Startest du die clvm-Ressource durch, würde er also beim iscsi-daemon anfangen und bis zur Volumegroup alles durchstarten.

Der bessere (aber umständlichere) Weg ist es der Clone-Ressource zu verbieten auf einem bestimmten Knoten zu laufen. Dazu fügt man eine Location in die aktuelle Clusterconfig ein:
Code:
location c_storage-not-on-node1 c_storage -inf: node1
 
So, los gehts:


Du hast also deine einzelnen Primitive Ressourcen: p_iscsi, p_dlm_controld, p_clvm, usw. Davon erstellst du von den einzelnen Primitives jeweils einen Klon. Danach definierst du eine Colocation mit den ganzen Klonen, damit nicht eine Resource hier hoch kommt und eine andere auf einem anderen Knoten. Zum Schluss gibst du noch eine Order an, in welcher Reihenfolge die einzelnen Ressourcen starten sollen.

Wichtig ist dabei nur, dass du bei Colocation und Order die Clone-Ressourcen angibst und nicht die Primitives und immer "inf:" verwendest um eine Abhängigkeitskette zu erstellen.

Ist nicht genau das eine Group?

http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/ch10.html#group-resources hat gesagt.:
One of the most common elements of a cluster is a set of resources that need to be located together, start sequentially, and stop in the reverse order. To simplify this configuration we support the concept of groups.

Also waere doch der kuerzeste Weg genau das zu erreichen

primitives -> group -> clone, also

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 \
        cluster-node-max="1"
Gruesse
Serow
 
Wo ich gerade keine Idee habe oder aufm Schlauch stehe ist das Problem mit den VMs. Wenn ich dich richtige verstehe sollen die VMs zwar in Abhängigkeit der Storage-Ressourcen starten, aber eben nicht auf allen Knoten, sondern nur auf Irgendeinem, auf dem alles funktioniert.

Wuerde eine Collocation der VM Resource mit der Gruppe g_storage das erledigen?

Gruesse
serow
 
Also, zuerst einmal zu den Gruppen. Theoretisch sollte dies so sein und je nach Anwendungsfall funktioniert es auch problemlos. Aber ich hatte mit den Gruppierungen schon mehrere Probleme (gerade was Abhängigkeiten von Resourcen angeht) und verwende sie daher nur dort, wo mir die Start-/Stoporder egal ist oder ich bilde mehrere kleine Gruppen, anstatt eine Große. Aber kannste ja selber rausfinden ob es bei dir mit einer Gruppe zu erschlagen ist oder ob du besser mehrere Einzelressourcen verwaltest. Da bist du bei Pacemaker ja absolut frei in der Gestaltung deines Clusters.

Wuerde eine Collocation der VM Resource mit der Gruppe g_storage das erledigen?
Eine Colocation brauchst du auf jeden Fall, sonst hättest du u.U. eben den Fall, dass die Storage-Ressourcen auf Knoten A hochkommen und die VMs auf Knoten B gestartet werden sollen.

Aber ich hab gestern wirklich auf dem Schlauch gestanden. Du kannst doch die VMs mit der Option "clone-node-max" starten und dann hast du im Cluster nur auf einem Knoten nur 1 Kopie dieser Ressource.
Wenn du allerdings bei "c_storage" die Option "clone-node-max=1" drin lässt brauchst du bei den VMs diese Einschränkung nicht, da c_storage ja nur auf einem Knoten gestartet wird und durch das Colocation-Constraint wird auch nur auf diesem Knoten die VM-Ressource gestartet.
 
Entspricht das dem was du meintest?

Code:
primitive p_clvm ocf:lvm2:clvmd \
        params daemon_timeout="30" \
        op monitor interval="60" timeout="30" \
        op start interval="0" timeout="90" \
        op stop interval="0" timeout="100"
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_libvirt lsb:libvirt-bin \
        op monitor interval="120" timeout="30" \
        meta target-role="Stopped"
primitive p_shared_gfs2 ocf:heartbeat:Filesystem \
        params device="/dev/vg0/shared-gfs2" directory="/shared00" fstype="gfs2" \
        op monitor interval="120s"
primitive p_vg0 ocf:heartbeat:LVM \
        params volgrpname="vg0" \
        op monitor interval="60" timeout="60"
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"

clone c_iscsi p_iscsi meta globally-unique="true" clone-max="2" clone-node-max="1"
clone c_dlm_controld p_dlm_controld meta globally-unique="true" clone-max="2" clone-node-max="1"
clone c_gfs_controld p_gfs_controld meta globally-unique="true" clone-max="2" clone-node-max="1"
clone c_clvm p_clvm meta globally-unique="true" clone-max="2" clone-node-max="1"
clone c_vg0 p_vg0 meta globally-unique="true" clone-max="2" clone-node-max="1"
clone c_shared_gfs2 p_shared_gfs2 meta globally-unique="true" clone-max="2" clone-node-max="1"

order order_stor_rule1 inf: c_iscsi c_dlm_controld
order order_stor_rule2 inf: c_dlm_controld c_gfs_controld
order order_stor_rule3 inf: c_gfs_controld c_clvm
order order_stor_rule4 inf: c_clvm c_vg0
order order_stor_rule5 inf: c_vg0 c_shared_gfs2

Mit dem globally-unique bin ich mir auch nicht sicher...
 
"globally-unique" bedeutet, dass jeder Klon als einzigartig betrachtet wird. Du hast also nicht mehr 1 Ressource von der es x Kopien gibt, sondern es wird aus einer Ressource x eigenständige Klone erzeugt. Normalerweise verwendet man das fürs Loadbalancing von Ressourcen (z.B. bei einem Active/Active-Setup) oder wenn man von einer Ressource mehrere Instanzen auf einem Knoten laufen lassen will.

Ich würde es so machen:
Code:
primitive p_clvm ocf:lvm2:clvmd \
        params daemon_timeout="30" \
        op monitor interval="60" timeout="30" \
        op start interval="0" timeout="90" \
        op stop interval="0" timeout="100"
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_libvirt lsb:libvirt-bin \
        op monitor interval="120" timeout="30" \
        meta target-role="Started"
primitive p_shared_gfs2 ocf:heartbeat:Filesystem \
        params device="/dev/vg0/shared-gfs2" directory="/shared00" fstype="gfs2" \
        op monitor interval="120s"
primitive p_vg0 ocf:heartbeat:LVM \
        params volgrpname="vg0" \
        op monitor interval="60" timeout="60"
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"

clone c_iscsi p_iscsi
clone c_dlm_controld p_dlm_controld
clone c_gfs_controld p_gfs_controld
clone c_clvm p_clvm
clone c_vg0 p_vg0
clone c_shared_gfs2 p_shared_gfs2
clone c_libvirt p_libvirt meta clone-node-max=1

colocation col_stor_only inf: c_iscsi c_dlm_controld c_gfs_controld c_clvm c_vg0 c_shared_gfs2
colocation col_stor_with vms inf: col_stor_only c_libvirt

order order_stor_rule inf: c_iscsi c_dlm_controld c_gfs_controld c_clvm c_vg0 c_shared_gfs2
order order_start_stor_first inf: c_shared_gfs2 p_libvirt

So würde ich es versuchen. Allerdings bin ich mit der Verkettung der Colocation nicht ganz sicher. Kannst es ja mal probieren. Aber mit der Config sollte der Storage-Stack überall gestartet werden und Libvirt nur einmal, und zwar dort wo auch alle Storageressourcen laufen.

Was mir noch aufgefallen ist:
Code:
primitive p_libvirt lsb:libvirt-bin \
        op monitor interval="120" timeout="30" \
        meta target-role="Stopped"

War das die ganze Zeit so? Dann wäre klar warum die VMs nicht starten. Die Option "targe-role" gibt an, in welchem Zustand sich die Ressource befinden soll.
 
Hi, ne das libvirt war nicht auf stopped. Das ist eine der wenigen Sachen, die ich selber gemerkt habe, dass es dieses Attribut gibt und dass das System das selbst setzt wenn man eine Resource per crmsh beendet.

Ich habe jetzt deine Config eingespielt und der este Knoten kommt schonmal hoch - soweit so gut:

Code:
============
Last updated: Fri Nov 29 21:32:43 2013
Last change: Fri Nov 29 21:31:33 2013 via cibadmin on kvm00
Stack: openais
Current DC: kvm00 - partition with quorum
Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff
2 Nodes configured, 2 expected votes
12 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
        p_vg0:0 (ocf::heartbeat:LVM) Started
        p_shared_gfs2:0 (ocf::heartbeat:Filesystem) Started

Inactive resources:

 Clone Set: c_iscsi [p_iscsi]
     Started: [ kvm00 ]
     Stopped: [ p_iscsi: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_clvm [p_clvm]
     Started: [ kvm00 ]
     Stopped: [ p_clvm:1 ]
 Clone Set: c_vg0 [p_vg0]
     Started: [ kvm00 ]
     Stopped: [ p_vg0:1 ]
 Clone Set: c_shared_gfs2 [p_shared_gfs2]
     Started: [ kvm00 ]
     Stopped: [ p_shared_gfs2:1 ]

Jetzt koennte ich also VMs auf kvm00 starten - wunderbar. Nun ist mir aber aufgefallen - und das hat garnichts speziell mit deiner Konfig zu tun , das habe ich vorher schonmal festgestellt -, dass ein zweiter Knoten das Cluster nicht joinen kann ohne die Resourcen auf kvm00 wieder zu beende und neuzustarten!

Starte ich jetzt kvm01 mit "service pacemaker start", kommt er irgendwann online und man kann in crm_mon beobachten, wie erst alles der Reihe nach auf kvm00 beendet und anschliessend mit samt dem Klon auf kvm01 wieder hoch kommt. Die Log Datei von kvm00 dazu habe ich mal zu Patebin geschickt , da > 600 Zeilen.

Das ist irgendwie nicht sonderlich sinnvoll in meinem Fall, denn das wuerde heissen, dass meine VMs down gehen!

1. Cluster laeuft
2. Knoten geht down
3. VMs werden (hoffentlich - soweit sind wir noch nicht ;)) uebernommen
4. Knoten wird repariert und hochgefahren
5. Alle VMs muessen down gehen um den Knoten wieder aufzunehmen

Ist kein sonderlich hochverfuegbarer Prozess :D Ne Idee wie man das hinkriegen kann? Vom Gedanken her fuehrt mich das wieder zu globally-unique, aber vllt habe ichs auch falsch verstanden :(

Gruesse
serow
 
Das Verhalten ist normal. Grob gesagt berechnet Pacemaker einen Punktestand anhand dessen entschieden wird auf welchem Knoten was laufen soll. Wenn du nicht willst, dass deine Resourcen nach einem Ausfall zurückschwenken, setzte bei den "Resource Defaults" den Wert für "resource-stickiness" auf einen Wert zwischen 0 und 100 (Default ist glaube ich 0, was bedeutet, dass es nichts kostet zu schwenken).

Bei deiner Teststellung hat das auch mit dem Status deiner Nodes zu tun. kvm01 ist OFFLINE und wenn du ihn Online schaltest, kommt dies einem Recovery gleich (siehe Ablauf in deinen Logs).
Wenn du für Tests oder Neukonfigurationen einen Knoten aus dem Cluster nehmen willst, würde ich ihn eher in den Standby-Modus versetzen. Dann gehört er dem Cluster noch an, bekommt alles mit, aber nimmt keine Ressourcen auf und gibt laufende Ressourcen ab.

Wenn du ganz sicher gehen willst, kannst du im Übrigen mit Hilfe dieser Punkteberechnung auch Location-Constraints anlegen, die festlegen wo die Ressourcen "am günstigsten" sind:
Code:
location vms-prefer-kvm00 p_libvirt 100: kvm00
location vms-backup-kvm01 p_libvirt 25: kvm01
Und danach bringst du den Knoten online. Dann schwenken sie auch nicht, da es günstiger ist auf kvm00 zu bleiben. Nur wenn kvm00 offline/standby geht werden die Ressourcen auf kvm01 übertragen.
 
Das Verhalten ist normal. Grob gesagt berechnet Pacemaker einen Punktestand anhand dessen entschieden wird auf welchem Knoten was laufen soll. Wenn du nicht willst, dass deine Resourcen nach einem Ausfall zurückschwenken, setzte bei den "Resource Defaults" den Wert für "resource-stickiness" auf einen Wert zwischen 0 und 100 (Default ist glaube ich 0, was bedeutet, dass es nichts kostet zu schwenken).

Hmm irgendwie verstehe ich den Zusammenhang mit meinem Problem nicht. Fuer alle Resourcen, die zu Storage gehoeren, hat doch Resource Stickiness ueberhaupt keine Relevanz, denn ich lasse ja von allem soviele Clones laufen, wie es Cluster Knoten gibt und erlaubt pro Knoten nur eine Instanz.

Vorallem dachte ich, dass diese PEengine oder welcher Teil das wieder war die Aktionen berechnet, die vom Ist Zustand zum Soll Zustand fuehren. Und in dem Kontext macht es ja wenig Sinn die Resourcen p_iscsi, p_*_controld, p_clvm usw zu stoppen nur um sie danach wieder auf demselben Knoten zu starten.

Oder?

Gruesse
serow
 
Ich meinte auch eher deine VMs. Dein Storage-Stack startet aufgrund der Klone ja überall.

Aber dieses Verhalten ist insoweit normal, dass es logisch ist. Bei jeder Änderung des Clusterzustands werden sämtliche Bedingungen neu überprüft und der Punktestand neu berechnet.
Und Colocation vergibt keinen hohen Wert für den bevorzugten Knoten (wie man es vielleicht erwarten würde), sondern setzt für allen anderen Knoten wird der Wert "-INFINITY".

Es passiert also folgendes:
1.) Alle Ressourcen laufen auf Knoten A (bedeutet 100 Punkte)
2.) Knoten B wird dem Cluster hinzugefügt (hat im ersten Moment 0 Punkte)
3.) Unter Berücksichtigung aller Constraints werden Punkte für die einzelnen Ressourcen neu berechnet und entschieden was auf Knoten B laufen soll. Das 2. Colocation-Constraint sorgt nun dafür, dass aus den 100 Punkten bei Knoten A "-INFINITY" Punkte werden, was weniger als 0 ist bei Knoten B. Somit wird die Ressource von B nach A migriert.

Übrigens kannst du dir mit
Code:
ptest -s -L
den aktuellen Punktestatus anzeigen lassen.
 
Hi, die Zauberworte zu dem Thema heisstn "meta interleave=true". Gibt man dem Clone das mit, hat man das Problem mit dem Stack beim Join eines Knoten nicht.

Grüße
serow
 
Zurück
Oben