3 Replies Latest reply on Feb 16, 2016 11:27 AM by Sundar Munirathnam Rajendran

    Fuse Deployment Architecture Model

    Ravishankar Hassain Newbie

      We are trying to design and come up with an architecture for the PROD environment using JBoss Fuse 6.2.1 OSGi container. We have decided to create 5 Fabric server each running in separate host. Each fabric server will have 2 child container one container for A-MQ broker and another container for deploying our application bundles. At any given time there should be 3 container in an active mode and should share the load across all the 3 active containers (Master nodes) and the rest 2 containers should be in passive mode (Slave nodes). When any one of the active container goes down then the slave nodes should pitch in and become active and start sharing the load.

      Also the A-MQ containers should follow the same topology

      I understand that in Master-Slave topology there can be only one Master node up and running at any point of time. But just wanted to check if there is any other possible ways to achieve this kind of requirement.

      If suppose this requirement is not possible then can anyone suggest me good and better approach to achieve HA, DR and fault tolerant deployment architecture for Prod env using JBoss Fuse 6.2.1

        • 1. Re: Fuse Deployment Architecture Model
          Sundar Munirathnam Rajendran Newbie

          In Fabric mode of setup that you have there is no concept of passive node for karaf containers , you can have your routes deployed with camel master component to provide the master slave configuration to the route , the master component can be referred from here.Red Hat JBoss Fuse - EIP Component Reference - Master Component

          • 2. Re: Fuse Deployment Architecture Model
            Ravishankar Hassain Newbie

            Hi Sundar,


              Thanks for your reply. I am sure that we can have Master Slave topology for fabric containers since fabric containers are built on top of karaf and we can have container level lock to implement Master slave topology. We have also implemented this earlier in one of our projects which used fabric in JBoss Fuse.


            I know about fabric and master component of camel for implementing load balancing and cluster for camel components. Also recently they have introduced fabric gateway for implementing HA, Load balancing and fault tolerant for CXF service and JMS servers. But these apply for component level implementation.

            I am just trying to find out whether we can achieve Master Slave switching from container level lock configuration. My question now is how to configure fabric container using container level locking in such a way that at any given time there would be 3 active master nodes and 2 passive slave nodes.

            As of now I have decided to use 3 Master - Slave pairs so at that any time there would be 3 active and 3 passive nodes. Also planning to implement Fabric and Master camel components for camel endpoints and to use Fabric gateway for CXF and JMS to achieve over all HA, Load balancing and Fault tolerance in PROD env.

            Any suggestion on this is highly appreciated. If the above approach is not an ideal way of doing it then some one can point me to the right direction so that I can have a look at it.

            • 3. Re: Fuse Deployment Architecture Model
              Sundar Munirathnam Rajendran Newbie

              Hi Ravi,

              That is true you can edit the system.properties file to exploit the karaf functionality to provide master slave , there the lock depends either on the file system or jdbc and the container lock lets you decide what level of standby node you need. In this mode you can always have one active container and multiple slave containers which have their startup level tweaked . I haven't seen it being used along with fabric . Fabric is all about profiles and generally discourages the changes being made to the file level ( one reason being the zookeeper would flush all the changes held in the master node and could ignore the changes done at the file level after the synch,in this case it will be not be relavant though ) .


              You could probably try using autoscale to define how many nodes need to be always running in a fabric and fabric would automatically spin up the nodes. Suppose you want three nodes running , you can specify the minimum instances on the profile and when one node goes down , fabric would automatically spin up the extra node ( only issue here is that fabric will not attempt to restart the node , it will simply create a new node , which probably is not always good ).


              I would in my experience discourage using the locks for karaf containers , though it is possible . Hope that helps



              Sundar M R