Indeed, I will gather that as a part of my design specification so, the 
expectation can be set right. A very good point ! Also to Marvin's last email, 
I might end up doing a proof of concept first before recommending a final 
design. 

From what I saw/read about cas clients ( I read /tried phpCAS), I only had the 
ability to specify one CAS server FQDN ( of course in case of the cluster this 
would be a load balancer address). Is this true or can i specify multiple CAS 
servers in the CAS client. If its not possible, the only alternative I can 
think of is GTM/GSLB so I can retain the same FQDN across the datacenters. If 
any one knows of an alternative to this, please let me know. 





Thank you. 
-sri 
Srinivas Varadaraj 
Security Operations Center, 
Lamar University, 
409-880-8410 (O) 
409-225-7415 (C) 
Email: [email protected] 


----- Original Message -----
From: "Scott Battaglia" <[email protected]> 
To: [email protected] 
Sent: Monday, November 15, 2010 1:59:07 PM 
Subject: Re: [cas-user] CAS architecture request. 

I know Marvin already gave a detailed response for some of the clustering 
stuff. 

One thing you must ask during DR planning is what level of data loss can you 
sustain with regards to CAS tickets. 

For example, if you lose the TGT data store, the worst case scenario is people 
need to log back in, etc. If that's acceptable, you can minimize the complexity 
of your structure (i.e. then you only need to cluster per data center, vs. 
across data centers, etc.) 




On Mon, Nov 15, 2010 at 12:39 PM, Srinivas Varadaraj < [email protected] > wrote: 





All, 
I would like request CAS user's experience/advice on implementing CAS service 
in HA env with DR / Business continuity architectures. Basically, I have two 
datacenters separated by a WAN link (with IPSec VPN running between the 
gateways). I have AD (authentication source for CAS) replicating over this 
link. Now to build an active-active CAS infrastructure that spans across 
datacenter(s). Here are my thoughts: 
1) Setup 2 separate application clusters on either side that replicate/share 
session information. Store all tickets and other dynamic information where 
possible in an mysql database cluster ( replicated over the WAN VPN link). The 
application clusters , in theory should be able to see active sessions on both 
sides using the information in the database ( not sure about this). I am not 
sure if I want to multicast over the WAN link or even replicate sessions over 
TCP on the WAN link. There is sufficient bandwidth but the latency is major 
factor. 

2) Load balance between the data centers using technology such as Big IP's GTM 
. Or any other alternative solution. 

So, before going down this path, I need to know if I am thinking this through. 
I would love to hear ideas on how others have approached and accomplished the 
same with alternative designs/technologies. 







Thank you. 
-sri 
Srinivas Varadaraj 
Security Operations Center, 
Lamar University, 
409-880-8410 (O) 
409-225-7415 (C) 
Email: [email protected] 


CONFIDENTIALITY: Any information contained in this e-mail 
(including attachments) is the property of The State of Texas and 
unauthorized disclosure or use is prohibited. Sending, receiving or 
forwarding of confidential, proprietary and privileged information is 
prohibited under Lamar Policy. If you received this e-mail in error, 
please notify the sender and delete this e-mail from your system. -- 
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 




CONFIDENTIALITY: Any information contained in this e-mail 
(including attachments) is the property of The State of Texas and 
unauthorized disclosure or use is prohibited. Sending, receiving or 
forwarding of confidential, proprietary and privileged information is 
prohibited under Lamar Policy. If you received this e-mail in error, 
please notify the sender and delete this e-mail from your system.

-- 
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

Reply via email to