Hi Curtis,
Sorry if this answer wasn't clear. All LDAP calls are made from
individual array members and not routed through the primary (or any
other single array member).
You are correct here, the main reason SGD recommends LDAP directories
should be mirrored is to ensure user data consistancy when speaking to
any of the LDAP servers.
-- DD
Curtis Cunningham wrote:
Deany,
thanks for your response.
I'd suspect the main reason they want all LDAP servers to be mirrors
of each other is to ensure that some members don't get denied SGD
access if a different LDAP server is spoken to.
This also doesn't really clarify the SGD behavior, i.e. are all
requests made from a single SGD member (the primary is a strong
possibility here I think), or if individual servers make LDAP requests.
Curtis.
Deany Dean wrote:
I'm pretty sure that even though the configuration is distributed
across the array, the LDAP calls are made from individual array
members so, if you have multiple LDAP servers configured in SGD, the
LDAP server that an array member is using may not be the same as other
members of the array. This is one of the reasons why the SGD docs
recommend the all LDAP servers configured for access by SGD are
mirrors of the same directory.
Hope that helps,
-- DD
On Mon, Feb 25, 2008 at 7:29 PM, Curtis Cunningham
<[EMAIL PROTECTED]> wrote:
Thanks Rick.
Customer is using IBM LDAP server for this deployment, so unsure how
open they might be to these options .. they seem to introduce further
complexity/admin /cost overhead I doubt they'd accept.
I'm also curious on the underlying behavior, i.e. do all SGD servers
speak LDAP, or is it just the primary which then proxies results back to
secondaries.
Thanks ..
Curtis.
Rick Butland wrote:
> Hey Curtis,
>
> no expert here, but it seems that something like the Sun
> Directory Proxy service may be able to do what you want -
> http://www.sun.com/software/products/directory_srvr_ee/dir_proxy/index.xml
> - see: http://docs.sun.com/app/docs/doc/820-2493/6ne3feeoa?a=view
>
> Similarly, there are other load-balancing products that are supposed
> to deal with geographically distributed LDAP servers, though these
> tend to be switch-based, so expensive.
> I suppose you could look into some DNS-based trickery, such as having
> each site resolve the LDAP url locally, with a "fixed" backup url.
> Or look at a weighted DNS resolver.
> You'll probably want to have a look at the DSEE Forums for advice on
> this - http://forum.java.sun.com/forum.jspa?forumID=761
>
> Regards,
> Rick
>
>
>
> Curtis Cunningham wrote:
>> Hi experts,
>>
>> IHAC who is deploying a geographically distributed SGD array. We will
>> be associating geographically close SGD servers and application
>> servers in the same "Load Balancing Group".
>>
>> There is a lot of redundancy built into this deployment and as a
>> result there will be duplicated/replicated LDAP servers in each of
>> our locations. I remember that SGD accepts a list of URLs when
>> specifying LDAP authentication, and that the default behavior is to
>> try the first in the list, then if that's not available try the next,
>> etc. From my reading of the admin guide this is still the same in 4.4.
>>
>> Ideally for this customer we would like to associate SGD servers in a
>> location with a local LDAP server in that same location. Is there any
>> other way to do this?
>>
>> Thanks,
>> Curtis.
>>
>
>
--
Curtis Cunningham
email: [EMAIL PROTECTED]
"There are 10 kinds of people in the world, those
that understand binary .. and those that don't"
_______________________________________________
SGD-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sgd-users
_______________________________________________
SGD-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sgd-users
--
Curtis Cunningham
email: [EMAIL PROTECTED]
"There are 10 kinds of people in the world, those
that understand binary .. and those that don't"
------------------------------------------------------------------------
_______________________________________________
SGD-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sgd-users
_______________________________________________
SGD-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sgd-users
