RHEL Cluster Suite

[Alzhy]

In a bid to get GFS (to compare with Oracle's OCFS2) -- I noticed that to have GFS on a RHEL system, Cluster Suite is a pre-requisite.

I've installed all the software groups and am about ready to configure via "Conga".

Questions:

* My LUCI node (Conga Mgmt) - can it be one of the nodes?
* What Fence Device should I configure - is it absolutely necessary
* Do I need a "private" (heartbeat) network?

I am still reading through docus and would like to get some tips/feedback from those who've already implemented this.

TIA!

[Matti_Kurkela · Accepted solution]

* My LUCI node (Conga Mgmt) - can it be one of the nodes?

It *can* be, although if that node is down for maintenance or because of hardware failure, you won't be able to access the Conga management interface.

If you want to do this, consider installing LUCI on all nodes - if your primary admin node fails, it will be reasonably easy to establish LUCI control using some other node.

* What Fence Device should I configure - is it absolutely necessary

Yes, it is necessary. It is the ultimate guarantee against data corruption in case one node loses other connectivity with the rest of the cluster. If you have fault-tolerant heartbeat connections, your cluster may never need to actually *use* fencing - but when building a cluster, you should be planning for the worst.

Your choice of Fence Devices depends on what hardware you're using to run your cluster. If you use HP Proliant hardware, iLO power-switch fencing is the obvious choice. If you have supported SAN switches, you might use SAN fencing. If you have three or more nodes and your storage system supports SCSI persistent reservations, you might use that as your fencing method. If your nodes are Virtual Machines (Xen, VMware or whatever), you can use VM fencing.

If one node in a GFS cluster becomes unreachable, all nodes will stop accessing GFS filesystems until it's known for sure that the unreachable node won't perform any writes. This is necessary, because an unreachable node would be unaware of any GFS locks held by any other node, and vice versa. The locks are essential for GFS filesystem integrity.

If the cluster cannot get positive confirmation that the unreachable node has been fenced out, your GFS filesystem will remain frozen, and your cluster will be no more fault tolerant than a single host.

* Do I need a "private" (heartbeat) network?

RedHat Cluster Suite uses IP Multicasts for heartbeat. There is no requirement that the heartbeats should be isolated to a private network, although you can do it if you wish.

It's more important for the heartbeat network to be fault-tolerant than to be isolated from any other traffic.

MK

[Alzhy]

Thanks Matti... I actually found that RHEL docu on Fencing.

[Alzhy]

Matti..
Managed to set up my 2 node cluster... Also have LUCI installed on both, etc... One node is where I set up the CLuster. When I try to access LUCI on the other node -- I don't see my cluster at all.. Anything I am missing?

[Steven E. Protter]

Shalom,

* My LUCI node (Conga Mgmt) - can it be one of the nodes?
Yes.

* What Fence Device should I configure - is it absolutely necessary
Yes. Absolutely necessary. HP server with iLo works good. The APC power supplies are little harder on the hardware but less prone to iLo problems.
* Do I need a "private" (heartbeat) network?
No. But it is helpful.

SEP
102 from Linux Mount Olympus with a penguin on top.

[Matti_Kurkela]

The LUCI on the node you used to set up your cluster won't automatically replicate its configuration to the other node.

When you need to use LUCI on the "other" node, you will have to use its "Add existing cluster" function to take over the cluster management.

Hmm... perhaps it would be possible to find the necessary certificates and/or other files on the primary LUCI setup, and copy them to the other node. I haven't tried this.

MK

[macosta]

I cannot comment on GFS+ClusterSuite specifically, but for clustering packages, the private network is not always just for heartbeat. In some cases (I *think* GFS/CS is one of them,) there is a DLM (Distributed Lock Manager) process that arbitrates disk I/O to keep nodes from stepping on each other - in some cases, the cluster also uses the designated "private" network for lock traffic, and should be reserved for low-latency operations.