Story #2331
Identity portal replication
100%
Subtasks
History
#1 Updated by Ben Leinfelder almost 13 years ago
- Assignee set to Ben Leinfelder
With round-robin DNS, each CN needs to have replicas of the cilogon portal information; includes http session and client certificates for authenticated users.
#2 Updated by Dave Vieglais almost 13 years ago
An alternative (certainly less desirable but easily achievable) strategy to consider is to keep the CN portals separate for the time being. RR DNS would direct the user to one CN. The "cn.dataone.org" virtual host would redirect the client to its full host name, say "cn-ucsb-1.dataone.org" where interactions would continue with that host as the base.
The less desirable aspect of this is that revisiting "cn.dataone.org" may direct the user to another CN. However, if the original visit set a cookie in the domain cn.dataone.org that contained the original host (cn-ucsb-1.dataon.org), then the redirect virtual host could redirect to the host listed in the cookie. Thus the user would continue interaction with the original host.
Not perfect by any means, but perhaps a lot simpler than setting up distributed sessions. Less satisfying though.
#3 Updated by Dave Vieglais over 12 years ago
- Target version changed from Sprint-2012.07-Block.1.4 to Sprint-2012.09-Block.2.1
- Position deleted (
3) - Position set to 20
#4 Updated by Ben Leinfelder over 12 years ago
- Status changed from New to Closed
We are using a partial replication strategy now: The DB backing store for certificate transactions and proxy is shared by the three nodes whereas the three nodes have completely independent webapp deployments of the portal and use HZ session replication.
