Hello Terry,
Terry L. Inzauro a écrit :
> Jean Baptiste Favre wrote:
>> Hello,
>> I'm still building a xen cluster managed by pacemaker/openais.
>> Things are quite close to be OK I think, execpt when I want to put a
>> node in standby mode:
>> When it happens, all XEN VM are shut down and restarted on the other node.
>> When I ask for ressource migration, XEN Live Migration does the job so
>> that no downtime occurs.
>>
>> Is there any way to "slow down" standby mode so that XEN VM can migrate
>> gracefully ?
>>
>> Bellow you can find my cluster configuration, if it can help.
>>
>> Thanks,
>> JB
>>
>> =======================================
>> node remus attributes standby="false"
>> node romulus attributes standby="false"
>> primitive Cluster-ocfs-DRBD ocf:linbit:drbd \
>> params drbd_resource="cluster-ocfs" \
>> operations $id="Cluster-ocfs-DRBD-operations" \
>> op monitor interval="20" role="Master" timeout="20" \
>> op monitor interval="30" role="Slave" timeout="20"
>> primitive Cluster-ocfs-FS ocf:heartbeat:Filesystem \
>> params device="/dev/drbd/by-res/cluster-ocfs" \
>> directory="/cluster" fstype="ocfs2"
>> primitive xps-101-DRBD ocf:linbit:drbd \
>> params drbd_resource="xps-101" \
>> operations $id="xps-101-DRBD-operations" \
>> op monitor interval="20" role="Master" timeout="20" \
>> op monitor interval="30" role="Slave" timeout="20"
>> primitive xps-101 ocf:heartbeat:Xen \
>> params xmfile="/cluster/xen/xps-101.cfg" allow_migrate="true" \
>> op monitor interval="10s" \
>> meta allow-migrate="true"
>> ms Cluster-ocfs-MS Cluster-ocfs-DRBD \
>> meta resource-stickines="100" master-max="2" notify="true" \
>> interleave="true"
>> ms xps-101-MS xps-101-DRBD \
>> meta resource-stickines="100" master-max="2" notify="true" \
>> interleave="true"
>> clone Cluster-ocfs-FSCL Cluster-ocfs-FS \
>> meta interleave="true" ordered="true"
>> colocation xps-101-Xen-DRBD inf: xps-101 xps-101-MS:Master
>> order Cluster-ocfs-AfterDRBD inf: Cluster-ocfs-MS:promote \
>> Cluster-ocfs-FSCL:start
>> order xps-101-AfterDRBD inf: xps-101-MS:promote xps-101:start
>> property $id="cib-bootstrap-options" \
>> dc-version="1.0.4-2ec1d189f9c23093bf9239a980534b661baf782d" \
>> cluster-infrastructure="openais" \
>> expected-quorum-votes="2" \
>> last-lrm-refresh="1253739607" \
>> node-health-red="0" \
>> stonith-enabled="false" \
>> no-quorum-policy="ignore"
>
>
> I'm not attempting to solve your issue, but I may be able to help simplify
> things a little (depending on which version of Xen
> you are using).
> You 'may' not have to manage the DRBD resource(s) yourself. Xen will take
> care of promotion/demotion of the DRBD resource.
> To see if yours supports it, look for /etc/xen/scripts/block-drbd. Once you
> do so, you will not have a need to use
> colocation and ordering ;) This was added to make what you are doing ALOT
> easier and more pragmatic.
Yes I saw that, but DRBD documentation you mentionned notes:
"There are three sets of circumstances under which you cannot use this
"approach:
" * You are configuring a fully virtualized (HVM) domU.
And I use HVM domU :-(
> DRBD note:
> I believe you will have to "allow-two-primaries" for your resources in
> /etc/drbd.conf in order for live migration to work.
Dual primary is enabled. When I manually migrate a DomU ressource, it
gets live migrated. It's only when requesting a node to be put in
standby mode that they got shut down.
It seems that when a node switch to standby mode, all ressources on the
remaining node are restarted. Therefore, when DRBD resource is stopped,
domU is stopped as well because of colocation constraint.
Maybe a start_delay property could do the trick. I will try it today.
Regards,
JB
===============================
DRBD conf exerpt
===============================
global {
usage-count yes;
}
common {
syncer {
rate 33M;
}
protocol C;
}
resource cluster-ocfs {
meta-disk internal;
device /dev/drbd0;
disk {
fencing resource-only;
}
handlers {
fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
after-resync-target "/usr/lib/drbd/crm-unfence-peer.sh";
}
on remus {
disk /dev/XenHosting/cluster-ocfs;
address 192.168.0.1:7800;
}
on romulus {
disk /dev/XenHosting/cluster-ocfs;
address 192.168.0.0:7800;
}
net {
allow-two-primaries;
}
startup {
become-primary-on both;
}
}
resource xps-101 {
meta-disk internal;
device /dev/drbd1;
disk {
fencing resource-only;
}
handlers {
fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
after-resync-target "/usr/lib/drbd/crm-unfence-peer.sh";
}
on remus {
disk /dev/XenHosting/xps-101.sda.disk;
address 192.168.0.1:7801;
}
net {
allow-two-primaries;
}
startup {
become-primary-on both;
}
}
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
