Pulse Secure vADC

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

Looking for Installation and User Guides for Pulse vADC? User documentation is no longer included in the software download package with Pulse vTM, so the documentation can now be found on the Pulse Techpubs pages  

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 Stingray be free to load-balance all other requests (images, static content) as appropriate.   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" ); }   Read more   Collected Tech Tips: TrafficScript examples

A great feature of the Stingray Traffic Manager is the ability to upload External Program Monitors.  An External Program Monitor is a custom health monitor that can be written to monitor any service.  An External Program Monitor for LDAP is available here.   To use it first install ldapsearch onto the Stingray Traffic Manager: apt-get install ldap-utils (For Ubuntu based distros)   The key is to install ldap-utils.  Once that is installed, upload and install the monitor:   In the Stingray web interface navigate to Catalogs -> Extra Files -> Monitor Programs.  Upload ldap.pl (in the ldap.zip file) Navigate to Catalogs -> Monitors.  Scroll down to Create new monitor.  Give it a name and select External program monitor as the type. Select ldap.pl from the drop down menu that appears. Scroll down to program arguments and create four arguments: base, filter, pass, user.  It should look like the below screenshot: Fill in the fields appropriately: base is your LDAP search base, user and pass are your LDAP login credentials, and filter should be set to the CN associated with user.  For the pass field, Stingray does not automatically insert asterisks, so please be aware of that. Attach the monitor to the appropriate pool.   That completes the configuration of the LDAP Health Monitor for the Stingray Traffic Manager.   Note: If you are using the virtual appliance, then follow the instructions in this KB article instead. (edit - the file ldapmonitor.pl is attached to this article)

TrafficScript is the programming language that is built into the Traffic Manager.  With TrafficScript, you can create traffic management 'rules' to control the behaviour of Traffic Manager in a wide manner of ways, inspecting, modifying and routing any type of TCP or UDP traffic.   The language is a simple, procedural one - the style and syntax will be familiar to anyone who has used Perl, PHP, C, BASIC, etc. Its strength comes from its integration with Traffic Manager, allowing you to perform complex traffic management tasks simply, such as controlling traffic flow, reading and parsing HTTP requests and responses, and managing XML data.   This article contains a selection of simple technical tips to illustrate how to perform common tasks using TrafficScript.   TrafficScript Syntax   HowTo: TrafficScript Syntax HowTo: TrafficScript variables and types HowTo: if-then-else conditions in TrafficScript HowTo: loops in TrafficScript HowTo: TrafficScript rules processing and flow control HowTo: TrafficScript String Manipulation HowTo: TrafficScript Libraries and Subroutines HowTo: TrafficScript Arrays and Hashes   HTTP operations   HowTo: Techniques to read HTTP headers HowTo: Set an HTTP Response Header HowTo: Inspect HTTP Request Parameters HowTo: Rewriting HTTP Requests HowTo: Rewriting HTTP Responses HowTo: Redirect HTTP clients HowTo: Inspect and log HTTP POST data HowTo: Handle cookies in TrafficScript   XML processing   HowTo: Inspect XML and route requests Managing XML SOAP data with TrafficScript   General examples   HowTo: Controlling Session Persistence HowTo: Control Bandwidth Management HowTo: Monitor the response time of slow services HowTo: Query an external datasource using HTTP HowTo: Techniques for inspecting binary protocols HowTo: Spoof Source IP Addresses with IP Transparency HowTo: Use low-bandwidth content during periods of high load HowTo: Log slow connections in Stingray Traffic Manager HowTo: Inspect and synchronize SMTP HowTo: Write Health Monitors in TrafficScript HowTo: Delete Session Persistence records   More information   For a more rigorous introduction to the TrafficScript language, please refer to the TrafficScript guide in the Product Documentation

Stingray Traffic Manager can run as either a forward or a reverse proxy. But what is a Proxy? A reverse proxy? A forward proxy? And what can you do with such a feature?   Let's try and clarify what all these proxies are. In computing, a Proxy is a service that accepts network connections from clients and then forwards them on to a server. So in essence, any Load Balancer or Traffic Manager is a kind of proxy. Web caches are another example of proxy servers. These keep a copy of frequently requested web pages and will deliver these pages themselves, rather than having to forward the request on to the 'real' server.   Forward and Reverse Proxies   The difference between a 'forward' and 'reverse' proxy is determined by where the proxy is running.   Forward Proxies:  Your ISP probably uses a web cache to reduce its bandwidth costs. In this case, the proxy is sitting between your computer and the whole Internet. This is a 'forward proxy'. The proxy has a limited set of users (the ISP's customers), and can forward requests on to any machine on the Internet (i.e. the web sites that the customers are browsing).   Reverse Proxies: Alternatively, a company can put a web cache in the same data center as their web servers, and use it to reduce the load on their systems. This is a 'reverse proxy'. The proxy has an unlimited set of users (anyone who wants to view the web site), but proxies requests on to a specific set of machines (the web servers running the company's web site). This is a typical role for Traffic Managers - they are traditionally used as a reverse proxy.   Using Stingray Traffic Manager as a Forward Proxy   You may use Stingray Traffic Manager to forward requests on to any other computer, not just to a pre-configured set of machines in a pool. TrafficScript is used to select the exact address to forward the request on to:   pool.use( "Pool name", $ipaddress, $port );   The pool.use() function is used, in the same way as you would normally pick a pool of servers to let Stingray Traffic Manager load balance to. The extra parameters specify the exact machine to use. This machine does not have to belong to the pool that is mentioned; the pool name is there just so Stingray Traffic Manager can use its settings for the connection (e.g. timeout settings, SSL encryption, and so on).   We refer to this technique as 'Forward Proxy mode', or 'Forward Proxy' for short.   What use is a Forward Proxy?   Combined with TrafficScript, the Forward Proxy feature gives you complete control over the load balancing of requests. For example, you could use Stingray Traffic Manager to load balance RDP (Remote Desktop Protocol), using TrafficScript to pick out the user name of a new connection, look the name up in a database and find the hostname of a desktop to allocate for that user.   Forward Proxying also allows Stingray Traffic Manager to be used nearer the clients on a network. With some TrafficScript, Stingray Traffic Manager can operate as a caching web proxy, speeding up local Internet usage. You can then tie in other Stingray Traffic Manager features like bandwidth shaping, service level monitoring and so on. TrafficScript response rules could then filter the incoming data if needed.   Example: A web caching proxy using Stingray Traffic Manager and TrafficScript   You will need to set up Stingray Traffic Manager with a virtual server listening for HTTP proxy traffic. Set HTTP as the protocol, and enable web caching. Also, be sure to disable Stingray's "Location Header rewriting", on the connection management page. Then you will need to add a TrafficScript rule to examine the incoming connections and pick a suitable machine. Here's how you would build such a rule:   # Put a sanity check in the rule, to ensure that only proxy traffic is being received: $host = http.getHostHeader(); if( http.headerExists( "X-Forwarded-For" ) || $host == "" ) { http.sendResponse( "400 Bad request", "text/plain", "This is a proxy service, you must send proxy requests", "" ); } # Trim the leading http://host from the URL if necessary $url = http.getRawUrl(); if ( string.startswith( $url, "http://" ) ) { $slash = string.find( $url, "/", 8 ); $url = string.substring( $url, $slash, -1 ); } http.setPath( string.unescape( $url ) ); # Extract the port out of the Host: header, if it is there $pos = string.find( $host, ":" ); if( $pos >= 0 ) { $port = string.skip( $host, $pos + 1 ); $host = string.substring( $host, 0, $pos - 1 ); } else { $port = 80; } # We need to alter the HTTP request to supply the true IP address of the client # requesting the page, and we need to tweak the request to remove any proxy-specific headers. http.setHeader( "X-Forwarded-For", request.getRemoteIP() ); http.removeHeader( "Range" ); # Removing this header will make the request more cacheable http.removeHeader( "Proxy-Connection" ); # The user might have requested a page that is unresolvable, e.g. # http://fakehostname.nowhere/. Let's resolve the IP and check $ip = net.dns.resolveHost( $host ); if( $ip == "" ) { http.sendResponse( "404 Unknown host", "text/plain", "Failed to resolve " . $host . " to an IP address", "" ); } # The last task is to forward the request on to the target website pool.use( "Forward Proxy Pool", $ip, $port );   Done! Now try using the proxy: Go to your web browser's settings page or your operating system's network configuration (as appropriate) and configure an HTTP proxy.  Fill in the hostname of your Stingray Traffic Manager and the port number of the virtual server running this TrafficScript rule. Now try browsing to a few different web sites. You will be able to see the URLs on the Current Activity page in the UI, and the Web Cache page will show you details of the content that has been cached by Stingray:   'Recent Connections' report lists connections proxied to remote sites   Content Cache report lists the resources that Stingray has cached locally     This is just one use of the forward proxy. You could easily use the feature for other uses, e.g. email delivery, SSL-encrypted proxies, and so on. Try it and see!

You've just downloaded and installed Traffic Manager, and you're wondering "where next?". This article talks through the process of load-balancing traffic to a public website, and explains the potential pitfalls and how to overcome them. We'll look at how to set up a basic load balanced service using the Manage a New Service wizard, then consider four potential problems: Problem Solution When you access the Web site through Traffic Manager, it responds with a 404 Not Found or other error, or redirects you directly to the website You need to correct the Host Header in the request your web browser has sent.  Use a simple Request Rule in Traffic Manager to patch the request up correctly. The web site stops working when you access it through Traffic Manager Traffic Manager is running Ping health checks against the web servers, and these are failing because the public servers won't respond to pings.  Remove the health checks, or replace them with HTTP checks. Links in the web content refer directly to the fully-qualified domain of the website, rather than to the website delivered through Traffic Manager You need to rewrite the web content to correct the fully-qualified links.  Use a response rule in Traffic Manager to make this change. HTTP Location redirects and cookies issued by the website refer to the fully-qualified domain of the website, rather than to the website delivered through Traffic Manager You need to use the connection management settings to transparently rewrite the Location and Set-Cookie headers as appropriate   Basic Load Balancing Let's start with a simple example. Select a target website, such as www.w3.org. Fire up the Manage a New Service wizard: This will pop up a new window to step you through the process of creating a new service. Warning:  If you don't see the pop-up window, your web browser may be configured to prevent popups.  Check and fix this problem.   Step through the wizard.  Create a service named web site, listening on port 80: Specify the servers ("nodes") that will host the website.  In this example, enter www.w3.org, port 80: Note:  If you get an "ERROR: Cannot resolve" message, then most likely your Traffic Manager is not configured with a correct nameserver address, or it cannot route to the outside world.  You'll need to fix these problems before continuing: You can use 8.8.8.8 as the nameserver Ensure that the networking is configured so that the Traffic Manager has external connectivity   Review your settings and commit the result: Note:  If you get a 'Cannot Bind' error when you commit the changes, then another service on the Traffic Manager is listening on port 80. If it's a pre-existing Traffic Manager Virtual Server, you should stop this virtual server It it's another service on the same host (for example, a webserver), you should stop this service Alternatively, select another port (instead of port 80). The wizard will create a virtual server object listening on port 80, and a pool object containing the www.w3.org nodes (or whatever you chose).  The Virtual Server will receive traffic and then pass it on to the pool for load balancing.   Try it out Try it out.  Go to http://your-traffic-manager-ip-address/ with your web browser.  If you are lucky, it will work first time, but most likely, you'll get an error message, or possibly a redirect to http://www.yourwebsite.com/. Problem #1: The Host Header Most webservers host many websites on the same IP address and port.  They determine which website a particular request is destined for by inspecting a parameter in the request called the 'Host Header'. The 'Host Header' is constructed from the URL that you typed in your web browser (for example: http://192.168.35.10/).  This will cause the webbrowser to include the following header in the request:   Host: 192.168.35.10 The web server will reject this request, returning either an error message, 404 Not Found, or a forceful redirect to the correct page. You can use a TrafficScript Rule to change the host header in the request to a value that the web site will recognise.   How to create the TrafficScript Rule Edit the 'web site' virtual server you created and navigate to the 'Rules' page.  In the 'Request Rules' section, click the 'Manage Rules in Catalog' link to create a new rule that is associated with that virtual server: Create a TrafficScript rule called 'w3.org host header':   with the following text http.setHeader( "Host", "www.w3.org" ); and save your changes. Now, Traffic Manager will fix up the host header in every request and the site should render correctly. Problem #2: Health Monitors If your Traffic Manager service works for a short time, then starts returning a "Service Unavailable" error message, you've most likely hit a health monitoring problem. When Traffic Manager creates a new pool, it assigns a 'ping' health monitor to the nodes.  Many public webservers, and websites that are delivered over a CDN, do not respond to 'ping' healthchecks, so this monitor will quickly fail and mark the nodes as unavailable. Edit the 'web site pool' Pool object and locate the Health Monitoring section.  Remove the Ping health monitor: This will clear the error.  You could replace the Ping health check with an HTTP health check (for example) if you wished. Problem #3: Embedded Links As you click round the website that is delivered through Traffic Manager, you may find that you jump off the http://your-traffic-manager-IP-address/ version of the site and start going directly to the http://www.site.com/ URLs. This may happen because the website content contains absolute, fully-qualified links: <a href="http://www.nytimes.com/headlines">Headlines</a> rather than unqualified links: <a href="https://community.brocade.com/headlines">Headlines</a>   Yes, this is a problem if you load-balance to www.nytimes.com for example. You can fix those links up by rewriting the HTML responses from the webservers using a Response Rule in Traffic Manager: $contentType = http.getResponseHeader( "Content-Type" ); if( string.startsWith( $contentType, "text/html" ) ) {   $body = http.getResponseBody(); $body = string.replaceAll( $body, "http://www.nytimes.com/", "/" );   http.setResponseBody( $body ); }   Problem #4: Cookies and Location redirects The origin webserver may issue cookies and Location redirects that reference the fully-qualified domain of the website, rather than the IP address of the Traffic Manager device.  Your web browser will not submit those cookies, and it will jump to the origin website if it follows a Location redirect.   Traffic Manager can automatically patch up these parts of the HTTP response, using the Cookie and Location Header settings in the Connection Management page of your Virtual Server's configuration:   Rewrite domains, paths and other cookie parameters when proxying a website using a different URL Intelligently rewrite location redirects so that users are not hopped on to the origin server Use these settings to address any inconsistencies and problems related to cookies or location redirects. Conclusion These three problems (host header, health monitors, embedded links) can occur when you load-balance public websites; they are a lot less likely to happen in production because there won't be a firewall blocking pings between Traffic Manager and the local webservers, and the DNS for www.site.com will resolve to a traffic IP address on the Traffic Manager so the host header and embedded links will be correct. Watch out for situations where the web server sends HTTP redirects to another domain.  For example, when I tested by load balancing to www.yahoo.com, the website immediately tried to redirect me to www.uk.yahoo.com (I was based in the UK).  You have no control over this behavior by a public website; I configured my Traffic Manager to forward traffic to www.uk.yahoo.com instead. Now that you have a working load-balancing configuration, you can: Check out the Activity Monitors and Connections Reports to observe the traffic that Traffic Manager is managing Start experimenting with some of the examples and use cases from the list in Top Pulse vADC Examples and Use Cases Read some of the Product Briefs for Traffic Manager to understand how it can manage and control traffic  

This document describes some operating system tunables you may wish to apply to a production Traffic Manager instance.  Note that the kernel tunables only apply to Traffic Manager software installed on a customer-provided Linux instance; it does not apply to the Traffic Manager Virtual Appliance or Cloud instances. Consider the tuning techniques in this document when: Running Traffic Manager on a severely-constrained hardware platform, or where Traffic Manager should not seek to use all available resources; Running in a performance-critical environment; The Traffic Manager host appears to be overloaded (excessive CPU or memory usage); Running with very specific traffic types, for example, large video downloads or heavy use of UDP; Any time you see unexpected errors in the Traffic Manager event log or the operating system syslog that relate to resource starvation, dropped connections or performance problems For more information on performance tuning, start with the Tuning Pulse Virtual Traffic Manager article. Basic Kernel and Operating System tuning   Most modern Linux distributions have sufficiently large defaults and many tables are autosized and growable, so it is often not be necessary to change tunings.  The values below are recommended for typical deployments on a medium-to-large server (8 cores, 4 GB RAM). Note: Tech tip: How to apply kernel tunings on Linux File descriptors # echo 2097152 > /proc/sys/fs/file-max   Set a minimum of one million file descriptors unless resources are seriously constrained.  See also the setting maxfds below. Ephemeral port range # echo "1024 65535" > /proc/sys/net/ipv4/ip_local_port_range # echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout Each TCP and UDP connection from Traffic Manager to a back-end server consumes an ephemeral port, and that port is retained for the ‘fin_timeout’ period once the connection is closed.  If back-end connections are frequently created and closed, it’s possible to exhaust the supply of ephemeral ports. Increase the port range to the maximum (as above) and reduce the fin_timeout to 30 seconds if necessary. SYN Cookies # echo 1 > /proc/sys/net/ipv4/tcp_syncookies SYN cookies should be enabled on a production system.  The Linux kernel will process connections normally until the backlog grows , at which point it will use SYN cookies rather than storing local state.  SYN Cookies are an effective protection against syn floods, one of the most common DoS attacks against a server. If you are seeking a stable test configuration as a basis for other tuning, you should disable SYN cookies. Increase the size of net/ipv4/tcp_max_syn_backlog if you encounter dropped connection attempts. Request backlog # echo 1024 > /proc/sys/net/core/somaxconn The request backlog contains TCP connections that are established (the 3-way handshake is complete) but have not been accepted by the listening socket (on Traffic Manager).  See also the tunable parameter ‘listen_queue_size’.  Restart the Traffic Manager software after changing this value. If the listen queue fills up because the Traffic Manager does not accept connections sufficiently quickly, the kernel will quietly ignore additional connection attempts.  Clients will then back off (they assume packet loss has occurred) before retrying the connection. Advanced kernel and operating system tuning In general, it’s rarely necessary to further tune Linux kernel internals because the default values that are selected on a normal-to-high-memory system are sufficient for the vast majority of deployments, and most kernel tables will automatically resize if necessary.  Any problems will be reported in the kernel logs; dmesg is the quickest and most reliable way to check the logs on a live system. Packet queues In 10 GbE environments, you should consider increasing the size of the input queue: # echo 5000 > net.core.netdev_max_backlog TCP TIME_WAIT tuning TCP connections reside in the TIME_WAIT state in the kernel once they are closed.  TIME_WAIT allows the server to time-out connections it has closed in a clean fashion. If you see the error “TCP: time wait bucket table overflow”, consider increasing the size of the table used to store TIME_WAIT connections: # echo 7200000 > /proc/sys/net/ipv4/tcp_max_tw_buckets TCP slow start and window sizes In earlier Linux kernels (pre-2.6.39), the initial TCP window size was very small.  The impact of a small initial window size is that peers communicating over a high-latency network will take a long time (several seconds or more) to scale the window to utilize the full bandwidth available – often the connection will complete (albeit slowly) before an efficient window size has been negotiated. The 2.6.39 kernel increases the default initial window size from 2 to 10.  If necessary, you can tune it manually: # ip route change default via 192.168.1.1 dev eth0 proto static initcwnd 10 If a TCP connection stalls, even briefly, the kernel may reduce the TCP window size significantly in an attempt to respond to congestion.  Many commentators have suggested that this behavior is not necessary, and this “slow start” behavior should be disabled: # echo 0 > /proc/sys/net/ipv4/tcp_slow_start_after_idle TCP options for Spirent load generators If you are using older Spirent test kit, you may need to set the following tunables to work around optimizations in their TCP stack: # echo 0 > /proc/sys/net/ipv4/tcp_timestamps # echo 0 > /proc/sys/net/ipv4/tcp_window_scaling [Note: See attachments for the above changes in an easy to run shell script]  irqbalance Interrupts (IRQs) are wake-up calls to the CPU when new network traffic arrives. The CPU is interrupted and diverted to handle the new network data. Most NIC drivers will buffer interrupts and distribute them as efficiently as possible.  When running on a machine with multiple CPUs/cores, interrupts should be distributed across cores roughly evenly. Otherwise, one CPU can be the bottleneck in high network traffic. The general-purpose approach in Linux is to deploy irqbalance , which is a standard package on most major Linux distributions.  Under extremely high interrupt load, you may see one or more ksoftirqd processes exhibiting high CPU usage.  In this case, you should configure your network driver to use multiple interrupt queues (if supported) and then manually map those queues to one or more CPUs using SMP affinity. Receive-Side Scaling (RSS) Modern network cards can maintain multiple receive queues. Packets within a particular TCP connection can be pinned to a single receive queue, and each queue has its own interrupt.  You can map interrupts to CPU cores to control which core each packet is delivered to. This affinity delivers better performance by distributing traffic evenly across cores and by improving connection locality (a TCP connection is processed by a single core, improving CPU affinity). For optimal performance, you should: Allow the Traffic Manager software to auto-size itself to run one process per CPU core (two when using hyperthreading), i.e. do not modify the num_children configurable.  Configure the network driver to create as many queues as you have cores, and verify the IRQs that the driver will raise per queue by checking /proc/interrupts. Map each queue interrupt to one core using /proc/irq/<irq-number>/smp_affinity You should also refer to the technical documentation provided by your network card vendor. [Updates by Aidan Clarke and Rick Henderson ]  

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.

This article describes how to inspect and load-balance WebSockets traffic using Stingray Traffic Manager, and when necessary, how to manage WebSockets and HTTP traffic that is received on the same IP address and port.   Overview   WebSockets is an emerging protocol that is used by many web developers to provide responsive and interactive applications.  It's commonly used for talk and email applications, real-time games, and stock market and other monitoring applications.   By design, WebSockets is intended to resemble HTTP.  It is transported over tcp/80, and the initial handshake resembles an HTTP transaction, but the underlying protocol is a simple bidirectional TCP connection.   For more information on the protocol, refer to the Wikipedia summary and RFC 6455.    Basic WebSockets load balancing   Basic WebSockets Load Balancing   Basic WebSockets load balancing is straightforward.  You must use the 'Generic Streaming' protocol type to ensure that Stingray will correctly handle the asynchronous nature of websockets traffic.   Inspecting and modifying the WebSocket handshake   A WebSocket handshake message resembles an HTTP request, but you cannot use the built-in http.* TrafficScript functions to manage it because these are only available in HTTP-type virtual servers.   The libWebSockets.rts library (see below) implements analogous functions that you can use instead:   libWebSockets.rts   Paste the libWebSockets.txt library to your Rules catalog and reference it from your TrafficScript rule as follows:   import libWebSockets.rts as ws;   You can then use the ws.* functions to inspect and modify WebSockets handshakes.  Common operations include fixing up host headers and URLs in the request, and selecting the target servers (the 'pool') based on the attributes of the request.   import libWebSockets.rts as ws; if( ws.getHeader( "Host" ) == "echo.example.com" ) { ws.setHeader( "Host", "www.example.com" ); ws.setPath( "/echo" ); pool.use( "WebSockets servers" ); }   Ensure that the rules associated with WebSockets virtual server are configured to run at the Request stage, and to run 'Once', not 'Every'.  The rule should just be triggered to read and process the initial client handshake, and does not need to run against subsequent messages in the websocket connection:   Code to handle the WebSocket handshake should be configured as a Request Rule, with 'Run Once'   SSL-encrypted WebSockets   Stingray can SSL-decrypt TCP connections, and this operates fully with the SSL-encrypted wss:// protocol: Configure your virtual server to listen on port 443 (or another port if necessary) Enable SSL decryption on the virtual server, using a suitable certificate Note that when testing this capability, we found that Chrome refused to connect to WebSocket services with untrusted or invalid certificates, and did not issue a warning or prompt to trust the certificate.  Other web browsers may operate similarly.  In Chrome's case, it was necessary to access the virtual server directly (https://), save the certificate and then import it into the certificate store.   Stingray can also SSL-encrypt downstream TCP connections (enable SSL encryption in the pool containing the real websocket servers) and this operates fully with SSL-enabled origin WebSockets servers.   Handling HTTP and WebSockets traffic   HTTP traffic should be handled by an HTTP-type virtual server rather than a Generic Streaming one.  HTTP virtual servers can employ HTTP optimizations (keepalive handling, HTTP upgrades, Compression, Caching, HTTP Session Persistence) and can access the http.* TrafficScript functions in their rules.   If possible, you should run two public-facing virtual servers, listening on two separate IP addresses.  For example, HTTP traffic should be directed to www.site.com (which resolves to the public IP for the HTTP virtual server) and WebSockets traffic should be directed to ws.site.com (resolving to the other public IP): Configure two virtual servers, each listening on the appropriate IP address   Sometimes, this is not possible – the WebSockets code is hardwired to the main www domain, or it's not possible to obtain a second public IP address. In that case, all traffic can be directed to the WebSockets virtual server and then HTTP traffic can be demultiplexed and forwarded internally to an HTTP virtual server:   Listen on a single IP address, and split off the HTTP traffic to a second HTTP virtual server   The following TrafficScript code, attached to the 'WS Virtual Server', will detect if the request is an HTTP request (rather than a WebSockets one) and hand the request off internally to an HTTP virtual server by way of a special 'Loopback Pool':   import libWebSockets.rts as ws; if( !ws.isWS() ) pool.use( "Loopback Pool" );   Notes: Testing WebSockets   The implementation described in this article was developed using the following browser-based client, load-balancing traffic to public 'echo' servers (ws://echo.websocket.org/, wss://echo.websocket.org, ws://ajf.me:8080/).   testclient.html   At the time of testing: echo.websocket.org did not respond to ping tests, so the default ping health monitor needed to be removed Chrome24 refused to connect to SSL-enabled wss resources unless they had a trusted certificate, and did not warn otherwise If you find this solution useful, please let us know in the comments below.

What is SteelApp?   SteelApp is a software Application Delivery Controller.  It's generally installed as a proxy, in front of groups of web servers, app servers and other networked applications.   Stingray provides the core features of a Load Balancer or Application Delivery Controller, an Application Firewall and Web Content Optimization.  It also provides a rich data-plane programming environment called TrafficScript that lets you control how users interact with your services, letting you visualize, prioritize, rewrite, filter and debug all transactions.   Read more: Check out the key Product Briefs for Stingray Traffic Manager.   Download and Install SteelApp   The quickest way to get started with Stingray is to begin with the Developer Edition.  Grab either the software (Linux or Solaris) or Virtual Appliance (VMware, Xen or OracleVM) installation and follow the instructions in the appropriate Getting Started guide.   If you have a particular project in mind and you would like assistance from Riverbed's technical and sales team, you should register for a full Stingray Evaluation.   Where to next?   Try Getting Started - Load-balancing to a website using Stingray Traffic Manager to begin.   Then you can check out the Stingray Splash Community in more depth: Learn about Stingray Traffic Manager (the Feature Brief: Introduction to the Stingray Architecture is a good place to begin) Browse through the tech tips and solutions Check out the product videos Ask a question or join a discussion Share suggestions and raise feature requests

This document describes performance-related tuning you may wish to apply to a production Stingray Traffic Manager software, virtual appliance or cloud instance.  For related documents (e.g. operating system tuning), start with the Tuning Pulse Virtual Traffic Manager article.   Tuning Pulse Traffic Manager   Traffic Manager will auto-size the majority of internal tables based on available memory, CPU cores and operating system configuration.  The default behavior is appropriate for typical deployments and it is rarely necessary to tune it. Several changes can be made to the default configuration to improve peak capacity if necessary. Collectively, they may give a 5-20% capacity increase, depending on the specific test. Basic performance tuning Global settings Global settings are defined in the ‘System’ part of the configuration. Recent Connections table: Set recent_conns to 0 to prevent Stingray from archiving recent connection data for debugging purposes Verbose logging: Disable flipper!verbose, webcache!verbose and gslb!verbose to disable verbose logging Virtual Server settings Most Virtual Server settings relating to performance tuning are to be found in the Connection Management section of the configuration. X-Cluster-Client-IP: For HTTP traffic, Traffic Manager adds an 'X-Cluster-Client-IP' header containing the remote client's IP address by default.  You should disable this feature if your back-end applications do not inspect this header. HTTP Keepalives: enable support for Keepalives; this will reduce the rate at which TCP connections must be established and torn down.  Not only do TCP handshakes incur latency and additional network traffic, but closed TCP connections consume operating system resources until TCP timeouts are hit. UDP Port SMP: set this to 'yes' if you are managing simple UDP protocols such as DNS.  Otherwise, all UDP traffic is handled by a single Traffic Manager process (so that connections can be effectively tracked) Pool settings HTTP Keepalives: enable support for Keepalives (Pool: Connection Management; see Virtual Server note above). This will reduce the load on your back-end servers and the Traffic Manager system. Session Persistence: Session Persistence overrides load balancing and can prevent the traffic manager from selecting the optimal node and applying optimizations such as LARD. Use session persistence selectively and only apply to requests that must be pinned to a node. Advanced Performance Tuning General Global Settings: Maximum File Descriptors (maxfds): File Descriptors are the basic operating system resource that Traffic Manager consumes.  Typically, Traffic Manager will require two file descriptors per active connection (client and server side) and one file descriptor for each idle keepalive connection and for each client connection that is pending or completing. Traffic Manager will attempt to bypass any soft per-process limits (e.g. those defined by ulimit) and gain the maximum number of file descriptors (per child process). There are no performance impacts, and minimal memory impact to doing this.  You can tune the maximum number of file descriptors in the OS using fs.file-max The default value of 1048576 should be sufficient. Traffic Manager will warn if it is running out of file descriptors, and will proactively close idle keepalives and slow down the rate at which new connections are accepted. Listen queue size (listen_queue_size): this should be left to the default system value, and tuned using somaxconn (see above) Number of child processes (num_children): this is auto-sized to the number of cores in the host system.  You can force the number of child processes to a particular number (for example, when running Traffic Manager on a shared server) using the tunable ‘num_children’ which should be added manually to the global.cfg configuration file. Tuning Accept behavior The default accept behavior is tuned so that child processes greedily accept connections as quickly as possible.  With very large numbers of child processes, if you see uneven CPU usage, you may need to tune the multiple_accept, max_accepting and accepting_delay values in the Global Settings to limit the rate at which child processes take work. Tuning network read/write behavior The Global Settings values so_rbuff_size and so_wbuff_size are used to tune the size of the operating system (kernel-space) read and write buffers, as restricted by the operating system limits /proc/sys/net/core/rmem_max and /proc/sys/net/core/wmem_max. These buffer sizes determine how much network data the kernel will buffer before refusing additional data (from the client in the case of the read buffer, and from the application in the case of the write buffer).  If these values are increased, kernel memory usage per socket will increase. In normal operation, Traffic Manager will move data from the kernel buffers to its user-space buffers sufficiently quickly that the kernel buffers do not fill up.  You may want to increase these buffer sizes when running under connection high load on a fast network. The Virtual Server settings max_client_buffer and max_server_buffer define the size of the Traffic Manager (user-space) read and write buffers, used when Traffic Manager is streaming data between the client and the server.  The buffers are temporary stores for the data read from the network buffers. Larger values will increase memory usage per connection, to the benefit of more efficient flow control; this will improve performance for clients or servers accessing over high-latency networks. The value chunk_size controls how much data Traffic Manager reads and writes from the network buffers when processing traffic, and internal application buffers are allocated in units of chunk_size.  To limit fragmentation and assist scalability, the default value is quite low (4096 bytes); if you have plenty of free memory, consider setting it to 8192 or 16384. Doing so will increase Traffic Manager's memory footprint but may reduce the number of system calls, slightly reducing CPU usage (system time). You may wish to tune the buffer size parameters if you are handling very large file transfers or video downloads over congested networks, and the chunk_size parameter if you have large amounts of free memory that is not reserved for caching and other purposes. Tuning SSL performance Some modern ciphers such as TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 are faster than older ciphers in Traffic Manager.  SSL uses a private/public key pair during the initial client handshake.  1024-bit keys are approximately 5 times faster than 2048-bit keys (due to the computational complexity of the key operation), and are sufficiently secure for applications that require a moderate degree of protection. SSL sessions are cached locally, and shared between all traffic manager child processes using a fixed-size (allocated at start-up) cache.  On a busy site, you should check the size, age and miss-rate of the SSL Session ID cache (using the Activity monitor) and increase the size of the cache (ssl!cache!size) if there is a significant number of cache misses. Tuning from-Client connections Timeouts are the key tool to controlling client-initiated connections to the traffic manager: connect_timeout discards newly-established connections if no data is received within the timeout; keepalive_timeout holds client-side keepalive connections open for a short time before discarding them if they are not reused; timeout is a general-purpose timeout that discards an active connection if no data is received within the timeout period. If you suspect that connections are dropped prematurely due to timeouts, you can temporarily enable the Virtual Server setting log!client_connection_failures to record the details of dropped client connections. Tuning to-Server connections When processing HTTP traffic, Traffic Manager uses a pool of Keep-Alive connections to reuse TCP connections and reduce the rate at which TCP connections must be established and torn down.  If you use a webserver with a fixed concurrency limit (for example, Apache with its MaxClients and ServerLimit settings ), then you should tune the connection limits carefully to avoid overloading the webserver and creating TCP connections that it cannot service.   Pool: max_connections_pernode: This setting limits the total number of TCP connections that this pool will make to each node; keepalive connections are included in that count. Traffic Manager will queue excess requests and schedule them to the next available server. The current count of established connections to a node is shared by all Traffic Manager processes.   Pool: max_idle_connections_pernode: When an HTTP request to a node completes, Traffic Manager will generally hold the TCP connection open and reuse it for a subsequent HTTP request (as a KeepAlive connection), avoiding the overhead of tearing down and setting up new TCP connections.  In general, you should set this to the same value as max_connections_pernode, ensuring that neither setting exceeds the concurrency limit of the webserver.   Global Setting: max_idle_connections: Use this setting to fine-tune the total number of keepalive connections Traffic Manager will maintain to each node.  The idle_connection_timeout setting controls how quickly keepalive connections are closed.You should only consider limiting the two max_idle_connections settings if you have a very large number of webservers that can sustain very high degrees of concurrency, and you find that the traffic manager routinely maintains too many idle keepalive connections as a result of very uneven traffic. When running with very slow servers, or when connections to servers have a high latency or packet loss, it may be necessary to increase the Pool timeouts: max_connect_time discards connections that fail to connect within the timeout period; the requests will be retried against a different server node; max_reply_time discards connections that fail to respond to the request within the desired timeout; requests will be retried against a different node if they are idempotent. When streaming data between server and client, the general-purpose Virtual Server ‘timeout’ setting will apply.  If the client connection times out or is closed for any other reason, the server connection is immediately discarded. If you suspect that connections are dropped prematurely due to timeouts, you can enable the Virtual Server setting log!server_connection_failures to record the details of dropped server connections. Nagle’s Algorithm You should disable “Nagle’s Algorithm” for traffic to the backend servers, unless you are operating in an environment where the servers have been explicitly configured not to use delayed acknowledgements.  Set the node_so_nagle setting to ‘off’ in the Pool Connection Management configuration. If you notice significant delays when communicating with the back-end servers, Nagle’s Algorithm is a likely candidate. Other settings Ensure that you disable or de-configure any Traffic Manager features that you do not need to use, such as health monitors, session persistence, TrafficScript rules, logging and activity monitors.  Disable debug logging in service protection classes, autoscaling settings, health monitors, actions (used by the eventing system) and GLB services. For more information, start with the Tuning Pulse Virtual Traffic Manager article.  

In many cases, it is desirable to upgrade a virtual appliance by deploying a virtual appliance at the newer version and importing the old configuration.  For example, the size of the Traffic Manager disk image was increased in version 9.7, and deploying a new virtual appliance lets a customer take advantage of this larger disk.  This article documents the procedure for deploying a new virtual appliance with the old configuration in common scenarios.   These instructions describe how to upgrade and reinstall Traffic Manager appliance instances (either in a cluster or standalone appliances). For instructions on upgrading on other platforms, please refer to Upgrading Traffic Manager.   Upgrading a standalone Virtual Appliance   This process will replace a standalone virtual appliance with another virtual appliance with the same configuration (including migrating network configuration). Note that the Traffic Manager Cloud Getting Started Guide contains instructions for upgrading a standalone EC2 instance from version 9.7 onwards; if upgrading from a version prior to 9.7 and using the Web Application Firewall these instructions must be followed to correctly back up and restore any firewall configuration.   Make a backup of the traffic manager configuration (See section "System > Backups" in the Traffic Manager User Manual), and export it. If you are upgrading from a  version prior to 9.7 and are using the Web Application Firewall, back up the Web Application Firewall configuration - Log on to a command line - Run /opt/zeus/stop-zeus - Copy /opt/zeus/zeusafm/current/var/lib/config.db off the appliance. Shut down the original appliance. Deploy a new appliance with the same network interfaces as the original. If you backed up the application firewall configuration earlier, restore it here onto the new appliance, before you restore the traffic manager configuration: - Copy the config.db file to /opt/zeus/stingrayafm/current/var/lib/config.db    (overwriting the original) - Check that the owner on the config.db file is root, and the mode is 0644. Import and restore the traffic manager configuration via the UI. If you have application firewall errors Use the Diagnose page to automatically fix any configuration errors Reset the Traffic Manager software.   Upgrading a cluster of Virtual Appliances (except Amazon EC2)   This process will replace the appliances in the cluster, one at a time, maintaining the same IP addresses. As the cluster will be reduced by one at points in the upgrade process, you should ensure that this is carried out at a time when the cluster is otherwise healthy, and of the n appliances in the cluster, the load can be handled by (n-1) appliances.   Before beginning the process, ensure that any cluster errors have been resolved. Nominate the appliance which will be the last to be upgraded (call it the final appliance).  When any of the other machines needs to be removed from the cluster, it should be done using the UI on this appliance, and when a hostname and port are required to join the cluster, this appliance's hostname should be used. If you are using the Web Application Firewall first ensure that vWAF on the final appliance in the cluster is upgraded to the most recent version, using the vWAF updater. Choose an appliance to be upgraded, and remove the machine from the cluster: - If it is not the final appliance (nominated in step 2),    this should be done via the UI on the final appliance - If it is the final appliance, the UI on any other machine may be used. Make a backup of the traffic manager configuration (System > Backups) on the appliance being upgraded, and export the backup.  This backup only contains the machine specific info for that appliance (networking config etc). Shut down the appliance, and deploy a new appliance at the new version.  When deploying, it needs to be given the identical hostname to the machine it's replacing. Log on to the admin UI of the new appliance, and import and restore the backup from step 5. If you are using the Web Application Firewall, accessing the Application Firewall tab in the UI will fail and there will be an error on the Diagnose page and an 'Update Configuration' button. Click the Update Configuration button once, then wait for the error to clear.  The configuration is now correct, but the admin server still needs to be restarted to pick up the configuration: # $ZEUSHOME/admin/rc restart Now, upgrade the application firewall on the new appliance to the latest version. Join into the cluster: For all appliances except the final appliance, you must not select any of the auto-detected existing clusters.  Instead manually specify the hostname and port of the final appliance. If you are using Web Application Firewall, there may be an issue where the config on the new machine hasn't synced the vWAF config from the old machine, and clicking the 'Update Application Firewall Cluster Status' button on the Diagnose page doesn't fix the problem. If this happens, firstly get the clusterPwd from the final appliance: # grep clusterPwd /opt/zeus/zxtm/conf/zeusafm.conf clusterPwd = <your cluster pwd> On the new appliance, edit /opt/zeus/zxtm/conf/zeusafm.conf (with e.g. nano or vi), and replace the clusterPwd with the final appliance's clusterPwd. The moment that file is saved, vWAF should get restarted, and the config should get synced to the new machine correctly. When you are upgrading the final appliance, you should select the auto-detected existing cluster entry, which should now list all the other cluster peers. Once a cluster contains multiple versions, configuration changes must not be made until the upgrade has been completed, and 'Cluster conflict' errors are expected until the end of the process. Repeat steps 4-9 until all appliances have been upgraded.   Upgrading a cluster of STM EC2 appliances   Because EC2 licenses are not tied to the IP address, it is recommended that new EC2 instances are deployed into a cluster before removing old instances.  This ensures that the capacity of the cluster is not reduced during the upgrade process.  This process is documented in the "Creating a Traffic Manager Instances on Amazon EC2" chapter in the Traffic Manager Cloud Getting Started Guide.  The clusterPwd may also need to be fixed as above.

This user-contributed article describes how to parse and decode credentials in NTLM authentication. You can then log these credentials for audit reasons. It was a requirement that we needed to log all usernames against incoming requests, so that should there be a case of misuse, we would know which user generated the request, and which workstation was used.   This rule extracts the NTLM authentication details and logs them to the Stingray Event Log. NTLM background NTLM uses three different NTLM message types to complete a handshake for a given request. These are: NTLM Type-1 Message: This contains the hostname, the domain name, and the fact that it is a NTLM request type1, to initiate the correct stage in the handshake. NTLM Type-2 Message: This contains a NTLM challenge from the server. NTLM Type-3 Message: This contains DOMAIN, USERNAME, and Workstation\Hostname. For further information on the NTLM handshake go here: http://davenport.sourceforge.net/ntlm.html The Plan To fulfill the requirements and to ease load on the servers we will ignore Type-1/Type-2 messages, and instead just decode/process Type-3 Messages. We want to make the data available to the traffic manager to log, but still keep the request secure, i.e. not transmit the decoded information in headers. We will use the connection.data.set($key, $value) function; to access the values, use the %{key}d macro in the Virtual Server -> Edit -> Request Logging -> log!format parameter. The Code Please note Basic Authentication is included as a just in case you need it: $h = http.getHeader( "Authorization" ); # Although none of our websites use this,i have still included Basic Authenticaton. if( string.startsWith( $h, "Basic " ) ) {    $enc = string.skip( $h, 6 );    $userpasswd = string.base64decode( $enc );    log.info( "Basic: User used: ".$userpasswd ); } # Test to see if the Authorization token, begins with NTLM if(string.startsWith( $h, "NTLM " )) {    # Skip Authorization Token Header 'NTLM ', so we can decode just token.    $enc = string.skip( $h, 5 );    $ntlmpacket= string.base64decode( $enc ); #Decode TOKEN       # Username, DOMAIN, and Workstation are only in the third NTLM handshake.    # So we ignore the initial handshakes and test for the third, '3'.    if((string.bytesToInt(string.substring($ntlmpacket, 8, 8))) == 3) {       # Extract header fields.       $B = string.substring($ntlmpacket, 28, 51);             # Select and decode the Domain Offset, Domain length, Username length and Workstation length.       # Numbers are little-endian, so can't just use string.bytesToInt() on the entire substring       $dLen = ((string.bytesToInt(string.substring($B, 0, 0)))          +((string.bytesToInt(string.substring($B, 1, 1)))*256));       $dOff = ((string.bytesToInt(string.substring($B, 4, 4)))          +((string.bytesToInt(string.substring($B, 5, 5)))*256)          +((string.bytesToInt(string.substring($B, 6, 6)))*(256*256))          +((string.bytesToInt(string.substring($B, 7, 7)))*(256*256*256)));       $uLen = ((string.bytesToInt(string.substring($B, 8, 8)))          +((string.bytesToInt(string.substring($B, 9, 9)))*256));       $wLen = ((string.bytesToInt(string.substring($B, 16, 16)))          +((string.bytesToInt(string.substring($B, 17, 17)))*256));       # The data we are after is back to back, so we only need the initial offset;       # we can decode the rest with the lengths of the previous key.       connection.data.set( "NTLM_Domain", string.substring($ntlmpacket, $dOff, $dOff+$dLen-1 ) );       connection.data.set( "NTLM_User", string.substring($ntlmpacket, $dOff + $dLen, $dOff + $dLen + $uLen - 1 ) );       connection.data.set( "NTLM_Workstation", string.substring($ntlmpacket, $dOff + $dLen + $uLen, $dOff + $dLen + $uLen + $wLen - 1 ) );    } } You can log the NTLM authentication parameters in the Request log using the appropriate log format macros: %{NTLM_Domain}d etc.

A user commented that Stingray Traffic Manager sometimes adds a cookie named 'X-Mapping-SOMERANDOMDATA' to an HTTP response, and wondered what the purpose of this cookie was, and whether it constitited a privacy or security risk.   Transparent Session Affinity   The cookie used used by Stingray's 'Transparent Session Affinity' persistence class.   Transparent session affinity inserts cookies into the HTTP response to track sessions. This is generally the most appropriate method for HTTP and SSL-decrypted HTTPS traffic, because it does not require the nodes to set any cookies in their response.   The persistence class adds a cookie to the HTTP response that identifies the name of the session persistence class and the chosen back-end node:   Set-Cookie: X-Mapping-hglpomgk=4A3A3083379D97CE4177670FEED6E830; path=/   When subsequent requests in that session are processed and the same sesison persistence class is invoked, it inspects the requests to determine if the named cookie exists. If it does, the persistence class inspects the value of the cookie to determine the node to use.   The unique identifier in the cookie name is a hashed version of the name of the session persistence class (there may be multiple independent session persistence rules in use). When the traffic manager processes a request, it can then identify the correct cookie for the active session persistence class.   The value of the cookie is a hashed version of the name of the selected node in the cluster. It is non-reversible by an external party. The value identifies which server the session should be persisted to. There is no personally-identifiable information in the cookie. Two independent users who access the service, are managed by the same session persistence class and routed to the same back-end server will be assigned the same named cookie and value.

Stingray Traffic Manager operates as a full network proxy.  Incoming TCP and UDP traffic is terminated on the traffic manager, and new TCP or UDP sessions are initiated from the traffic manager to the selected target server.   This approach has the benefit that Stingray can apply a range of TCP optimizations (such as independent window scaling) and higher-level optimizations (HTTP connection reuse), and it's an architectural necessity for any complex content inspection and rewriting (including compression, SSL decryption and all manner of TrafficScript-based solutions).   However, the approach has the side effect that the target servers observe the connection as originating from the Stingray device, not from the remote client.  There are several situations where this may be a problem:   Security and access control measures that need to observe the source IP address of a connection will not work Access logs will identify the Stingray IP address as the source of the connection, and compliance requirements may mandate that the true origin is recorded   There are a number of steps you can take to address problems that arise from this situation.   Offload the task that requires the IP address on to the Stingray device   In many cases, it's possible to move the task that requires access to the IP address from the back-end servers and deploy it on the traffic manager instead:   Access Logging: Stingray provides full webserver-style access logging.  Another advantage of logging transactions on Stingray rather than the webserver cluster is that you don't need to worry about merging log files from multiple servers Security: You can implement a range of IP-based security measures on Stingray, such as Checking IP addresses against a DNS blacklist with Stingray Traffic Manager   Modify the behavior of the Server Application   When Stingray manages an HTTP connection, it adds an X-Cluster-Client-Ip header to the request that identifies the true source address. A web based application that wishes to know the source address of the connection could inspect the value of this header instead.   For example, if you are logging transactions using the common log format in a server such as Apache:   LogFormat "%h %l %u %t \"%r\" %>s %b"   ... you can replace the %h macro with a macro that records the value of the custom header that Stingray inserts:   LogFormat "%{X-Cluster-Client-Ip} %l %u %t \"%r\" %>s %b"   If you are using Apache, you should consider using the mod_remoteip - Apache HTTP Server module (thanks to Julian Midgley for the following).  Enable it as follows:   LoadModule remoteip_module modules/mod_remoteip.so RemoteIPHeader X-Cluster-Client-Ip RemoteIPTrustedProxy 1.2.3.4   ... where 1.2.3.4 is the trusted source of the traffic (i.e. the IP address of the Stingray device).  If you want to trust the header even if it points to a private IP (e.g. 192.168.0.1), then use RemoteIPInternalProxy instead of RemoteIPTrustedProxy.   Note that Apache will continue to log the Stingray IP address when using %h in the log file; replace this with %a to get the client IP address.   If you're using iPlanet, SunONE or a related webserver, you can look at this alternative: Preserving the Client IP address to iPlanet/SunONE/Sun Java System Web Server servers and apps.   Use Stingray's IP Transparency Feature   Stingray's IP Transparency Feature is used to rewrite the source IP address in the server-side connection so that the TCP and UDP traffic appears to originate from the remote client.   It is a very effective solution, but it requires careful network configuration and it incurs an additional workload on the Stingray host because it needs to maintain a large NAT table for the rewritten connections.   On the Stingray Virtual Appliance, the ztrans kernel module that provides IP Transparency is pre-installed; if you are using the Stingray software on a Linux host, you will need to install the Stingray Kernel Modules for Linux Software.  The feature is not available for Solaris.   Once installed, you enable IP Transparency on a per-pool basis:     Please refer to the Stingray Product Documentation for more information.   Read more   HowTo: Spoof Source IP Addresses with IP Transparency Transparent Load Balancing with Stingray Traffic Manager Preserving the Client IP address to iPlanet/SunONE/Sun Java System Web Server servers and apps

This guide will walk you through the setup to deploy Global Server Load Balancing on Traffic Manager using the Global Load Balancing feature. In this guide, we will be using the "company.com" domain.     DNS Primer and Concept of operations: This document is designed to be used in conjuction with the Traffic Manager User Guide.   Specifically, this guide assumes that the reader: is familiar with load balancing concepts; has configured local load balancing for the the resources requiring Global Load Balancing on their existing Traffic Managers; and has read the section "Global Load Balancing" of the Traffic Manager User Guide in particular the "DNS Primer" and "About Global Server Load Balancing" sections.   Pre-requisite:   You have a DNS sub-domain to use for GLB.  In this example we will be using "glb.company.com" - a sub domain of "company.com";   You have access to create A records in the glb.company.com (or equivalent) domain; and   You have access to create CNAME records in the company.com (or equivalent) domain.   Design: Our goal in this exercise will be to configure GLB to send users to their geographically closes DC as pictured in the following diagram:   Design Goal We will be using an STM setup that looks like this to achieve this goal: Detailed STM Design     Traffic Manager will present a DNS virtual server in each data center.  This DNS virtual server will take DNS requests for resources in the "glb.company.com" domain from external DNS servers, will forward the requests to an internal DNS server, an will intelligently filter the records based on the GLB load balancing logic.     In this design, we will use the zone "glb.company.com".  The zone "glb.company.com" will have NS records set to the two Traffic IP addresses presented by vTM for DNS load balancing in each data centre (172.16.10.101 and 172.16.20.101).  This set up is done in the "company.com" domain zone setup.  You will need to set this up yourself, or get your DNS Administrator to do it.       DNS Zone File Overview   On the DNS server that hosts the "glb.company.com" zone file, we will create two Address (A) records - one for each Web virtual server that the vTM's are hosting in their respective data centre.     Step 0: DNS Zone file set up Before we can set up GLB on Traffic Manager, we need to set up our DNS Zone files so that we can intelligently filter the results.   Create the GLB zone: In our example, we will be using the zone "glb.company.com".  We will configure the "glb.company.com" zone to have two NameServer (NS) records.  Each NS record will be pointed at the Traffic IP address of the DNS Virtual Server as it is configured on vTM.  See the Design section above for details of the IP addresses used in this sample setup.   You will need an A record for each data centre resource you want Traffic Manager to GLB.  In this example, we will have two A records for the dns host "www.glb.company.com".  On ISC Bind name servers, the zone file will look something like this: Sample Zone FIle     ; ; BIND data file for glb.company.com ; $TTL 604800 @ IN SOA stm1.glb.company.com. info.glb.company.com. ( 201303211322 ; Serial 7200 ; Refresh 120 ; Retry 2419200 ; Expire 604800 ; Default TTL ) @ IN NS stm1.glb.company.com. @ IN NS stm2.glb.company.com. ; stm1 IN A 172.16.10.101 stm2 IN A 172.16.20.101 ; www IN A 172.16.10.100 www IN A 172.16.20.100   Pre-Deployment testing:   - Using DNS tools such as DiG or nslookup (do not use ping as a DNS testing tool) make sure that you can query your "glb.company.com" zone and get both the A records returned.  This means the DNS zone file is ready to apply your GLB logic.  In the following example, we are using the DiG tool on a linux client to *directly* query the name servers that the vTM is load balancing  to check that we are being served back two A records for "www.glb.company.com".  We have added comments to the below section marked with <--(i)--| : Test Output from DiG [email protected]$ dig @172.16.10.40 www.glb.company.com A ; <<>> DiG 9.8.1-P1 <<>> @172.16.10.40 www.glb.company.com A ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19013 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.glb.company.com. IN A ;; ANSWER SECTION: www.glb.company.com. 604800 IN A 172.16.20.100 <--(i)--| HERE ARE THE A RECORDS WE ARE TESTING www.glb.company.com. 604800 IN A 172.16.10.100 <--(i)--| ;; AUTHORITY SECTION: glb.company.com. 604800 IN NS stm1.glb.company.com. glb.company.com. 604800 IN NS stm2.glb.company.com. ;; ADDITIONAL SECTION: stm1.glb.company.com. 604800 IN A 172.16.10.101 stm2.glb.company.com. 604800 IN A 172.16.20.101 ;; Query time: 0 msec ;; SERVER: 172.16.10.40#53(172.16.10.40) ;; WHEN: Wed Mar 20 16:39:52 2013 ;; MSG SIZE rcvd: 139       Step 1: GLB Locations GLB uses locations to help STM understand where things are located.  First we need to create a GLB location for every Datacentre you need to provide GLB between.  In our example, we will be using two locations, Data Centre 1 and Data Centre 2, named DataCentre-1 and DataCentre-2 respectively: Creating GLB  Locations   Navigate to "Catalogs > Locations > GLB Locations > Create new Location"   Create a GLB location called DataCentre-1   Select the appropriate Geographic Location from the options provided   Click Update Location   Repeat this process for "DataCentre-2" and any other locations you need to set up.     Step 2: Set up GLB service First we create a GLB service so that vTM knows how to distribute traffic using the GLB system: Create GLB Service Navigate to "Catalogs > GLB Services > Create a new GLB service" Create your GLB Service.  In this example we will be creating a GLB service with the following settings, you should use settings to match your environment:   Service Name: GLB_glb.company.com   Domains: *.glb.company.com   Add Locations: Select "DataCentre-1" and "DataCentre-2"   Then we enable the GLB serivce:   Enable the GLB Service Navigate to "Catalogs > GLB Services > GLB_glb.company.com > Basic Settings" Set "Enabled" to "Yes"   Next we tell the GLB service which resources are in which location:   Locations and Monitoring Navigate to "Catalogs > GLB Services > GLB_glb.company.com > Locations and Monitoring" Add the IP addresses of the resources you will be doing GSLB between into the relevant location.  In my example I have allocated them as follows: DataCentre-1: 172.16.10.100 DataCentre-2: 172.16.20.100 Don't worry about the "Monitors" section just yet, we will come back to it.     Next we will configure the GLB load balancing mechanism: Load Balancing Method Navigate to "GLB Services > GLB_glb.company.com > Load Balancing"   By default the load balancing "algorithm" will be set to "Adaptive" with a "Geo Effect" of 50%.  For this set up we will set the "algorithm" to "Round Robin" while we are testing.   Set GLB Load Balancing Algorithm Set the "load balancing algorithm" to "Round Robin"   Last step to do is bind the GLB service "GLB_glb.company.com" to our DNS virtual server.   Binding GLB Service Profile Navigate to "Services > Virtual Servers > vs_GLB_DNS > GLB Services > Add new GLB Service" Select "GLB_glb.company.com" from the list and click "Add Service" Now that we have GLB applied to the "glb.company.com" zone, we can test GLB in action. Using DNS tools such as DiG or nslookup (again, do not use ping as a DNS testing tool) make sure that you can query against your STM DNS virtual servers and see what happens to request for "www.glb.company.com". Following is test output from the Linux DiG command. We have added comments to the below section marked with the <--(i)--|: Step 3 - Testing Round Robin Now that we have GLB applied to the "glb.company.com" zone, we can test GLB in action. Using DNS tools such as DiG or nslookup (again, do not use ping as a DNS testing tool) make sure that you can query against your STM DNS virtual servers and see what happens to request for "www.glb.company.com". Following is test output from the Linux DiG command. We have added comments to the below section marked with the <--(i)--|:   Testing [email protected] $ dig @172.16.10.101 www.glb.company.com ; <<>> DiG 9.8.1-P1 <<>> @172.16.10.101 www.glb.company.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17761 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.glb.company.com. IN A ;; ANSWER SECTION: www.glb.company.com. 60 IN A 172.16.2(i)(i)0.100 <--(i)--| DataCentre-2 response ;; AUTHORITY SECTION: glb.company.com. 604800 IN NS stm1.glb.company.com. glb.company.com. 604800 IN NS stm2.glb.company.com. ;; ADDITIONAL SECTION: stm1.glb.company.com. 604800 IN A 172.16.10.101 stm2.glb.company.com. 604800 IN A 172.16.20.101 ;; Query time: 1 msec ;; SERVER: 172.16.10.101#53(172.16.10.101) ;; WHEN: Thu Mar 21 13:32:27 2013 ;; MSG SIZE rcvd: 123 [email protected] $ dig @172.16.10.101 www.glb.company.com ; <<>> DiG 9.8.1-P1 <<>> @172.16.10.101 www.glb.company.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9098 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.glb.company.com. IN A ;; ANSWER SECTION: www.glb.company.com. 60 IN A 172.16.1(i)0.100 <--(i)--| DataCentre-1 response ;; AUTHORITY SECTION: glb.company.com. 604800 IN NS stm2.glb.company.com. glb.company.com. 604800 IN NS stm1.glb.company.com. ;; ADDITIONAL SECTION: stm1.glb.company.com. 604800 IN A 172.16.10.101 stm2.glb.company.com. 604800 IN A 172.16.20.101 ;; Query time: 8 msec ;; SERVER: 172.16.10.101#53(172.16.10.101) ;; WHEN: Thu Mar 21 13:32:27 2013 ;; MSG SIZE rcvd: 123   Step 4: GLB Health Monitors Now that we have GLB running in round robin mode, the next thing to do is to set up HTTP health monitors so that GLB can know if the application in each DC is available before we send customers to the data centre for access to the website:     Create GLB Health Monitors Navigate to "Catalogs > Monitors > Monitors Catalog > Create new monitor" Fill out the form with the following variables: Name:   GLB_mon_www_AU Type:    HTTP monitor Scope:   GLB/Pool IP or Hostname to monitor: 172.16.10.100:80 Repeat for the other data centre: Name:   GLB_mon_www_US Type:    HTTP monitor Scope:   GLB/Pool IP or Hostname to monitor: 172.16.20.100:80   Navigate to "Catalogs > GLB Services > GLB_glb.company.com > Locations and Monitoring" In DataCentre-1, in the field labled "Add new monitor to the list" select "GLB_mon_www_AU" and click update. In DataCentre-2, in the field labled "Add new monitor to the list" select "GLB_mon_www_US" and click update.   Step 5: Activate your preffered GLB load balancing logic Now that you have GLB set up and you can detect application failures in each data centre, you can turn on the GLB load balancing algorithm that is right for your application.  You can chose between: GLB Load Balancing Methods Load Geo Round Robin Adaptive Weighted Random Active-Passive The online help has a good description of each of these load balancing methods.  You should take care to read it and select the one most appropriate for your business requirements and environment.   Step 6: Test everything Once you have your GLB up and running, it is important to test it for all the failure scenarios you want it to cover. Remember: failover that has not been tested is not failover...   Following is a test matrix that you can use to check the essentials: Test # Condition Failure Detected By / Logic implemented by GLB Responded as designed 1 All pool members in DataCentre-1 not available GLB Health Monitor Yes / No 2 All pool members in DataCentre-2 not available GLB Health Monitor Yes / No 3 Failure of STM1 GLB Health Monitor on STM2 Yes / No 4 Failure of STM2 GLB Health Monitor on STM1 Yes / No 5 Customers are sent to the geographically correct DataCentre GLB Load Balancing Mechanism Yes / No   Notes on testing GLB: The reason we instruct you to use DiG or nslookup in this guide for testing your DNS rather than using a tool that also does an DNS resolution, like ping, is because Dig and nslookup tools bypass your local host's DNS cache.  Obviously cached DNS records will prevent you from seeing changes in status of your GLB while the cache entries are valid.     The Final Step - Create your CNAME: Now that you have a working GLB entry for "www.glb.company.com", all that is left to do is to create or change the record for the real site "www.company.com" to be a CNAME for "www.glb.company.com". Sample Zone File ; ; BIND data file for company.com ; $TTL 604800 @ IN SOA ns1.company.com. info.company.com. ( 201303211312 ; Serial 7200 ; Refresh 120 ; Retry 2419200 ; Expire 604800 ; Default TTL ) ; @ IN NS ns1.company.com. ; Here is our CNAME www IN CNAME www.glb.company.com.

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

This article explains how to use Pulse vADC RESTful Control API with Perl.  It's a little more work than with Tech Tip: Using the RESTful Control API with Python - Overview but once the basic environment is set up and the framework in place, you can rapidly create scripts in Perl to manage the configuration.   Getting Started   The code examples below depend on several Perl modules that may not be installed by default on your client system: REST::Client, MIME::Base64 and JSON.   On a Linux system, the best way to pull these in to the system perl is by using the system package manager (apt or rpm). On a Mac (or a home-grown perl instance), you can install them using CPAN   Preparing a Mac to use CPAN   Install the package 'Command Line Tools for Xcode' either from within the Xcode or directly from https://developer.apple.com/downloads/.   Some of the CPAN build scripts indirectly seek out /usr/bin/gcc-4.2 and won't build if /usr/bin/gcc-4.2 is missing.  If gcc-4.2 is missing, the following should help:   $ ls -l /usr/bin/gcc-4.2 ls: /usr/bin/gcc-4.2: No such file or directory $ sudo ln -s /usr/bin/gcc /usr/bin/gcc-4.2   Installing the perl modules   It may take 20 minutes for CPAN to initialize itself, download, compile, test and install the necessary perl modules:   $ sudo perl –MCPAN –e shell cpan> install Bundle::CPAN cpan> install REST:: Client cpan> install MIME::Base64 cpan> install JSON   Your first Perl REST client application   This application looks for a pool named 'Web Servers'.  It prints a list of the nodes in the pool, and then sets the first one to drain.   #!/usr/bin/perl use REST::Client; use MIME::Base64; use JSON; # Configurables $poolname = "Web Servers"; $endpoint = "stingray:9070"; $userpass = "admin:admin"; # Older implementations of LWP check this to disable server verification $ENV{PERL_LWP_SSL_VERIFY_HOSTNAME}=0; # Set up the connection my $client = REST::Client->new( ); # Newer implementations of LWP use this to disable server verification # Try SSL_verify_mode => SSL_VERIFY_NONE. 0 is more compatible, but may be deprecated $client->getUseragent()->ssl_opts( SSL_verify_mode => 0 ); $client->setHost( "https://$endpoint" ); $client->addHeader( "Authorization", "Basic ".encode_base64( $userpass ) ); # Perform a HTTP GET on this URI $client->GET( "/api/tm/1.0/config/active/pools/$poolname" ); die $client->responseContent() if( $client->responseCode() >= 300 ); # Add the node to the list of draining nodes my $r = decode_json( $client->responseContent() ); print "Pool: $poolname:\n"; print " Nodes: " . join( ", ", @{$r->{properties}->{basic}->{nodes}} ) . "\n"; print " Draining: " . join( ", ", @{$r->{properties}->{basic}->{draining}} ) . "\n"; # If the first node is not already draining, add it to the draining list $node = $r->{properties}->{basic}->{nodes}[0]; if( ! ($node ~~ @{$r->{properties}->{basic}->{draining}}) ) { print " Planning to drain: $node\n"; push @{$r->{properties}->{basic}->{draining}}, $node; } # Now put the updated configuration $client->addHeader( "Content-Type", "application/json" ); $client->PUT( "/api/tm/1.0/config/active/pools/$poolname", encode_json( $r ) ); die $client->responseContent() if( $client->responseCode() >= 300 ); my $r = decode_json( $client->responseContent() ); print " Now draining: " . join( ", ", @{$r->{properties}->{basic}->{draining}} ) . "\n";   Running the script   $ perl ./pool.pl Pool: Web Servers: Nodes: 192.168.207.101:80, 192.168.207.103:80, 192.168.207.102:80 Draining: 192.168.207.102:80 Planning to drain: 192.168.207.101:80 Now draining: 192.168.207.101:80, 192.168.207.102:80   Notes   This script was tested against two different installations of perl, with different versions of the LWP library.  It was necessary to disable SSL certificate checking using:   $ENV{PERL_LWP_SSL_VERIFY_HOSTNAME}=0;   ... with the older, and:   # Try SSL_verify_mode => SSL_VERIFY_NONE. 0 is more compatible, but may be deprecated $client->getUseragent()->ssl_opts( SSL_verify_mode => 0 );   with the new.  The older implementation failed when using SSL_VERIFY_NONE.  YMMV.

I have several hundred websites that all use host headers in IIS. I would like to use a single virtual/Public IP address and have the traffic manager select the appropriate pool based on the host header passed in. I’ve been using a traffic script similar to the code snippet below. Is there a more efficient way to code this there will be several hundred pools and if statements? Can you do case statements in traffic script? $HostHeader = http.getHostHeader(); if( string.contains( $HostHeader, "site1.test.com" ) ){    pool.use( "Pool_site1.test.com_HTTP"); }else if( string.contains( $HostHeader, "site2.test.com" ) ){    pool.use( "Pool_site2.test.com_HTTP"); }else if( string.contains( $HostHeader, "site3.test.com" ) ){    pool.use( "Pool_site3.test.com_HTTP"); }else if( string.contains( $HostHeader, "site4.test.com" ) ){    pool.use( "Pool_site4.test.com_HTTP"); }else if( string.contains( $HostHeader, "site5.test.com" ) ){    pool.use( "Pool_site5.test.com_HTTP"); }else if( string.contains( $HostHeader, "site6.test.com" ) ){    pool.use( "Pool_site6.test.com_HTTP"); }else{    http.changeSite( "http://www.test.com" );   }