privatenet.html

Previous: ? Next: ?

In all of these documents, it is assumed that the master cluster control server (named "master") is configured with its primary ethernet interface set to 192.168.2.1

The 192.168.0.0/255.255.0.0 address space is reserved for allocation by private internets by rfc1918.

We will use this for the cluster to greatly simply just about everything and keep us out of the administrators' hair as well.

For instance, we can do proper domain name reverse mapping with bind when we use a private IP name space since we can assume full authority over the IP forward and reverse DNS mappings. Conceivably this could be done with the standard routable IP space, but it would very likely come back in the future to bite you. Having two servers authoritative for the same address space on the same network but with different administrators is a sure recipe for trouble. Asking the DNS administrator of the routable IP space to make configuration changes is impractical, unreasonable and risky. Impractical since development has to stop until a change can be approved and applied. Unreasonable and risky since development requires frequent, experimental changes that could cause chaos to the functioning of the corporate/institutional network. I certainly don't want to be responsible or even to be suspicious of being responsible for whatever problems might turn up. Isolating everything we do to the rfc1918 reserved address space avoids all of those issues as well as giving us the kind of fine grained control we need.

Well tuned and properly configured DNS mappings can greatly increase network performance. For example, proper reverse mappings tremendously speeds up the establishment of tcp/ip connections between hosts. This is a very important consideration for high performance clustered computing.

The rfc1918 reserved IP space also provides us with a protective shield/firewall from the internet. This means we can use rsh between cluster nodes using a host/ip based authentication sheme (using hosts.equiv), essentially a wide open configuration, provided we can keep the physical network we use secure. Since all our machines are on one switch and we can lock the rooms, this is something we can do with a reasonable degree of confidence. Again this gives us a performance advantage; a dramatic increase of speed with both mpi and pvm as compared to using ssh and key based authentication which would be necesary if we did not have the firewall.

We use our own DHCP server to dynamically assign the private IP addresses to the nodes of the cluster.