[Linux-HA] Antw: Re: location and orders : Question about a behavior ...
Dan Frincu df.clus...@gmail.com schrieb am 03.08.2011 um 13:28 in Nachricht CADQRkwiFCEUnq-i9Dtv6AbjQz4Z_e792=3is81zv1eqdrnj...@mail.gmail.com: Hi, On Wed, Aug 3, 2011 at 2:22 PM, alain.mou...@bull.net wrote: Hi Thanks I don't think the 1000 or 5000 value makes any difference, The values make little difference, it's about having a higher score atm. Hi! Isn't the stickyness effectively based on the failcount? We have one resource that has a location constraint for one node with a weight of 50 and a sticky ness of 10. The resource runs on a different node and shows no tendency of moving back (not even after restarts). Somehow the implementation of stickyness is not what one might expect. I'd expect stickyness to be related to RUNNING resources. I see little sense in keeping a resource on a node after restarting. Why? Usually you want stickyness to prevent unexpected downtimes or negative side effects caused by migration (e.g. all users loosing their connections). But as a restart will have these side-effects anyway, I see little sense with the current implementation. Regards, Ulrich so the rsc_options could make it work ? Yes, I believe so. But do you have also the order with a clone ? No. Because on other of my configurations, I have also property $id=cib-bootstrap-options \ default-resource-stickiness=5000 and the resource does not failback automatically ... so ... Could somebody explain ? Try the following: crm_verify -L 21 | grep stick And see what scores (weights) are given to resources. Based on these weights it might make more sense. HTH, Dan Thanks Alain De :Dan Frincu df.clus...@gmail.com A : General Linux-HA mailing list linux-ha@lists.linux-ha.org Date : 03/08/2011 13:00 Objet : Re: [Linux-HA] location and orders : Question about a behavior ... Envoyé par :linux-ha-boun...@lists.linux-ha.org Hi, On Tue, Aug 2, 2011 at 6:06 PM, alain.mou...@bull.net wrote: Hi I have this simple configuration of locations and orders between resources group-1 , group-2 and clone-1 (on a two nodes ha cluster with Pacemaker-1.1.2-7 /corosync-1.2.3-21) : location loc1-group-1 group-1 +100: node2 location loc1-group-2 group-2 +100: node3 order order-group-1 inf: group-1 clone-1 order order-group-2 inf: group-2 clone-1 property $id=cib-bootstrap-options \ dc-version=1.1.2-f059ec7ced7a86f18e5490b67ebf4a0b963bccfe \ cluster-infrastructure=openais \ expected-quorum-votes=2 \ stonith-enabled=true \ no-quorum-policy=ignore \ default-resource-stickiness=5000 \ I use it as: rsc_defaults $id=rsc-options \ resource-stickiness=1000 Instead of: property $id=cib-bootstrap-options \ default-resource-stickiness=5000 And the behavior is the expected one, no failback. HTH, Dan (and no current cli- preferences) When I stop the node2, the group-1 is well migrated on node3 But when node2 is up again, and that I start Pacemaker again on node2, the group-1 automatically comes back on node2 , and I wonder why ? I have other similar configuration with same location constraints and same default-resource-stickiness value, but without order with a clone resource, and the group does not come back automatically. But I don't understand why this order constraint would change this behavior ... Thanks for your help Alain Moullé ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems -- Dan Frincu CCNA, RHCE ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems -- Dan Frincu CCNA, RHCE ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
Re: [Linux-HA] Antw: Re: location and orders : Question about a behavior ...
On Thu, Aug 4, 2011 at 4:28 PM, Ulrich Windl ulrich.wi...@rz.uni-regensburg.de wrote: Dan Frincu df.clus...@gmail.com schrieb am 03.08.2011 um 13:28 in Nachricht CADQRkwiFCEUnq-i9Dtv6AbjQz4Z_e792=3is81zv1eqdrnj...@mail.gmail.com: Hi, On Wed, Aug 3, 2011 at 2:22 PM, alain.mou...@bull.net wrote: Hi Thanks I don't think the 1000 or 5000 value makes any difference, The values make little difference, it's about having a higher score atm. Hi! Isn't the stickyness effectively based on the failcount? No. A long long time ago there was failure-stickiness, but that was a bad idea that we got rid of. We have one resource that has a location constraint for one node with a weight of 50 and a sticky ness of 10. The resource runs on a different node and shows no tendency of moving back (not even after restarts). Somehow the implementation of stickyness is not what one might expect. I'd expect stickyness to be related to RUNNING resources. It is. I see little sense in keeping a resource on a node after restarting. Why? Usually you want stickyness to prevent unexpected downtimes or negative side effects caused by migration (e.g. all users loosing their connections). But as a restart will have these side-effects anyway, I see little sense with the current implementation. Regards, Ulrich so the rsc_options could make it work ? Yes, I believe so. But do you have also the order with a clone ? No. Because on other of my configurations, I have also property $id=cib-bootstrap-options \ default-resource-stickiness=5000 and the resource does not failback automatically ... so ... Could somebody explain ? Try the following: crm_verify -L 21 | grep stick And see what scores (weights) are given to resources. Based on these weights it might make more sense. HTH, Dan Thanks Alain De : Dan Frincu df.clus...@gmail.com A : General Linux-HA mailing list linux-ha@lists.linux-ha.org Date : 03/08/2011 13:00 Objet : Re: [Linux-HA] location and orders : Question about a behavior ... Envoyé par : linux-ha-boun...@lists.linux-ha.org Hi, On Tue, Aug 2, 2011 at 6:06 PM, alain.mou...@bull.net wrote: Hi I have this simple configuration of locations and orders between resources group-1 , group-2 and clone-1 (on a two nodes ha cluster with Pacemaker-1.1.2-7 /corosync-1.2.3-21) : location loc1-group-1 group-1 +100: node2 location loc1-group-2 group-2 +100: node3 order order-group-1 inf: group-1 clone-1 order order-group-2 inf: group-2 clone-1 property $id=cib-bootstrap-options \ dc-version=1.1.2-f059ec7ced7a86f18e5490b67ebf4a0b963bccfe \ cluster-infrastructure=openais \ expected-quorum-votes=2 \ stonith-enabled=true \ no-quorum-policy=ignore \ default-resource-stickiness=5000 \ I use it as: rsc_defaults $id=rsc-options \ resource-stickiness=1000 Instead of: property $id=cib-bootstrap-options \ default-resource-stickiness=5000 And the behavior is the expected one, no failback. HTH, Dan (and no current cli- preferences) When I stop the node2, the group-1 is well migrated on node3 But when node2 is up again, and that I start Pacemaker again on node2, the group-1 automatically comes back on node2 , and I wonder why ? I have other similar configuration with same location constraints and same default-resource-stickiness value, but without order with a clone resource, and the group does not come back automatically. But I don't understand why this order constraint would change this behavior ... Thanks for your help Alain Moullé ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems -- Dan Frincu CCNA, RHCE ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems -- Dan Frincu CCNA, RHCE ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See
Re: [Linux-HA] Antw: Re: location and orders : Question about a behavior ...
On 08/04/2011 08:28 AM, Ulrich Windl wrote: Hi! Isn't the stickyness effectively based on the failcount? We have one resource that has a location constraint for one node with a weight of 50 and a sticky ness of 10. The resource runs on a different node and shows no tendency of moving back (not even after restarts). No stickiness has nothing to do with the failcount. The policy engine could take both into account the stickiness (for RUNNING resources) and the failcount for (RUNNING or non-running ressources). If you ever had a on-start-failure of a resource on a node the failcount is set to infinity which means, the resource could not be started at this node. If the policy engine needs to evaluate where to run a resource it uses the location/antcolocation/cololaction constraints, failcounts, stickiness and maybe some other scores to evaluate WHERE to run a resource. So in my opinion the stiness does exactly what you are asking for. Kind Regards Fabian Somehow the implementation of stickyness is not what one might expect. I'd expect stickyness to be related to RUNNING resources. I see little sense in keeping a resource on a node after restarting. Why? Usually you want stickyness to prevent unexpected downtimes or negative side effects caused by migration (e.g. all users loosing their connections). But as a restart will have these side-effects anyway, I see little sense with the current implementation. Regards, Ulrich ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
Re: [Linux-HA] Antw: Re: location and orders : Question about a behavior ...
Hi, and so ... about my initial question about automatic failback that was not expected for me with regards similar configuration on some other cluster of mine ? Thanks Alain De :Maloja01 maloj...@arcor.de A : linux-ha@lists.linux-ha.org Date : 04/08/2011 12:58 Objet : Re: [Linux-HA] Antw: Re: location and orders : Question about a behavior ... Envoyé par :linux-ha-boun...@lists.linux-ha.org On 08/04/2011 08:28 AM, Ulrich Windl wrote: Hi! Isn't the stickyness effectively based on the failcount? We have one resource that has a location constraint for one node with a weight of 50 and a sticky ness of 10. The resource runs on a different node and shows no tendency of moving back (not even after restarts). No stickiness has nothing to do with the failcount. The policy engine could take both into account the stickiness (for RUNNING resources) and the failcount for (RUNNING or non-running ressources). If you ever had a on-start-failure of a resource on a node the failcount is set to infinity which means, the resource could not be started at this node. If the policy engine needs to evaluate where to run a resource it uses the location/antcolocation/cololaction constraints, failcounts, stickiness and maybe some other scores to evaluate WHERE to run a resource. So in my opinion the stiness does exactly what you are asking for. Kind Regards Fabian Somehow the implementation of stickyness is not what one might expect. I'd expect stickyness to be related to RUNNING resources. I see little sense in keeping a resource on a node after restarting. Why? Usually you want stickyness to prevent unexpected downtimes or negative side effects caused by migration (e.g. all users loosing their connections). But as a restart will have these side-effects anyway, I see little sense with the current implementation. Regards, Ulrich ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
[Linux-HA] DMC 0.9.7 - Pacemaker/Storage GUI
Hi, This is the next DMC release 0.9.7. DMC is Pacemaker, Cluster Virtual Manager and Storage/DRBD GUI written in Java. The LVM plugins are now normal part of the GUI in the Storage view, where you can create, delete physical volumes, volume groups, logical volumes, resize them and create snapshots in the (whole) cluster. Goodbye command line... Some issues with KDE/Compiz were fixed or at least they were made much less likely to appear. Most notably blank windows. Personally I haven't use KDE since the 4.0 came out and just assumed that everything worked at least as anything else on the KDE, but it didn't. Some issues with applets were fixed as well, so go ahead and use your browser for everything. :) Screenshot: http://oss.linbit.com/drbd-mc/img/drbd-mc-0.9.7.png You can get DRBD:MC here: http://oss.linbit.com/drbd-mc/ 1. You don't need Java on the cluster servers only on your desktop. 2. Download the DMC-0.9.7.jar file. 3. Start it: java -jar DMC-0.9.7.jar, or click on the file. 4. It connects to the cluster via SSH. 5. If you use it without DRBD, you have to click Skip button on couple of places. 6. It is recommended to use it with SUN Java. DRBD:MC is compatible with Heartbeat 2.1.3 to the Pacemaker 1.1.5 with Corosync or Heartbeat and DRBD 8. The most important changes: * fix fonts in dialogs * convert plugin code to normal dialogs * add --debug level option * add VG remove dialog * add VG create to the dialogs * add PV remove dialog * show in the graph whether the block device is physical volume * add PV create dialog * add --out option to redirect the stdout * fix distro detection so that it detects centos6 * fix unexpected jumping from Service view to VM view * make default button work in dialogs again * allow setting both bds to primary if allow-two-primaries is set * don't allow to enter the same ids for the same resources * don't create new dependent resource with existing id * use checkboxes for colocation and order only constraints * fix gray window problem with popups * type to search feature for popups * fix problem with not editable fields in an applet * workarounds for gray windows * fix null pointer exception, while removing a DRBD volume * fix problem with menu nodes, while adding a clone Rasto Levrinc -- DI Rastislav Levrinc Senior Software Engineer ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
Re: [Linux-HA] Antw: Re: location and orders : Question about a behavior ...
Maloja01 maloj...@arcor.de schrieb am 04.08.2011 um 12:58 in Nachricht 4e3a7b5c.1030...@arcor.de: On 08/04/2011 08:28 AM, Ulrich Windl wrote: Hi! Isn't the stickyness effectively based on the failcount? We have one resource that has a location constraint for one node with a weight of 50 and a sticky ness of 10. The resource runs on a different node and shows no tendency of moving back (not even after restarts). No stickiness has nothing to do with the failcount. The policy engine could take both into account the stickiness (for RUNNING resources) and the failcount for (RUNNING or non-running ressources). If you ever had a on-start-failure of a resource on a node the failcount is set to infinity which means, the resource could not be started at this node. fabian, I know that, and the errors were removed by crm_resource -C. Still the resource is happy where it is, and doesn't want to move away. If the policy engine needs to evaluate where to run a resource it uses the location/antcolocation/cololaction constraints, failcounts, stickiness and maybe some other scores to evaluate WHERE to run a resource. So in my opinion the stiness does exactly what you are asking for. Unfortunately someone did a manual migrate yesterday, so I cannot show the scores that lead to the problem. Regards, Ulrich ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
Re: [Linux-HA] Antw: Re: location and orders : Question about a behavior ...
Hi Ulrich, I did not folow the complete thread, just jumped in - sorry. Is the resource inside a resource group? In this case the stickiness is multiplied. And sofor the stickiness could be greater than the location role (score). Regards Fabian On 08/04/2011 03:10 PM, Ulrich Windl wrote: Maloja01 maloj...@arcor.de schrieb am 04.08.2011 um 12:58 in Nachricht 4e3a7b5c.1030...@arcor.de: On 08/04/2011 08:28 AM, Ulrich Windl wrote: Hi! Isn't the stickyness effectively based on the failcount? We have one resource that has a location constraint for one node with a weight of 50 and a sticky ness of 10. The resource runs on a different node and shows no tendency of moving back (not even after restarts). No stickiness has nothing to do with the failcount. The policy engine could take both into account the stickiness (for RUNNING resources) and the failcount for (RUNNING or non-running ressources). If you ever had a on-start-failure of a resource on a node the failcount is set to infinity which means, the resource could not be started at this node. fabian, I know that, and the errors were removed by crm_resource -C. Still the resource is happy where it is, and doesn't want to move away. If the policy engine needs to evaluate where to run a resource it uses the location/antcolocation/cololaction constraints, failcounts, stickiness and maybe some other scores to evaluate WHERE to run a resource. So in my opinion the stiness does exactly what you are asking for. Unfortunately someone did a manual migrate yesterday, so I cannot show the scores that lead to the problem. Regards, Ulrich ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
Re: [Linux-HA] Heartbeat Restart is not same as Stop and Start
Mike, I checked the permission and those are fine. If you can please check the restart script I have given below, it does not touch the heartbeat lock file *touch $LOCKDIR/$SUBSYS* when the heartbeat is restared and I guess it is a problem. Is it not? Btw, we have a product for some web application and as part of it we allow Administrators to configure servers as redundant server and under lying we use linux-ha to set up redundant servers. Rahul ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
