Hi Alex > For the time being I myself am experimenting with things like > JGroups for state propagation.
I had never heard of JGroups before I read your email. I will try to read about JGroups. I am by no means an expert in this field, but I can mention some issues and techniques. ============================================================ 1. A clear defintion of clustering should be made. Is cluster a group of servers (in Merlin containers) that cooperatively achieve a common goal? Or is cluster a a group of identical twin servers that can automatically take over each other without loss of state? There exist several very different definitions in the area. A clear definition of "cluster" establishes the ground for further analysis and work. ============================================================ 2. Stateless versus stateful should be addressed. Usually it is easier to develop stateless clustering systems than stateful clustering. To my knowledge, stateful clustering is pretty complex. ---------------------------------------------------------------------------- -------------------------------- a. Stateless clustering I would actually call it loadbalancing rather than clustering. At best, such systems are not adequate for critical environments, like Bank & Finance where no information must ever be lost in case of failure of a server node. The most common techniques is Round Robin with several variants. Many of the systems, I am aware of, actually provide what is called "Loadbalancing with Session Binding" or called "Loadbalancing with Sticky Session". E.g. I saw the proposal in Apache Geronimo where it was suggested. Most of the EJB servers provide some sort of loadbalancing. Some of systems move the burden of clustering over to the client code called Cluster Aware Proxy. Here the client stores and caches enough information in order to continue the session with a second server if the first one dies. In WebLogic documentation, I read something that seemed to be in this category, but I am not sure. Some of the systems provide an automatic discovery and recovery of a Service Provider. However, there is no guarantee that the state is replicated among service providers of the same kind. I think Jini falls into this category. To my limited knowledge, Grid Computing falls into this category too. ---------------------------------------------------------------------------- -------------------------------- b. Stateful clustering The second group of clustering systems provide some sort of synchronization among different cluster nodes (servers). To my limited knowledge, following techniques exist: I. Multicast replication among various nodes. E.g. in Oracle OC4J (Orion) II. Each node persists each state in a database and thus a shared state of the cluster always exists. The are several issues here. Firstly, performance. Secondly, who is going to write the persistence code, the container or the application developer? Thirdly, the database itself could be a single point of failure something that could be solved using clustering/replication of the database itself. E.g. I think WebSphere is using this technique. III. Each node reads and writes from a shared memory like (Linda Spaces, IBM's TSpace and Sun's JavaSpaces). This looks like II, but uses shared memory. Here the shared memory itself could rely on a persistent manager like a database. Like in the above item, the shared memory could itself be a single point of failure and should be replicable to another shared memory. I heard that JBoss was using JavaSpaces. IV. Mobile Code Here there are two categories: Weak Migration and Strong Migration. In weak migration, the mobile code itself is responsible to restore its state when it arrives at another container. In the strong migration, the container is responsible to save and restore the state as the code migrates from one container to another. Mobile Code has been a hot field within Mobile Agents, and probably some of the techniques could be used for the purpose of clustering. V. There exist many other techniques like operating system clustering and hardware clustering. Here there are many techniques and strategies. Just to mention few examples, Linux clustering, MS Windows Clustering farms, Solaris etc. ============================================================ 3. One other important aspect is to define the scope and granularity of cluster. Consider that nodes in a magical way synchronize with each other. The question is how often and where do they synchronize? Should synchronization happen when an object is changed (a local variable changes), when a method call is finished, when a transaction finishes or ....? Of course, the more granularity, more stability and more performance penalty. ============================================================ 4. Another important question is whether the cluster should handle any and every type of object or whether only certain types of objects should be supported. Should cluster-enabled objects be run in any and every container, or should only certain types of containers provide such funtionality? The last question is co-related with the aspect of security. Cluster-enabled containers embedded within general purpose containers might also be a way to go. The benefit is that as long the parent non-cluster container lives, a sort of state persistance and code migration (mobile code) strategy could be adopted. I have not studied this area, so I leave it to further investigation. ============================================================ 5. Life Style of components as Merlin defines is also very important to address in this regard. How should the cluster-enabled container handle pools and singletons? How should threads and synchronized code be treated? Best Regards -- Nader Aeinehchi Aasenhagen 66 E 2020 Skedsmokorset NORWAY Direct and Mobile +47 41 44 29 57 Tel (private): +47 64 83 09 08 Fax +47 64 83 08 07 www.aeinehchi.com ----- Original Message ----- From: "Alex Karasulu" <[EMAIL PROTECTED]> To: "'Avalon Developers List'" <[EMAIL PROTECTED]> Sent: Monday, April 26, 2004 3:59 PM Subject: RE: Question: scalability, stability and multiple JVMs with Merlin? > Nader, > > > > Background: > > ----------------------------------------------------- > > It is a common practice to scale up by running several instances of a > > container system, e.g. Merlin, on multiprocessor machines and on several > > computers. This would require communication among container systems > > running in different JVMs. There exist many different techniques: simple > > Round Robin external routing, shared memory systems like JavaSpaces, > > persistant shared memory systems involving RDBM and finally mobile codes > > (as in mobile agents). > > ---------------------------------------------------- > > > > Question: > > Is there any specification/best practice/mechanism in Merlin? > > Again to my knowledge nothing exists. > > Basically we're talking about "clustering" components and/or > component failover. Things like the stateful or the stateless > nature of components might need to be considered and state > propagation must be handled in the stateful case. Component > affinity must also be considered. There are several factors I > could go on ad infinitum. Some will think it is impossible to > achieve component clustering due to the perceived need to consider > the nature of each component. I don't think this is the case. > If a good clustering framework can be devised then yeah sure I > think components can be clustered. Perhaps this can be a facility > of the container - just thinking out loud. > > For the time being I myself am experimenting with things like > JGroups for state propagation. This is something I need to do for > enabling replication for Eve. However the same technology can be > used in a container to replicate things like configuration and > component state. > > Feel free to pick up this torch and run with an attempt to > "cluster" components within multiple containers within multiple > JVMs. It takes a brave soul but I have a feeling that you may > be the right guy for it. > > > Alex > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
