Les, thank you very much for the comprehensive explanation here. We are going to use LVS (Linux Virtual Server) as our LB and command interfaces like ipvsdm, keep alive and heartbeats to assure HA. And in conjunction we plan to use Memcached. I don't have any plan for persistent disk space yet, but from what you mentioned, I see that the clustering question should not really targeted to Shiro. And instead should be addressed by distributed caching programs.
Thank you, Navid On 2012-01-26, at 1:51 PM, Les Hazlewood wrote: > Most production Shiro environments will delegate state management to a > quality CacheManager implementation. For authentication and > authorization caching, this is straight forward - those cache entries > can reside in the memory of the local machine only, or with a > distributed caching mechanism (Memcache, Ehcache+Terracotta, etc), in > the memory of an accessible cache node. > > For actual Subject sessions (e.g. subject.getSession()) this same > cache mechanism is often used, so long as sessions are saved to a > persistent store if memory becomes constrained. This persistent store > can be a disk or disk array, an RDBMS, a NoSQL data store, or anything > similar. The SessionDAO implementation (e.g. CachingSessionDAO) can > be used for a if-not-in-memory-then-query-the-store approach, or you > can use the EnterpriseCacheSessionDAO which assumes that the cache > itself knows how to overflow to a persistent store (e.g. > TerraCotta+Ehcache, Coherence, GigaSpaces, etc) and you don't need to > tell Shiro what that persistent store is. > > So, this question is really about Cache management - how much cache > memory will you enable for your application cluster? Is your cache > distributed across multiple machine nodes? > > The cache does not have to be distributed if you use load-balancing > with sticky routing. That is, if each application host has a local > cache running, and all requests from a particular client can be routed > to a particular machine, you'll see good performance benefits. The > tricky part is ensuring that once a cache instance starts to fill up > on a given host (e.g. ~80% high watermark) you direct new client > requests to another cluster node. > > This implies coordination between the load balancer(s) and each > application node so the LBs know when to direct new hosts to a new > node. A distributed cache mechanism however can allow one to use > 'dumb' load balancers and any local-vs-remote data segmentation can be > managed by the caching product itself. > > HTH, > > -- > Les Hazlewood > CTO, Katasoft | http://www.katasoft.com | 888.391.5282 > twitter: @lhazlewood | http://twitter.com/lhazlewood > katasoft blog: http://www.katasoft.com/blogs/lhazlewood > personal blog: http://leshazlewood.com > > On Thu, Jan 26, 2012 at 6:20 AM, vdzhuvinov <[email protected]> wrote: >> >> Navid Mohaghegh wrote >>> >>> Thank you Vladimir. I try to be as specific as I can: Image a cluster of >>> 4 servers each has a quad processor AMD Opteron 6272 (e.g. total of 64 >>> cores per server running at 2.1 GHz sharing a 16 MB of L3 cache). Each >>> server has 64 GB of ECC registered DDR3 memory clocked at 1333MHz. The >>> servers will be connect using Infiniband links of 40 GB/s. We can add >>> SSD/HDD for caching on disk or persistent sessions. I want to know how >>> many sessions concurrently in total can be tolerated here and how fast we >>> can expect to get the authentication done (e.g. average of 15-20 ms for >>> the authentication request and persisting the session ...?). Thank you. >>> >> >> I cannot give you an answer, but here is how you can get a feeling of what >> to expect. >> >> In terms of memory, if a single session object is 1kByte on average, you >> would be able to store 1 million sessions in 1Gb. So memory space is not >> likely to be an issue for sessions that store just a few strings of info. >> >> The other factor is processing load and this will depend on the number of >> HTTP requests you get per second. You may look at benchmarks to get a >> feeling for that. >> >> If you're planning to use Terracotta here is one useful guide: >> >> http://docs.terracotta.org/confluence/display/docs35/Deployment+Guide#DeploymentGuide-MemorySizing >> >> My rule of thumb is not to worry too much about actual hardware performance, >> but to make sure fault tolerance, disaster recovery and the ability to scale >> and stay fluid is well thought of in advance. >> >> Vladimir >> >> ----- >> Vladimir Dzhuvinov >> -- >> View this message in context: >> http://shiro-user.582556.n2.nabble.com/Shiro-on-Cluster-tp7225939p7227093.html >> Sent from the Shiro User mailing list archive at Nabble.com.
