2 Replies Latest reply on Mar 22, 2009 7:14 PM by jochen.reinhardt

    Entities in clustered environment

    testrot

      Hello,

      I read the JBoss Application Server Clustering Guide version 5.0.0 beta to receive an impression about the failover/load balancing features provided by JBoss AS 5.0. The ultimate goal is to build a failsafe system on top of the AS.

      But I'm not quite sure about the failover capabilities concerning entities. The Clustering guide says that a distributed cache can by used for entities to avoid db round trips. The entity manager injected by the AS uses this cache and so my application benefits from it. But as far as I understood I don't get any failsafe benefits. If the db server fails the whole systems fails, so the db is a single point of failure.

      Is there any mechanism/system deployment to get rid of this single point of failure?

      I guess using a high end database cluster would be one, but is there another solution. Perhaps using 2 separate databases and something like a replication mechanismen inside the AS which replicates entities across the 2 db instances?

      Thanks for help,
      Martin

        • 1. Re: Entities in clustered environment
          vink

          Is there any update on this clustering issue?

          Which option is suitable for production,
          - Every JBoss Node (with Database) in Cluster
          - Many JBoss using single Database

          • 2. Re: Entities in clustered environment

            Hi,

            I must admit, I am new to clustering with JBoss. But I am currently learning for an exam for MySQL cluster. That would be what you called an high end database cluster ;-). The cost is 0,00$ or whatever currency you prefer :-D

            I guess having several databases is not feasable. There would be too much work to do for replacating between them. And as DB replication is usually done in an asynchronous way, you will never know when the second database applies the latest changes. As far as I know, replication is used for backup-purposes and cold standby. That means, you use the slave to do backups while the master is still running - stopping relplication during backup allows to make a consistent backup. In the second scenario, you change the application configuration to fall back to the replication slave when the master fails. This usually will cause loss of some data. As the updates happen asynchronously, there is no transaction support. I guess that can't be used for JBoss clustering.

            Instead, using a clustered database is what I would recommend. In case of MySQL, you'll have some NDB nodes, storing and retrieving cluster data in main memory, and several MySQL server nodes for accessing the cluster via SQL. A typical setup would be having four NDB nodes, two MySQL nodes and at least one management node for setting up and monitoring the cluster. I think, in a JBoss Cluster made up of two nodes, you should be able to use the MySQL server nodes as datasources.

            Your APP
            / \
            AS1 <------> AS2
            | |
            MySQL1 MySQL2
            | |
            NDB1 <------> NDB2
            | X |
            NDB3 <------> NDB4

            Your APP: your application with some kind of interface to the user / caller. You could also be able to add some kind of load balancing proxy on top of your setup.
            AS: JBoss Application Server
            MySQL: MySQL server node
            NDB: MySQL cluster data node

            This way the DB would not be your single point of failure, as it is HA by design. But as I said, I really do not have any idea about JBoss clustering, so it may be that I am wrong in some points. But from a DB point of view, this would be a recommended setup.

            Best regards,
            Jochen

            PS: Clustering is very expensive, if you want to do it right. All componenent have to exist at leas twice. This is also true for your network equipment. E.g connecting all nodes using one switch will make the switch your single point of failure and so on...