| 1 |
On Mon, 2009-05-18 at 14:39 -0500, Brian Kroth wrote: |
| 2 |
|
| 3 |
> Since 2.6.26, OCFS2 has two cluster stacks available to it: |
| 4 |
> - ocfs2_stack_o2cb: which is the original stack |
| 5 |
> - ocfs2_stack_user: which is the one that requires cman and openais |
| 6 |
|
| 7 |
oh, I missed it completely. |
| 8 |
I'm using the first one :) |
| 9 |
|
| 10 |
> > Yes, you're right. The only way I have to get a sort of STONITH (if it |
| 11 |
> > can be used, I've still to check this) is IPMI which is working well so |
| 12 |
> > far. |
| 13 |
> |
| 14 |
> I believe that will work just fine. |
| 15 |
|
| 16 |
hoping so, after a quick search I've seen IPMI agents for heartbeat and |
| 17 |
for fenced. |
| 18 |
|
| 19 |
> > The problem is that a node will use (mount) some LVs and the other one |
| 20 |
> > some others. So I can't do the fast way as you suggest, as I need to |
| 21 |
> > stop all services that use data on LVs before unmounting. |
| 22 |
> |
| 23 |
> But, with OCFS2 you can (even temporarily) have a single node mount all |
| 24 |
> the LVs, move your service IPs over, and _then_ umount and stop them on |
| 25 |
> the other one while you do your changes and then remount them all. |
| 26 |
> That's the great things amount a clustered fs - more than one node can |
| 27 |
> play in the sandbox without problems. |
| 28 |
|
| 29 |
Uh, that can be an option. It seems even a scriptable work, with a bit |
| 30 |
of effort and error-checking, but it seems doable in the end. Will check |
| 31 |
that, thanks. |
| 32 |
|
| 33 |
> Also, I'm gonna put a plug in for Heartbeat [1] for service management. |
| 34 |
> It's much more powerful than rgmanager in my opinion. If you're dead |
| 35 |
> set on using the openais cluster stack you can also use pacemaker [2]. |
| 36 |
>The model I typically use for Heartbeat, is to have it run a couple of |
| 37 |
> dummy monitoring scripts as resource agents clones that each set an |
| 38 |
> attribute as to the service's health on a machine. Then using the value |
| 39 |
> of that attribute I setup rules to move service IPs to the "healthiest" |
| 40 |
> node, where your definition of "healthiest" is completely dependent upon |
| 41 |
> your monitoring scripts. |
| 42 |
> |
| 43 |
Again, thanks for the pointers. Expecially pacemaker of which I did not |
| 44 |
know the existence. |
| 45 |
|
| 46 |
Giacomo |
Archives