Tuesday, April 5. 2011
High Availability in Application Servers (sequel)
Comments
Display comments as
(Linear | Threaded)
Great, thanx for this addon!
Regarding the question where session replication/clustering should be handled (you say that HA should be handled by the repository/storage, outside of tomcat) I have a slightly different opinion.
One disadvantage I see is that more infrastructural/operational complexity is introduced by adding more layers/components. This also represents potential points of failures and bottlenecks.
The addition of moxi IMHO is an example for this. In your setup it represents a single point of failure (for both cases, running it on the client/tomcat or server/membase side). To get around this, you'd need to setup (at least) a pair of moxi processes and configure the second one as fallback/failover moxi (in the client/tomcat) for the case that the previous moxi process died.
Regarding replication, it would be interesting to know how moxi/membase handle this. Does it an all-to-all replication (which would limit scalability)? How are the responsible nodes for a session selected (lookup table, consistent hashing)? What happens during rebalancing of the membase cluster?
What I like with the combination of tomcat (+msm) + memcached is simplicity. There is only one logical component (memcached) added to the distributed system and that's easy to handle from an operational perspective.
Why do you think should HA / session replication be handled by the repository/storage, outside of tomcat?
Cheers,
Martin
Regarding the question where session replication/clustering should be handled (you say that HA should be handled by the repository/storage, outside of tomcat) I have a slightly different opinion.
One disadvantage I see is that more infrastructural/operational complexity is introduced by adding more layers/components. This also represents potential points of failures and bottlenecks.
The addition of moxi IMHO is an example for this. In your setup it represents a single point of failure (for both cases, running it on the client/tomcat or server/membase side). To get around this, you'd need to setup (at least) a pair of moxi processes and configure the second one as fallback/failover moxi (in the client/tomcat) for the case that the previous moxi process died.
Regarding replication, it would be interesting to know how moxi/membase handle this. Does it an all-to-all replication (which would limit scalability)? How are the responsible nodes for a session selected (lookup table, consistent hashing)? What happens during rebalancing of the membase cluster?
What I like with the combination of tomcat (+msm) + memcached is simplicity. There is only one logical component (memcached) added to the distributed system and that's easy to handle from an operational perspective.
Why do you think should HA / session replication be handled by the repository/storage, outside of tomcat?
Cheers,
Martin
Several questions...
First, you have to think in client-side moxi like in spymemcached. It's as single point of failure as it's tomcat itself (of course how to check that servers are working is now more complicated). Besides couchbase is working in a vbucket-aware version of spymemcached (http://techzone.couchbase.com/wiki/display/membase/prerelease+spymemcached+vbucket).
Second, why do I prefer a complete independent repository solution? Cos this is the normal way to work. You talk about simplicity but what is simpler than just setting and getting sessions, why just one backup copy (not two or three), why not to consider more concepts like proximity or whatever... For me there are two separate layers, and considering them as two different things gives a lot of room for improvement (I know it's not a fair comparison but what about repeating two insert statements in two different DDBB instead of left replication or HA stuff to the engine).
Letting sessions stay in tomcat in a sticky solution could be reasonable and, maybe in this case, I'm too drastic (I accept that).
Finally, right now you're absolutely right (MSM with at least two memcached servers is the right decision), but just think about that: a in-memory solution with automatic rebalancing, replication, proximity. A client library for this software that knows current topology, has some space for local copies, etc. etc. If you separate the repository layer the solution can improve without limit.
Thank you again for spending some of your time over here.
First, you have to think in client-side moxi like in spymemcached. It's as single point of failure as it's tomcat itself (of course how to check that servers are working is now more complicated). Besides couchbase is working in a vbucket-aware version of spymemcached (http://techzone.couchbase.com/wiki/display/membase/prerelease+spymemcached+vbucket).
Second, why do I prefer a complete independent repository solution? Cos this is the normal way to work. You talk about simplicity but what is simpler than just setting and getting sessions, why just one backup copy (not two or three), why not to consider more concepts like proximity or whatever... For me there are two separate layers, and considering them as two different things gives a lot of room for improvement (I know it's not a fair comparison but what about repeating two insert statements in two different DDBB instead of left replication or HA stuff to the engine).
Letting sessions stay in tomcat in a sticky solution could be reasonable and, maybe in this case, I'm too drastic (I accept that).
Finally, right now you're absolutely right (MSM with at least two memcached servers is the right decision), but just think about that: a in-memory solution with automatic rebalancing, replication, proximity. A client library for this software that knows current topology, has some space for local copies, etc. etc. If you separate the repository layer the solution can improve without limit.
Thank you again for spending some of your time over here.
1.) Moxi: also with moxi running on the client (tomcat machine) you have to make it HA. You are right, it's a single point of failure as it's tomcat itself, but it's one more component that must be made highly available. For tomcat there are several tomcats running with a loadbalancer in front of them. For moxi there must be a similar solution. Of course it's possible, but it has to be done and must be operated/monitored/maintained etc.
2.) Independent repository solution: I agree that from a client side point of view it's simpler to just get and set sessions. It only has to be fast, highly available and scalable.
I have to read a little bit about how these things are represented in membase.
Cheers,
Martin
2.) Independent repository solution: I agree that from a client side point of view it's simpler to just get and set sessions. It only has to be fast, highly available and scalable.
I have to read a little bit about how these things are represented in membase.
Cheers,
Martin
Comments