I was discussing with a customer few days ago regarding how to deploy OpenAM optimally on Amazon Web Services. One topic which we discussed in-depth was how does OpenAM session work and why do OpenAM nodes need to be aware of one another.
ForgeRock documentation has a lot of information regarding how the Core Token Service (CTS) works and how performance is optimised when Reduced Crosstalk is enabled.
However, the documentation did not mention much about any activity besides sessions validation via cross-talk.
Our discussion that day was : "What is the other usage(s) of crosstalk? Can we remove crosstalk totally as we scale up/down frequently in AWS environment? If not, what happens when an OpenAM node is removed from site? Will crosstalk becomes the performance bottleneck in "non-locatable" OpenAM situation? "
Luckily, as what Peter has mentioned in his blog, Cluster State Service is here to help.
Monitoring servers
As we already know, under normal circumstances OpenAM uses crosstalk when requests gets misrouted, and this is something that does not change once session failover is enabled. Although the sessions are stored in OpenDJ, OpenAM will remain to send crosstalk requests to the other instances (in essence, this behavior is what the reduced crosstalk mode attempts to change).
In case of session failover it doesn’t really help if AM waits on crosstalk response from a node which may be actually unavailable. In order to prevent this scenario, there is a component that gets automatically enabled once session failover has been enabled: the ClusterStateService (or CSS as I’d like to call it). The ClusterStateService essentially tries to monitor the servers within the current site (and since 12 it also monitors remote site URLs), so that if there is a need to do a crosstalk, OpenAM first checks with ClusterStateService whether the given node is available, before sending any kind of crosstalk request.
Great stuff!
PS: Peter has started using diagrams in his blog! Keep it up! :)
.
Thanks for the pingback :)
ReplyDeleteThe biggest enemy of autoscaling OpenAM is the server/site setup and its relation with the sessionservice. As you now should know the server IDs and the site IDs are embedded into the session IDs are validated/processed with each request, hence scaling down can cause problems if you are also decommissioning the OpenAM servers from the server/site configurations. In those cases the session ID will suddenly become invalid which is probably not wanted.
OPENAM-480 is the other biggest enemy of autoscaling, but fortunately that one is currently targeted for the 13.0.0 release, so if everything goes well autoscaling won't be that hard in the close future.
Oh yes, I totally missed out the restarting of OpenAM server. Thanks for reminding. Will add restarting as one of the autoscaling step for now. Painful though. :)
ReplyDelete