Re: [ClusterLabs] One Failed Resource = Failover the Cluster?
It shouldn't relocate or affect any other resource,as long as the stop succeeds.If the stop operation times out or fails -> fencing kicks in. Best Regards,Strahil Nikolov___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] One Failed Resource = Failover the Cluster?
On Fri, 2021-06-04 at 19:10 +, Eric Robinson wrote: > Sometimes it seems like Pacemaker fails over an entire cluster when > only one resource has failed, even though no other resources are > dependent on it. Is that expected behavior? > > For example, suppose I have the following colocation constraints… > > filesystem with drbd master > vip with filesystem > mysql_01 with filesystem > mysql_02 with filesystem > mysql_03 with filesystem By default, a resource that is colocated with another resource will influence that resource's location. This ensures that as many resources are active as possible. So, if any one of the above resources fails and meets its migration- threshold, all of the resources will move to another node so a recovery attempt can be made for the failed resource. No resource will be *stopped* due to the failed resource unless it depends on it. As of the forthcoming 2.1.0 release, the new "influence" option for colocation constraints (and "critical" resource meta-attribute) controls whether this effect occurs. If influence is turned off (or the resource made non-critical), then the failed resource will just stop, and the other resources won't move to try to save it. > > …and the following order constraints… > > promote drbd, then start filesystem > start filesystem, then start vip > start filesystem, then start mysql_01 > start filesystem, then start mysql_02 > start filesystem, then start mysql_03 > > Now, if something goes wrong with mysql_02, will Pacemaker try to > fail over the whole cluster? And if mysql_02 can’t be run on either > cluster, then does Pacemaker refuse to run any resources? > > I’m asking because I’ve seen some odd behavior like that over the > years. Could be my own configuration mistakes, of course. > > -Eric -- Ken Gaillot ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
[ClusterLabs] One Failed Resource = Failover the Cluster?
Sometimes it seems like Pacemaker fails over an entire cluster when only one resource has failed, even though no other resources are dependent on it. Is that expected behavior? For example, suppose I have the following colocation constraints... filesystem with drbd master vip with filesystem mysql_01 with filesystem mysql_02 with filesystem mysql_03 with filesystem ...and the following order constraints... promote drbd, then start filesystem start filesystem, then start vip start filesystem, then start mysql_01 start filesystem, then start mysql_02 start filesystem, then start mysql_03 Now, if something goes wrong with mysql_02, will Pacemaker try to fail over the whole cluster? And if mysql_02 can't be run on either cluster, then does Pacemaker refuse to run any resources? I'm asking because I've seen some odd behavior like that over the years. Could be my own configuration mistakes, of course. -Eric Disclaimer : This email and any files transmitted with it are confidential and intended solely for intended recipients. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Physician Select Management. Warning: Although Physician Select Management has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
[ClusterLabs] fence-agents v4.9.0
ClusterLabs is happy to announce fence-agents v4.9.0. The source code is available at: https://github.com/ClusterLabs/fence-agents/releases/tag/v4.9.0 The most significant enhancements in this release are: - bugfixes and enhancements: - build: enable fence_virtd cpg plugin by default - build: tidy up module sources - fence_aws: add filter parameter to be able to limit which nodes are listed - fence_gce: default method moved back to powercycle (#389) - fence_lindypdu: new fence agent - fence_mpath: watchdog retries support - fence_openstack: major rework of the agent. (#397) - fence_redfish: add missing diag logic - fence_virt*: simple_auth: use %zu for sizeof to avoid failing verbose builds on some archs - fence_virt: fix required=1 parameters that used to not be required and add deprecated=1 for old deprecated params - fencing: add multi plug support for reboot-action - fencing: add stonith_status_sleep parameter for sleep between status calls during a STONITH action - fencing: fix issue with hardcoded help text length for metadata - virt: drop fence_virtd non-modular build - virt: drop null, libvirt-qmf, pm-fence plugins - virt: fixes and cleanup of deadcode The full list of changes for fence-agents is available at: https://github.com/ClusterLabs/fence-agents/compare/v4.8.0...v4.9.0 Everyone is encouraged to download and test the new release. We do many regression tests and simulations, but we can't cover all possible use cases, so your feedback is important and appreciated. Many thanks to all the contributors to this release. Best, The fence-agents maintainers ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
