Re: [ClusterLabs] question on www.gossamer-threads.com/lists/linuxha/users/
DOH! Please ignore my mail - i live in the past ;) Last mail in archive is from Jul. Stefan ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Antw: CentOS 7 - Pacemaker - Problem with nfs-server and system
Hi, thank you for your reply. It seems to be a problem with the systemd unit files for nfs-server - specifically a timing issue. [root@centos7-n1 ~]# systemctl list-unit-files --type=service | grep rpcbind rpcbind.service static rpcbind is set to static - should be started on demand by other units. Invoking systemctl start nfs-server is pulling in rpcbind and nfs-lock rpcbind is started - but nfs-lock is maybe trying to start too early: Invoking manually systemctl start rpcbind and then systemctl start nfs-lock works within a second. Invoking manually systemctl start rpcbind and then sytemctl start nfs-server works within a few seconds as well. Invoking manually systemctl start nfs-server is only working randomly due to some timing issues. My current workaround is to also start rpcbind by the cluster - just before nfsserver. I also tried /usr/lib/ocf/resource.d/heartbeat/nfsserver - it is capable of handling systemd systems but start nfs-lock and nfs-server manually - hence hit the same problem in my case. Cheers, Stefan -Ursprüngliche Nachricht- Von: Ulrich Windl ulrich.wi...@rz.uni-regensburg.de [root@centos7-n1 ˜]# time systemctl start nfs-server real1m0.480s Probably time to look into syslog. I suspect a name/address resolving issue... ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
[ClusterLabs] group resources without order behavior / monitor timeout smaller than interval?
Hi, I'm trying to understand some cluster internals and would be happy to get some best practice recommendations: monitor interval and timeout: shouldn't timeout value always be smaller than interval to avoid another check even though the first is not over yet? Additionally i would like to use the group function to put all my VMS (ocf:heartbeat:VirtualDomain) in one group and colocate the group with the VIP and my LVM-volume. Unfortunately group function starts the resources in the listed order. So if i stop one VM, the following VMs are also stopped. Right now I'm having the following configuration and want to make it less redundant: # never let the stonith_service run on the host to stonith location l_st_srv20 st_ipmi_srv20 -inf: srv20 location l_st_srv21 st_ipmi_srv21 -inf: srv21 # do not run resources on quorum only node location loc_r_lvm_vg-storage_quorum_only_node r_lvm_vg-storage -inf: quorum_only_node location loc_r_vm_ado01_quorum_only_node r_vm_ado01 -inf: quorum_only_node location loc_r_vm_bar01_quorum_only_node r_vm_bar01 -inf: quorum_only_node location loc_r_vm_cmt01_quorum_only_node r_vm_cmt01 -inf: quorum_only_node location loc_r_vm_con01_quorum_only_node r_vm_con01 -inf: quorum_only_node location loc_r_vm_con02_quorum_only_node r_vm_con02 -inf: quorum_only_node location loc_r_vm_dsm01_quorum_only_node r_vm_dsm01 -inf: quorum_only_node location loc_r_vm_jir01_quorum_only_node r_vm_jir01 -inf: quorum_only_node location loc_r_vm_jir02_quorum_only_node r_vm_jir02 -inf: quorum_only_node location loc_r_vm_prx02_quorum_only_node r_vm_prx02 -inf: quorum_only_node location loc_r_vm_src01_quorum_only_node r_vm_src01 -inf: quorum_only_node # colocate ip with lvm storage colocation col_r_Failover_IP_r_lvm_vg-storage inf: r_Failover_IP r_lvm_vg-storage # colocate each VM with lvm storage colocation col_r_vm_ado01_r_lvm_vg-storage inf: r_vm_ado01 r_lvm_vg-storage colocation col_r_vm_bar01_r_lvm_vg-storage inf: r_vm_bar01 r_lvm_vg-storage colocation col_r_vm_cmt01_r_lvm_vg-storage inf: r_vm_cmt01 r_lvm_vg-storage colocation col_r_vm_con01_r_lvm_vg-storage inf: r_vm_jir01 r_lvm_vg-storage colocation col_r_vm_con02_r_lvm_vg-storage inf: r_vm_con02 r_lvm_vg-storage colocation col_r_vm_dsm01_r_lvm_vg-storage inf: r_vm_dsm01 r_lvm_vg-storage colocation col_r_vm_jir01_r_lvm_vg-storage inf: r_vm_con01 r_lvm_vg-storage colocation col_r_vm_jir02_r_lvm_vg-storage inf: r_vm_jir02 r_lvm_vg-storage colocation col_r_vm_prx02_r_lvm_vg-storage inf: r_vm_prx02 r_lvm_vg-storage colocation col_r_vm_src01_r_lvm_vg-storage inf: r_vm_src01 r_lvm_vg-storage # start lvm storage before VIP order ord_r_lvm_vg-storage_r_Failover_IP inf: r_lvm_vg-storage r_Failover_IP # start lvm storage before each VM order ord_r_lvm_vg-storage_r_vm_ado01 inf: r_lvm_vg-storage r_vm_ado01 order ord_r_lvm_vg-storage_r_vm_bar01 inf: r_lvm_vg-storage r_vm_bar01 order ord_r_lvm_vg-storage_r_vm_cmt01 inf: r_lvm_vg-storage r_vm_cmt01 order ord_r_lvm_vg-storage_r_vm_con01 inf: r_lvm_vg-storage r_vm_con01 order ord_r_lvm_vg-storage_r_vm_con02 inf: r_lvm_vg-storage r_vm_con02 order ord_r_lvm_vg-storage_r_vm_dsm01 inf: r_lvm_vg-storage r_vm_dsm01 order ord_r_lvm_vg-storage_r_vm_jir01 inf: r_lvm_vg-storage r_vm_jir01 order ord_r_lvm_vg-storage_r_vm_jir02 inf: r_lvm_vg-storage r_vm_jir02 order ord_r_lvm_vg-storage_r_vm_prx02 inf: r_lvm_vg-storage r_vm_prx02 order ord_r_lvm_vg-storage_r_vm_src01 inf: r_lvm_vg-storage r_vm_src01 any help is greatly appreciated. thank you. Stefan ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] group resources without order behavior / monitor timeout smaller than interval?
Hi Ken, thank you very much. I will test it! Cheers, Stefan -Ursprüngliche Nachricht- Von: Ken Gaillot <kgail...@redhat.com> Gesendet: Mit 14 September 2016 21:59 An: users@clusterlabs.org Betreff: Re: [ClusterLabs] group resources without order behavior / monitor timeout smaller than interval? On 09/14/2016 03:01 AM, Stefan Bauer wrote: > Hi, > > I'm trying to understand some cluster internals and would be happy to > get some best practice recommendations: > > monitor interval and timeout: shouldn't timeout value always be smaller > than interval to avoid another check even though the first is not over yet? The cluster handles it intelligently. If the previous monitor is still in progress when the interval expires, it won't run another one. It certainly makes sense that the timeout will generally be smaller than the interval, but there may be cases where a monitor on rare occasions takes a long time, and the user wants the high timeout for those occasions, but a shorter interval that will be used most of the time. > Additionally i would like to use the group function to put all my VMS > (ocf:heartbeat:VirtualDomain) in one group and colocate the group with > the VIP and my LVM-volume. Unfortunately group function starts the > resources in the listed order. So if i stop one VM, the following VMs > are also stopped. > > Right now I'm having the following configuration and want to make it > less redundant: You can use one ordering constraint and one colocation constraint, each with two resource sets, one containing the IP and volume with sequential=true, and the other containing the VMs with sequential=false. See: http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Explained/index.html#s-resource-sets > > # never let the stonith_service run on the host to stonith > > location l_st_srv20 st_ipmi_srv20 -inf: srv20 > location l_st_srv21 st_ipmi_srv21 -inf: srv21 > > > # do not run resources on quorum only node > location loc_r_lvm_vg-storage_quorum_only_node r_lvm_vg-storage -inf: > quorum_only_node > location loc_r_vm_ado01_quorum_only_node r_vm_ado01 -inf: quorum_only_node > location loc_r_vm_bar01_quorum_only_node r_vm_bar01 -inf: quorum_only_node > location loc_r_vm_cmt01_quorum_only_node r_vm_cmt01 -inf: quorum_only_node > location loc_r_vm_con01_quorum_only_node r_vm_con01 -inf: quorum_only_node > location loc_r_vm_con02_quorum_only_node r_vm_con02 -inf: quorum_only_node > location loc_r_vm_dsm01_quorum_only_node r_vm_dsm01 -inf: quorum_only_node > location loc_r_vm_jir01_quorum_only_node r_vm_jir01 -inf: quorum_only_node > location loc_r_vm_jir02_quorum_only_node r_vm_jir02 -inf: quorum_only_node > location loc_r_vm_prx02_quorum_only_node r_vm_prx02 -inf: quorum_only_node > location loc_r_vm_src01_quorum_only_node r_vm_src01 -inf: quorum_only_node > > > # colocate ip with lvm storage > colocation col_r_Failover_IP_r_lvm_vg-storage inf: r_Failover_IP > r_lvm_vg-storage > > > # colocate each VM with lvm storage > colocation col_r_vm_ado01_r_lvm_vg-storage inf: r_vm_ado01 r_lvm_vg-storage > colocation col_r_vm_bar01_r_lvm_vg-storage inf: r_vm_bar01 r_lvm_vg-storage > colocation col_r_vm_cmt01_r_lvm_vg-storage inf: r_vm_cmt01 r_lvm_vg-storage > colocation col_r_vm_con01_r_lvm_vg-storage inf: r_vm_jir01 r_lvm_vg-storage > colocation col_r_vm_con02_r_lvm_vg-storage inf: r_vm_con02 r_lvm_vg-storage > colocation col_r_vm_dsm01_r_lvm_vg-storage inf: r_vm_dsm01 r_lvm_vg-storage > colocation col_r_vm_jir01_r_lvm_vg-storage inf: r_vm_con01 r_lvm_vg-storage > colocation col_r_vm_jir02_r_lvm_vg-storage inf: r_vm_jir02 r_lvm_vg-storage > colocation col_r_vm_prx02_r_lvm_vg-storage inf: r_vm_prx02 r_lvm_vg-storage > colocation col_r_vm_src01_r_lvm_vg-storage inf: r_vm_src01 r_lvm_vg-storage > > # start lvm storage before VIP > > order ord_r_lvm_vg-storage_r_Failover_IP inf: r_lvm_vg-storage r_Failover_IP > > > # start lvm storage before each VM > order ord_r_lvm_vg-storage_r_vm_ado01 inf: r_lvm_vg-storage r_vm_ado01 > order ord_r_lvm_vg-storage_r_vm_bar01 inf: r_lvm_vg-storage r_vm_bar01 > order ord_r_lvm_vg-storage_r_vm_cmt01 inf: r_lvm_vg-storage r_vm_cmt01 > order ord_r_lvm_vg-storage_r_vm_con01 inf: r_lvm_vg-storage r_vm_con01 > order ord_r_lvm_vg-storage_r_vm_con02 inf: r_lvm_vg-storage r_vm_con02 > order ord_r_lvm_vg-storage_r_vm_dsm01 inf: r_lvm_vg-storage r_vm_dsm01 > order ord_r_lvm_vg-storage_r_vm_jir01 inf: r_lvm_vg-storage r_vm_jir01 > order ord_r_lvm_vg-storage_r_vm_jir02 inf: r_lvm_vg-storage r_vm_jir02 > order ord_r_lvm_vg-storage_r_vm_prx02 inf: r_lvm_vg-storage r_vm_prx02 > order ord_r_lvm_vg-storage_r_vm_src01 inf: r_lvm_vg-storage r_vm_src01 > > any help is greatly appreciated. > > thank you. > >
[ClusterLabs] best practice fencing with ipmi in 2node-setups / cloneresource/monitor/timeout
Hi, i run a 2 node cluster and want to be save in split-brain scenarios. For this i setup external/ipmi to stonith the other node. Some possible issues jumped to my mind and i would ike to find the best practice solution: - I have a primitive for each node to stonith. Many documents and guides recommend to never let them run on the host it should fence. I would setup clone resources to avoid dealing with locations that would also influence scoring. Does that make sense? - Monitoring operation on the stonith primitive is dangerous. I read that if monitor operations fail for the stonith device, stonith action is triggered. I think its not clever to give the cluster the option to fence a node just because it has an issue to monitor a fence device. That should not be a reason to shutdown a node. What is your opinion on this? Can i just set the primitive monitor operation to disabled? Thank you. Stefan ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
