Re: Private Network for all cluster comms?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Corosync Cluster Engine]     [GFS]     [Linux Virtualization]     [Centos Virtualization]     [Centos]     [Linux RAID]     [Fedora Users]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Camping]

  Powered by Linux