I feel like I am beating a dead fish (and I apologize), but I am still have
clustering issues. I have been able to devote much more time to testing this
and am still stuck.  I wanted to give a detailed explanation as to what I am
doing and our setup so that maybe someone will be able to help.  I really
appreciate the time and effort spent trying to help me out.  I am really
struggling to get this setup and it is being a major problem for our
University.  I appreciate any help that anyone can provide.

*Environment*

   - 2 CAS servers (tomcat with apache)
   - CAS version 3.3.1
   - Hardware load balancer with sticky sessions enabled
   - SQL server database for service and ticket registry
   - IIS web server
   - ASP.NET web application using the DotNetCasClient from the JASIG
   website/wiki
   - CAS is configured to NOT store webflow in the session but to store it
   in the REQUEST; per Scott’s instructions (
   
http://www.nabble.com/Reconfiguring-Spring-Web-Flow-to-store-its-information-as-part-of-the-request-td25664749.html)
   I modified cas-servlet.xml to include:

<flow:executor id="flowExecutor" registry-ref="flowRegistry"
repository-type="client">

                                <flow:execution-attributes>

                                                <flow:alwaysRedirectOnPause
value="false"/>

                                </flow:execution-attributes>

                </flow:executor>

   -  I have NOT replicated tomcat session information using multicast

*Situation Information*

   - We have written an application on our CAS servers that tells us which
   server we are on when we are going though the load balancer’s name. (i.e.
   going to http://cas.university.edu/cgi-bin/server will tell me either
   cas1.university.edu or cas2.university.edu
   - Using this I was able to find that my computer had affinity to cas 1
   and the web server (I logged in and used a local browser) had affinity to
   cas 2

*[image: scenario.png]
*

*
*

*Web Application Test*

   1. In my browser I go to http://server.university.edu/CasTest
   2. Application CasTest has been CASified and redirects my browser to
   
https://cas.university.edu/cas/login?service=http://server.university.edu/CasTest
   3. I log into CAS
   4. CAS validates my credentials and redirects to
   http://server.university.edu/CasTest?ticket=ST-XXXXXXXXXXXXXX-cas
   5. CasTest sees the ticket and tries to validate it at
   
https://cas.university.edu/cas/serviceValidate?service=http://server.university.edu/CasTest&ticket=ST-XXXXXXXXXXXXXXX-cas
   6. CasTest gets a response of INVALID TICKET ticket
   ST-XXXXXXXXXXXXXXX-cas not recognized

* Manual Test*

With the same CAS affinities as before I did the following:

   1. From my browser went to
   https://cas.university.edu/cas/login?service=http://www.university.edu(where
this is a static page so that I can get the ticket from the query
   string)
   2. I logged in to CAS and was redirected to
   
http://www.university.edu?ticket=ST-XXXXXXXXXXX-cas<http://www.university.edu/?ticket=ST-XXXXXXXXXXX-cas>
   3. I ran a query in the serviceticket table of the database and confirmed
   that there was a ticket with id of ST-XXXXXXXXXXXXXXXX-cas
   4. I copied the ticket to the clipboard, remotely logged into the web
   server, opened a browser, and went to
   
https://cas.university.edu/cas/serviceValidate?service=http://www.university.edu&ticket=ST-XXXXXXXXXXXXX-cas
   5. The browser displays
   
https://secure.byui.edu/cas/serviceValidate?service=http://www.byui.edu&ticket=ST-XXXXXXXXXX-casin
the address bar and the page says INVALID_TICKET, ticket
   ST-XXXXXXXXXX-cas not recognized
   6. I went back to the database and verified that ST-XXXXXXXXXXX-cas was
   no longer in the serviceticket table since it had been attempted to be
   validated

* Questions*

   1. I have tried to follow guidance from
   http://www.ja-sig.org/wiki/display/CASUM/Clustering+CAS (except that I
   did NOT setup session replication) and from my questions in
   http://www.nabble.com/CAS-Clustering-Problem-td25573142.html (where Scott
   & Marvin say that I shouldn’t need session replication) but I am still
   having problems.  What have I configured incorrectly?
   2. If there doesn’t seem to be anything configured incorrectly, what is
   going on with these test scenarios?  Why does the ticket get inserted
   into the database by CAS 1, fails validation on CAS 2, yet is deleted from
   the database by CAS 2?
   3. Would session replication make things work correctly?



On Tue, Sep 29, 2009 at 7:20 PM, Scott Battaglia
<[email protected]>wrote:

> On Tue, Sep 29, 2009 at 5:35 PM, Ryan Andreasen 
> <[email protected]>wrote:
>
>> I have been able to do more testing (finally).  I have developed a VERY
>> simple ASP.NET web application that uses the DotNetCasClient out of the
>> box to CASify the application.  With only one server in our cluster (behind
>> the load balancer name) things work correctly.  As soon as we add in the
>> other server things do not work and I get an unrecognized ticket in the
>> response to validate the ST.  In troubleshooting I went into the database
>> that is behind our two CAS servers and tried to find the ST that was sent
>> back to my application.  It was not in the database!  (Which explains why
>> the other server couldn't find it to validate it.)  I removed the other
>> server out of the cluster and ran the same test.  The ticket validated,
>> however, it again was NOT in the database.  This made it look like the cas
>> server was validating the ticket (in memory?) since it was the one that
>> granted it, but it still hadn't written the ticket to the database.
>>
>
> If its not in there, it was validated (or at least it failed validation).
> Can you make sure the validation was successful? (It should say in the
> logs).
>
>
>
>
>>
>> I thought that I must have somehow turned off the JPATicketRegistry in my
>> spring config and deployerConfigContext files; I looked but it was still
>> configured.  So I ran just a normal test through my browser by going to
>> https://server.domain/cas/login?service=http://www.server.edu.  I logged
>> in, got redirected to the static html page and grabbed the ticket from the
>> url.  This ticket WAS in the database!  I am going to look into this more,
>> but I thought I would post my discovery here in case someone might have an
>> idea as to why some tickets are being persisted and others are not.
>>
>> Oh, I checked the cas.log and the catalina logs on the server, no errors
>> were recorded.  Any thoughts on what might be going on would be greatly
>> appreciated.
>>
>> On Fri, Sep 25, 2009 at 1:16 PM, Scott Battaglia <
>> [email protected]> wrote:
>>
>>> We're currently running two Sun T5120 servers in an active-active
>>> scenario.  Each server holds one instance of CAS and one instance of
>>> memcached-patched-as-repcache.  We've disabled Web Flow sessions so our CAS
>>> instance requires no Tomcat sessions.
>>>
>>> We're currently deployed behind a Cisco Content Service Switch but moving
>>> to their ACE hardware.  We use no sticky-session, and its most likely
>>> least-connection load balancing.  We have a simple servlet in each CAS
>>> deployment that the CSS uses to test whether CAS is "up" or not.
>>>
>>> CAS currently points to two "virtual LDAP servers".   I say virtual
>>> because one is actually backed by two load balanced machines (our primary
>>> LDAP) and the other has one LDAP server (these are all ~ V240s +/- a 5).
>>> The LDAPs point to a ring of Kerberos servers.
>>>
>>> Currently, the LDAP servers and the Kerberos servers are located in
>>> various machine rooms across the campus.  Both CAS machines are currently
>>> located in one machine room.  They're testing some additional networking
>>> hardware and configuration which would make it easier for us to deploy CAS
>>> in multiple machine rooms.
>>>
>>> Hopefully that helps.
>>>
>>> Cheers,
>>> Scott
>>>
>>>
>>> On Fri, Sep 25, 2009 at 3:03 PM, Marvin Addison <
>>> [email protected]> wrote:
>>>
>>>> > Thank you that was the problem and it validated the ticket correctly
>>>> just as
>>>> > in test 2.  This makes me think our cluster should be working.  Right
>>>> now
>>>> > our load balancer address (https://loadbalancer.domain/cas/) only has
>>>> one
>>>> > server active
>>>>
>>>> This may explain why you're not getting the error you did formerly.
>>>> Whatever problems you are having appear to manifest only when both
>>>> nodes are active.
>>>>
>>>> > Is there anyway I can get more details as to how you (Scott &
>>>> > Marvin) have setup your clusters?
>>>>
>>>> We use Foundry (now Brocade) ServerIron application switches for load
>>>> balancing.  Our cluster is active-active using least number of
>>>> connections algorithm for routing requests.  We use the host affinity
>>>> feature (sticky sessions) so that a request from a given source is
>>>> routed to the same node during a session (30m timeout).  There are
>>>> some other details that I'll reserve since they're not relevant here,
>>>> but in summary our setup is a common active-active configuration.
>>>>
>>>> It is standard practice here to deploy all core services in a high
>>>> availability configuration.  If you value your CAS service, it's worth
>>>> the effort to invest in clustering.
>>>>
>>>> M
>>>>
>>>> --
>>>> You are currently subscribed to [email protected] as:
>>>> [email protected]
>>>> To unsubscribe, change settings or access archives, see
>>>> http://www.ja-sig.org/wiki/display/JSG/cas-user
>>>>
>>>>
>>> --
>>> You are currently subscribed to [email protected] as: 
>>> [email protected]
>>>
>>>
>>>
>>>
>>> To unsubscribe, change settings or access archives, see 
>>> http://www.ja-sig.org/wiki/display/JSG/cas-user
>>>
>>>
>> --
>> You are currently subscribed to [email protected] as: 
>> [email protected]
>>
>>
>>
>>
>> To unsubscribe, change settings or access archives, see 
>> http://www.ja-sig.org/wiki/display/JSG/cas-user
>>
>>
> --
> You are currently subscribed to [email protected] as: 
> [email protected]
>
>
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>
>

-- 
You are currently subscribed to [email protected] as: 
[email protected]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

<<scenario.png>>

Reply via email to