Load balancing both the SP and IdP

[Martin, Andrew J.]

Brian,

We're in a similar situation in that we want high availability, but we haven't been able to take the time to work out the clustering aspects of Shibboleth.

So - in our environment, we came up with a compromise:

We use a BigIP F5 Load balancer to define a pool of two IdPs with identical configurations. However, rather than it being truly load balanced, we configured the F5 pool to always prefer one box, assuming that one box is up. If not up, the F5 will fail over to the alternate node within a few seconds.

The most important part is that only one Shibboleth IdP is receiving requests at once, which resolved the "stickiness" issues you mentioned. It also makes upgrading a snap since we can test new upgrades and configurations on the "passive" node without necessarily affecting production.

This has worked pretty well for us, though at some point we'd still like to move to the clustering options you mentioned. While I wouldn't recommend this over proper clustering, it may be better than having just a single node.

-Andy

-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Brian Reindel
Sent: Tuesday, October 22, 2013 8:06 PM
To: Shib Users
Subject: Re: Load balancing both the SP and IdP

Okay, that is good to know. I did review the clustering documentation, 
and we are considering a few options, but mostly the memcached storage 
service. For launch if we don't have the clustering situated then we may 
not load balance the IdP and just stick with it on one server since we 
have lower traffic volume.

Thanks again.


On 2013-10-22 15:07, Cantor, Scott wrote:
> On 10/22/13 4:52 PM, "Brian Reindel" <brian at reindel.com> wrote:
> 
>> We run an enterprise SSO solution where the SPs are load balanced and
>> the IdP is also load balanced in production. I've been reading up on
>> the stateful aspects of the Shibboleth IdP, and we're trying to 
>> figure
>> out the required configuration details. We often refer to the
>> stickiness as it pertains to the user's browser session. However,
>> isn't there communication that happens in the SP client (SOAP
>> requests) that require stickiness as well?
> 
> No. The only stickiness would involve an impossibility, guaranteeing 
> that
> the client and the SP were talking to the same box. That's the only 
> way at
> present you could put artifacts in memory and make them work, and you
> can't do that because those are two different "clients".
> 
> The IdP clustering material addresses all of the functional issues 
> arising
> from the different choices, the SP doesn't enter into it.
> 
> -- Scott
> 
> 
> --
> To unsubscribe from this list send an email to 
> users-unsubscribe at shibboleth.net
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net