Because of the problem clustering http we defined SOAP/JMS as our
primary protocol inside the ESB. You can achieve clustering with
JMS without using a hardware cluster. The redundant services simply have
to listen on the same queue.
But that means you have to JMS enable all clients and servers. When
using java you can use servicemix service units that are exposed through
a JMS Binding component.
For .Net we are going to use .Net 3 and write our own transport layer
adapter for Messaging.
For all clients that support only http you can use a servicemix cluster
that bridges between SOAP/HTTP and SOAP/JMS. But for this machine you will
need hardware cluster support. The advantage of our scenario is that you
need to have only one machine with hardware cluster support.
Best regards
Christian
ywtsang schrieb:
Thanks for your answer, this helps me a lot in re-thinking the problem.
Let me talk a little bit more about my situation.
We want to have a servicemix to act as a ESB to provide some "services" to
different kinds of clients (java, .NET, whatever). Since we need these
"services" to be highly available with good performance with backup of the
capablity to scale up, we design to have a cluster of servicemix.
With study of servicemix, we know it can support clustering (e.g. load
balance, failover, etc), this fits our needs and so we want to dig into more
details for that.
I am doing the evaluation on servicemix and my schedule is quite harsh, with
trying some playing on the examples and studying on the online documents and
mail list, I decide to seek help here for a quicker pointer :)
Please don't mind my direct question.
In fact, your answer had given me a lot of help, thanks~
gnodet wrote:
I don't see your problem has being specific to ServiceMix, but rather
a problem of load balancing http requests.
AFAIK, you have several solutions:
* DNS round robin (no real failover)
* hardware load balancer (quite expensive)
* software load balancer
I'm quite sure the last solution is the best one, unless you plan to have
more than 10.000 concurrent clients. As for the software to choose,
I would try plain ServiceMix, Jetty and Httpd. If none of them can handle
your HTTP load, the only solution is a hardware load balancer afaik.
If you use them as only HTTP load balancer (not using ServiceMix and JMS),
then the processing should be quite low as you should be able to just
redirect
streams without actually processing them.
Anyway, as I said, this is an architectural problem which is somewhat
unrelated
to ServiceMix, and you should try to google a bit around HTTP load
balacing.
For example, I just found http://www.linuxvirtualserver.org/ which might
be
interesting.
On 5/22/07, ywtsang <[EMAIL PROTECTED]> wrote:
Thanks for your quick response. I would like to dig deeper to my
question.
Let say we use a single servicemix instance as the "entry-point" of all
the
request and let the cluster of the remaining servicemix receives the
requests that are already "load-balanced".
I have doubt on the capability of handling all the large volume request
for
the single entry-point servicemix instance to handle.
For hardware load-balancer, the request is forwarded to the other
servicemix
and that servicemix handles the request and response connection directly
with the client.
But for our case: "single entry point servicemix" even the request is
forwarded to the cluster of servicemix automatically for processing, the
return of result from processing to client is still needed to be passed
though that "single entry point servicemix" ? Will that single entry
point
servicemix be overloaded?
Please correct me if there is any misunderstanding.
gnodet wrote:
AFAIK, unless you use a hardware load balancer, you will always have a
single
point of failure. But the goal is to minimize the work done by this
server
so that
failures happen on other nodes I would say.
So you could use ServiceMix as a front-end HTTP and let the clustering
happen using JMS (JMS is automatically load balanced).
Another way would be to use Apache HTTPD
(http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html) in front
of
several
ServiceMix running HTTP .
On 5/22/07, ywtsang <[EMAIL PROTECTED]> wrote:
We are trying to setup a cluster of servicemix and are successful in
running
the example of "cluster".
We want to test the other setup of cluster of servicemix to see if the
servicemix can provide transparent fail-over functionalitiy, but we
met
difficulties in setting up this and want to seek help here.
We want to simulate a simple situation that a simple client, using
"webservice", to make request to a cluster of servicemix to query for
something. For the client, we should specify a single ip address of
servicemix server for the client to connect to. Does that mean for the
cluster of servicemix, we need to have a single servicemix instance
acting
as the entry point of the cluster, and let that entry point service to
do
all the "clustering" stuff (e.g. fail-over, load-balance, etc)?
Is what I am describing correct?
Is it possible that we do not have that single entry point of
servicemix
for
the cluster? i.e. the client can automatically "connect" to the
cluster
by
some means?
My main concern is that we want the "cluster of servicemix" to be
"100%
available" with high scalablility using "clustering". What does the
appropriate setup of this cluster of servicemix look like?
I may be describing the problems with many unclear parts, it would be
nice
to point me out for further clarification of the problems.
--
View this message in context:
http://www.nabble.com/cluster-setup-tf3795182s12049.html#a10734374
Sent from the ServiceMix - User mailing list archive at Nabble.com.
--
Cheers,
Guillaume Nodet
------------------------
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/
--
View this message in context:
http://www.nabble.com/cluster-setup-tf3795182s12049.html#a10735964
Sent from the ServiceMix - User mailing list archive at Nabble.com.
--
Cheers,
Guillaume Nodet
------------------------
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/
--
Christian Schneider
---
http://www.liquid-reality.de
