Mail Archive Home | enhydra List | Febuary 1999 Index
|<-- Date Index -->||<-- Thread Index -->|
Hi, The "Session Failover" project suggests to build a PersistentSessionManager for fault-tolerance, load-balancing and scalability. Kyle Clark mentions that one has already been built by Lutris for a customer. Would it be possible to get more details about it? If we get such a PersistentSessionManager, four problems remain to be solved to ensure fault-tolerance, load-balancing and scalability: 1. Request dispatching 2. Session handling 3. Load evaluation 4. Persistent data replication Here are more details: 1. Request dispatching Requests are sent to a central dispatcher which forwards them to a server available on the cluster. This central dispatcher is a single point of failure but it could be replicated on a second IP specified by the DNS. Several dispatching mechanisms are possible, depending on the level of protocol where such a dispatching is managed (IP, HTTP). More details are available there: http://www.di.unipi.it/~gulli/tutorial/load.html. Managing it at IP level would allow to get a fault-tolerant framework supporting any protocol (HTTP, RMI, WAI, ...), but I do not see any way to do this in a platform-independent fashion. Managing it at protocol level (HTTP, RMI, WAI) could be done with a dispatcher servlet entirely written in Java. Such a servlet could be based on existing software like Jamming.Net (http://www.di.unipi.it/~gulli/papers/webnet/98/webnet98.htm) if his author (Antonio Gulli) agrees to release it under an Open Source license. This servlet would act as a proxy between the client and the application server (Enhydra). Such a strategy would have the following advantages: * Dispatching could be implemented in different ways according to the protocol used. * Only a subset of supported protocols could offer such a dispatching, which would allow to distribute development work accross a team of developers. * Dispatching could be managed using the Java framework, which would simplify the design of session handling (see 2.). * The dispatcher could have extended features for acting as a cache server or a firewall. 2. Session handling If requests are dispatched to several servers, a given user must always been handled by the same server during a session. This requires that the dispatcher is aware of which server is currently serving a given user. Then the dispatcher must implement the mechanisms used by the application server to handle user sessions and must manage a database associating a server to a user session. If a new session is requested, the dispatcher must forward this request to the most available server. This requires some server load evaluation mechanisms (see 3.). If a request associated to an active session fails because of a server failure, the dispatcher must forward this request to another server and must update its user session database. 3. Load evaluation Load-balancing requires load evaluation mechanisms. I do not know much about such mechanisms which could be platform independent and available from the Java framework. Any idea? 4. Persistent data replication The previous sections described how fault-tolerance, load-balancing and scalability are ensured at runtime. Suggested mechanisms should allow users to get access to an available server anytime, provided that not all servers are down. Nevertheless this does not ensure that users will ever get access to their persistent data. In order to provide the required level of fault-tolerance, persistent data (like processing resources) must be replicated. Persistent data means session data (stored on a database server) and users data stored on a database server and/or on a filesystem. Unlike for "front-side" protocols (HTTP, RMI, WAI), a generic solution for "back-side" servers (file server, database server, mail server, directory server, ...) seems to be far more simple than a specific one and do not need to be platform independent (servers used are not platform independent). Then a simple solution based on a replicated filesystem (using rdist for example) could be used. According to such a solution, the dispatcher would just have to manage a table specifying where "back-side" servers are located. This table would be replicated on Enhydra servers using it to access to the right servers. If a "back-side" server fails, the Enhydra server requesting it would just have to notify it to the dispatcher which would update its table (and all replications of this table) replacing the failed server by a new one. Is there any standard protocol to cleanly implement such a strategy? Regards Ismaël Ghalimi ----------------------------------------------------------------------------- To unsubscribe from this mailing list, send email to majordomo@xxxxxxxxxxx with the text "unsubscribe enhydra" in the body of the email. If you have other questions regarding this mailing list, send email to the list admin at owner-enhydra@xxxxxxxxxxxx
|<-- Date Index -->||<-- Thread Index -->|
Powered by MHonArc.Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.