OK that's clear. So if I have this scenario say: eth0 - To be a Storage network with subnet 192.168.1.0/24 (back to back network) eth1 - Fence network 192.168.2.0/24, local network between nodes and used for the fence devices. eth2 - Main Internal network on which services will be provided by the cluster (say 10.1.1.0/24). I'd also like to manage the network from a remote luci or a luci running on another system on the main network. If I have as a hosts file node1-sn 192.168.1.1 node2-sn 192.168.1.2 node1-fn 192.168.2.1 node2-fn 192.168.2.2 node1 10.1.1.1 node2 10.1.1.2 I'm presuming I'd have to set the machine's hostnames to "node1-sn" and "node2-sn", and these names in the "<name...>" in cluster.conf to get all cluster comms to go on eth0? Then set altname to "node1-fn" and "node2-fn" for backup comms to be on the fence network or "node1" for backup comms (ring1) to be on the main network. Am I good so far? But this seems pretty ugly, as firstly the hostnames are node1-sn which means that they won't match the main network's DNS entries (forward and reverse) (which would sensibly be node1 and node2 as per the hosts file above to be consistent). Maybe not a big issue on Internet application, but it will complicate things like Kerberos authentication to the nodes (SSH login to nodes via host/ keys). And I'm concerned breaks a centralised luci from my main network (as Corey was asking). The only thing I can think of is to run a luci on every cluster and hopefully I'll be able to connect to it from the main network. But all seems a bit nasty. Is this all I can do? Is there no way of saying, well my cluster nodes are node1 and node2 but I'd like to use these IP's for comms to these nodes. Or maybe there is some nastiness I can do with domain search orders. Thanks again Colin On Sat, 2010-11-20 at 13:01 +0000, Digimer wrote: > On 11/20/2010 05:41 AM, Colin Simpson wrote: > > > > > > > > > > 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. > > > > So how do you force cluster comms to a private network in > cluster.conf > > if the the hostnames are still the main network names? > > I use three interfaces; > > eth0 = private back-channel network w/ fence devices. Hostnames (uname > -n) resolve to this interface's IP (thus being ring 0) > > eth1 = private storage channel. Entries in /etc/hosts with ".sn" > suffix > resolve to this interface's IP address. This is used with > <altname...>, > thus, is ring 1 > > eth2 = Internet facing network. During setup, these have hostnames in > /etc/hosts with ".ifn" suffix resolving to IP addresses on the > internet > polluted network and have nothing cluster related on them. > > > I suppose also as I've never seen any reference to ring numbers in > > cluster.conf itself. > > <name ...> = ring 0 > <altname ...> = ring 1 > > > Thanks > > > > Colin > > Hope that helps. :) > > -- > Digimer > E-Mail: digimer@xxxxxxxxxxx > AN!Whitepapers: http://alteeve.com > Node Assassin: http://nodeassassin.org > > This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify the sender and delete the original. -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
