Thank you. That helps. From: Andrew Feller [mailto:[email protected]] Sent: Monday, June 22, 2009 10:21 AM To: [email protected] Subject: Re: [cas-user] Clustering and certificates
Bruno, Depending on your load balancer, some hardware vendors allow you to run multiple in tandem and they monitor one another using some heart beat technique. Here are two scenarios given a 2-machine cluster: ACTIVE-PASSIVE Both machines are up and running, however only one load balancer is answering requests for all of the load balanced applications. Both machines keep a check on one another using a heartbeat technique, so if the active server fails, the passive server knows all of the same load balanced applications and the DNS hostnames it needs to answer, so it just requests IP addresses for those DNS entries. When the machine comes back up, it depends on the load balancers whether they revert control back to a primary machine or keep the currently active machine up. ACTIVE-ACTIVE Both machines are up and running, however they have split the work load; machine A has apps 1, 2, and 3 while machine B has 4, 5, 6. They still keep checking on one another through a heartbeat, so whenever the other dies, they will pick up the load they dropped until it comes back up online. At that point, they will split up work again and carry on happily. This all depends on what kind of hardware / software you are using. A- On 6/22/09 9:58 AM, "Bruno Melloni" <[email protected]> wrote: Scott and Chris, Thank you for your replies, and please forgive my utter ignorance on the load balancer topic and that my following question might be slightly off-topic... how do you keep the load balancer (hardware or Apache/mod_jk) from becoming the single point of failure that you are trying to avoid when you cluster? Do you really have 2 or more load balancers talking to each other and having a single hostname in DNS (perhaps through some kind of round-robin)? Thank you, bruno From: Scott Battaglia [mailto:[email protected]] Sent: Monday, June 22, 2009 9:05 AM To: [email protected] Subject: Re: [cas-user] Clustering and certificates On Mon, Jun 22, 2009 at 9:59 AM, Bruno Melloni <[email protected]> wrote: <snip /> 1. jBoss recommends placing a certificate in a load balancer (like apache/mod_jk) that sits in front of the cluster, placing no certificate on the jBoss servers themselves. a. Will CAS work with the certificate in the load balancer instead of each individual application server? Yes, we deploy with a certificate on a hardware load balancer over here. b. Or does CAS require a certificate in each cluster node - so that the calls between the client and CAS can happen (and be trusted) using HTTPS? It does not because technically all of your clients are talking to the load balancer first. 2. Is there a good document about clustering CAS? (it would be even better if it was about clustering CAS on jBoss, but I won't hold my breath) Our wiki has documentation on the multitude of solutions available (JBoss Cache, Memcached, JPA). The two that get the most testing are Memcached and JPA. If you disable sessions for the Spring Web Flow then you don't need to worry about actually clustering JBoss Application Server. You just deploy multiple instances and they are all stateless. Only the ticket cache is then stateful. 3. Do you have any recommendations, warnings, knowledge about pitfalls, etc... that I should keep in mind as I setup this? Setup is easier if you rely on client storage of Spring Web Flow flows (its a relatively simple change to the configuration). There are the usual warnings about properly protecting your network and the traffic between your clusters, etc. Cheers, Scott Thank you, Bruno -- Andrew Feller, Analyst LSU University Information Services 200 Frey Computing Services Center Baton Rouge, LA 70803 Office: 225.578.3737 Fax: 225.578.6400 -- 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
