looking for thoughts on IDP deploy architectures

[Peter Schober]

* Steven Carmody <steven_carmody at brown.edu> [2013-02-15 20:12]:
> high throughput -- traditionally, sites have run clustered IDPs, using 
> various approaches to clustering (terracotta, jboss, stateless IDPs, 
> etc).

Single node (virtualized on VMware ESX, IIRC) handles it all, easily.
I can ask for details but back when I ran the service it was 2 vCPUs
and 4GB of RAM. +200k active accounts in the system but in January I
see only about 56k unique userids, with <30k logins per day avg.

> high availability, failover -- traditionally, sites have run multiple 
> IDPs behind a load balancer. If an IDP encounters problems, or is 
> undergoing maintenance, it is removed from the pool. Are sites using 
> other approaches to this requirement ?

2 Hardware load balancers in seperate buildings sharing internal state
(run by the networking dept, as they're part of the routers), single
IdP node with hot standby. Looking at OSU's stateless cluster (like
many are, I guess).

> High availability could also extend to services that the IDP may rely 
> on. Authentication (perhaps kerberos) and attribute stores (perhaps 
> ldap) are obvious examples, and are easy to also run with the "multiple 
> server" approach.

Multiple DSAs behind the same 2 loadbalancers mentioned above.
Part hardware, part VMware-virtualized like the IDP nodes and most
central servers at Univie.

> less obvious is if the IDP requires a database (eg for storing
> persistent ID values, or perhaps consent decisions). What approaches
> are sites using to address high availability and failover
> requirements for the DB ?

For other business systems the DBA team runs an Oracle RAC and we
reused that for storing persistentIds there. Otherwise I'd probably
had copied Jim Fox's ingenious way to generate & store persistentIds.
(Won't help for storing consent later on, though.)
-peter