Niki W. Waibel wrote:
actually i am using successfully the following (unsupported) config:
* ray servers with 2 nics (primary: data/nfs traffic, secondary for ray gfx
traffic)
* ray clients directly connected to secondary interface
* ray clients connected over WAN, traffic routed to secondary interface
* none of the ray servers acts as a dhcp server (a separate DHCP server is in
use)
It's critical that you always either use an unrouted interconnect (utadm
-a) or a fully-connected LAN (utadm -A).
ray servers have been configured with
utadm -L on
only. utadm -a and/or utadm -A have never been called.
This is exactly equivalent to calling it with -A, but not assigning
addresses.
The point is that nothing you do with utadm can ever make SRSS work with
a routed, isolated network.
If it's isolated but not routed, then utadm -a can help you. Otherwise,
you're out of luck I'm afraid.
If you try to configure an isolated network (i.e. such that your primary
interface can't reach it) with Sun Rays, and either it's routed or you
neglect to configure it as an interconnect, your topology will not
function properly.
load balancing or AMGH, as you mention it below. the only workaround i found
was to translate/NAT the IPs of the primary interface to the secondary
interface on an external gateway. that is what i'd like to avoid.
Right. I suppose you might also get away with source routes for every
server, on every server, that tell it that the way to get to the primary
subnet addresses are via the secondary subnet addresses.
I've never tried that, but it might work.
rays directly attached to the secondary interface have no problem. the ray
servers will answer requests from the rays sent over the secondary interface to
the IP of the primary interface.
Right. Your trouble comes with the Group Manager (FOG-related)
operations like load balancing and AMGH.
That said, if you do route your two subnets together, the vast bulk of
traffic (e.g. all the rendering) will remain on your secondary network.
Initial rendezvous, such as for load balancing or AMGH, will occur on
the primary interface.
right. that's what i've been seeing, and i feel it is a bug (load balancing or
AMGH over primary interface).
how does the ray server know/decide which interface is the primary?
it should be possible to tell the ray services to which IPs they shall binds
the ports ...
Without complete knowledge of which IPs are reachable from which other
IPs, that wouldn't help. You could have any number of isolated
networks, each partially routable but unreachable from other subnets.
It's a nightmare. OTOH, the CR I mentioned, which unfortunately isn't
externally viewable, is suggesting that the Group Manager use its
knowledge of the FOG (it knows all of the IP addresses for each server
in the FOG) and extend the redirect protocol to specify multiple IPs
(i.e. all the IPs known for the host in question), and let the DTU
choose one that it's directly connected to, if one exists. Even that's
not going to be sufficient in a sufficiently wacky network topology
(e.g. a bunch of disconnected networks consisting of multiple subnets
each), but it should work for what most people appear to be doing.
-Bob
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
