4 Replies Latest reply on Jul 17, 2015 2:10 PM by wdfink

    Copying a cluster config to a new cluster

    tomo04

      Hi

       

      I have a JBoss AS 5.1 on RHL installation, it's a clustered environment with VIP address in front of two VMs. The two VMs share the app load in 'Active-Active' config.

      The setup is setup for security so using "UserRolesLoginModule"

      ...

        <authentication>

          <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">

      ...

       

      I now want to create a new cluster on the same two VMs with the same setup but using an LDAP login module. The intention is to use the same hostname but a different port so that the two clusters can run side-by-side for testing purposes.

       

      My question is rather than recreate the whole cluster again and configure all the High Availaibility and replication setup etc, can I simply copy the profile directory to a new directory, reconfigure it to use a different port and then continue to configure the second cluster for ldap login?

       

      What I need is the two clusters running side-by-side with the old authentication method and the new authentication method. Can I save time by simply copying the relevant profile directory and doing the necessary configuration?

       

      Many Thanks

       

      Andy

        • 1. Re: Copying a cluster config to a new cluster
          tomo04

          I read the following: https://developer.jboss.org/wiki/ConfiguringMultipleJBossInstancesOnOnemachine

           

          In summary it says you cannot have two daemons listening on the same IP address and same port for incoming requests. To address this issue you have two choices:

          1. Bind each JBoss AS instance to a different IP address

          2. Ensure each instance is using a distinct port for each service. This can be done using the Service Binding Manager.

           

          So, I believe I should be able to run the following:

          ./run.sh -c node1 -b 123.456 -g cluster1 --> starts the first cluster running on port 5000

           

          and

           

          ./run.sh -c node2 -b 123.456 -g cluster2 -Djboss.service.binding.set=ports-01   --> starts second cluster on port 5100

           

          Has anyone done anything similar and got it to work or hit any issues that I should be aware of?

           

          Any help appreciated.

           

          Regards

           

          Andy

          • 2. Re: Copying a cluster config to a new cluster
            wdfink

            With different IP addresses (i.e. if youhave more nic's with your box) or using the binding manager you are able to run more instances on one physical or VM box

            But you need to consider that you need more CPU power and memory then, it doesn't make sense to have two instances which overload the box

            • 3. Re: Copying a cluster config to a new cluster
              tomo04

              Hi

               

              Thanks for the reply. I appreciate what you say and I have taken these things into account, we have sufficient resources.

               

              I am looking for answers to what I actually need to reconfigure to make this happen. Obviously there will be potentially a conflict of ports, I understand typically the Service.Bindng.Manager will take care of this but because I'm using tcp protocol (-Djboss.default.jgroups.stack=tcp) does this mean, for example, I need to edit the jboss-channelfactory-jboss-beans.xml file?

               

              The tcp protocol shows start_port=7600 for cluster 1, will this need changing for cluster 2 along with the TCPPING initial_hosts parameter?

               

              Regards

               

              Andy

              • 4. Re: Copying a cluster config to a new cluster
                wdfink

                The port is changed for the second instance.

                So you need to specify the initial_host parameter different for each cluster and not mix the members of the different clusters