on the workstation of the user. Other reasons are braindead license servers
which are not NATable. Like the ones used by Catia or LS-DYNA. Management
could be much easier when the administrator is able to contact every device
directly from his workstation.
I don't agree with the latter, at all. the marginal effort of admining
through another box is trivial.
Oh! I thought NAT worked transparently and the application didnt even
realize it was NAT-ed. I didn't know some servers could have a problem
with this.
a client using NAT will not know any different, but the _talked_to_ service
might, since it'll see multiple connections from the same NAT server
address(es), and won't be able to originate a socket to the client.
(unless the NATer has some protocol-specific awareness like NATed FTP.)
we have all our compute nodes on private addresses and also disable NAT.
this does make it somewhat trickier to get external-hosted evil-type licenses
to work (flexlm with vendor daemons). but I'd say this is a fairly useful
dividing issue: clusters that are all-public tend to be personal-ish and
small. clusters that are larger and support very wide groups tend to be
more tightly controlled. I think the way to think of it is that if you
have a personal or limited-purpose cluster, you _do_ in fact want it to
depend on (and wait on) external resources (licenses, fileservers, GUI apps).
for a large, broad-purpose cluster with lots of disparate users, it's very
important to minimize those sources of complexity and inefficiency.
_______________________________________________
Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
