|
osdir.com mailing list archive |
|
Subject: Re: A few GFS newbie questions: journals, etc - msg#00275List: linux.redhat.clusterThat is right. What you have here is cman correcting an incorrect configuration. You've told it to expect only 10 votes but provided it with 101 votes. It knows when you're lying to it ;-) But darn it, I *want* to be able to lie to it! :) What you actually have here is a special case of a two-node cluster, because there are only two "real" nodes involved. Unfortunately the cman "two_node" mode is no use here because it enforces the 2-node restriction which would prevent you bringing any VMs online once the two real machines were up. I've only got two physical boxes right now, but will be adding 2 more in the near future (once I migrate all the services off the boxes in my old colo to the new one.) One little-known feature is that you can set votes to zero (only in CCS, not from the cman_tool command-line) which may go a little way to helping out. it would, at least, work for 3 or more Xen host nodes if all the VMs had zero votes. I'm not sure how that would help - if I lose another physical host, won't it still lose quorum? But sounds like a good idea anyways - I'll drop the VM's down to 0 votes. Perhaps we should change "2-node" mode to allow >2 nodes provided the extra nodes all had zero votes ? If possible, an option that would let me say "here's the number required for a quorum, I know I'm lying to you, but do it anyways" would be nice. :) ------------------------------------------------------------------------ | nate carlson | natecars@xxxxxxxxxxxxxxx | http://www.natecarlson.com | | depriving some poor village of its idiot since 1981 | ------------------------------------------------------------------------ Thread at a glance:
Previous Message by Date: click to view message previewRe: A few more newbie questions about gulmOn Thu, Jun 30, 2005 at 02:40:55AM +0200, Florian G. Pflug wrote: > FYI, things work now, after porting the changes from gulm/src/xdr_base.c > to gfs-kernel/.../xdr_base.c > > Seems like those problems do not only affect gcc4, but also gcc3.3 (at > least the version from debian/sarge) ok. I made the changes and commited them to HEAD&STABLE in the kernel module as well then. -- Michael Conrad Tadpol Tilstra Too many errors on one line (make fewer) pgp1eT6kDmQpV.pgp Description: PGP signature Next Message by Date: click to view message previewRe: A few GFS newbie questions: journals, etcI lowered my votes to 0 and that didn't work for me. Here is my current cluster.conf <?xml version="1.0"?> <cluster name="SAN1" config_version="1"> <cman two_node="1" expected_votes="1"> </cman> <clusternodes> <clusternode name="data" votes="1"> <fence> <method name="manual"> <device name="human" agent="fence_manual"/> </method> </fence> </clusternode> <clusternode name="front0" votes="1"> <fence> <method name="single"> <device name="human" agent="fence_manual"/> </method> </fence> </clusternode> <clusternode name="front1" votes="0"> <fence> <method name="single"> <device name="human" agent="fence_manual"/> </method> </fence> </clusternode> </clusternodes> <fence_devices> <device name="apc1" agent="fence_apc" ipaddr="10.1.1.1" login="apc" passwd="apc"/> <device name="brocade1" agent="fence_brocade" ipaddr="10.1.1.2" login="user" passwd="pw"/> <device name="brocade2" agent="fence_brocade" ipaddr="10.1.1.3" login="user" passwd="pw"/> <device name="human" agent="fence_manual"/> </fence_devices> </cluster> This is the error that I get still. Starting Cluster (ccsd, fence, clvm, gnbd): cluster/sbin/cman_tool: the two-node option requires exactly two nodes with one vote each and expected votes of 1 (node_count=3 vote_sum=2) Am I misunderstanding a step or something. Thanks, Jon Nate Carlson wrote: > On Thu, 30 Jun 2005, Patrick Caulfield wrote: > >> That is right. What you have here is cman correcting an incorrect >> configuration. You've told it to expect only 10 votes but provided it >> with 101 votes. It knows when you're lying to it ;-) > > > But darn it, I *want* to be able to lie to it! :) > >> What you actually have here is a special case of a two-node cluster, >> because there are only two "real" nodes involved. Unfortunately the >> cman "two_node" mode is no use here because it enforces the 2-node >> restriction which would prevent you bringing any VMs online once the >> two real machines were up. > > > I've only got two physical boxes right now, but will be adding 2 more > in the near future (once I migrate all the services off the boxes in > my old colo to the new one.) > >> One little-known feature is that you can set votes to zero (only in >> CCS, not from the cman_tool command-line) which may go a little way >> to helping out. it would, at least, work for 3 or more Xen host nodes >> if all the VMs had zero votes. > > > I'm not sure how that would help - if I lose another physical host, > won't it still lose quorum? But sounds like a good idea anyways - I'll > drop the VM's down to 0 votes. > >> Perhaps we should change "2-node" mode to allow >2 nodes provided the >> extra nodes all had zero votes ? > > > If possible, an option that would let me say "here's the number > required for a quorum, I know I'm lying to you, but do it anyways" > would be nice. :) > > ------------------------------------------------------------------------ > | nate carlson | natecars@xxxxxxxxxxxxxxx | http://www.natecarlson.com | > | depriving some poor village of its idiot since 1981 | > ------------------------------------------------------------------------ > > -- > Linux-cluster mailing list > Linux-cluster@xxxxxxxxxx > http://www.redhat.com/mailman/listinfo/linux-cluster > Previous Message by Thread: click to view message previewRe: A few GFS newbie questions: journals, etcNate Carlson wrote: > On Wed, 29 Jun 2005, Patrick Caulfield wrote: > >> Can you be more explicit please ? When another node comes online it >> should set the expected_votes to be 50 regardless of any manual >> intervention. Is that not what is happening ? > > > Here's relevant snippets from my cluster.conf: > > <cman expected_votes="10"> > </cman> > > <clusternode name="xen1.msp.technicality.org" votes="50"> > </clusternode> > > <clusternode name="xen2.msp.technicality.org" votes="50"> > </clusternode> > > <clusternode name="xen-vm-1.msp.technicality.org" votes="1"> > </clusternode> > > I can bring xen1 or xen2 online without any other nodes online, and get > quorum. Once both nodes are online, though, cman_tool status says: > > Nodes: 2 > Expected_votes: 10 > Total_votes: 100 > Quorum: 51 > > ..so the quorum value is being raised to 51, which is half+1 of > Total_votes, not the Expected_votes (which would be what I'd expect, but > again, I'm a newbie.) That is right. What you have here is cman correcting an incorrect configuration. You've told it to expect only 10 votes but provided it with 101 votes. It knows when you're lying to it ;-) > What I'd really like is a way to lock the quorum > number down to 10 (at all times), so if any physical node is surviving > the cluster will be up. Is there any simple way to do that? What you actually have here is a special case of a two-node cluster, because there are only two "real" nodes involved. Unfortunately the cman "two_node" mode is no use here because it enforces the 2-node restriction which would prevent you bringing any VMs online once the two real machines were up. One little-known feature is that you can set votes to zero (only in CCS, not from the cman_tool command-line) which may go a little way to helping out. it would, at least, work for 3 or more Xen host nodes if all the VMs had zero votes. Perhaps we should change "2-node" mode to allow >2 nodes provided the extra nodes all had zero votes ? -- patrick Next Message by Thread: click to view message previewRe: A few GFS newbie questions: journals, etcI lowered my votes to 0 and that didn't work for me. Here is my current cluster.conf <?xml version="1.0"?> <cluster name="SAN1" config_version="1"> <cman two_node="1" expected_votes="1"> </cman> <clusternodes> <clusternode name="data" votes="1"> <fence> <method name="manual"> <device name="human" agent="fence_manual"/> </method> </fence> </clusternode> <clusternode name="front0" votes="1"> <fence> <method name="single"> <device name="human" agent="fence_manual"/> </method> </fence> </clusternode> <clusternode name="front1" votes="0"> <fence> <method name="single"> <device name="human" agent="fence_manual"/> </method> </fence> </clusternode> </clusternodes> <fence_devices> <device name="apc1" agent="fence_apc" ipaddr="10.1.1.1" login="apc" passwd="apc"/> <device name="brocade1" agent="fence_brocade" ipaddr="10.1.1.2" login="user" passwd="pw"/> <device name="brocade2" agent="fence_brocade" ipaddr="10.1.1.3" login="user" passwd="pw"/> <device name="human" agent="fence_manual"/> </fence_devices> </cluster> This is the error that I get still. Starting Cluster (ccsd, fence, clvm, gnbd): cluster/sbin/cman_tool: the two-node option requires exactly two nodes with one vote each and expected votes of 1 (node_count=3 vote_sum=2) Am I misunderstanding a step or something. Thanks, Jon Nate Carlson wrote: > On Thu, 30 Jun 2005, Patrick Caulfield wrote: > >> That is right. What you have here is cman correcting an incorrect >> configuration. You've told it to expect only 10 votes but provided it >> with 101 votes. It knows when you're lying to it ;-) > > > But darn it, I *want* to be able to lie to it! :) > >> What you actually have here is a special case of a two-node cluster, >> because there are only two "real" nodes involved. Unfortunately the >> cman "two_node" mode is no use here because it enforces the 2-node >> restriction which would prevent you bringing any VMs online once the >> two real machines were up. > > > I've only got two physical boxes right now, but will be adding 2 more > in the near future (once I migrate all the services off the boxes in > my old colo to the new one.) > >> One little-known feature is that you can set votes to zero (only in >> CCS, not from the cman_tool command-line) which may go a little way >> to helping out. it would, at least, work for 3 or more Xen host nodes >> if all the VMs had zero votes. > > > I'm not sure how that would help - if I lose another physical host, > won't it still lose quorum? But sounds like a good idea anyways - I'll > drop the VM's down to 0 votes. > >> Perhaps we should change "2-node" mode to allow >2 nodes provided the >> extra nodes all had zero votes ? > > > If possible, an option that would let me say "here's the number > required for a quorum, I know I'm lying to you, but do it anyways" > would be nice. :) > > ------------------------------------------------------------------------ > | nate carlson | natecars@xxxxxxxxxxxxxxx | http://www.natecarlson.com | > | depriving some poor village of its idiot since 1981 | > ------------------------------------------------------------------------ > > -- > Linux-cluster mailing list > Linux-cluster@xxxxxxxxxx > http://www.redhat.com/mailman/listinfo/linux-cluster > Loading Comments...
|
|
