Performance and scalability: clustering??

  1. clustering?? (10 messages)

    What is clustering in Weblogic? Why would one need clustering?


    Threaded Messages (10)

  2. clustering??[ Go to top ]

    Clustering capabilities are included into WebLogic platform. Primarily it comes with WebLogic Enterprise. The primary use for clustering would be for scalability and reliability purposes. The idea is to create a cluster of WebLogic servers that to the developers and end-users would look like a single server. You can add and remove servers from the cluster transparently. Several servers in the cluster can go down and the cluster can still operate properly. The cluster is basically a set of servers that act as one in the eyes of the outside world.

    Hope this answers your question.
  3. clustering??[ Go to top ]

    Instead of buying one huge and expensive machine, you have many medium sized machines. If you load increases, you add a new machine into the cluster. This is horizontal scaling as opposed to vertical scaling (buying a bigger box to replace the old one.)

    Also, some app servers can have a difficult time pegging out a CPUs full potential with the JVM. so you might not get full potential from your big honking box - another reason why clustering is a good idea.

    And failover - where one of the boxes in the cluster dies, yet the rest continue on without it - is another huge reason. mission critical apps, J2EEs target market in the eyes of Sun, need to be available reliably by definition.

    gedanken at io dot com

  4. clustering??[ Go to top ]


    Leo nicely describes the clustering behavior of WebLogic Server. I would just like to comment on Leo's posting really quickly:

    Clustering is available in all WebLogic Server products, including WebLogic Server Express. WebLogic Enterprise is a completely separate product based upon Tuxedo and CORBA (it doesn't have a Java engine at all). All WebLogic products, however, do support clustering.

    You need to talk to a sales representative to be sure, but there are levels of clustering support that WLS instances have. For instance, all versions of WLS support load balancing, web server integration, and replica-aware stubs. However, only the more advanced editions support fail over and object replication. When you download WLS, you have a complete codebase, but the production capabilities of your system is limited by the license key that BEA issues. BEA, as all application server companies do, has set up levels of functionality that are available at different cost levels.

    BEA Education Strategist
  5. WLE[ Go to top ]

    Tyler -- Weblogic Enterprise doesn't even have Java inside it? What's the T-Engine, then? I know the J-Engine is just plain ol' WebLogic, but I thought the T-Engine actually integrated J2EE into Tux. (?)

  6. WLE[ Go to top ]

    Yeah... the whole WLS / WLE mess confuses everyone.

    As of April of this year, here is what it will be:

    WebLogic Server is the 100% pure Java engine.
    Tuxedo is the T-Engine and will include all CORBA support.
    WebLogic Enterprise is WebLogic Server bundled with Tuxedo AND a bi-directional Jolt bridge between the two products. This should make things a little more clear than it currently is.

    Currently, WebLogic Server is the 100% pure Java engine. WebLogic Enterprise is Tuxedo with a CORBA layer added on top of it. Currently, WebLogic Enterprise has a proprietary Java engine built into it as well that does EJBs, but no one uses it (they all use the CORBA stuff). BEA found that having two separate Java code bases in their products was very confusing to people so they are focusing on Tuxedo (C/C++) and WebLogic Server (Java). They will make both products equivalent in features (except Tuxedo will never have a web component to it). Both products will support SNMP and JMX, common messaging, WAN clustering, large scale messaging, etc.

    The bi-directional JOlt bridge is key to making the products integrate smoothly together.

  7. clustering??[ Go to top ]

    I might add that GemStone/J offers Extreme Clustering. Unlike other J2EE servers, GSJ allows you to run several VMs on the same hardware without needing to do any special configuration work.
    Someone else mentioned that you could not peg the CPU on larger machines. This is because you can only effectly run about 200 threads in a VM. After you've reached that limit, the VM becomes bloated and other performance issues start to appear. With Extreme Clustering, the system automaticly load balances by transparently adding and removing VMs from the system. Thus GSJ is capabile of supporting very large applications on a single piece of hardware.

  8. clustering??[ Go to top ]


    Even Weblogic supports clustering on the same machine. It is called multi-homing where the actual IP address maps ot several IP addresses on the same host. This has more to do with scalability than redundancy.

  9. clustering??[ Go to top ]

    I concur with Pavan -- Both products are capable of operating many VMs on a single machine. I know that GemStone does it transparently where WebLogic requires some administration configuration. They both do work, however.
  10. clustering??[ Go to top ]

    I concur with Pavan -- Both products are capable of operating many VMs on a single machine. I know that GemStone does it transparently where WebLogic requires some administration configuration. They both do work, however.
  11. clustering??[ Go to top ]

    Is this really transparent in WL. Say you find that you need to add more VMs to your WL cluster to handle an unexpected load. How do you do this? When you deploy, do you need to deploy into each server seperately?

    GemStone dynamicly adjusts to load automaticlly without any configuraiton work. You only need to deploy your application once. This is because every VM particpates in the same system, not a different one. An activation service looks after load balancing. GemStone's PCA allows you to safely share objects between all the VM's attached to a single GSJ system. The PCA is transactional and has ACID properties.

    One specific experience I had was where a friend of mine was working on with a WL application server and I was working on GSJ server at different sites at the same time. We were both experiencing about the same type of problems. During this time, his site had less than a 50% avaliability. Our site had > 95%. I would contend that the differences avalability are primarly due to the underlying architectual differences in the products. These differences allowed me to do things that were not even options for my friend. Further more, the site I was at is fairly stable today. My friend just finished slamming WL in their customer forum. We started our stabilization exercises in September.
    So, the same, I think not!

      Using the VM pooling in tandom with the PCA means that you can scale your application on a system without performing any special adminstrative tasks. I've seen systems running with more than 20 VMs.