cancel
Showing results for 
Search instead for 
Did you mean: 

Pulse Secure vADC

Sort by:
We release major and minor updates to Traffic Manager on a periodic basis, and you are strongly advised to maintain production instances of Traffic Manager on recent releases for support, performance, stability and security reasons.   Where to find updates   Software and Virtual Appliance updates are posted on the http://my.pulsesecure.net site, and updates are announced on the community pages, such as this article.   The update process is designed to be straightforward and minimizes disruption, although instantaneous downtime is inevitable. The process depends on the form factor of your Traffic Manager device:   Upgrading Traffic Manager Software Upgrading Traffic Manager Virtual Appliance   Am I running software or virtual appliance?   You can easily verify if you're running the software-only install (installed on your Linux/Solaris host) or a Virtual Appliance (running on VMware, Xen or another platform) by checking the header of an admin server page: Software install - identifies itself as "Traffic Manager 4000 VH" Virtual Appliance - identifies itself as "Traffic Manager Virtual Appliance 4000 VH"     Updating Cloud Instances of Traffic Manager   The Amazon EC2 instances of Traffic Manager are provided and supported directly by Pulse:   Upgrading Traffic Manager on Amazon EC2   For third-party instances of Traffic Manager, please refer to your cloud provider.   More information   For more detailed information on the installation and upgrade process, please refer to the relevant Getting Started guide in the Product Documentation
View full article
TrafficScript is Traffic Manager's scripting and configuration language that lets you specify precisely how Traffic Manager must handle each type of request, in as much detail as you need. Without TrafficScript, you would have to configure your load balancer with a single, ‘lowest-common-denominator’ policy that describes how to handle all your network traffic. With TrafficScript, you control how Traffic Manager handles your traffic, inspecting and modifying each request and response as you wish, and pulling in each of Traffic Manager's features as you require.   What is TrafficScript?   TrafficScript is a high-level programming language used to create ‘rules’ which are invoked by the traffic manager each time a transaction request or response is received:   TrafficScript rules have full access to all request and response data, and give the you full control over how end users interact with the load balanced services.  They are commonly used to selectively enable particular Traffic Manager features (for example, bandwidth control, caching or security policies) and to modify request and response data to handle error cases or augment web page data.   Although TrafficScript is a new language, the syntax is intentionally familiar.  It is deeply integrated with the traffic management kernel for two reasons:   Performance: the integration allows for very efficient, high-performance interaction with the internal state of the traffic manager Abstraction: TrafficScript presents a very easy-to-use request/response event model that abstracts the internal complexities of managing network traffic away from the developer.   You can use TrafficScript to create a wide range of solutions and the familiar syntax means that complex code can be prototyped and deployed rapidly.   Example 1 - Modifying Requests   # Is this request a video download? $url = http.getPath(); if( string.wildmatch( $url, "/videos/*.flv" ) ) { # Rewrite the request to target an f4v container, not flv $url = string.replace( $url, ".flv", ".f4v" ); http.setPath( $url ); # We encode flash videos at 1088 Kbits max. Apply a limit to 2 Gbit # to control download tools and other greedy clients response.setBandwidthClass( "Videos 2Mbits" ); # We don't want to cache the response in the Stingray cache, even if # the HTTP headers state that it is cacheable http.cache.disable(); } A simple request rule that modifies the request and instructs the traffic manager to apply bandwidth and cache customizations   TrafficScript's close integration with the traffic management kernel makes it as easy to rewrite HTTP responses as HTTP requests:   Example 2 - Modifying Responses   $url = http.getResponseHeader( "Content-Type" ); if( !string.startsWith( $url, "text/html" ) ) break; $response = http.getResponseBody(); $response = string.replaceAll( $response, "http://intranet.mycorp.com/", "https://extranet.mycorp.com/" ); http.setResponseBody( $response ); A response rule that makes a simple replacement to change links embedded in HTTP responses   TrafficScript can invoke external systems in a synchronous or asynchronous fashion:   TrafficScript functions like http.request.get() , auth.query() and net.dns.resolveIP() will query an external HTTP, LDAP or DNS server and return the result of the query.  They operate synchronously (the rule is ‘blocked’ while the query is running) but the Traffic Manager will process other network traffic while the current rule is temporarily suspended. The TrafficScript function event.emit() raises an event to Stingray’s Event Handling system.  The TrafficScript rule continues to execute and the event is processed asynchronously. Events can trigger a variety of actions, ranging from syslog or email alerts to complex user-provided scripts.   These capabilities allow the Traffic Manager to interface with external systems to retrieve data, verify credentials or initiate external control-plane actions.   Example 3 - Accessing an external source (Google News)   $type = http.getResponseHeader( "Content-Type" ); if( $type != "text/html" ) break; # Stop processing this rule $res = http.request.get( "https://ajax.googleapis.com/ajax/services/search/news?". "v=1.0&q=Riverbed" ); $r = json.deserialize( $res ); $rs = $r['responseData']['results']; $html .= "<ul>\n"; foreach( $e in $rs ) { $html .= '<li>' . '<a href="'.$e['unescapedUrl'].'">'.$e['titleNoFormatting'].'</a>'. '</li>'; } $html .= "</ul>\n"; $body = http.getResponseBody(); $body = string.replace( $body, "<!--RESULTS-->", $html); http.setResponseBody( $body ); An advanced response rule that queries an external datasource and inserts additional data into the web page response   TrafficScript rules may also invoke Java Extensions.  Extensions may be written in any language that targets the JVM, such as Python or Ruby as well as Java. They allow developers to use third-party code libraries and to write sophisticated rules that maintain long-term state or perform complex calculations.   Getting started with RuleBuilder   The full TrafficScript language gives you access to over 200 functions, with the support of a proper programming language - variables, tests, loops and other flow control. You can write TrafficScript rules much as you'd write Perl scripts (or Python, JavaScript, Ruby, etc).   The RuleBuilder gives you a UI that lets you configure tests, and actions which are executed if one-of or all-of the tests are satisfied. The tests and actions you can use are predefined, and cover a subset of the full functions of TrafficScript. You can use the RuleBuilder much as you'd use the filtering rules in your email client.   RuleBuilder provides a simple way to create basic policies to control Traffic Manager   If you're not familiar with programming languages, then RuleBuilder is a great way to get started.  You can create simple policies to control Traffic Manager's operation, and then, with one click, transform them into the equivalent TrafficScript rule so that you can learn the syntax and extend them as required.  There's a good example to start with in the Stop hot-linking and bandwidth theft! article.   Examples   Collected Tech Tips: TrafficScript examples Top Examples of Traffic Manager in action (many solutions depend on TrafficScript)   Read More   TrafficScript Guide in the Product Documentation
View full article
Traffic Manager's SOAP Control API is a standards-conformant SOAP-based API that makes it possible for other applications to query and modify the configuration of a Traffic Manager cluster. For example, a network monitoring or intrusion detection system may reconfigure Traffic Manager's traffic management rules as a result of abnormal network traffic; a server provisioning system could reconfigure Traffic Manager when new servers came online.   The SOAP Control API can be used by any programming language and application environment that supports SOAP services.   Examples   Collected Tech Tips: SOAP Control API examples   Read more   SOAP Control API Guide in the Product Documentation
View full article
Overview Traffic Manager's RESTful Control API allows HTTP clients to access and modify Traffic Manager cluster configuration data.  For example a program using standard HTTP methods can create or modify virtual servers and pools, or work with other Traffic Manager configuration objects.   The RESTful Control API can be used by any programming language and application environment that supports HTTP.   Resources   The Traffic Manager RESTful API is an HTTP based and published on port :9070.  Requests are made as standard HTTP requests, using the GET, PUT or DELETE methods.  Every RESTful call deals with a “resource”.  A resource can be one of the following:   A list of resources, for example, a list of Virtual Servers or Pools. A configuration resource, for example a specific Virtual Server or Pool. A file, for example a rule or a file from the extra directory.   Resources are referenced through a URI with a common directory structure.  For this first version of the Traffic Manager RESTful API the URI for all resources starts with “/api/tm/1.0/config/active”, so for example to get a list of pools, the URI would be “/api/tm/1.0/config/active/pools” and to reference the pool named “testpool”, the URI would be “/api/tm/1.0/config/active/pools/testpool.   When accessing the RESTful API from a remote machine, HTTPS must be used, but when accessing the RESTful API from a local Traffic Manager instance, HTTP can be used.   By default, the RESTful API is disabled and when enabled listens on port 9070.  The RESTful API can be enabled and the port can be changed in the Traffic Manager GUI by going to System->Security->REST API.   To complete the example, to reference the pool named “testpool” on the Traffic Manager instance with a host name of “stingray.example.com”, the full URI would be “https://stingray.example.com:9070/api/tm/1.0/config/active/pools/testpool”.  To get a list off all the types of resources available you can access the URL,  “https://stingray.example.com:9070/api/tm/1.0/config/active".   To retrieve the data for a resource you use the GET method, to add or change a resource you use the PUT method and to delete a resource you use the DELETE method.   Data Format   Data for resource lists and configuration resources are returned as JSON structures with a MIME type of "application/json".  JSON allows complex data structures to be represented as strings that can be easily passed in HTTP requests.  When the resource is a file, the data is passed in its raw format with a MIME type of "application/octet-stream".   For lists of resources the data returned will have the format:   { "children": [{ "name": "", "href": "/api/tm/1.0/config/active/pools/" }, { "name": "", "href": "/api/tm/1.0/config/active/pools/" }] }   For example, the list of pools, given two pools, “pool1” and “pool2” would be:   { "children": [{ "name": "pool1", "href": "/api/tm/1.0/config/active/pools/pool1" }, { "children": [{ "name": "pool2", "href": "/api/tm/1.0/config/active/pools/pool2" }] }   For configuration resources, the data will contain one or more sections of properties, always with at least one section named "basic", and the property values can be of different types.  The format looks like:   { "properties": { "<section name>": { "<property name>": "<string value>", "<property name>": <numeric value>, "<property name>": <boolean value>, "<property name>": [<value>, <value>], "<property name>": [<key>: <value>, <key>: <value>] }, "<section name>": { "<property name>": "<string value>", "<property name>": <numeric value>" } }   Accessing the RESTful API   Any client or program that can handle HTTP requests can be used to access the RESTful API. Basic authentication is used with the usernames and passwords matching those used to administer Traffic Manager.  To view the data returned by the RESTful API without having to do any programming, there are browser plug-ins that can be used.  One that is available, is the Chrome REST Console.  It is very helpful during testing to have something like this available.  One nice thing about a REST API is that it is discoverable, so using something like the Chrome REST Console, you can walk the resource tree and see everything that is available via the RESTful API.  You can also add, change and delete data.  For more information on using the Chrome REST Console see: Tech Tip: Using Traffic Manager's RESTful Control API with the Chrome REST Console   When adding or changing data, use the PUT method and for configuration resources, the data sent in the request must be in JSON format and must match the data format returned when doing a GET on the same type of resource.  For adding a configuration resource you do not need to include all properties, just the minimum sections and properties required to add the resource and this will vary for each resource.  When changing data you only need to include the sections and properties that need to be changed.  To delete a resource use the DELETE method.   Notes   An important caution when changing or deleting data is that this version of the RESTful API does do data integrity checking.  The RESTful API will allow you to makes changes that would not be allowed in the GUI or CLI.  For example, you can delete a Pool that is being used by a Virtual Server.  This means that when using the RESTful API, you should be sure to understand the data integrity requirements for the resources that you are changing or deleting and put validation in any programs you write. This release of the RESTful API is not compatible with Multi-Site Manager, so both cannot be enabled at the same time.   Read more   REST API Guide in the Product Documentation Collected Tech Tips: Using the RESTful Control API with Python Tech Tip: Using Stingray's RESTful Control API with the Chrome REST Console
View full article
Traffic Manager's autoscaling capability is intended to help you dynamically control the resources that a service uses so that you can deliver services to a desired SLA, while minimizing the cost.  The intention of this feature is that you can:   Define the desired SLA for a service (based on response time of nodes in a pool)   Define the minimum number of nodes needed to deliver the service (e.g. 2 nodes for fault-tolerance reasons) Define the maximum number of resources (acting as a brake – this limits how much resource Traffic Manager will deploy in the event of a denial of service attack, traffic surge, application fault etc)   You also need to configure Traffic Manager to deploy instances of the nodes, typically from a template in Amazon, Rackspace or VMware.   You can then leave Traffic Manager to provision the notes, and to dynamically scale the number of nodes up or down to minimize the cost (number of nodes) while preserving the SLA.   Details   Autoscaling is a property of a pool.   A pool contains a set of ‘nodes’ – back-end servers that provide a service on an IP address and port.  All of the nodes in a pool provide the same service.  Autoscaling monitors the service level (i.e. response time) delivered by a pool.  If the response time falls outside the desired SLA, then autoscaling will add or remove nodes from the pool to increase or reduce resource in order to meet the SLA at the lowest cost.   The feature consists of a monitoring and decision engine, and a collection of driver scripts that interface with the relevant platform.   The decision engine   The decision engine monitors the response time from the pool.  Configure it with the desired SLA, and the scale-up/scale-down thresholds.   Example: my SLA is 1000 ms.  I want to scale up (add nodes) if less than 40% of transactions are completed within this SLA, and scale-down (remove nodes) if more than 95% of transactions are completed within the SLA.  To avoid flip-flopping, I want to wait for 20 seconds before initiating the change (in case the problem is transient and goes away), and I want to wait 180 seconds before considering another change.     Other parameters control the minimum and maximum number of nodes in a pool, and how we access the service on new nodes:   The driver   Traffic Manager includes drivers for Amazon EC2, Rackspace and VMware vSphere.  You will need to configure a set of ‘cloud credentials’ (authentication details for the management API for the virtual platform):     You'll also need to specify the details of the virtual machine template that instantiates the service in the pool:     The decision engine initiates a scale-up or scale-down action by invoking the driver with the configured credentials and parameters.  The driver instructs the virtualization layer to deploy or terminate a virtual machine.  Once the action is complete, the driver returns the new list of nodes in the pool and the decision engine update the pool configuration.   Notes:   You can manually provision nodes by editing the max-nodes and min-nodes settings in the pool.  If Traffic Manager notices that there is a mismatch between the max/min and the actual number of nodes active, then it will initiate a series of scale-up or scale-down actions.   Creating a custom driver for a new platform   You can create a custom driver for any platform that is capable of deploying new service instances on demand.  Creating a new driver involves:   Create the driver script, that conforms to the API below Upload the script to the Extra Files -> Miscellaneous store using the UI (or copy to $ZEUSHOME/zxtm/conf/extra) Create a Credentials object that contains the uids, passwords etc necessary to talk to the cloud platform:   Configure the pool to autoscale, and provide the details of the virtual machine that should be provisioned:     Specification of the driver scripts   The settings in the UI are interpreted by the Cloud API script. Traffic Manager will invoke this script and pass the details in. Use the ZEUSHOME/zxtm/bin/rackspace.pl or vsphere-client scripts as examples (the ZEUSHOME/zxtm/bin/awstool script is multi-purpose and used by Traffic Manager's handling of EC2 EIPs for failover as well). Arguments:   The scripts should support several actions - status , createnode , destroynode , listimageids and listsizeids . Run --help:     root@stingray-1:/opt/zeus/zxtm/bin# ./rackspace.pl --help Usage: ./rackspace.pl [--help] action options action: [status|createnode|destroynode|listimageids|listsizeids] common options: --verbose=1 --cloudcreds=name other valid options depend on the chosen action:   status: --deltasince=tstamp Only report changes since timestamp tstamp (unix time)   createnode: --name=newname Associate name newname (must be unique) with the new instance               --imageid=i_id Create an instance of image uniquely identified by i_id               --sizeid=s_id  Create an instance with size uniquely identified by s_id   destroynode: --id=oldid destroy instance uniquely identified by oldid   Note: The ' --deltasince ' isn't supported by many cloud APIs, but has been added for Rackspace.  If the cloud API in question supports reporting only changes since a given date/time, it should be implemented.   The value of the --name option will be chosen by the autoscaler on the basis of the 'autoscale!name': a different integer will be appended to the name for each node.   The script should return a JSON-formatted response for each action:   Status action   Example response:     {"NodeStatusResponse": {   "version":1,   "code":200,   "nodes":[    {"sizeid":1,     "status":"active",     "name":"TrafficManager",     "public_ip":"174.143.156.25",     "created":1274688603,     "uniq_id":98549,     "private_ip":"10.177.4.216",     "imageid":8,     "complete":100},    {"sizeid":1,     "status":"active",     "name":"webserver0",     "public_ip":"174.143.153.20",     "created":1274688003,     "uniq_id":100768,     "private_ip":"10.177.1.212",     "imageid":"apache_xxl",     "complete":100}   ] } }   version and code must be JSON integers in decimal notation; sizeid, uniq_id, imageid can be decimal integers or strings.   name must be a string.  Some clouds do not give every instance a name; in this case it should be left out or be set to the empty string.  The autoscaler process will then infer the relevance of a node for a pool on the basis of the imageid (must match 'autoscale!imageid' in the pool's configuration).   created is the unix time stamp of when the node was created and hence must be a decimal integer. When the autoscaler destroys nodes, it will try to destroy the oldest node first.  Some clouds do not provide this information; in this case it should be set to zero.   complete must be a decimal integer indicating the percentage of progress when a node is created.   A response code of 304 to a 'status' request with a '--deltasince' option is interpreted as 'no change from last status request'. CreateNode action   The response is a JSON-formatted object as follows:   {"CreateNodeResponse": {   "version":1,   "code":202,   "nodes":[    {"sizeid":1,     "status":"pending",     "name":"webserver9",     "public_ip":"173.203.222.113",     "created":0,     "uniq_id":230593,     "private_ip":"10.177.91.9",     "imageid":41,     "complete":0}   ] } } The 202 corresponds to the HTTP response code 'Accepted'.   DestroyNode Action   The response is a JSON-formatted object as follows: {"DestroyNodeResponse": {   "version":1,   "code":202,   "nodes":[    {     "created":0,     "sizeid":"unknown",     "uniq_id":230593,     "status":"destroyed",     "name":"unknown",     "imageid":"unknown",     "complete":100}   ] } } Error conditions   The autoscaling driver script should communicate error conditions using responsecodes >= 400 and/or by writing output to stderr. When the autoscaler detects an error from an API script it disables autoscaling for all pools using the Cloud Credentials in question until an API call using those Cloud Credentials is successful.
View full article
Traffic Manager's Content Caching capability allows Traffic Manager to identify web page responses that are the same for each request and to remember (‘cache’) the content. The content may be ‘static’, such as a file on disk on the web server, or it may have been generated by an application running on the web server.   Why use Content Caching?   When another client asks for content that Traffic Manager has cached in its internal web cache, Traffic Manager can return the content directly to the client without having to forward the request to a back-end web server.   This has the effect of reducing the load on the back-end web servers, particularly if Traffic Manager has detected that it can cache content generated by complex applications which consume resources on the web server machine.   What are the pitfalls?   A content cache may store a document that should not be cached.   Traffic Manager conforms to the caching recommendations of RFC 2616, which describe how web browsers and server can specify cache behaviour. However, if a web server is misconfigured, and does not provide the correct cache control information, then a TrafficScript or RuleBuilder rule can be used to override Traffic Manager's default caching logic.   A content cache may need a very large amount of memory to be effective   Depending on the spread of content for your service, and the proportion that is cacheable and frequently used compared to the long tail of less-used content, you may need a very large content cache to get the best possible hit rates.   Traffic Manager allows you to specify precisely how much memory you wish to use for your cache, and to impose fine limits on the sizes of files to be cached and the duration that they should be cached for. Traffic Manager's 64-bit software overcomes the 2-4Gb limit of older solutions, and Traffic Manager can operate with a two-tier (in-memory and on-SSD) cache in situations where you need a very large cache and the cost of server memory is prohibitive.   How does it work?   Not all web content can be cached. Information in the HTTP request and the HTTP response drives Traffic Manager's decisions as to whether or not a request should be served from the web cache, and whether or not a response should be cached.   Requests   Only HTTP GET and HEAD requests are cacheable. All other methods are not cachable. The Cache-Control header in an HTTP request can force Traffic Manager to ignore the web cache and to contact a back-end node instead. Requests that use HTTP basic-auth are uncacheable.   Responses   The Cache-Control header in an HTTP response can indicate that an HTTP response should never be placed in the web cache.  The header can also use the max-age value to specify how long the cached object can be cached for. This may cause a response to be cached for less than the configured webcache!time parameter. HTTP responses can use the Expires header to control how long to cache the response for. Note that using the Expires header is less efficient than using the max-age value in the Cache-Control response header. The Vary HTTP response header controls how variants of a resource are cached, and which variant is served from the cache in response to a new request.   If a web application wishes to prevent Traffic Manager from caching a response, it should add a ‘ Cache-Control: no-cache ’ header to the response.   Debugging Traffic Manager's Cache Behaviour   You can use the global setting webcache!verbose if you wish to debug your cache behaviour. This setting is found in the Cache Settings section of the System, Global Settings page. If you enable this setting, Traffic Manager will add a header named ‘ X-Cache-Info ’ to the HTTP response to indicate how the cache policy has taken effect. You can inspect this header using Traffic Manager's access logging, or using the developer extensions in your web browser.   X-Cache-Info values   X-Cache-Info: cached X-Cache-Info: caching X-Cache-Info: not cacheable; request had a content length X-Cache-Info: not cacheable; request wasn't a GET or HEAD X-Cache-Info: not cacheable; request specified "Cache-Control: no-store" X-Cache-Info: not cacheable; request contained Authorization header X-Cache-Info: not cacheable; response had too large vary data X-Cache-Info: not cacheable; response file size too large X-Cache-Info: not cacheable; response code not cacheable X-Cache-Info: not cacheable; response contains "Vary: *" X-Cache-Info: not cacheable; response specified "Cache-Control: no-store" X-Cache-Info: not cacheable; response specified "Cache-Control: private" X-Cache-Info: not cacheable; response specified "Cache-Control: no-cache" X-Cache-Info: not cacheable; response specified max-age <= 0 X-Cache-Info: not cacheable; response specified "Cache-Control: no-cache=..." X-Cache-Info: not cacheable; response has already expired X-Cache-Info: not cacheable; response is 302 without expiry time   Overriding Traffic Manager's default cache behaviour Several TrafficScript and RuleBuilder cache contrl functions are available to facilitate the control of Traffic Manager’s caching behaviour. In most cases, these functions eliminate the need to manipulate headers in the HTTP requests and responses.   http.cache.disable()   Invoking http.cache.disable() in a response rule prevents Traffic Manager from caching the response. The RuleBuilder 'Make response uncacheable' action has the same effect.   http.cache.enable()   Invoking http.cache.enable() in a response rule reverts the effect of a previous call to http.cache.disable(). It causes Traffic Manager's default caching logic to take effect. Note that it possible to force Traffic Manager to cache a response that would normally be uncachable by rewriting the headers of that response using TrafficScript or RuleBuilder (response rewriting occurs before cachability testing).   http.cache.setkey()   The http.cache.setkey() function is used to differentiate between different versions of the same request, in much the same way that the Vary response header functions. It is used in request rules, but may also be used in response rules.   It is more flexible than the RFC2616 vary support, because it lets you partition requests on any calculated value – for example, different content based on whether the source address is internal or external, or whether the client’s User-Agent header indicates an IE or Gecko-based browser.   This capability is not available via RuleBuilder.   Simple control   http.cache.disable and http.cache.disable allow you to easily implement either 'default on', or 'default off' policies, where you either wish to cache everything cacheable unless you explicity disallow it, or you wish to only let Traffic Manager cache things you explictly allow. For example, you have identified a particular set of transactions out of a large working set that each 90% of your web server usage, and you wish to just cache those requests, and not lets less painful transactions knock these out of the cache. Alternatively, you may be trying to cache a web-based application which is not HTTP compliant in that it does not properly mark up pages which are not cacheable and caching them would break the application. In this scenario, you wish to only enable caching for particular code paths which you have tested to not break the application. An example TrafficScript rule implementing a 'default off' policy might be:     # Only cache what we explicitly allow http.cache.disable(); if( string.regexmatch( http.geturl(), "^/sales/(order|view).asp" )) { # these are our most painful pages for the DB, and are cacheable http.cache.enable(); }     RuleBuilder offers only the simple 'default on' policy, overridden either by the response headers or the 'Make response uncacheable' action.   Caching multiple resource versions for the same URL Suppose that your web service returns different versions of your home page, depending on whether the client is coming from an internal network (10.0.0.0) or an external network. If you were to put a content cache in front of your web service, you would need to arrange that your web server sent a Cache-Control: no-cache header with each response so that the page were not cached. Use the following request rule to manipulate the request and set a 'cache key' so that Traffic Manager caches the two different versions of your page:   # We're only concerned about the home page... if( http.getPath() != "/" ) break; # Set the cache key depending on where the client is located $client = request.getRemoteIP(); if( string.ipmaskmatch( $ip, "10.0.0.0/8" ) ) { http.cache.setkey( "internal" ); } else { http.cache.setkey( "external" ); } # Remove the Cache-Control response header - it's no longer needed! http.removeResponseHeader( "Cache-Control" );     Forcing pages to be cached   You may have an application, say a JSP page, that says it is not cacheable, but actually you know under certain circumstances that it is and you want to force Traffic Manager to cache this page because it is a heavy use of resource on the webserver.   You can force Traffic Manager to cache such pages by rewriting its response headers; any TrafficScript rewrites happen before the content caching logic is invoked, so you can perform extremely fine-grained caching control by manipulating the HTTP response headers of pages you wish to cache.   In this example, as have a JSP page that sets a 'Cache-Control: no-cache' header, which prevents Stingray by caching the page. We can make this response cacheable by removing the Cache-Control header (and potentially the Expires header as well), for example:   if( http.getpath() == "/testpage.jsp" ) { # We know this request is cacheable; remove the 'Cache-Control: no-cache' http.removeResponseHeader( "Cache-Control" ); }   Granular cache timeouts   For extra control, you may wish instead to use the http.setResponseHeader() function to set a Cache-Control with a max-age= paramter to specify exactly how long this particular piece of content should be cached or; or add a Vary header to specify which parts of the input request this response depends on (e.g. user language, or cookie). You can use these methods to set cache parameters on entire sets of URLs (e.g. all *.jsp) or individual requests for maximum flexibility.   The RuleBuilder 'Set Response Cache Time' action has the same effect.   Read more   Stingray Product Documentation Cache your website - just for one second? Managing consistent caches across a Stingray Cluster
View full article
Why do you need Session Persistence?   Consider the process of conducting a transaction in your application - perhaps your user is uploading and annotating an image, or concluding a shopping cart transaction.   This process may entail a number of individual operations - for example, several HTTP POSTs to upload and annotate the image - and you may want to ensure that these network transactions are routed to the same back-end server.  Your application design may mandate this (because intermediate state is not shared between nodes in a cluster), or it just may be highly desireable (for performance and cache-hit reasons).   Traffic Manager's Load Balancing (Feature Brief: Load Balancing in Traffic Manager) will work against you. Traffic Manager will process each network operation independently, and it's very likely that the network transactions will be routed to different machines in your cluster.  In this case, you need to be firm with Traffic Manager and require that all transactions in the same 'session' are routed to the same machine.   Enter 'Session Persistence' - the means to override the load balancing decision and pin 'sessions' to the same server machine.   Session Persistence Methods Traffic Manager employs a range of session persistence methods, each with a different way to identify a session. You should generally select the session persistence method that most accurately identifies user sessions for the application you are load balancing.      Persistence Type Session identifier Session data store IP-based persistence Source IP address Internal session cache Universal session persistence TrafficScript-generated key Internal session cache Named Node session persistence TrafficScript specifies node None Transparent session affinity HTTP browser session Client-side Cookie (set by Stingray) Monitor application cookies Named application cookie Client-side Cookie (set by Stingray) J2EE session persistence J2EE session identifier Internal session cache ASP and ASP.NET session persistence ASP/ASP.Net session identifiers Internal session cache X-Zeus-Backend cookies Provided by backend node Client-side Cookie (set by backend) SSL Session ID persistence SSL Session ID Internal session cache   For a detailed description of the various session persistence methods, please refer to the User Manual (Product Documentation).   Where is session data stored?   Client-side Cookies   Traffic Manager will issue a Set-Cookie header to store the name of the desired node in a client-side cookie.  The cookie identifier and the name of the node are both hashed to prevent tampering or information leakage:   In the case of ‘Monitor Application Cookies’, the session cookie is given the same expiry time as the cookie it is monitoring. In the case of ‘Transparent Session Affinity’, the session cookie is not given an expiry time.  It will last for the duration of the browser session.  See also What's the X-Mapping- cookie for, and does it constitute a security or privacy risk?   Internal session cache   Session data is stored in Traffic Manager in a fixed-size cache, and replicated across the cluster according to the ‘State Synchronization Settings’ (Global Settings).   All session persistence classes of the same type will share the same cache space.  The session persistence caches function in a ‘Least Recently Used’ fashion: each time an entry is accessed, its timestamp is updated. When an entry must be removed to make room for a new session, the entry with the oldest timestamp is dropped.   Controlling Session Persistence   Session persistence ties the requests from one client (ie, in one 'session') to the same back-end server node. It defeats the intelligence of the load-balancing algorithm, which tries to select the fastest, most available node for each request.   In a web session, often it's only necessary to tie some requests to the same server node. For example, you may want to tie requests that begin " /servlet " to a server node, but let Traffic Manager be free to load-balance all other requests (images, static content) as appropriate.   Session Persistence may be a property of a pool - all requests processed by that pool are assigned to a session and routed accordingly - but if you want more control you can control it using TrafficScript.   Configure a session persistence class with the desired configuration for your /servlet requests, then use the following request rule:   if( string.startswith( http.getPath(), "/servlet" ) ) { connection.setPersistenceClass( "servlet persistence" ); }   Missing Session Persistence entries   If a client connects and no session persistence entry exists in the internal table, then the connection will be handled as if it were a new session. Traffic Manager will apply load-balancing to select the most appropriate node, and then record the selection in the session table.  The record will be broadcast to other Traffic Manager machines in the cluster.   Failed Session Persistence attempts   If the session data (client cookie or internal table) references a node that is not available (it has failed or has been removed), then the default behavior is to delete the session record and load-balance to a working node.   This behavior may be modified on a Persistence class basis, to send a ‘sorry’ message or just drop the connection:   Configure how to respond and how to manage the session if a target node cannot be reached   Draining and disabled nodes   If a node is marked as draining then existing sessions will be directed to that node, but no new sessions will be established.  Once the existing sessions have completed, it is safe to remove the node without interrupting connections or sessions.   Traffic Manager provides a counter indicating when the node was last used.  If you wish to time sessions out after 10 minutes of activity, then you can remove the node once the counter passes 10 minutes:   The ‘Connection Draining’ report indicates how long ago the last session was active on a node   If a node is marked as disabled, no connections are sent to it.  Existing connections will continue until they are closed.  In addition, Traffic Manager stops running health monitors against the disabled node.  Disabling a node is a convenient way to take it out of service temporarily (for example, to apply a software update) without removing it completely from the configuration.   Monitoring and Debugging Session Persistence   SNMP and Activity Monitor counters may be used to monitor the behavior of the session cache.  You will observe that the cache gradually fills up as sessions are added, and then remains full.  The max age of cache entries will likely follow a fine saw-tooth pattern as the oldest entry gradually ages and then is either dropped or refreshed, although this is only visible if new entries are added infrequently:     In the first 4 minutes, traffic is steady at 300 new sessions per minute and the session cache fills.  Initially, the max age grows steadily but when the cache fills (after 2 minutes) the max age remains fairly stable as older entries are dropped.  In the last minute, no new entries were added, so the cache remains full and the max-age increases steadily.   The ‘Current Connections’ table will display the node that was selected for each transaction that the traffic manager processed:   Observe that requests have been evenly distributed between nodes 201, 202 and 203 because no session persistence is active   Transaction logging can give additional information.  Access logs support webserver-style macros, and the following macros are useful:   Macro Description %F The favored node; this is a hint to the load-balancing algorithm to optimize node cache usage %N The required node (may be blank): defined by a session persistence method %n The actual node used by the connection; may differ from %F if the favoured node is overloaded, and differ from %N if the required node has failed   Finally, TrafficScript can be used to annotate pages with the name of the node they were served from:     if( http.getResponseHeader( "Content-Type" ) != "text/html" ) break; $body = http.getResponseBody(); $html = '<div style="position:absolute;top:0;left:0;border:1px solid black;background:white">'. 'Served by ' . connection.getNode() . '</div>'; $body = string.regexsub( $body, "(<body[^>]*>)", "$1\n".$html."\n", "i" ); http.setResponseBody( $body );   Final Observations   Like caching, session persistence breaks the simple model of load-balancing each transaction to the least-loaded server.  If used without a full understanding of the consequences, it can provoke strange and unexpected behavior.   The built-in session persistence methods in Traffic Manager are suitable for a wide range of applications, but it’s always possible to construct situations with fragile applications or small numbers of clients where session persistence is not the right solution for the problem at hand.   Session persistence should be regarded as a performance optimization, ensuring that users are directed to a node that has their session data ready and fresh in a local cache. No application should absolutely depend upon session persistence, because to do so would introduce a single point of failure for every users’ session.   Pragmatically, it is not always possible to achieve this. Traffic Manager's TrafficScript language provides the means to fine-tune session persistence to accurately recognize individual sessions, apply session persistence judiciously to the transactions that require it, and implement timeouts if required.   Read more   Session Persistence - implementation and timeouts HowTo: Controlling Session Persistence HowTo: Delete Session Persistence records
View full article
The Traffic Manager Documentation (user manual) describes how to configure and use Traffic Manager's Service Level Monitoring capability. This article summarizes how the SLM statistics are calculated so that you can better appreciate what they mean and how they can be used to detect service level problems.   Overview   Service Level Monitoring classes are used to determine how well a service is meeting a response-time-based service level. One key goal of the implementation of Service Level Monitoring is that the data it measures is not affected by the performance or reliability of the remote clients; as far as possible, the SLM class gives an accurate measure of performance and reliability that measures only the factors that the application administrator has control over.   By default, connections are not measured using Service Level Monitoring classes. Typically, an administrator would select the types of connections he or she is interested in (for example, just requests for .asp resources) and assign those to a service level monitoring class:   connection.setServiceLevelClass( "My SLM Class Name" );   A virtual server may also be configured with a 'default' service level class, so that all of the connections it manages are times using the class.   Timers   Traffic Manager starts a timer for each connection when it receives the request from the remote client. The timer is stopped when either the first data from the server is received, or if the connection is unexpectedly closed (perhaps due to a client or server timeout).   The high-res timer measures the time taken to run any TrafficScript request rules (including the delay if these rules perform a blocking action such as communicating with an external server), the time taken to read any additional request data (such as HTTP body data), the time to connect to a node, write the request and read the first response data.   When the timer is stopped, Traffic Manager checks to see if a Service Level Class was assigned to this connection. If so, the elapsed time is recorded against the SLM class, and the per-second 'max' and 'min' response time managed by the class is updated if necessary. Traffic Manager also maintains a per-second count of how many requests conformed and how many failed to conform.   Note: connections which close unexpectedly before the 'conformance' time limit are disregarded completely because they never completed. Connections which close unexpectedly after the 'conformance' time-limit has passed are counted as non-conforming and the elasped time is counted towards the performance of the SLM class.   Calculations   For each service level class, Traffic Manager maintains a list of the last 10 seconds worth of data in a rolling fashion - min, max and average response times, numbers conforming and non-confirming. When asked for the percentage-confirming for the SLM class, Traffic Manager sums the results from the last 10 seconds.   Note: Traffic Manager commonly runs in multi-process mode (one process per CPU core). In that case, each child process counts SLM data in a shared memory segment, so the results should be consistent no matter which process handles a given connection.   Note: When running in a cluster, Traffic Manager automatically shares and merges SLM data from other members of the cluster. There may be a slight time-delay in the state sharing, so the SLM calculations from different cluster members running in active-active mode may be slightly inconsistent. If the cluster has only one active traffic manager for a given SLM class, the passive traffic managers will be able to 'see' the SLM statistics, but they may be delayed by a second or so.   Using SLM classes   SLM class data may be used in a variety of ways. You can configure 'warning' and 'serious' conformance levels, and Traffic Manager will log whenever the class transits between an 'ok', 'warning' or 'serious' state. The transition can also trigger an event using Traffic Manager's Event Handling capability, and you can assign custom actions to these events.   You can inspect the state of an SLM class in TrafficScript to return an error message or return different content when a service begins to underperform. Service Level Monitoring is a key measurement tool when determining whether or not to prioritize traffic.
View full article
'Server First', 'Client First' and 'Generic Streaming' protocols are the most basic L7 protocol types that Traffic Manager can use to manage traffic. They are useful when managing custom protocols or simple TCP connections because they do not expect the traffic to conform to any specific format. This document describes the difference between Server First, Client First and Generic Streaming protocols, and explains some of the details of managing them.     Server-first protocols Server-first is the simplest. When Traffic Manager receives a connection from a client, it immediately runs any TrafficScript rules, then immediately connects to a back-end server. It then listens on both connections (client-side and server-side) and passes data from one side to the other as it comes.   Load-balancing a simple server-first protocol, such as TIME or MySQL   Server-first protocols may be one-shot protocols such as Time (where the server writes the response data, then immediately closes the connection), or complex protocols like MySQL (where the server opens the dialog with a password challenge).   Client-first Protocols   Client-first is an optimization of server-first. On the client-side, Traffic Manager is only alerted when a connection has been established and data has been received. Traffic Manager then proceeds in the style of server-first, i.e. runs TrafficScript rules, connects to back-end and relays data back and forth. In practice, you can use server-first any time you use client-first, but client-first is more efficient when a client is expected to write the first data.   Load-balancing a client-first protocol such as HTTP   When you use a client-first procotol, you can use TrafficScript rules to inspect the client's request data before making your load-balancing decision.   Server-first with 'server banner'   Server-first with a 'server banner' is a different optimization (to cater for servers which broadcast a banner on connect, such as SMTP). When a client connects, Traffic Manager immediately writes the configured 'server-first banner' to the client, then proceeds as a regular client-first connection. In addition, Traffic Manager slurps and discards the first line or data (terminated by a \n) that the server sends.   Load-balancing a simple server-first protocol with a greeting banner, such as SMTP or FTP   Once again, you can use TrafficScript rules to inspect the client's request data before making your load-balancing decision.   Generic Streaming   Generic Streaming is a very basic connection handing mode that does not allow for any synchronization.  It's best suited for long-lived asynchronous protocols where either party may initiate a transaction, such as WebSockets or chat protocols.   Load-balancing an unsynchronized protocol such as chat or websockets   If the protocol has a well-defined handshake (such as WebSockets) you can attach rules to manage the handshake.  You can create rules that manage the subsequent, asynchronous packets but you should take care not to call TrafficScript functions that would block (such as request.read() ) as these will stall data flowing in the other direction in the connection.   Troubleshooting Protocol problems   Timeouts   All connections have associated timeouts on connect and data. If a connect does not complete within the 'connect' timeout, or the connection is idle for the 'idle timeout', the connection will be discarded.   If it's a server-side connection, it will count as a server failure; three successive failures mark the node as dead.   The timeouts and 'three-failures' count can all be tuned if necessary via the Connection Management settings in the Virtual Server and Pool, and the Global Settings page.   Deadlocks   A request or response rule can cause the connection to block. For example, if Traffic Manager runs a request rule that calls 'request.read()', the connection will block until the required data has been read from the client. During this period, Traffic Manager stops relaying data from the server.   This may stall a connection or even trigger a timeout; be very careful if you use read (or write) TrafficScript functions with a bi-directional protocol.   Examples   The generic protocols typically function 'out-of-the-box' - all of the other protocols implemented by Traffic Manager layer on top of these and add protocol-specific handlers and optimizations.   Inspecting and managing generic protocols is challenging.  The following articles describe such advanced use of these protocols:   Virtual Hosting FTP services Managing WebSockets traffic with Traffic Manager Building a load-balancing MySQL proxy with TrafficScript
View full article
What is Load Balancing?   Load Balancing is one of the many capabilities of Traffic Manager:   Load Balancing is one of the many capabilities of Traffic Manager   Load Balancing distributes network traffic across a ‘pool’ of servers (‘nodes’), selecting the most appropriate server for each individual request based on the current load balancing policy, session persistence considerations, node priorities and cache optimization hints.  Under certain circumstances, if a request fails to elicit a response from a server, the request may be tried against multiple nodes until a successful response is received.   Load Balancing meets several primary goals:   Scalability: The capability to transparently increase or decrease the capacity of a service (by adding or removing nodes) without changing the public access point (IP address, domain name or URL) for the service; Availability: The capability to route traffic to working nodes and avoid nodes that have failed or are under-performing; is the ability of a site to remain available and accessible even during the failure of one or more systems. Manageability: By abstracting the server infrastructure from the end user, load balancing makes it easy to remove nodes for maintenance (software or hardware upgrades or scheduled reboots) without interrupting the user experience.   Load Balancing also addresses performance optimization, supporting Traffic Manager's ability to deliver the best possible service level from your server infrastructure.   How does load balancing work?   For each request, Traffic Manager will select a ‘pool’ of servers to handle that request.  A pool represents a collection of servers (‘nodes’) that each performs the same function (such as hosting a web applications). The pool will specify a load-balancing algorithm that determines which of the nodes in that pool should be selected to service that request.   In some cases, Traffic Manager will then make a new connection to the selected node and forward the request across that connection.  In the case of HTTP, Traffic Manager maintains a collection of idle ‘keepalive’ connections to the nodes, and will use one of these established connections in favor of creating a new connection.  This reduces latency and reduces the connection-handling overhead on each server node.   What Load Balancing methods are available?   Traffic Manager offers multiple different load balancing algorithms:   Round Robin and Weighted Round Robin:  With these simple algorithms, the traffic manager cycles through the list of server nodes, picking the next one in turn for each request that it load-balances.  If nodes are assigned specific weights, then they are selected more or less frequently in proportion to their weights. Random: The traffic manager selects a node from the pool at random each time it performs a load-balancing decision. Least Connections and Weighted Least Connections: The traffic manager maintains a count of the number of ongoing transactions against each node.  On each load balancing decision, the traffic manager selects the node with the fewest ongoing connections.  Weights may be applied to each node to indicate that the node is capable of handing more or fewer concurrent transactions than its peers. Fastest Response Time: The traffic manager maintains a rolling average of the response time of each node.  When it makes a load-balancing decision, it selects the node with the lowest average response time. Perceptive: The Perceptive method addresses undesired behaviors from the least connections and fastest algorithms, blending the information to predict the optimal node based on past performance and current load.   A TrafficScript rule can override the load balancing decision, using either the ‘named node’ session persistence method to specify which node in the pool should be used, or by using the ‘forward proxy’ capability to completely ignore the list of nodes in the pool and explicitly specify the target node (IP address and port) for the request.   What factors influence the load balancing decision?   Other than the method chosen and the weights, a number of other factors influence the load-balancing decision:   Health Monitoring: Traffic Manager monitors the health and correct operation of each node, using both synthetic transactions (built-in and user-defined) and passive monitoring of real transactions.  If a node consistently fails to meet the health and operation parameters, Traffic Manager will temporarily remove it from future load-balancing decisions until health checks indicate that it is operating correctly again. Session Persistence: Session Persistence policies override the load balancing decision and may be used easily to pin transactions within the same session to the same server node.  This behavior is mandatory for stateful HTTP applications, and is useful for HTTP applications that share state but gain performance improvements if local state caches are used effectively. Locality-aware Request Distribution (LARD): LARD is automatically used to influence the least-connections, fastest-response-time and perceptive load balancing decisions for HTTP traffic.  If the metrics used for load-balancing decisions are finely-balanced (for example, several nodes have very similar response times or current connection counts), then Traffic Manager will also consider the specific URL being requested and will favor nodes that have served that URL recently.  These nodes are more likely to have the requested content in memory or in cache, and are likely to be able to respond more quickly than nodes that have not serviced that request recently. Past History: The perceptive algorithm builds a past history of node performance and uses this in its load balancing decision.  If a new node is introduced into the cluster, or a failed node recovers, no history exists for that node. The Perceptive Algorithm performs a ‘gradual start’ of that node, slowly ramping up the amount of traffic to that node until its performance stabilizes.  The ‘gradual restart’ avoids the problem that a node with unknown performance is immediately overloaded with more traffic than it can cope with, and the duration of the ramp up of the traffic adapts to how quickly and reliably the node responds.   What is connection draining?   To assist administrators who need to take a node out of service, Traffic Manager provides a ‘connection draining’ capability.  If a node is marked as ‘draining’, Stingray will not consider it during the load balancing decision and no new connections will be made to that node.  Existing connections can run to completion, and established, idle HTTP connections will be shut down.   However, session persistence classes override load balancing decisions.  If any sessions have been established to the draining node, then requests in that session will use the node.  There is no automatic way to determine when a client session has competed, but Traffic Manager provides a ‘most recently used’ report than indicates when a node was last used.  For example, if you are prepared to time sessions out after 20 minutes, then you can safely remove the node from the pool once the ‘most recently used’ measure exceeds 20 minutes.   Administrators may also mark nodes as ‘disabled’.  This has the same effect as ‘draining’, except that existing sessions are not honored and health-monitors are not invoked against ‘disabled’ nodes.  Once a node is ‘disabled’, it can be safely shut down and reintroduced later.   What Load Balancing method is best?   Least Connections is generally the best load-balancing algorithm for homogeneous traffic, where every request puts the same load on the back-end server and where every back-end server is the same performance. The majority of HTTP services fall into this situation. Even if some requests generate more load than others (for example, a database lookup compared to an image retrieval), the ‘least connections’ method will evenly distribute requests across the machines and if there are sufficient requests of each type, the load will be very effectively shared. However, Least Connections is not appropriate when infrequent high-load requests cause significant slowdowns. The Fastest Response Time algorithm will send requests to the server that is performing best (responding most quickly), but it is a reactive algorithm (it only notices slowdowns after the event) so it can often overload a fast server and create a choppy performance profile.   Perceptive is designed to take the best features of both ‘Least Connections’ and ‘Fastest Response’. It adapts according to the nature of the traffic and the performance of the servers; it will lean towards 'least connections' when traffic is homogeneous, and 'fastest response time' when the loads are very variable. It uses a combination of the number of current connections and recent response times to trend and predict the performance of each server. Under this algorithm, traffic is introduced to a new server (or a server that has returned from a failed state) gently, and is progressively ramped up to full operability. When a new server is added to a pool, the algorithm tries it with a single request, and if it receives a reply, it gradually increases the number of requests it sends the new server until it is receiving the same proportion of the load as other equivalent nodes in the pool. This ramping is done in an adaptive way, dependent on the responsiveness of the server. So, for example, a new web server serving a small quantity of static content will very quickly be ramped up to full speed, whereas a Java application server that compiles JSPs the first time they are used (and so is slow to respond to begin with) will be ramped up more slowly.   Least Connections is simpler and more deterministic than ‘Perceptive’, so should be used in preference when possible.   When are requests retried?   Traffic Manager monitors the response from each node when it forwards a request to it. Timeouts quickly detect failures of various types, and simple checks on the response body detect server failures.   Under certain, controlled circumstances, Traffic Manager will retry the request against another node in the pool. Traffic Manager will only retry requests that are judged to be ‘idempotent’ (based on guidelines in the HTTP specification – this includes requests that use GET and HEAD methods), or requests that failed completely against the server (no request data was written before the failure was detected).  This goes a long way to avoiding undesired side effects, such as processing a financial transactions twice.   In rare cases, the guidelines may not apply.  A administrator can easily indicate that all requests processed by a virtual server are non-idempotent (so should never be retried), or can selectively specify the status of each request to override the default decision.   Detecting and retrying when an application generates an error   Traffic Manager rules can also force requests to be retried. For example, a response rule might inspect a response, judge that it is not appropriate, and then instruct the traffic manager to re-try the request against a different node: Hiding Application Errors   Rules can also transparently prompt a client device to retry a request with a different URL (for example).  For example, a rule could detect 404 Not Found errors and prompt the client to try requesting the parent URL, working up the URL hierarchy until the client receives a valid response or cannot proceed any further (i.e. past the root page at ‘/’): No more 404 Not Found...?   Global Load Balancing   Traffic Manager also provides a ‘Global Server Load Balancing’ capability that manages DNS lookups to load-balance users across multiple datacenters. This capability functions in a different fashion to the server load balancing described in this brief.   Conclusion   ADCs today provide much more granular control over all areas that affect application performance. The ability to deliver advanced layer 7 services and enhanced application performance with ADCs is based on the foundation of a basic load balancing technology. Traffic Manager (vTM) is full software and virtual ADC that has been designed as a full-proxy, layer 7 load balancer. Traffic Manager's load balancing fabric enables applications to be delivered from any combination of physical, virtual or cloud-based datacenters.
View full article
In situations where TrafficScript does not provide the necessary functionality, you may wish to turn to a  general-purpose language.  In this case, TrafficScript can call out to a locally-installed JVM (Java Virtual Machine) and invoke a ‘Java Extension’ to perform the necessary processing:   This allows you to run code written in a variety of languages (Python and Ruby can target the JVM as well as Java), and to use third-party libraries to provide functionality that would be difficult to code up in TrafficScript. For example, you can use a Java Extension and the relevant class libraries to inspect image and pdf data ‘on-the-wire’ and apply watermarks or stenography to secure the data and trace unauthorized redistribution.  Java Extensions provide a means to interface with third-party systems that are not natively supported by TrafficScript, such as a MySQL or Oracle databases, or an XML-RPC server.  Finally, they make it easier to accumulate data outside of the regular request/response event model and act on that data asynchronously.   How do Java Extensions function? Traffic Manager Java Extensions use an extended version of the standard Java Servlet API that adds implementations of significant TrafficScript control functions and allows a chain of Java Extensions to process requests and responses.    A Java Extension is loaded into the local JVM on demand (the first time java.run( 'ExtensionName' ) is invoked). Traffic Manager passes the basic request (and response) data to the extension and then invokes the servlet 'service' or 'doGet' method in the extension.  The extension runs to completion and then control is handed back to the TrafficScript rule that invoked it. Java Extensions run in a dedicated Java Virtual Machine (JVM), on the same server system as the core Traffic Manager traffic management software. The JVM isolates the Java Extensions from the Traffic Manager kernel, so that extensions can safely perform operations such as database access without blocking or unduly interfering with the Traffic Manager kernel. The Java Extensions engine can run multiple extensions concurrently (subject to a global limit), and extensions can build up and store persistent data, spawn threads for background processing tasks and perform all manner of blocking operations, subject to configured connection timeouts. The engine supports remote debugging and hot code patching so that running extensions can be debugged and updated on-the-fly. Java Extensions may be used against HTTP and non-HTTP traffic, and may also be used to implement additional functions that can be called from TrafficScript.  Extensions can be written in Java, Python or Ruby.   What can you do with Java Extensions?   Java Extensions let you draw on the capabilities of Java, the functionality of the JRE and the huge variety of supporting Java class libraries. You can perform detailed content inspection and modification, communicate with external databases, applications and services, and implement very sophisticated application delivery logic.   Possible applications include:   Content Watermarking - protect intellectual property by applying unique visible or hidden watermarks to outgoing documents or images; Authentication, Authorization and Access Control - checking user credentials against an LDAP, Radius, TACACS+, Active Directory or other database and applying access control; Proxying multiple applications behind a single-sign-on gateway, using Java Extensions to create the necessary the logic to broker, authenticate and translate requests between remote clients and the different back-end applications and services; Application Mash-ups, built from multiple different sources. Java Extensions can even communicate with raw sockets to interface with proprietary applications; XML Signature Verification and Generation - verify and strip signatures from incoming XML data, or replace signatures with locally generated ones to indicate that a document has passed initial checking at the gateway; Transaction logging and alerting, logging key events to a remote database or raising an alert, reconfiguring Stingray via the Control API or performing other custom actions as appropriate; Complex Request Routing based on location data, URL hash values or real-time information retrieved from an external database or service.   Examples   Collected Tech Tips: Java Extension Examples   Read More   Traffic Manager Java Development Guide in the Product Documentation
View full article
Feature briefs   Feature Brief: Introduction to the Traffic Manager Architecture Feature Brief: Load Balancing in Traffic Manager Feature Brief: Session Persistence in Traffic Manager Feature Brief: Application Acceleration with Stingray Traffic Manager Feature Brief: TrafficScript Feature Brief: Server First, Client First and Generic Streaming Protocols Feature Brief: Clustering and Fault Tolerance in Traffic Manager Feature Brief: Health Monitoring in Traffic Manager Feature Brief: Content Caching with Traffic Manager Feature Brief: Bandwidth and Rate Shaping in Traffic Manager Feature Brief: Autoscaling with Traffic Manager Feature Brief: Service Level Monitoring Feature Brief: Event Handling in Traffic Manager Feature Brief: Java Extensions in Traffic Manager Feature Brief: Traffic Manager's RESTful Control API Feature Brief: Traffic Manager's SOAP Control API   Product Documentation Deployment Guide - Global Load Balancing with Parallel DNS   Other product briefs   Installation and Configuration   Hardware and Software requirements for Traffic Manager Kernel Modules for Linux Software A guide to Policy Based Routing with Stingray (Linux and VA) Techniques for Direct Server Return with Traffic Manager Tuning Traffic Manager IP Transparency: Preserving the Client IP address in Traffic Manager   Operation   Ten Administration good practices What happens when Traffic Manager receives more HTTP connections than the servers can handle? Connection mirroring and failover with Traffic Manager Managing consistent caches across a Traffic Manager Cluster Session Persistence - implementation and timeouts   TrafficScript   How is memory managed in TrafficScript? Investigating the performance of TrafficScript - storing tables of data Evaluating and Prioritizing Traffic with Traffic Manager Managing XML SOAP data with TrafficScript   Other briefs   Introducing Zeusbench     Technical Tips: How to use Stingray Traffic Manager   Collected Tech Tips: TrafficScript examples Collected Tech Tips: Java Extension Examples Collected Tech Tips: Using the RESTful Control API Collected Tech Tips: SOAP Control API examples
View full article
Traffic Manager operates as a layer 7 proxy.  It receives traffic on nominated IP addresses and ports and reads the client request.  After processing the request internally, Traffic Manager selects a candidate 'node' (back-end server).  It writes the request using a new connection (or an existing keepalive connection) to that server and reads the server response. Traffic Manager processes the response, then writes it back to the client.    Traffic Manager performs a wide range of traffic inspection, manipulation and routing tasks, from SSL decryption and service protection, through load balancing and session persistence, to content compression and bandwidth management.  This article explains how each task fits within the architecture of Traffic Manager. Virtual Servers and Pools The key configuration objects in Traffic Manager are the Virtual Server and the Pool: The Virtual Server manages the connections between the remote clients and Traffic Manager. It listens for requests on the published IP address and port of the service.   The Pool manages the connections between Traffic Manager and the back-end nodes (the servers which provide the service). A pool represents a group of back-end nodes.   Everything else   All other data-plane (relating to client traffic) functions of Traffic Manager are associated with either a virtual server or a pool: Health Monitors run asynchronously, probing the servers with built-in and custom tests to verify that they are operating correctly.  If a server fails, it is taken out of service.   1. Virtual Server's processing (request)   The Virtual Server listens for TCP connections or UDP datagrams on its nominated IP and port.  It reads the client request and processes it:   SSL Decryption is performed by a virtual server. It references certificates and CRLs that are stored in the configuration catalog. Service Protection is configured by Service Protection Classes which reside in the catalog. Service Protection defines which requests are acceptable, and which should be discarded immediately. A Virtual Server then executes any Request Rules. These rules reside in the catalog. They can manipulate traffic, and select a pool for each request.   2. Pool's processing   The request rules may select a pool to handle the request. If they complete without selecting a pool, the virtual server's 'default pool' is used:   The pool performs load-balancing calculations, as specified by its configuration. A number of load balancing algorithms are available. A virtual server's request rule may have selected a session persistence class, or a pool may have a preferred session persistence class. In this case, the pool will endeavour to send requests in the same session to the same node, overriding the load-balancing decision. Session persistence classes are stored in the catalog and referenced by a pool or rule. Finally, a pool may SSL-encrypt traffic before sending it to a back-end node. SSL encryption may reference client certificates, root certs and CRLs in the catalog to authenticate and authorize the connection.   3. Virtual Servers's processing (response ) The pool waits for a response from a back-end node, and may retry requests if an error is detected or a response is not received within a timeout period. When a response is received, it is handed back to the virtual server: The virtual server may run Response Rules to modify the response, or to retry it if it was not acceptable. Response rules are stored in the catalog. A virtual server may be configured to compress HTTP responses. They will only be compressed if the remote client has indicated that they can accept compressed content. The virtual server may be configured to write a log file entry to record the request and response. HTTP access log formats are available, and formats for other protocols can be configured. A request rule may have selected a Service Level Monitoring class to monitor the connection time, or the virtual server may have a default class. These servive level monitoring classes are stored in the catalog, and are used to detect poor response times from back-end nodes. Finally, a virtual server may assign the connection to a Bandwidth Management Class. A bandwidth class is used to restrict the bandwidth available to a connection; these classes are stored in the catalog.   Many of the more complex configuration objects are stored in the configuration catalog. These objects are referenced by a virtual server, pool or rule, and they can be used by a number of different services if desired.   Other configuration objects Two other configuration objects are worthy of note:   Monitors are assigned to a pool, and are used to asynchronously probe back-end nodes to detect whether they are available or not. Monitors reside in the catalog. Traffic IP Groups are used to configure the fault-tolerant behavior of Traffic Manager. They define groups of IP addresses that are shared across a fault-tolerant cluster.   Configuration Core service objects - Virtual Servers, Pools, Traffic IP Groups - are configured using the 'Services' part of the Traffic Manager Admin server: Catalog objects and classes - Rules, Monitors, SSL certificates, Service Protection, Session Persistence, Bandwidth Management and Service Level Monitoring classes - are configured using the 'Catalogs' part of the Traffic Manager Admin server: Most types of catalog objects are referenced by a virtual server or pool configuration, or by a rule invoked by the virtual server.   Read more   For more information on the key features, refer to the Product Briefs for Traffic Manager      
View full article
Traffic Manager operates as a TCP/UDP proxy.  It receives traffic from remote clients, processes it internally, and then hands it off to a pool.  The pool performs a load balancing decision to pick a back-end server, and then forwards the traffic to that server node.   Traffic Manager has two main methods to verify the correct operation of a back-end server. If it detects that a server has failed, it will stop sending traffic to it until the server has recovered and can be re-introduced back into the pool of servers.   Passive Health Monitoring is a basic technique that checks each response from a back-end server. It uses live traffic to detect a limited range of errors (it is not application aware), and end-users may experience slow or broken responses while the health monitors seek to confirm that the node has failed. Active Health Monitoring uses synthetic transactions to regularly probe each node to verify correct operation. It can detect a very wide range of application-level failures, and will detect node failures independently of managing live traffic. In most cases, both health monitoring techniques are used together to assure the availability of the service.   Passive Health Monitoring   Every time Traffic Manager forwards a request to a back-end server, it verifies that a response is received. A number of tests are performed:   If the connection is refused, or is not established within the max_connect_time setting (default 4 seconds), the request is considered to have failed; If the connection is closed prematurely, or if the beginning of a response is not received within max_reply_time seconds (default 30 seconds), the request is considered to have failed; SSL only: if the SSL handshake to the node fails, the request is considered to have failed; HTTP only; if an invalid HTTP response or a 503 status code is received, the request is considered to have failed.   The max_connect_time and max_reply_time settings are properties of the Connection Management settings in a Pool. If these tests fail, then the request may be retried against another node in the pool, depending on the Idempotent status of the request. The request may be tried against all of the working nodes in the pool before the traffic manager gives up. If the traffic manager does give up, it either drops the connection or returns a custom error message (Virtual Server -> Connection Management -> Connection Error Settings).   If requests to a particular back-end server fail 3 times in a row (node_connection_attempts), then Traffic Manager assumes that the back-end server has failed. Traffic Manager does not send the server any new requests for a period of time (node_fail_time, default 60 seconds) and then speculatively sends it requests occasionally to probe it, to determine whether or not it has recovered.   When a node recovers, the perceptive load balancing algorithm will gradually ramp up traffic to the new node: Tech Tip: Perceptive Load Balancing.  The 'Fastest Response Time' algorithm has similar behavior; other load balancing algorithms will immediately load up the node with new requests.   Summary   Passive Health Monitoring is basic and very easy to configure. However, it only performs basic tests to verify the health of a server, so it cannot detect application-level failures other than '503' HTTP responses. Furthermore, Passive Health Monitoring only detects failures when Traffic Manager attempts to forward a request to a back-end node, so some clients may experience a slow or broken response while Traffic Manager attempts to verify whether the node has failed or not.   Active Health Monitoring   Traffic Manager may be configured with explicit health monitors. These health monitors perform periodic tests and verify the correct operation of each node. By using health monitors, the traffic manager can detect failures even when no traffic is being handled.   The tests are performed at configured intervals against each node in a pool (defined per-health-monitor). If the monitors fail sufficiently often, that node is marked as unavailable and the traffic manager will stop sending traffic to that node.   The monitors are held in the Monitors Catalog and can be applied to any pool. Each performs a specific test, ranging from simple operations, such as pinging each node, to more sophisticated tests which check that the appropriate port is open and the node is able to serve specified data, such as your home page. You may also create custom health monitors to perform sophisticated tests against your servers.   Summary   Active Health Monitors are very effective at determining the correct operation of each back-end server and are able to detect a wide range of network and application failures.   Logging and debugging health monitoring   Whenever a node fails or recovers, a log message is written to Traffic Manager's event log, and an event is raised.   The Virtual Server setting log!server_connection_failures may be used to log request failures against back-end servers and will help to track how passive health monitoring is functioning.   Each active Health Monitor has a verbose configuration setting that may be used to log the result of each test that is conducted.   Note that when a node fails, it may take several seconds for a health monitor to detect that it has failed (a combination of the delay, timeout and failures settings). Passive Health Monitoring will not detect the failure until Traffic Manager has attempted to send sufficient live traffic to the node.   Find out more Please refer to the Health Monitoring chapter in the User Manual (Product Documentation) for a more detailed description of the various methods used to measure server health.    
View full article
Traffic Manager's sophisticated 'Event Handling' system allows an administrator to configure precisely what actions Traffic Manager should take when a wide range of events occur.  The range of events covers internal changes (configuration modified, SSL certificate timing out), external changes (back-end server failure, service-level class falling outside parameters) and traffic-initiated events (trafficscript rule raising an event due to certain user traffic). Traffic Manager can be configured to perform any of a range of actions when an event is raised - log a message, raise an SNMP trap or syslog alert, send an email or even run a custom script: The Event Handler configuration maps groups of events to user-defined actions Configuration   Traffic Manager already contains one built-in event handler that causes all events to be written to the global Event Log. This built-in handler and its "Log all Events" action can not be deleted, but you can add additional actions if required. You can add additional event handlers, such as the handler illustrated above that sends an email when there is a problem with a license key.   Components of an Event Handler   Each Event Handler is triggered by events of a particular type. When an event that matches the Event Type occurs, the Event Handler will invoke the Action it is configured to perform:   An Event Type is a set of events that can trigger an Event Handler. Traffic Manager includes a number of predefined event types, such as 'Service Failed' or 'Any critical problem', so that you can easily create simple event handlers, such as 'email the administrator if any part of the infrastructure fails'.  You can create new event types, and even create new events that you can raise from TrafficScript or Java Extensions. There are a number of built-in Actions, such as 'send an SNMP trap', and you can create additional actions using either the SOAP alerting interface or scripts and programs that you can upload to Traffic Manager.   Event formats   Information about the event is provided to the action that it triggered in the following format:   LEVEL (tab) [section] (tab) primary tag (tab) [tags (tab)]* text   LEVEL may be one of 'INFO' (for example, a configuration file was modified), 'WARNING' (for example, a node in a pool failed), 'SERIOUS' (for example, all of the nodes in a pool have failed) or 'FATAL' (a catastrophic error that prevents the traffic manager from functioning).   For example, if you stop a virtual server called 'Server1' the following event will be raised:   INFO (tab) vservers/Server1 (tab) vsstop (tab) Virtual server stopped   The first two components indicate that the event is an informational message about the virtual server "Server1". The primary tag, vsstop , defines what has happened to that virtual server. There are no additional tags because this event does not affect any other aspects of the configuration. Finally there is a human-readable description of the event that occurred.   You can find a full list of the events that may be raised in the Traffic Manager UI:   Create a set of events: there are 100's of event that can be trapped and acted upon...   Raising events from TrafficScript   You can use the TrafficScript function ' event.emit() ' to raise an event.  For example, you may wish to log certain requests to the main Event Log, and this is an appropriate way to do so.   Read more   Custom event handling in Traffic Manager Traffic Managers can Tweet Too
View full article
Multi-hosted IP addresses allow the same traffic IP to be hosted on multiple traffic managers at the same time. This can provide benefits to traffic distribution and reduce the number of IPs needed to run a service.   For a background on Traffic Manager's Fault Tolerance and Clustering approach, please refer to the document Feature Brief: Clustering and Fault Tolerance in Traffic Manager.   How do Multi-Hosted IP addresses work? Multi-hosted IPs make use of multicast MAC addresses.  When Traffic Manager observes an ARP for the target traffic IP address, it responds with a multicast MAC address that is calculated based on the value of the multicast IP address used for clustered communications:       The upstream switch will relay packets destined to the traffic IP address to that MAC address; because it's a multicast MAC, the switch will learn which nodes are using that MAC address and forward the traffic to each (problems with switches learning the location of MAC address - check out this solution: Why can't users connect to my multi-hosted IPs?). The zcluster kernel module ( Kernel Modules for Linux Software) implements a filter in the hosts TCP stack that partitions the traffic to that traffic IP address and discards all but the host's share of the traffic. The method used to determine the shares that each host takes is stable and guarantees statistically-perfect distribution of traffic.  It handles failover gracefully, redistributing the failed traffic share evenly between the remaining traffic managers, while ensuring that the remaining traffic managers don't need to rebalance their own shares to preserve the statistically-perfect distribution, and it does so in a stable fashion that does not require any per-connection synchronization or inter-cluster negotiation.   In more detail Suppose you have 4 traffic managers in a cluster, all listening on the same user-specified IP address.  These traffic managers all ARP the same multicast MAC address so the switch forwards all incoming traffic to that IP to all traffic managers. The zcluster kernel module will: Take source IP, source port, destination IP, destination port (this is sufficient to identify a TCP or UDP session) and hash them together Give its local traffic manager a fixed quarter of the hash space and silently discard the remaining 3-quarters   This means that every connection is handled by just one traffic manager and connections are evenly distributed (on a statistical basis) between traffic managers.   If one or more traffic managers fail, then the distribution method makes three guarantees:   The hash space is balanced perfectly equally between the running traffic managers When a traffic manager fails or recovers, the only part of the hash space that is redistributed is the portion relating to that traffic manager (i.e. it’s not necessary to move any of the hash space between running traffic managers to rebalance) The method only depends on the instantaneous state of the cluster   This means that the only ‘synchronization’ is the shared view of the health of the cluster (i.e. for the method to be stable, each running traffic manager has the same view as to which traffic managers are running and which are failed).  Traffic Manager's health broadcasts ensure that this is the case (apart from possible momentary differences when one or more traffic managers fail or recover).   A worked example   Suppose you have four traffic managers, A, B, C and D.  They each get 1/4 of the hash space.   Traffic manager D fails: its 1/4 is shared three ways between A, B and C (so the hash space is still balanced) Traffic manager C fails: its original 1/4 and the 1/3 * 1/4 it inherited from D are both split half and half between A and B Traffic manager D recovers: Traffic managers A and B stop listening for 1/3 of their traffic (i.e. all of the traffic they inherited from D and 1/3rd of the traffic they inherited from C), and D starts listening for the portions that A and B released   Observations   Multi-hosted Traffic IP addresses are useful when you want to ensure even distribution of traffic across a cluster (for example, to spread SSL processing load) or when you have a very limited number of public IP addresses at your disposal.   They do replicate ingress traffic across multiple ports in the internal network.  The implication of this is that each Traffic Manager needs the same ingress bandwidth as the upstream switch; this is rarely a significant problem.   There is a built-in limit of 8 - the maximum number of traffic managers that can be present in a multi-cast traffic IP group.   Using Multi-Hosted traffic IP groups with IP transparency to your back-end servers is challenging.  You need to configure appropriate source-based routing on each back-end server so that it directs the egress traffic to the correct node in the cluster.
View full article
This technical brief discusses Traffic Manager's Clustering and Fault Tolerance mechanisms ('TrafficCluster').   Clustering Traffic Managers are routinely deployed in clusters of two or more devices, for fault-tolerance and scalability reasons:     A cluster is a set of traffic managers that share the same basic configuration (for variations, see 'Multi-Site Management' below).  These traffic managers act as a single unit with respect to the web-based administration and monitoring interface: configuration updates are automatically propagated across the cluster, and diagnostics, logs and statistics are automatically gathered and merged by the admin interface.   Architecture - fully distributed, no 'master'   There is no explicit or implicit 'master' in a cluster - like the Knights of the Round Table, all Traffic Managers have equal status.  This design improves reliability of the cluster as there is no need to nominate and track the status of a single master device.   Administrators can use the admin interface on any Traffic Manager to manage the cluster.  Intra-cluster communication is secured using SSL and fingerprinting to protect against the interception of configuration updates or false impersonation (man-in-the-middle) of a cluster member.   Note: You can remove administration privileges from selected traffic managers by disabling the control!canupdate configuration setting for those traffic managers.  Once a traffic manager is restricted in that way, its peers will refuse to accept configuration updates from it, and the administration interface is disabled on that traffic manager.  If a restricted traffic manager is in some way compromised, it cannot be used to further compromise the other traffic managers in your cluster.   If you find yourself in the position that you cannot access any of the unrestricted traffic managers and you need to promote a restricted traffic manager to regain control, please refer to the technical note What to do if you need to access a restricted Traffic Manager.   Traffic Distribution across a Cluster Incoming network traffic is distributed across a cluster using a concept named 'Traffic IP Groups'.   A Traffic IP Group contains a set of floating (virtual) IP addresses (known as 'Traffic IPs') and it spans some or all of the traffic managers in a cluster: The Traffic Manager Cluster contains traffic managers 1, 2, 3 and 4.   Traffic IP Group A contains traffic IP addresses 'x' and 'y' and is managed by traffic managers 1, 2 and 3.   Traffic IP Group B contains traffic IP address 'z' and is managed by traffic managers 3 and 4. The traffic managers handle traffic that is destined to the traffic IP addresses using one of two methods:   Single-hosted traffic IP groups:  If a group is configured to operate in a 'single-hosted' fashion, each IP address is raised on a single traffic manager.  If there are multiple IP addresses in the group, the IP addresses will be shared between the traffic managers in an even fashion. Multi-hosted traffic IP groups:  If a group is configured to operate in a 'multi-hosted' fashion, each IP address is raised on all of the traffic managers.  The traffic managers publish the IP address using a multi-cast MAC address and employ the zcluster Kernel Modules for Linux Software module to filter the incoming traffic so that each connection is processed by one traffic manager, and the workload is shared evenly.   Single-hosted is typically easier to manage and debug in the event of problems because all of the traffic to a traffic IP address is targetted to the same traffic manager.  In high-traffic environments, it's common to assign multiple IP addresses to a single-hosted traffic IP group and let the traffic managers distribute those IP addresses evenly.  Publish all of the IP addresses in a round-robin DNS fashion.  This gives approximately even distribution of traffic across these IP addresses.   Multi-hosted traffic IP groups are more challenging to manage, but they have the advantage that all traffic is evenly distributed across the machines that manage the traffic IP group.   For more information, refer to the article Feature Brief: Deep-dive on Multi-Hosted IP addresses in Traffic Manager   If possible, you should use single-hosted traffic IP groups in very high traffic environments.  Although multi-hosted gives even traffic distribution, this comes at a cost:   Incoming packets are sprayed to all of the traffic managers in the multi-hosted traffic IP group, resulting in an increase in network traffic Each traffic manager must run the zcluster kernel module to filter incoming traffic; this module will increase the CPU utilization of the kernel on that traffic manager   Fault Tolerance   The traffic managers in a cluster each perform frequent self-tests, verifying network connectivity, correct operation and internal self-tests.  They broadcast health messages periodically (every 500 ms by default - see flipper!monitor_interval) and listen for the health messages from their peers.   If a traffic manager fails, it either broadcasts a health message indicating the problem, or (in the event of a catastrophic situation) it stops broadcasting health messages completely.  Either way, its peers in the Stingray cluster will rapidly identify that it has failed.   In this situation, two actions are taken:   An event is raised to notify the Event System that a failure has occured.  This will typically raise an alert in the event log and UI, and may send an email or other actions if they have been configured Any traffic IP addresses that the failed traffic manager was responsible for are redistributed appropriately across the remaining traffic managers in each traffic IP group   Note that if a traffic manager fails, it will voluntarily drop any traffic IP addresses that it is responsible for.   Failover   If a traffic manager fails, the traffic IP addresses that it is responsible for are redistributed.  The goal of the redistribution method is to share the  orphaned IP responsibilities as evenly as possible with the remaining traffic managers in the group, without reassigning any other IP allocations.  This minimizes disruption and seeks to ensure that traffic is as evenly shared as possible across the remaining cluster members.   The single-hosted method is granular to the level of individual traffic IP addresses.  The failover method is described in the article How are single-hosted traffic IP addresses distributed in a cluster (TODO).   The multi-hosted method is granular to the level of an individual TCP connection.  It's failover method is described in the article How are multihosted-hosted traffic IP addresses distributed in a cluster (TODO).   State sharing within a cluster   Stingray machines within a cluster will share some state information:   Configuration: Configuration is automatically replicated across the cluster and all traffic managers will hold an identical copy of the entire configuration at all points Health Broadcasts: Stingray machines periodically broadcast their health to the rest of the cluster Session Persistence data&colon; Some session persistence methods depend on Traffic Manager's internal store (see Session Persistence - implementing timeouts).  Local updates to that store are automatically replicated across the cluster on a sub-second granularity Bandwidth Data: Bandwidth classes that share a bandwidth allocation across a cluster (see Feature Brief: Bandwidth and Rate Shaping in Traffic Manager) will periodically exchange state so that each traffic manager can dynamically negotiate its share of the bandwidth class based on current demand   Traffic Manager does not share detailed connection information across a cluster (SSL state, rules state etc), so if a Traffic Manager were to fail, any TCP connections it is currently managing will be dropped.  You can guarantee that no connections are ever dropped by using a technique like VMware Fault Tolerance to run a shadow traffic manager that tracks the state of the active traffic manager completely.  This solution is supported and is in use in a number of deployments where 5- or 6-9's uptime is not sufficient: VMware Fault Tolerance is used to ensure that no connections are dropped in the event of a failure   Multi-Site Management   Recall that all of the traffic managers in a cluster have identical copies of configuration and therefore will operate in identical fashions.   Traffic Manager clusters may span multiple locations, and in some situations, you may need to run slightly different configurations in each location.  For example, you may wish to use a different pool of web servers when your service is running in your New York datacenter compared to your Docklands datacenter.   In simple situations, this can be achieved with judicious use of TrafficScript to apply slightly different traffic management actions based on the identity of the traffic manager that is processing the request ( sys.hostname() ), or the IP address that the request was received on: $ip = request.getLocalIP(); # Traffic IPs in the range 31.44.1.* are hosted in Docklands if( string.ipmaskMatch( $ip, "31.44.1.0/24" ) ) pool.select( "Docklands Webservers" ); # Traffic IPs in the range 154.76.87.* are hosted in New Jersey if( string.ipmaskMatch( $ip, "154.76.87.0/24" ) ) pool.select( "New Jersey Webservers" );   In more complex situations, you can enable the Multi-Site Management option for the configuration.  This option allows you to apply a layer of templating to your configuration - you define a set of locations, assign each traffic manager to one of these locations, and then you can template individual configuration keys so that they take different values depending on the location in which the configuration is read.   There are limitations to the scope of Multi-Site Manager (it currently does not interoperate with Web Application Firewall, and the REST API is not able to manage configuration that is templated using Multi-Site Manager).  Please refer to the What is Multi-Site Manager? feature brief for more information, and to the relevant chapter in the Product Documentation for details of limitations and caveats.   Read More   User Manual in the Product Documentation
View full article
Bandwidth Management and Rate Shaping are two key techniques to prioritize traffic using Traffic Manager.   Bandwidth Management is used to limit the bandwidth used by network traffic Rate Shaping is used to limit the rate of transactions   Bandwidth Management   Traffic Manager's Bandwidth Management is applied by assigning connections to a Bandwidth Class.  A bandwidth class limits the bandwidth used by its connections in one of two ways: Per connection: You could use a bandwidth class to limit the bandwidth of each video download to, for example, 400Mbits, to limit the effect of download applications that would otherwise use all your available bandwidth Per class: All of the connections assigned to the class share the total bandwidth limit in a fair and equitable fashion.  For example, you may wish to limit the amount of bandwidth that unauthenticated users use so that a proportion of your bandwidth is reserved for other traffic   The 'per class' bandwidth can be counted on a per-traffic-manager basis (simple) or can be shared across a traffic manager cluster (sophisticated).  When it is shared, the traffic managers negotiate between themselves on a per-second basis (approx) to share out parts of the bandwidth allocation in proportion to the demand on each Traffic Manager.   Assigning Bandwidth Management to connections   A bandwidth management class may be assigned in one of two different ways:   Per service: All of the connections processed by a virtual server will be assigned to a common bandwidth management class Per connection: A TrafficScript rule can assign a connection to a bandwidth class based on any critera, for example, whether the user is logged in, what type of content the user is requesting, or the geographic location of the user.   Examples of Bandwidth Management in action   HowTo: Control Bandwidth Management Detecting and Managing Abusive Referers   Rate Shaping   Rate Shaping is most commonly used to control the rate of particular types of transactions.  For example, you could use Rate Shaping to control the rate at which users attempt to log in to a web form, in order to mitigate against dictionary attacks, or you could use Rate Shaping to protect a vulnerable application that is prone to being overloaded.   Rates are defined using Rate Classes, which can specify rates on a per-second or per-minute basis: Rate Shaping is implemented using a queue.  A TrafficScript rule can invoke a rate class, and the execution of that rule is immediately queued.   If the queue limits (per minute or per second) have not been exceeded, the rule is then immediately released from the queue and can continue executing If the queue limits have been exceeded, the rule execution is then paused until the queue limits are met   For example, to rate-limit requests for the /search.cgi resource using the limits defined in the 'DDoS Protect' rate class, you would use the following TrafficScript snippet:     $path = http.getPath(); if( $path == "/search.cgi" ) rate.use( "DDoS Protect" );   You can use the functions rate.getBacklog() and rate.use.noQueue() to query the length of the queue, or to test a connection against the current queue length without suspending it.   Rate limits are applied by each traffic manager.  The limit is not shared across the cluster in the way that bandwidth limits can be.   Rate shaping with contexts   In some cases, you may need to apply a rate limit per-user or per-URL.  You can use rate.use() with an additional 'context' argument; the rate limit is applied to each context individually.  For example, to limit the number of requests to /search.cgi from each individual IP address, you would use:     $path = http.getPath(); $ip = request.getRemoteIP(); if( $path == "/search.cgi" ) rate.use( "DDoS Protect", $ip );   Examples of Rate Shaping in action   Dynamic rate shaping slow applications Catching Spiders with Traffic Manager The "Contact Us" attack against mail servers Rate Limit only client Traffic from CDN/Proxy or Header Value Detecting and Managing Abusive Referers   Read more   Product Documentation
View full article
Traffic Manager employs a range of protocol optimization and specialized offload functions to improve the performance and capacity of a wide range of networked applications.   TCP Offload applies to most protocol types and is used to offload slow client-side connections and present them to the server as if they were fast local transactions.  This reduces the duration of a connection, reducing server concurrency and allowing the server to recycle limited resources more quickly HTTP Optimizations apply to HTTP and HTTPS protocols.  Efficient use of HTTP keepalives (including carefully limiting concurrency to avoid overloading servers with thread-per-connection or process-per-connection models) and upgrading client connections to the most appropriate HTTP protocol level will reduce resource usage and connection churn on the servers Performance-sensitive Load Balancing selects the optimal server node for each transaction based on current and historic performance, and will also consider load balancing hints such as LARD to prefer the node with the hottest cache for each resource Processing Offload: Highly efficient implementations of SSL, compression and XML processing offload these tasks from server applications, allowing them to focus on their core application code Content Caching will cache static and dynamic content (discriminated by use of a 'cache key') and eliminate unnecessary requests for duplicate information from your server infrastructure   Further specialised functions such as Web Content Optimization, Rate Shaping (Dynamic rate shaping slow applications) and Prioritization (Detecting and Managing Abusive Referers) give you control over how content is delivered so that you can optimize the end user experience.   The importance of HTTP optimization   There's one important class of applications where ADCs make a very significant performance difference using TCP offload, request/response buffering and HTTP keepalive optimization.   A number of application frameworks have fixed concurrency limits. Apache is the most notable (the worker MPM has a default limit of 256 concurrent processes), mongrel (Ruby) and others have a fixed number of worker processes; some Java app servers also have an equivalent limit. The reason the fixed concurrency limits are applied is a pragmatic one; each TCP connection takes a concurrency slot, which corresponds to a heavyweight process or thread; too many concurrent processes or threads will bring the server to its knees and this can easily be exploited remotely if the limit is not low enough.   The implication of this limit is that the server cannot service more than a certain number of TCP connections concurrently. Additional connections are queued in the OS' listen queue until a concurrency slot is released. In most cases, an idle client keepalive connection can occupy a concurrency slot (leading to the common performance detuning advice for apache recommending that keepalives are disabled or limited).   When you benchmark a concurrency-limited server over a fast local network, connections are established, serviced and closed rapidly. Concurrency slots are only occupied for a short period of time, connections are not queued for long, so the performance achieved is high.   However, when you place the same server in a production environment, the duration of connections is much greater (slow, lossy TCP; client keepalives) so concurrency slots are held for much longer. It's not uncommon to see an application server running in production at <10% utilization, but struggling to achieve 10% of the performance that was measured in the lab.   The solution is to put a scalable proxy in front of the concurrency-limited server to offload the TCP connection, buffer the request data, use connections to the server efficiently, offload the response, free up a concurrency slot and offload the lingering keepalive connection.   Customer Stories     "Since Traffic Manager was deployed, there has been a major improvement to the performance and response times of the site." David Turner, Systems Architect, PLAY.COM   "With Traffic Manager we effortlessly achieved between 10-40 times improvement in performance over the application working alone." Steve Broadhead, BroadBand Testing   "Traffic Manager has allowed us to dramatically improve the performance and reliability of the TakingITGlobal website, effectively managing three times as much traffic without any extra burden."  Michael Furdyk, Director of Technology, TakingITGlobal   "The performance improvements were immediately obvious for both our users and to our monitoring systems – on some systems, we can measure a 400% improvement in performance." Philip Jensen, IT Section Manager, Sonofon   "700% improvement in application response times… The real challenge was to maximize existing resources, rather than having to continually add new servers." Kent Wright, Systems Administrator, QuantumMail     Read more   Feature Brief: Content Caching with Traffic Manager
View full article
What is Policy Based Routing?   Policy Based Routing (PBR) is simply the ability to choose a different routing policy based on various criteria, such as the last hop used, or the local IP address of the connection. As you may have guessed, PBR is only necessary where your Traffic Manager is multi-homed (ie multiple default routes) and asynchronous routing is either not possible or not desired.   There are only really two types of multi homing which we commonly deal with in vADC deployments. I am going to refer to them as "Multiple ISP", and "Multiple Link".   Multiple ISP   This is the simpler scenario, and it is seen when vADC is deployed in an infrastructure with two or more independent ISPs. The ISPs all provide different network ranges, and Traffic IP Groups are the end points for the addresses in those ranges. Pulse vADC must chose the default gateway based on the local Traffic IP Address of the connection.   Multiple Link   This is slightly more complicated because traffic destined for the vADC Traffic IP can come in via a number of different gateways. Pulse vADC must ensure that return traffic is sent out of the same gateway as it arrived through. This is also known as "Auto-Last-Hop", and is achieved by keeping track of the Layer 2 mac address associated with the connection.     Setting up Policy Based Routing on Pulse vADC   This guide will show you how to set up a process within Traffic Manager vTM such that a PBR policy is applied during software start up. The advantage of configuring vTM this way is that there are no changes to the underlying OS configuration, and as such it is fully compatible with the Virtual Appliance as well as the software (Linux) version. The steps to set up the PBR are as follows...   Configure gateways.conf for your environment Upload the gateways.conf to Catalogs -> Extra -> Misc Create a new action called "DynamicPBR" in System -> Alerting -> Actions This should be a program action, and execute the dynamic-pbr.sh script Create a new Event called "Dynamic PBR" in System -> Alerting -> Events You want to hook the software started event here   Step 1: Upload the dynamic-pbr.sh script   Navigate to Catalogs -> Extra Files -> Actions Programs and upload the dynamic-pbr.sh script found attached to this article.     Step 2: Configure the gateways.conf for your environment   When the dynamic-pbr.sh script is executed it will attempt to load and process a file called gateways.conf from miscellaneous files. You will need to create that configuration file.   The configuration is a simple text file with a number of fields separated by white space. The first column should be either MAC (to indicate a “Multiple Link” config) or SRC (to indicate “Multiple ISP”).   If you are using the MAC method, then you only need to supply the IP address of each of your gateways and their Layer 2 MAC address. Each MAC line should read “MAC <Gateway IP> <Gateway MAC>”.   If you are using the SRC method, then you should include: local source IP (this can be an individual Traffic IP, or a subnet), the Gateway IP. You should also include information on the local network if you need to be able to access local machines other than the gateway. Do this using two additional/optional columns: Local subnet and device.   Each SRC line should read: “SRC <Local IP> <Gateway IP> <Local subnet> <local device>”     Step 3: upload the gateways.conf   Once you have configured the gateways.conf for your environment, you should upload it to Catalogs -> Extra Files -> Miscellaneous   Step 4: Create Dynamic PBR Action   Now we have the script and configuration file uploaded to vTM, the next steps are to configure the alerting system to execute them at software start up. First we must create a new program action under System -> Alerting -> Manage Actions.   Create a new action called “Dynamic PBR” of type Program. In the edit action screen, you should then be able to select dynamic-pbr.sh from the drop down list.     Step 5: Create Dynamic PBR Event   Now that we have an action, we need to create an event which hooks the “software is running” event. Navigate to System -> Alerting -> Manage Event Types and create a new Event Type called “Dynamic PBR”.   In the event list select the software running event under General, Information Messages.     Step 6: Link the event to the action   Navigate back to the System -> Alerting page and link our new “Dynamic PBR” event type to the “Dynamic PBR” action.     Finished   Now every time the software is started, the configuration from the gateways.conf will be applied.   How do I check the policy?   If you want to check what policy has been applied to the OS, you can do so on the command line. Either open the console or SSH into the vTM machine. The policy is applied by setting up a rule and matching routing table for each of the lines in the gateways.conf configuration file.You can check the routing policy by using the iproute2 utility.   To check the routing rules, run: “ip rule list”.   There are three default rules/tables in Linux: rule 0 looks up the “local” table, rule 32766 looks up “main”, and 32767 looks up “default”. The rules are executed in order. The local rule (0) is maintained by the kernel, so you shouldn’t touch it. The main table (look up rule 32766) and default table (look up rule 32767) tables go last. The main table holds the main routing table of your machine and is the one returned by “netstat –rn”. The default table is usually empty. All other rules in the list are custom, and you should see a rule entry for each of the lines in your gateway configuration file.   So where are the routes? Well the rules are passed in order and the lookup points to a table. You can have upto 255 tables in linux. The “main” table is actually table 255. To see the routes in the table you would use the “ip route list” command. Executing “ip route list table main” and “ip route list table 254” should return the same routing information.   You will note that the rules added by vTM are referenced by their number only. So to look at one of your tables you would use its number. For example “ip route list table 10”. Enjoy!   Updates 20150317: Modified script to parse configuration files which use windows format line endings.
View full article