ObjectWeb Consortium
Search ObjectWeb Mail Archive: 

Advanced Search - Powered by Google


Mail Archive Home | enhydra List | Febuary 1999 Index

<--  Date Index  --> <--  Thread Index  -->

Enhydra: About fault-tolerance, load-balancing and scalability


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  -->

Reply via email to:

Powered by MHonArc.

Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.