Load balancing JBoss

[buckman1]

Hi all,

Later I am going to scan through this forum to see if anything is said about how to do this, I apologize if this is an oft asked question, but as many of us are, I have too much on my plate right at the moment.

Anyway, we are now running up against the clock to deploy our solution using JBoss. We have a dual Xeon with 4GB server. What I want to do is load-balance two servers for high-availability as well as scalability purposes. For some reason we seem to be crashing either the JVM or JBoss after 125MB is used up during a stress test. What I aim to do in the next couple of days is set up two basic RedHat 8.1 Linux boxes, JBoss 3.04 or .06, and a software load balancer of some sort.

So question 1, is there a recommended software loadbalancer program I can use for testing and stress testing? I don't know if we'll have a hardware solution any time soon. So is there a free loadbalance software I can run on my Win2K box which will allow testing of load balancing between two separate JBoss server boxes?

Second, any info, docs or suggestions on ways to carry out load balancing with JBoss? I just found out we have some very high-end Cisco load balancers (11000 series content switch) that we can use at our deployment site. For local use I can not use these though. But, down the road we will probably be using stateful ejbs, although right now we are not. My primary concern for the immediate future is to figure out how to properly cluster two JBoss servers with stateless EJB. So any docs, links, etc that can explain this process would be much appreciated.

Thank you.

[jbossnz]

Try jboss 3.2.1 for the latest implementation.

Have you got the -Xms and -Xmx settings correct for your 4GB machine

[buckman1]

We do have the memory settings correct. Does 3.0.6 not able to cluster? Or is 3.2.1 the recommended one for clustering?

[slaboure]

1) read the clustering documentation
2) if you want to cluster SLSB or SFSB, you don't need a load-balancer.

Cheers,


sacha

[buckman1]

Oh I am reading it alright. I must have 300 pages of crap printed out on how to do this.

So if I may ask a silly question, if we plan to deploy in a clustered setup, shouldn't we be developing using one? From what I have read, we can set up a single node in one partition ready to cluster, even though its the only node. When ready, we can add another node and they will automagically become clustered. So, since we know we need to deploy in a clustered setup, would it make sense to set up our dev boxes in this manner so that our jndi settings and such are done in this manner as well? Or is it more advisable to only set up the QA/Staging/Production servers in this setup but leave our dev boxes normal?

I have set up Orion in a cluster and I have to say it was quite a bit easier, although I don't recall if it clustered JNDI and such. Probably not. Ideally I am guessing the best is to cluster JNDI as well, and make sure our code looks up through the various JNDI servers? The reason I ask this is we plan to set up many clients with JBoss clusters. I am wondering if I can just use all the default settings and things will work, or do I need to make changes to a lot of the files for it to work? It seems I can leave the /all folder as it is and get clustering to use the default partition names and such and be ok. The question then becomes, how do we get our client applications to properly contact the two nodes in a given parition? I saw the diagram and read how the proxy load balancing stuff comes back to the client (good stuff by the way as it eliminates a server side point of failure at the load balancer), but for each deployment, I assume we have to set up the jndi.properties file the client app reads in to point to the proper nodes in the partition?

[jbossnz]

> So if I may ask a silly question, if we plan to
> deploy in a clustered setup, shouldn't we be
> developing using one?

Yep sounds good. The app should work on one node, then can test with multiple nodes

>Ideally I am
> guessing the best is to cluster JNDI as well, and
> make sure our code looks up through the various JNDI
> servers?
>The question then
> becomes, how do we get our client applications to
> properly contact the two nodes in a given parition?
> I assume
> we have to set up the jndi.properties file the client
> app reads in to point to the proper nodes in the
> partition?
Yep
setting
java.naming.provider.url=server1:1100,server2:1100
etc in the jndi.properties of the clients should do the trick for your clients (where server1 is the hostname of the first server etc), this is on page 31 of the April 2003 version of the clustering paid for documentation, chapter 4 HA-JNDI.

> I am wondering if I
> can just use all the default settings and things will
> work, or do I need to make changes to a lot of the
> files for it to work?

Yep, not much else to do using the all configuration, other than setting which ejbs should be clustered in the jboss.xml files (page 34 and 35 of the April 2003 version of the clustering paid for documentation, chapter 5, Clustering EJB)

> It seems I can leave the /all
> folder as it is and get clustering to use the default
> partition names and such and be ok.

Yep, the only thing is if you want farming (chap 7 Farming,April 2003 version of the clustering paid for documentation) your ear file should be dropped in the /all/farm directory rather than the /all/deploy directory (for jboss3.2.1). If this farm directory isn't there, it will be created the first time you run jboss with the all configuration

[slaboure]

Pff.. I have to admit that it is a little bit frustrating...

You say "it was easier in Orion and bla bla bla" but you don't take 10 minutes to read the doco but instead keep asking trivial questions showing that you don't know at all how it works. How can you measure if it is easier or more difficult if ... you don't know!


For your deployment question (development vs deployment), you can work in a non-clustered environmment for your development and that's fine. But for your pre-production env, I strongly encourage to do lots of clustering testing. Other reasons are:
- you have to find the best way for you to deploy your environnement
- learn how to react in case of problems
- check if you need specific performance improvments since cache (for example) cannot be in Commit Option A most of the time.
- ...

Cheers,


sacha

[buckman1]

Sacha,

Ouch, a bit touchy on this topic heh? ;) Not to worry, I agree with you. I have read about 1/2 of the doc so far, and thus my previous post is invalid if it turns out all I need to do is use the /all dir and things will work (other than the jboss.xml changes). Don't be too upset, Jboss rocks! I wouldn't have switched from Orion if I didn't think so. I just recall Orion was very simple to cluster, although it didn't work very well last I tried. Getting it to work was easy, only two simple changes. It must have been buggy, because it didn't always work.

Non the less, after reading more, I am seeing that JBoss may be easy to cluster as well. Sorry to offend.

[slaboure]

That was me, an hormonal spike maybe ;)

Cheers,


sacha