<html><body><div style="font-family: verdana,helvetica,sans-serif; font-size: 10pt; color: #000000"><div>Hi<br></div><div><br></div><div>I'm not sure what constitutes high throughput - we have a maximum of about 250 sessions per hour. <br></div><div><br></div><div>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. <br></div><div><br></div><div>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. <br></div><div><br></div><div><span name="x"></span><div style="text-align: left;" data-mce-style="text-align: left;"><span style="font-size: small;" data-mce-style="font-size: small;" size="2"><span style="font-family: verdana,helvetica,sans-serif;" data-mce-style="font-family: verdana,helvetica,sans-serif;"></span></span>Regards<br></div><br>Simon Bright<br>Technical Services Manager<br>E2BN<br>01462 834588<br>07912 853 107<br><a href="http://www.e2bn.org" data-mce-href="http://www.e2bn.org">www.e2bn.org</a><br><div><br></div><br><span name="x"></span><br></div><hr id="zwchr"><div style="color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;" data-mce-style="color: #000; font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;">Hi,<br><div><br></div>Over the last few years many of us have seen our Shibboleth IDP <br>infrastructure evolve to become part of the core infrastructure, and to <br>have the same set of high throughput, high availability, failover <br>requirements (including participating in the local Disaster Recovery <br>framework) that the more traditional business systems already have.<br><div><br></div>We're interested in hearing how other sites are approaching these <br>requirements. I've included some points below, and would appreciate <br>hearing how others have approached these problems. And please add any <br>other info you think may be relevant.<br><div><br></div>Thanks in advance!<br><div><br></div>high throughput -- traditionally, sites have run clustered IDPs, using <br>various approaches to clustering (terracotta, jboss, stateless IDPs, <br>etc). A newer approach is virtualization, allowing a site to dynamically <br>expand and contract the "size" of the machine running an IDP). Is anyone <br>doing that ?<br><div><br></div>high availability, failover -- traditionally, sites have run multiple <br>IDPs behind a load balancer. If an IDP encounters problems, or is <br>undergoing maintenance, it is removed from the pool. Are sites using <br>other approaches to this requirement ?<br><div><br></div>High availability could also extend to services that the IDP may rely <br>on. Authentication (perhaps kerberos) and attribute stores (perhaps <br>ldap) are obvious examples, and are easy to also run with the "multiple <br>server" approach.<br><div><br></div>less obvious is if the IDP requires a database (eg for storing <br>persistent ID values, or perhaps consent decisions). What approaches are <br>sites using to address high availability and failover requirements for <br>the DB ?<br>--<br>To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net<br></div><div><br></div></div></body></html>