On 1/4/13 7:10 PM, Matthew Spah wrote: > Hey everyone, > > I've just recently built up a pacemaker cluster and have begun testing it. > Everything has been going great until after Christmas break.. I fired up > the cluster to find this going on. > > ============ > Last updated: Fri Jan 4 16:06:41 2013 > Last change: Fri Jan 4 16:02:13 2013 via crmd on emserver1 > Stack: openais > Current DC: emserver1 - partition with quorum > Version: 1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c > 2 Nodes configured, 2 expected votes > 9 Resources configured. > ============ > > Online: [ emserver1 emserver2 ] > > Master/Slave Set: ms_drbd_nfs [p_drbd_nfs] > Masters: [ emserver2 ] > Slaves: [ emserver1 ] > Clone Set: cl_lsb_nfsserver [p_lsb_nfsserver] > Started: [ emserver1 emserver2 ] > Resource Group: g_nfs > p_fs_nfs (ocf::heartbeat:Filesystem): Started emserver2 > p_exportfs_nfs (ocf::heartbeat:exportfs): Started emserver2 > (unmanaged) FAILED > p_ip_nfs (ocf::heartbeat:IPaddr2): Stopped > Clone Set: cl_exportfs_root [p_exportfs_root] > Started: [ emserver2 ] > Stopped: [ p_exportfs_root:1 ] > > Failed actions: > p_exportfs_root:0_start_0 (node=emserver1, call=10, rc=-2, status=Timed > Out): unknown exec error > p_exportfs_root:1_monitor_30000 (node=emserver2, call=11, rc=7, > status=complete): not running > p_exportfs_nfs_stop_0 (node=emserver2, call=39, rc=-2, status=Timed > Out): unknown exec error > > > I've been reading through documentation to figure out what is going on. If > you guys could point me in the right direction that would be a huge help. :) > > Here is my configuration... > node emserver1 > node emserver2 > primitive p_drbd_nfs ocf:linbit:drbd \ > params drbd_resource="r0" \ > op monitor interval="15" role="Master" \ > op monitor interval="30" role="Slave" > primitive p_exportfs_nfs ocf:heartbeat:exportfs \ > params fsid="1" directory="/srv/nfs" options="rw,crossmnt" > clientspec="10.1.10.0/255.255.255.0" \ > op monitor interval="30s" > primitive p_exportfs_root ocf:heartbeat:exportfs \ > params fsid="0" directory="/srv" options="rw,crossmnt" clientspec=" > 10.1.10.0/255.255.255.0" \ > op monitor interval="30s" > primitive p_fs_nfs ocf:heartbeat:Filesystem \ > params device="/dev/drbd1" directory="/srv/nfs" fstype="ext3" \ > op monitor interval="10s" > primitive p_ip_nfs ocf:heartbeat:IPaddr2 \ > params ip="10.1.10.10" cidr_netmask="24" iflabel="NFSV_IP" \ > op monitor interval="30s" > primitive p_lsb_nfsserver lsb:nfs-kernel-server \ > op monitor interval="30s" > group g_nfs p_fs_nfs p_exportfs_nfs p_ip_nfs > ms ms_drbd_nfs p_drbd_nfs \ > meta master-max="1" master-node-max="1" clone-max="2" > clone-node-max="1" notify="true" > clone cl_exportfs_root p_exportfs_root > clone cl_lsb_nfsserver p_lsb_nfsserver > colocation c_nfs_on_drbd inf: g_nfs ms_drbd_nfs:Master > colocation c_nfs_on_root inf: g_nfs cl_exportfs_root > order o_drbd_before_nfs inf: ms_drbd_nfs:promote g_nfs:start > order o_root_before_nfs inf: cl_exportfs_root g_nfs:start > property $id="cib-bootstrap-options" \ > dc-version="1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c" \ > cluster-infrastructure="openais" \ > expected-quorum-votes="2" \ > stonith-enabled="false" \ > no-quorum-policy="ignore" \ > maintenance-mode="false" \ > last-lrm-refresh="1357344133" > rsc_defaults $id="rsc-options" \ > resource-stickiness="200"
I've had problems like this with the exportfs resource. Here are some things to check: - You didn't list the software versions. In particular, look at the version of your resource-agents package. There have been some recent changes to the ocf:heartbeat:exportfs script that improve the pattern-matching in its monitor action. - The ocf:heartbeat:exportfs monitor works by comparing the clientspec parameter with the output of the exportfs command. Check when you export to 10.1.10.0 that the output of exportfs returns exactly that string, instead of a resolved name. It may help to give a concrete example: I exported a partition via ocf:heartbeat:exportfs to clientspec=mail.nevis.columbia.edu. The monitor action always failed, until I realized that mail.nevis.columbia.edu was an alias for franklin.nevis.columbia.edu; that was the name that appeared in the output of /usr/sbin/exportfs. Hope this helps. -- William Seligman | Phone: (914) 591-2823 Nevis Labs, Columbia Univ | PO Box 137 | Irvington NY 10533 USA | http://www.nevis.columbia.edu/~seligman/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 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
