<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <br><p style="color:#A0A0A8;">On Thursday, 24 October 2013 at 10:06:02, Jesse Santana (<a href="mailto://jesse.santana@csulb.edu">jesse.santana@csulb.edu</a>) wrote:</p> <div><blockquote type="cite" class="clean_bq" style="font-family: helvetica; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);"><span><div><div>Our configuration at CSU Long Beach is almost identical to the one Andrew described. The question I have for Andrew is, how do you handle session replication? As our configuration stands today, if one of our IdP's dies, the users bound to that IdP must re-authenticate. How are you avoiding this? I am looking into memcached as a possible solution but wanted to hear your thoughts.<span class="Apple-converted-space"> </span></div></div></span></blockquote></div><p>We have this config for our IdP as well and also operate as described to implement and test changes against the passive node from workstations with modified hosts file. For net reliability, you have to trade off the non-trivial complexity of session replication across nodes against the modest increase in reliability gained. In our case, neither the IdP service nor the platform on which it runs have “died” in the past 4 years (though an incorrect config change once caused an interruption of a few minutes). </p><p>David Bantz</p><div><blockquote type="cite" class="clean_bq" style="font-family: helvetica; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);"><span><div><div><br><br>Jesse Santana<span class="Apple-converted-space"> </span><br>Assistant Director - Enterprise Systems and Servers<span class="Apple-converted-space"> </span><br>CSU Long Beach - Network Services<span class="Apple-converted-space"> </span><br>1250 Bellflower Blvd.<span class="Apple-converted-space"> </span><br>Long Beach, CA 90840<span class="Apple-converted-space"> </span><br>(562)985-8511<span class="Apple-converted-space"> </span><br><br><br>-----Original Message-----<span class="Apple-converted-space"> </span><br>From: users-bounces@shibboleth.net [mailto:users-bounces@shibboleth.net] On Behalf Of Martin, Andrew J.<span class="Apple-converted-space"> </span><br>Sent: Thursday, October 24, 2013 10:51 AM<span class="Apple-converted-space"> </span><br>To: Shib Users<span class="Apple-converted-space"> </span><br>Subject: RE: Load balancing both the SP and IdP<span class="Apple-converted-space"> </span><br><br>We have a "master" virtual IP address in our F5 load balancer that hosts the pool of Shibboleth nodes. That's the actual service URL that's used everywhere. As I mentioned before, when we address Shibboleth through the "pool", only one server is considered active and will respond at a time.<span class="Apple-converted-space"> </span><br><br>However, we also have our load balancer set up so that we can address nodes individually from certain administrative VLANs. This has come in handy for monitoring the IdP status of each node from something like SCOM. If I want to test against the passive node, I'd simply use my workstations' local hosts file to repoint the shib service hostname to instead refer to the accessible IP address of the passive node, as opposed to the F5 pool (of all servers). As long as I test with the workstation with the modded 'hosts' file, I can direct my requests to the 'passive' node while everyone else is still pointed to active.<span class="Apple-converted-space"> </span><br><br>There may be some scenarios where this isn't ideal, but it's worked for testing most of my integrations. Just remember to clean up your hosts file when you're done, or you may be confused why things resolve incorrectly later...<span class="Apple-converted-space"> </span><br><br>-----Original Message-----<span class="Apple-converted-space"> </span><br>From: users-bounces@shibboleth.net [mailto:users-bounces@shibboleth.net] On Behalf Of Kevin P. Foote<span class="Apple-converted-space"> </span><br>Sent: Thursday, October 24, 2013 12:06 PM<span class="Apple-converted-space"> </span><br>To: Shib Users<span class="Apple-converted-space"> </span><br>Subject: Re: Load balancing both the SP and IdP<span class="Apple-converted-space"> </span><br><br><br>On Thu, 24 Oct 2013, Tom Zeller wrote:<span class="Apple-converted-space"> </span><br><br>>> It also makes upgrading a snap since we can test new upgrades and configurations on the "passive" node without necessarily affecting production.<span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>> Just curious what criteria you use during testing to select a node. IP address ?<span class="Apple-converted-space"> </span><br><br>Sorry not the OP ..<span class="Apple-converted-space"> </span><br><br>Most ADCs or Loadbalancers allow you to select a specific node or pool of nodes depending on incoming criteria.. so yea IP of originating request is pretty simple.<span class="Apple-converted-space"> </span><br><br>So for me when testing / upgrading. I enable a rule that says if my workstation is accessing the IdP service go to this particular node or pool that is defined on the ADC.<span class="Apple-converted-space"> </span><br><br><br><br>------<span class="Apple-converted-space"> </span><br>thanks<span class="Apple-converted-space"> </span><br>kevin.foote<span class="Apple-converted-space"> </span><br></div></div></span></blockquote></div></body></html>