Recommended clustering configuration

[Peter Schober]

* Brian Mathis <brian.mathis at gmail.com> [2016-05-12 22:05]:
> How I generally approach clustering for a web app is to have multiple
> nodes running an application, with nodes behind an haproxy load
> balancer that handles status checking and sticky sessions to ensure
> users go back to the same node.  The database (LDAP in this case) is
> somewhere else and has its own clustering, so not a concern here.
> This provides a resilient setup that is still relatively simple.

Well, you're distributing load (requests) across nodes and once a node
fails requests would be routed to a different not, and the subject
would lose their session. For the general case and nodes being down
the exception that's probably OK. (If you do rapid/frequent
redeploying and tear down / recreate nodes that may not be acceptable
without clusting the sessions for the web applications themselfs.)

> It seems that Shibboleth IdP would work in this kind of setup, but
> I'm still unclear on some things.

The issue with running several IDPs in such a way -- without taking
any extra steps -- is that in some deployments (maybe not yours!)
"back-channel" requests are beign used, where the accessed SP makes a
direct connection to the IDP. At that point your haproxy has no idea
what IDP node to route the request to, as the request from the SP does
not have the subject's browser's HTTP cookie.

The Shibboelth IDP provides methods to work around most of the issues
that do NOT require clustering of IDP sessions, i.e. requests landing
on the wrong node can stil complete successfully.

Only if your deployment depends on the corner-cases that are not
covered by these methods (SLO mostly, Artifacts even less likely)
would you need to look into clustering.
-peter