On 4/5/07, Trevor Dell <[EMAIL PROTECTED]> wrote:
I was needing to set up Sun Ray servers in two different cities and
needed the LDAP sync'd between the two sites.
Been working on finding a way to do this, and I started out by dusting
off the old SDS documentation. I was just gonna set up each site in a
separate FOG, then just configure SDS to replicate from a single master.
That should work, but it wouldn't be a supported configuration.
You'd get warnings from utreplica when you set it up but you
can ignore those.
Then I thought what would happen if I set up the 2 sites (4 servers) in
the same FOG knowing multicast packets between sites would be dropped.
I've been doing some testing to emulate the environment. I don't know if
SRSS operates like this on purpose, but everything actually just works
like it should. The LDAP replicates just fine of course. The beautiful
thing is when you do a utgstatus, the server doesn't even see the
members of the other site. So the FOGs work like they should in each
location seeming independent of each other. (Just for fun I tested
utswitch to see if I could hop sites, and it works!)
From what I can tell there shouldn't be any issues setting up a FOG in
this manner, anyone know anything that would say otherwise?
It should be OK. I'd be slightly worried about the availability
of the Data Store primary but that's because of the distance,
nothing to do with having one group or two. If the networking
between the sites is solid and has plenty of bandwidth then it
shouldn't be a problem.
Obviously both sites need to be able to trust each other to not
do anything to the DS that will break the other site.
You don't have to worry about admin activities at one site
accidentally spilling over to the other site because the admin
tools discover their potential in-group remote admin targets
the same way that utgstatus does. The downside is that
because admin activities will not be synchronised you'll have
to manually take care of things like restarting SRSS on the
remote machines after making DS changes that require a
group-wide restart. Those are rare.
OttoM.
__
ottomeister
Disclaimer: These are my opinions. I do not speak for my employer.
_______________________________________________
SunRay-Users mailing list
[email protected]
http://node1.filibeto.org/mailman/listinfo/sunray-users