This is an interesting conversation. Last month we've visited 2 large universities in the PAC-12 to learn about their IDM systems and Kuali.
The first university uses CAS with memcached with repcached and my boss was very impressed, hence the direction I am taking. However, they did say it took them 3 months to get it up and running since they had to search long and hard for a version of repcached that was compatible with the version of memcached. That was a red flag for me. I was just over on the memcached google group and someone had asked about HA memcached and there was no mention of repcached so that is another warning for me. I just drew up 2 proposals for CAS infrastructure: https://www.lucidchart.com/documents/view?#4660-b97c-4f90267e-a851-1b180a60e9bc?branch=126766c7-1b44-42b5-a3d4-296f535c8c62 I believe the second drawing is what you described? Where each CAS instance has a reference to the other CAS instance's memcached? -Bryan -----Original Message----- From: Marvin S. Addison [mailto:[email protected]] Sent: Thursday, April 19, 2012 9:07 AM To: [email protected] Subject: Re: [cas-user] Memcached Ticket Registry - Unresolved > I have been wondering what the preferred configuration of CAS and > memcached is. Should CAS and memcached be on the same physical box or > on separate boxes like my current configuration. Of course the end > game is to have 2 or more load balanced CAS instances using repcache > and memcached to share tickets and provide some level of HA. I don't know if there's a preferred configuration, but I'm a big fan of both simplicity and homogeneity in a HA setup. For that reason we simply have each CAS node run a memcached instance. We run VMs with 3G RAM and our CAS JVM can easily live within 1.75G, leaving 1G for memcached, and a little extra for system processes. With an efficient serialized form, a memcached instance with 1G RAM can accommodate millions of tickets. (I have some test data to back this up.) Also, having multiple memcached instances provides for a really beautiful failover mode. If a node goes down, the client (MemCacheTicketRegistry) will simply pick another node to read/write to. If it fails to get a ticket from the cache due to a memcached outage, the user will experience either an emphemeral serivce access failure (in the case of ST) or will be required to reauthenticate (in case of TGT). That's a perfectly acceptable failure mode for our purposes. I'd think long and hard about what repcache buys you other than additional complexity. 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
