Topic
5 replies Latest Post - ‏2014-06-10T23:49:42Z by Trey
tomiLee
tomiLee
33 Posts
ACCEPTED ANSWER

Pinned topic SLM Multicast Peering Recommended Practice

‏2014-06-04T15:01:50Z |

We want to keep a consumer from flooding the providers especially when the providers start to slow down for any reason.   (Consumer-->DP-->Provider). 

We are setting up an SLM Policy with the Threshold Interval Type set to Concurrent.    We plan to throttle the traffic if they exceed X Threshold level and notify if its 80% X.  I read this article that says it is recommended to not use Peer Groups when the resource type is concurrent.  In our case we are not using a resource type  but we are setting the threshold interval type to concurrent.  Is it recommended to use SLM multicast peering in our scenario and this article only applies to unicast?

 

Question  

An SLM policy configured to limit either the number of concurrent connections from a given user or the number of concurrent transactions into the service works as expected when implemented on one device. If the environment is expanded to include a similarly configured peer device, adding a peer group to that SLM policy is not a supported option. 

Cause  
SLM peers can only exchange historical averages. They cannot exchange instantaneous measures.
Answer  

This is a known limitation of the SLM facility. The Concurrent Connections and Concurrent Transactions Resource Types are not supported in the SLM Peer Group scenario. They rely on an instantaneous measurement, while peering is implemented based on the exchange of historical averages.

In general, SLM peer groups allow administrators to configure a set of appliances to share SLM data about a common service. 

For most resource types, the SLM policy will use this shared data in the configured Threshold algorithm while processing the policy. 

In the case of Concurrent Transactions or Concurrent Connections, however, the policy will use the instantaneous value on the device and will not incorporate data from the peer group. 

It is possible to work around this issue in a limited way by reducing the Concurrent thresholds on each peer device (for example, for 2 devices divide in half, for 4 divide into quarters, etc.); however, this is not an ideal solution. The best practice is to use these concurrent resource types without a Peer Group, for protecting the individual DataPower appliance or configured services, and to use another method for protecting the back-end service. 

Keep in mind that this is a permanent limitation with the original implementation of the SLM peering feature. Firmware version 5.0.0 introduces a new type of peering, SLM Multicast Peering, which is not affected by this limitation. SLM Unicast Peering, the type that was previously available, continues to have the limitation in release 5.0 and later.

 

http://www-01.ibm.com/support/docview.wss?uid=swg21404895

  • Trey
    Trey
    224 Posts
    ACCEPTED ANSWER

    Re: SLM Multicast Peering Recommended Practice

    ‏2014-06-04T15:08:31Z  in response to tomiLee

    tell us more about;

    - the number of appliances that will be in the pool

    - are all of the appliance in the same subnet

    - how many slm peer groups to you have

    - what is the current memory usage on the appliances, average usage is fine
    this will help answer your question properly.

    • tomiLee
      tomiLee
      33 Posts
      ACCEPTED ANSWER

      Re: SLM Multicast Peering Recommended Practice

      ‏2014-06-04T15:17:26Z  in response to Trey

      - the number of appliances that will be in the pool - there are two data centers eventually about 6 in each data center (currently 3 in each)

      - are all of the appliance in the same subnet  - yes in each data center

      - how many slm peer groups to you have  - we will plan to have one per datacenter

      - what is the current memory usage on the appliances, average usage is fine - this will help answer your question properly. - I think we use average memory on our XI52s will need to fine this information

       

      Thanks in Advance Trey!

      • Trey
        Trey
        224 Posts
        ACCEPTED ANSWER

        Re: SLM Multicast Peering Recommended Practice

        ‏2014-06-08T14:41:06Z  in response to tomiLee

        The technote works to explain that the unicast method is a simple tcp connection created between the appliances in the group and simply put the latency of creating and sending the SLM peer data can be old by the time the transaction is complete.

        This is where multicast traffic comes in and saves the day but has limits you will want to talk with your network admins about.  I do not say this to be safe or any other reason.  Your network admins should be able to help once they know the appliances will be using multicast to let you know if;

        1- that type of traffic can traverse the datacenters

        2- what the real world latency is expected to be between datacenters

        in the end you may have to keep your slm peers confined to the individual data centers as multicast is non routable.  The rest of your setup sounds fairly typical, slm multicast to a group of 3, growing to 6, appliances for a concurrent policy type.

        I ask about memory because an SLM peer group update can be large depending on the number of transactions being monitored and policy configuration also the receiver of the update has to allocate enough memory to parse and handle the connection table.  Since you say you are running relatively low or reasonable memory usage I would really just suggest that you keep an eye on the peer group members as you add them to the pool.  3 appliances sharing 10 megs worth of connection information every 60 seconds is one thing but 6 appliances sharing 20 meg connection tables with the entire group ever 5 seconds could start to impact performance.  This is just a suggestion to watch resource usage and impact as you create and grow your pool.

        Otherwise this looks like normal usage and multicast is your only option, unicast should not be used for what you have described.

        I hope this helps

         


        For anyone else curious this is the link to the technote text noted above:
        http://www-01.ibm.com/support/docview.wss?uid=swg21404895

    • tomiLee
      tomiLee
      33 Posts
      ACCEPTED ANSWER

      Re: SLM Multicast Peering Recommended Practice

      ‏2014-06-05T12:46:44Z  in response to Trey

      Is there any additional information that we need to provide.  Our memory is pretty low on your XI52s.  We are curious to know if we need to use Peer Groups when we use threshold interval type as concurrent and no resource type.  And if so I would assume we would use Multicast.

      • Trey
        Trey
        224 Posts
        ACCEPTED ANSWER

        Re: SLM Multicast Peering Recommended Practice

        ‏2014-06-10T23:49:42Z  in response to tomiLee

        No, I was meaning it to be a suggestion to monitor in your environment when you deploy the SLM policy.  Using multicast cuts down on the work needed but the number of SLM policies. the peer group settings, the connection volume and rate all are per environment.

        When I work on configuration changes I am always curious how it will impact on resources.  I know you have xi52s but I have seen folks accidentally consume 30gigs of memory with a simple config change and not realize it.  I hope this helps.