4 Replies Latest reply on Mar 22, 2012 2:26 AM by asabban

    Implementing a central management structure within V7

    iain.gardiner

      More of sanity check based on the product guide but can you confirm if my understanding is right. Apologies if this is confusing...

       

      Senario:

      Datacentre 1 = Multiple prod MWGs  + 1 x test MWG

      Datacentre 2 = Multiple prod MWGs  + 1 x test MWG

      Datacentre 3 = 1 x prod MWGs

       

      Prod traffic from Datacentre1 & Datacentre 2 is loadbalanced by BigIP

       

      1. Create Runtime group 'Prod' and associate all prod MWGs
      2. Create Update groups 'DC1', 'DC2' + 'DC3'
        DC1 contains the multiple prod MWGs + test MWG from Datacentre 1
        DC2 contains multiple prod MWGs + test MWG from Datacentre 2
        DC3 contains single prod MWG from Datacentre 3
      3. Create Network group 'DC1' and associate prod MWGs from Datacentre 1
      4. Create Network group 'DC2' and associate prod MWGs from Datacentre 2
      5. Create Network group 'DC3' and associate prod MWG from Datacentre 3
      6. Create Network group Transit and add 1 prod MWG from each Datacentre
      7. All nodes are set to priority 10

        At this stage changing the policy configuration on any prod node will push that configuration to remaining prod boxes. Is this correct?

        If adding a new prod MWG to a Network group set its node priority value to 11. It will therefore get the policy configurations from an existing node and not try to push its
        own settings even if its timestamp is newer. Is this correct?
      8. Create Runtime group 'Test' and associate all test MWGs
      9. Create a Network group 'Test' and associate test MWGs from Datacentre 1 + Datacentre 2
      10. Set nodes' priority to 50

        At this stage prod policy configurations are not pushed to test MWGs. Test policy configuartions will be pushed between the test boxes. Is this correct?

        If I wanted to bing the test policy configurations in-line with prod I would add one of the test MWGs to the Transit network group. That would allow the prod policy configuration
        to be pushed to the test MWGs but because they have a lower priority (50) the test policy configuration will not be pushed to the prod MWGs if timestamp is newer. Is this correct?

        Will this work if prod timestamp is older than test timestamp?
      11. It is not possible to create a master and site scenario as in V6 if greater than 2 MWGs as nodes with equal priority can overwrite each other. Is this correct?


        • 2. Re: Implementing a central management structure within V7
          asabban

          Hi Iain,

           

          I have collected some details. I hope I can help you a little bit, but I am not too confident with the cluster stuff :-)

           

          Important to know: The policy (everything in the policy tab) is always synched across ALL members of a cluster. You cannot split test/prod clusters by using the network groups, etc. In case you would like to have one cluster, but have different policies on prod and test, you will have to create a policy that reflects this. For example you can make two top-level rule sets, one called test, one called prod. You could then create two lists which contain the hostnames of all prod nodes or test nodes, and use "System.HostName is in list 'prod'" to apply the production policy (for example).

           

          By doing so you have ONE policy on all nodes, but depending on whether a node is in the list "prod" or "test" it will apply only a specific policy. Complete separation is not possible.

           

          Additionally I would like to state that the runtime group is only used to exchange runtime information such as quota information. It does not affect distribution of the policy either. Network groups are only used for routing information.

           

          Priorities are an interesting topic. Priorities only are used when there is no manual intervention, e.g. a node goes offline, the configuration gets changed and the nodes comes online again. In case you add a node that was stand-alone before, this node will get the current policy of the cluster, independed from its priority. Also a manual change on the GUI will always overwrite the policy, even if the system you make the change on has a lower priority.

           

          To create a master/site scenario you can pick one node as a master, give it a higher priority and turn off the GUI on all other nodes (after the cluster was setup). By doing so you only have one node to do changes. In case a node goes down and comes back with a different configuration, it will load the configuration from the "master" (because the master has the highest priority).

           

          I hope this helps you to get started.


          Best,

          Andre

          1 of 1 people found this helpful
          • 3. Re: Implementing a central management structure within V7
            iain.gardiner

            Thx Andre, think i'll keep test and prod separate!!

            • 4. Re: Implementing a central management structure within V7
              asabban

              Hi Iain,

               

              sounds good. Let me know if further questions arise.

               

              Best,

              Andre