Cluster formation

[Daniel Fourie]

Hi

I have got a sticky situation regards to security between nodes in the same cluster.

I have got a 10 to 1 node cluster but each node participating in the cluster is on its own subnet/network. The HB network connects all nodes including the failover node togeather on a layer-2 enviroment hence allowing a user to telnet from one node to the other accessing different subnets hence breaching security.

On the other hand the 1 failover machine needs to cater for all the other nodes in the cluster, making this node {failover} accesing all other nodes via rlogin,rcp and so on.This is achived by configuring vlan cards on the failover node and assigning these cards a valid IP for that subnet so that in the event of disaster the packages configured in the cluster can attache that package IP {multiplexed} on the correct IP/Card/VLAN (802.1q). Now the problem with this is that if a hacker gains access to the failover node he has got access to all other subnets thru there respective nodes, cause the failover node connects all other subnets togeather on a layer-2 perspective.

How do you prevent this, or how do you change the cluster design to tie down on security.

[Steven E. Protter · Accepted solution]

When a package fails over from one node to another, the IP address goes with it.

This would be a feature then.

careful use if /var/adm/inetd.sec

should allow you to prevent access to parts of your network that you don't want access to.

My understanding sitting in SG class right now is that when connected to the package, if you go to the failover node, your IP address does not change, therefore your network access should not change either.

You may want to prevent failover to the node in question to prevent this. failover is an option, not a requirement. Perhaps failover to a better configured node.

SEP

[Rita C Workman]

Well, interesting.

You actually can fail a package to a different subnet. I know what the book says and class says...but that is exactly what you do in a Continental Cluster. We achieved this reasonably efficiently by setting our resolution to pkg name. So when we failover to the other site (or for that matter to another node locally first) it resolves based on DNS to the pkg name... for example. Locally it's automatic no changes to anything required. But since CC is strictly a manual to failover to the other subnet we simply change 1 line in our /etc/host file on the DR site node, then use the hostfile to update DNS from there...and voila ! Pkg can now be resolved. It's worked for us.

But you have circumvented things by setting up multiple subnets on various vlan cards. So the only thing I can figure is what Steven mentioned...you would have to go and try to establish some security via ~/inetd.sec and then re-do it everytime there is a failover.

[Daniel Fourie]

Hi

Thanks for the great information, but to clarify how these nodes are laid out please see attached image. Note that some nodes are missing from the image, and that every node in this cluster is on a different subnet.

Question 1: What is required from a network connectivity's perspective to form a cluster [ no packages involved ] meaning, do I need layer-2 connectivity to all nodes in the cluster and so on.

Question 2: Is there a better way of doing this implementation then what I have done so far. Especially on behalf of the failover nodes vlan setup. Can I implement this cluster in a different way so that I have a higher level of security.

PS: All will receive 10's for the great information supplied.

[Stephen Doud]

Ques 1 - SG must "see" every node in the cluster. This requires layer 3 (IP) subnetting, and layer 2 (DLPI capability).

Quest 2 - quite a complex network implementation... consider network consultant?

-SD-