When I attended the Open Identity Summit, I took away with me a great tip for OpenAM when Steve Ferris presented his OpenAM Survival Tips.
In Production environment for large deployment, sometimes we have to configure multi-sites for customers. (Multiple sites => multiple login URLs)
If I could illustrate with a diagram, the following is the recommended deployment architecture for multi-sites. Each site will point to its own pair of MQ servers.
The reasons are clearly documented:
Multiple-Site configuration
In a multiple-site configuration, two or more OpenSSO Enterprise servers are configured in each site. A multiple-site configuration is useful when you need to centrally manage OpenSSO Enterprise servers located in distant geographical locations. Multiple-site configuration is usually used in WAN environments, or where sites are managed as separate operational units within a LAN environment. Each site can have one or more load balancers.
While system failover can be configured among all sites in the deployment, session failover is possible only within each site. WAN environments are subject to speed, network latency, firewall, and bandwidth issues.
For these reasons, OpenSSO Enterprise session failover is not supported across multiple sites within a LAN or WAN environment.
The following are typical reasons to use a multiple-site configuration:
- Close proximity of OpenSSO Enterprise servers in a LAN environment
- Underlying network infrastructure limitations exist.
- Operational domains are managed as independent units.
- OpenSSO Enterprise servers span across network boundaries as in the case of a WAN environment.
Why is it so? What's the problem technically?
It is due to the way Database URL list is keyed in for a site.
The following diagrams show what is happening behind the scene. All OpenAM instances will attempt to connect to the 1st MQ server in the Database URL list. If an OpenAM instance happens to be in another data-center from the 1st MQ server, no luck! It will still attempt to connect to it via WAN.
This, of course, causes latency and subsequently performance degradation. As such, session failover across WAN is never supported, even if you have a subscription from Oracle.
Well, not if you have a valid ForgeRock subscription. There is now an AM patch available for ForgeRock customers.
And thus, the following architecture is now made possible!
.
Hello,
ReplyDeletethe link to the openam-survival-tips is broken and I was not able to find it by searching on slideshare
they changed the URL. I have updated the link. Try again
DeleteWhat I did before is to spoof the session db hostname in the secondary site in its own /etc/hosts to point to its own session db. (provided there's no session sycnronization needed between sites, like for disaster recovery)
ReplyDeleteKnowing about this "paid" patch, probably know why for the disappearance of the multi-site support in the roadmap for 10.2.
ReplyDeleteFor the new session DB model using OpenDJ (starting 10.1), it was in roadmap to support multi-site in 10.2
See version 68 or before of the roadmap
https://wikis.forgerock.org/confluence/pages/viewpage.action?pageId=21758147.
But was removed probably to only provide patch for support subscribers?
I do not think it's a commercial thingy here. Most probably, some technical issue with OpenDJ sync. I'm just guessing here.
Delete