On 11/19/2010 02:46 PM, Colin Simpson wrote:
I'm looking at implementing a RHEL 6 based cluster using DRBD. For this I plan to have a dedicated fast bonded network between the two nodes for the backend DRBD Storage Network (SN), well a 10Gb with a 1Gb failover.
A good plan
Most examples I've seen of doing this seem to use the SN as ringnumber 1 in totem, does it make more sense to be ringnumber 0. I assume this could be accomplished by setting the hostnames associated with SN network IPs as the node names in cluster.conf. And put the altname in as the hostname associated with the main network IPs.
I don't think it matters much, assuming that your cluster communication is also on a private network. I'd sort of argue that the cluster comm network would be quieter and thus less likely to suffer latency which you might see during periods of high disk I/O on your storage network.
My reasons for thinking of doing this are that my SN network will be back to back wired so more reliable than a switch based network but more importantly it's performance will be higher for GFS2 locking etc
For this reason, it is a good one to use, regardless of whether it is ring 0 or 1.
Does this make sense to do (anyone else do this)?
I do this.
Does this make management harder at all say from a central off cluster luci, that the node names are not themselves are not resolveable from the main network DNS (the altname's will be). Any other nastyness that might arise?
When a ring fails, for any reason, it's recovery must be performed manually.
One thing I don't like is the machine hostnames will not be their network DNS names. Would the cluster suite be happy if the hostname of the node matches the "altname" but not the "clusternode name"?
Cluster comm will, iirc, happen on the network resolved by `uname -n`. I'm not certain of this though, as it may be tied to the interface of the active ring.
As a quick aside, I've only played with clustering on RHEL5 before so on RHEL6 does corosync.conf get generated from cluster.conf. If not, what would happen if I hand craft a corosync.conf for doing my config above ?
In RHCS3, corosync.conf should not, and is not used. Everything comes from cluster.conf.
Would this upset things with regards using keeping things the right way around in cluster.conf with regards "clusternode name" and "altname"?
My only real concern is that your SN could get too noisy. Personally, I'd advice making it ring 0 and leaving your names alone. That said, either *should* work.
-- Digimer E-Mail: digimer@xxxxxxxxxxx AN!Whitepapers: http://alteeve.com Node Assassin: http://nodeassassin.org -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
