Actually, CAS is just an application that's deployed on an app server, so they're all on the same boxes. Each VM has a Tomcat instance that's running CAS, so we have four SLES12 VMs, each running a copy of CAS on Tomcat, and each VM is running on a different physical host. (We use SLES12 for our app servers, because we can get "unlimited virtualization host" licenses for fairly inexpensive after the education discount.)
And yep, that's basically what we did -- built one VM, then cloned it to create the others (changing a few minor things on each VM as it was cloned (hostname, IP, and server identification string.)) Super easy to do, and makes it incredibly easy to spawn up new application servers should we need to do so -- roughly 15 minutes from start to finish. We have all of the session data replicated between the four nodes using Hazelcast. It's a lot easier to set up than other technologies IMO. That way if we happen to take one node offline during the day (upgrades, patches, hardware failure, etc.,) the logins will be redirected to the other servers without a hitch. It also enables us to do the "active-active-failover-lastresort" setup we've got. (Our third VM is just as robust as the first and second, and has the same software configuration, but is configured as a "failover" node on the load balancer because we primarily use it for doing scheduled tasks. But if the first and second nodes go offline, all of the traffic will get directed there as well. This is all done through the policies on the Barracuda.) Also, the SSL offloading done by the load balancer makes things a lot easier too...no more dealing with keystores on each individual box. Plus it lets Tomcat do what it's best at -- delivering applications. It leaves all that messy CPU-intensive encryption and decryption to hardware designed for the purpose. There is a bit of additional configuration you have to do to Tomcat, but it's not bad. Chris >>> Hank Foss <[email protected]> 08/12/16 8:11 AM >>> Chris, So you have TC and CAS on separate boxes. Is it possible to have both on the same box or is it better to have them separate? It sounds like in your environment you have quite a few services configured which is why you chose to separate the roles to different servers. So, e.g. having CAS and TC on same server, then replicate to other VMs - is that viable? Hank On Friday, August 12, 2016 at 8:50:22 AM UTC-4, Christopher Myers wrote:Likewise, we have 3+1 (two primary, one secondary, and an "oh crud the entire production VMWare environment went offline" backup.) All are running 4.0.x, connected together with hazelcast replication. We've got over 20 registered services, including connecting Shibboleth to CAS for its authentication source, which handles even more services. Each TC server is on its own VM, on a different VMWare server. All are front-ended by our Barracuda, with SSL offloading. So yeah, it's a pretty robust system :) Chris >>> Ray Bon <[email protected]> 08/11/16 5:09 PM >>> Hank, We have 3 CAS (v 3.5.2.1) virtual machine servers in a primary, secondary, tertiary setup with LDAP (all on Redhat). CAS is very capable and can handle several logins per second. Ray On 2016-08-11 14:23, Hank Foss wrote: Thanks, Misagh, much appreciated. It sounds like this will work quite well for us. Most of our web apps rely on LDAP authentication. Regarding architecture, hope you don't mind a couple of other questions: How many servers are in your CAS environment (presuming you recommend an HA environment) - e.g. 1 web server (Tomcat?) + 2 HA CAS ticketing servers Do you recommend RHEL for OS? Our user environment is about 12,000 (2,000 staff + 10 -Hank On Thursday, August 11, 2016 at 4:45:43 PM UTC-4, Misagh Moayyed wrote: If you mean CAS is going to provide you with an LDAP server, the answer is no. AFAIK, that has never been the case. If you mean you wish to authenticate via AD/LDAP and get access to your portal and other CAS-protected apps, then it’s quite simple. Since the dawn of time, CAS has supported LDAP/AD authentication. 90% of the deployments use that method of authentication. -- Misagh From: Hank Foss <[email protected]> Reply: Hank Foss <[email protected]> Date: August 11, 2016 at 1:38:35 PM To: CAS Community <[email protected]> Subject: [cas-user] New to CAS, new to Apereo Hello, I'm brand new to CAS and Apereo, and am asking the best way to begin. We are migrating our CAS from the cloud to on-premise as a cost savings measure. This will likely save us $60+k annually, as the vendor is also provides our portal. The externally hosted portal contains LDAP as well as CAS links. I understand CAS 5 comes out this fall (October?) which offers LDAP support, so I am on the fence a bit more. Since AD authentication drives many of our authentication, I have been told that we will either need to use ADFS or Shibboleth. The goal for this to be live is December of this year, so there are learning curve, architecture, installation and customization components of this project that all come into play. I built the Linux box, most current version of CentOS, but I believe being an open source application that the support of at least the OS should actually be a licensed RHEL instance. I'm technical, but this is uncharted territory so suggestions, comments, and criticism are all greatly welcome. Thanks, CAS-Newbie -- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/ccf659bc-12d9-4cb8-98dd-4dbf926f403a%40apereo.org. For more options, visit https://groups.google.com/a/apereo.org/d/optout. -- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/df64e990-a4f5-406a-871e-f4a8ea96d289%40apereo.org. For more options, visit https://groups.google.com/a/apereo.org/d/optout. -- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/f4aa7e4d-e9b0-367a-c790-8d6bb5db0673%40uvic.ca. For more options, visit https://groups.google.com/a/apereo.org/d/optout. -- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/a6fd1057-f6ae-4ad0-b3a3-90c4965672d0%40apereo.org. For more options, visit https://groups.google.com/a/apereo.org/d/optout. -- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/57AD8A76020000450007442B%40mugwgate.millikin.edu. For more options, visit https://groups.google.com/a/apereo.org/d/optout.
