Re: [ClusterLabs] Location constraints for fencing resources?

[Dan Swartzendruber]

On 2016-09-13 00:20, Klaus Wenninger wrote:

Location-constraints for fencing-resources are definitely supported and
don't just work by accident - if this was the question.

On 09/13/2016 02:43 AM, Dan Swartzendruber wrote:

On 2016-09-12 10:48, Dan Swartzendruber wrote:
Posting this as a separate thread from my fence_apc one.  As I said 
in

that thread, I created two fence_apc agents, one to fence node A and
one to fence node B.  Each was configured using a static pcmk node
mapping, and constrained to only run on the other node.  In the
process of testing this, I discovered a bug (feature?) in the LCMC 
GUI

I am using to manage the cluster.  To wit: when I click on a fence
object, it never seems to fetch the resource constraints (e.g. they
show in the GUI as "nothing selected"), so if I changes something 
(say

the power_wait timeout) and then click "Apply", the location
constraints are deleted from that fencing resource.  I also noticed
that if I connect to port 2224 (pcsd), regular resources show me the
location constraints, whereas fence resources don't, which is making
me wonder if this is not supported?  I'm thinking I can set up a
pcmk_host_map to tell it which APC outlet manages node A and which
manages node B, in which case I can just use one fence_apc resource
with a dynamic pcmk host list?  Thanks!


Okay, this *seems* to work.  e.g. pcmk_host_list has the two hosts.
pmck_host_map says nas1:8;nas2:2.  The fencing agent was running on
nas2.  I logged in to nas2 and did 'systemctl stop network'.
pacemaker moved the fencing resource to nas1, then power-cycled nas2.
Looking good...


Basically, yes.  I was puzzled, since the web GUI pcsd serves up gives 
no apparent way to edit location constraints for stonith resources, and 
LCMC apparently doesn't read them from the config, so if you edit a 
stonith resource and change anything, then click on "Apply", it nukes 
any change you *had* made.  For the latter, I will open a ticket with 
the lcmc developer(s).  Thanks!


___
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] Cold star of one node only

[Ken Gaillot]

On 09/13/2016 03:27 PM, Gienek Nowacki wrote:
> Hi,
> 
> I'm still testing (before production running) the solution with
> pacemaker+corosync+drbd+dlm+gfs2 on Centos7 with double-primary config.
> 
> I have two nodes: wirt1v and wirt2v - each node contains LVM partition 
> with DRBD (/dev/drbd2) and filesystem mounted as /virtfs2. Filesystems
> /virtfs2 contain the images of virtual machines.
> 
> My problem is so - I can't start the cluster and the resources on one
> node only (cold start) when the second node is completely powered off.

"two_node: 1" implies "wait_for_all: 1" in corosync.conf; see the
votequorum(5) man page for details.

This is a safeguard against the situation where the other node is up,
but not reachable from the newly starting node.

You can get around this by setting "wait_for_all: 0", and rely on
pacemaker's fencing to resolve that situation. But if so, be careful
about starting pacemaker when the nodes can't see each other, because
each will try to fence the other.

Example: wirt1v's main LAN network port gets fried in an electrical
surge, but its iDRAC network port is still operational. wirt2v may
successfully fence wirt1v and take over all resources, but if wirt1v is
rebooted and starts pacemaker, without wait_for_all it will fence wirt2v.

> Is it in such configuration at all posssible - is it posible to start
> one node only?
> 
> Could you help me, please?
> 
> The  configs and log (during cold start)  are attached.
> 
> Thanks in advance,
> Gienek Nowacki
> 
> ==
> 
> #-
> ### result:  cat /etc/redhat-release  ###
> 
> CentOS Linux release 7.2.1511 (Core)
> 
> #-
> ### result:  uname -a  ###
> 
> Linux wirt1v.example.com 
> 3.10.0-327.28.3.el7.x86_64 #1 SMP Thu Aug 18 19:05:49 UTC 2016 x86_64
> x86_64 x86_64 GNU/Linux
> 
> #-
> ### result:  cat /etc/hosts  ###
> 
> 127.0.0.1   localhost localhost.localdomain localhost4
> localhost4.localdomain4
> 172.31.0.23 wirt1.example.com  wirt1
> 172.31.0.24 wirt2.example.com  wirt2
> 1.1.1.1 wirt1v.example.com  wirt1v
> 1.1.1.2 wirt2v.example.com  wirt2v
> 
> #-
> ### result:  cat /etc/drbd.conf  ###
> 
> include "drbd.d/global_common.conf";
> include "drbd.d/*.res";
> 
> #-
> ### result:  cat /etc/drbd.d/global_common.conf  ###
> 
> common {
> protocol C;
> syncer {
> verify-alg sha1;
> }
> startup {
> become-primary-on both;
> wfc-timeout 30;
> outdated-wfc-timeout 20;
> degr-wfc-timeout 30;
> }
> disk {
> fencing resource-and-stonith;
> }
> handlers {
> fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
> after-resync-target "/usr/lib/drbd/crm-unfence-peer.sh";
> split-brain
> "/usr/lib/drbd/notify-split-brain.sh linuxad...@example.com
> ";
> pri-lost-after-sb  
> "/usr/lib/drbd/notify-split-brain.sh linuxad...@example.com
> ";
> out-of-sync
> "/usr/lib/drbd/notify-out-of-sync.sh linuxad...@example.com
> ";
> local-io-error 
> "/usr/lib/drbd/notify-io-error.shlinuxad...@example.com
> ";
> }
> net {
> allow-two-primaries;
> after-sb-0pri discard-zero-changes;
> after-sb-1pri discard-secondary;
> after-sb-2pri disconnect;
> }
> }
> 
> #-
> ### result:  cat /etc/drbd.d/drbd2.res  ###
> 
> resource drbd2 {
> meta-disk internal;
> device /dev/drbd2;
> on wirt1v.example.com  {
> disk /dev/vg02/drbd2;
> address 1.1.1.1:7782 ;
> }
> on wirt2v.example.com  {
> disk /dev/vg02/drbd2;
> address 1.1.1.2:7782 ;
> }
> }
> 
> #-
> ### result:  cat /etc/corosync/corosync.conf  ###
> 
> totem {
> version: 2
> secauth: off
> cluster_name: klasterek
> transport: udpu
> }
> nodelist {
> node {
> ring0_addr: wirt1v
> nodeid: 1
> }
> node {
> ring0_addr: wirt2v
> nodeid: 2
> }
> }
> quorum {
> provider: corosync_votequorum
> two_node: 1
> }
> logging {
> to_logfile: yes
> logfile: /var/log/cluster/corosync.log
> to_syslog: yes
> }
> 
> #--

Re: [ClusterLabs] [rgmanager] generic 'initscript' resource agent that passes arguments?

[bergman]

In the message dated: Tue, 06 Sep 2016 20:36:53 +0200,
The pithy ruminations from Jan =?utf-8?Q?Pokorn=C3=BD?= on 
 were:

=> On 29/08/16 13:41 -0400, berg...@merctech.com wrote:
=> > I've got a number of scripts that are based on LSB compliant scripts,
=> > but which also accept arguments & values. For example, a script to manage
=> > multiple virtual machines has a command-line in the form:
=> > 
=> >vbox_init --vmname $VMNAME [-d|--debug] [start|stop|status|restart]
=> > 

[SNIP!]

=> 
=> 
=> Adapting script.sh to scriptArgs.sh working as desired should not
=> be a hard task, though.  Once you add such custom RA to the system
=> (i.e., across all nodes), supposing you have adapted produced

OK.

Will ccs look for resource scripts anywhere other than
"/usr/share/cluster"? Does it use a search path, such as:

/usr/share/cluster:/usr/local/share/cluster

or is there a way to specify alternative locations for local resource
files?

I truly hate putting local files in directories that are managed by
external packages -- it will surely be a source of future confusion and
management difficulty.


=> meta-data respectively, you should remember to run "ccs_update_schema"
=> so that any subsequent start of the cluster stack on the node or
=> modification via ccs utility will not fail due to unrecognized RA
=> if present in the to-apply configuration.

Got it.

=> 
=> Note that the new agent will not get reflected in luci web UI
=> automatically, you would have to add a support on your own.
=> 

No problem, I do most cluster configuration via the command line.

Thanks,

Mark


=> -- 
=> Jan (Poki)

-- 
Mark Bergman 

___
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