looking for thoughts on IDP deploy architectures

Simon Bright simon.bright at e2bn.org
Tue Feb 19 11:37:55 EST 2013


I'm not sure what constitutes high throughput - we have a maximum of about 250 sessions per hour. 

Our IDP and LdAP server and SP are virtualised containers on an OpenVZ cluster. The containers can be migrated to a different cluster host if the host starts running into capacity issues. The containers are compressed and tar'd up every night so if we run into major issues we can destroy/redeploy the servers at will. The IDP and SP config is static so not too much of a problem with deploying from backup, any changes to federation data would be pulled down on startup. 

The LDAP container is backed up but we would miss any delta changes to LDAP users in the event of a complete loss. I'm implementing a replication LDAP server so that we have an up-to-date LDAP database if the master goes down or is lost. I'm looking at adding the replication LDAP into the IDP connector config so that we can round-robin or just failover automatically. 


Simon Bright 
Technical Services Manager 
01462 834588 
07912 853 107 

----- Original Message -----


Over the last few years many of us have seen our Shibboleth IDP 
infrastructure evolve to become part of the core infrastructure, and to 
have the same set of high throughput, high availability, failover 
requirements (including participating in the local Disaster Recovery 
framework) that the more traditional business systems already have. 

We're interested in hearing how other sites are approaching these 
requirements. I've included some points below, and would appreciate 
hearing how others have approached these problems. And please add any 
other info you think may be relevant. 

Thanks in advance! 

high throughput -- traditionally, sites have run clustered IDPs, using 
various approaches to clustering (terracotta, jboss, stateless IDPs, 
etc). A newer approach is virtualization, allowing a site to dynamically 
expand and contract the "size" of the machine running an IDP). Is anyone 
doing that ? 

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 ? 

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. 

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 ? 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130219/6590e4ec/attachment-0001.html 

More information about the users mailing list