Role of Application Delivery Controllers

Application Delivery Controllers have evolved over a period of time to do much more than application load balancing. Read on to find out some of the functionalities they provide…

Load Balancing: The primary function of an Application Delivery Controller (ADC) is to load balance the requests from the clients to appropriate servers by directing the incoming requests to the best performing and most accessible servers (by using various load balancing algorithms). It can determine the key elements of servers like number of concurrent connections and memory utilization. So, using an ADC is one way of expanding the number of servers for demanding web based applications and still ensure that the traffic is distributed across all the available servers. ADC’s can also determine if a particular server has a higher configuration (Dual Core Processors compared to Pentium III ones) and hence handle more requests, and accommodate such factors while distributing load. Click here to read more about application load balancing, in WAN optimization.

Fail-Over: If one of the servers is inaccessible (or down), the Application Delivery Controller can take that server off-line and re-route users to other functioning servers till the same is up and running.

Caching: Application Delivery Controllers can index frequently sent chunks of data streams and substitute them with shorter codes while sending them again. This helps reduce bandwidth especially for recurring/ frequently sent data. You can click this link to read a detailed account on types of Cashing for WAN optimization.

Protocol Substitution and Compression: Certain chatty protocols like TCP (which require frequent acknowledgements) are encapsulated and repackaged in to UDP packets and sent across the link in order to speed up the process, and hence optimize the WAN delivery. A variety of compression techniques are used to compress the data sent across the WAN. They are often encrypted while sending. Click here for reading a detailed account on Protocol Substitution and Compression.

Application Layer operation: ADC can operate on Application layer (Layer 7) of the OSI stack. So, they can take certain decision based on application layer criteria. For example, certain type of client requests (like video playback etc) can be selectively sent to a particular physical server optimized to perform such service.

High Availability: It is possible, and recommended to configure a couple of Application Delivery Controllers in High Availability mode in order to make sure that the application/website is not totally down due to the failure of an ADC.

SSL Offload: To enable the servers hosting applications to dedicate their hardware processors to process the requests related to the applications, SSL handshake and encryption/decryption processes are offloaded from the servers to the ADC’s. The ADC does the same by using certain ASIC chips which are tailor made to handle such operations. This would also enable the management of SSL certificates from a single place (ADC) rather than multiple servers. Some ADC’s would also offload processes like XML normalization.

Security: Since clients interface with ADC’s (rather than the host servers directly), certain basic security processes are also handled by some Application Delivery Controllers. They can check if the protocol messages are well formed, apply policies, discard DOS attacks, filter out attack signatures etc.

Network Link Optimization: Since many applications perform poorly when talking to slow, remote clients over unreliable networks, it is better that they speak to the application delivery controllers (which invariably happens when ADC is present), so that the applications perform their best believing that they are talking to fast local clients.

Connection Pooling: Opening a single web-page opens multiple TCP connections, which are generally short-lived. So, an Application Delivery Controller maintains a pool of open connections at all times, and when a client makes a request for new TCP connections, the ADC uses such already opened TCP connections instead of incurring the overhead and time associated with opening new connections.

Software based ADC/Virtualization: There are certain software based ADC’s (instead of appliance based) that can be loaded on generic computer servers and employed for the same WAN optimization applications. They might have an advantage over the generic appliance based ADC for cloud/virtualized server environments and better optimized for certain applications. But the appliance based ADC’s can also handle virtual server environments.

Connection Persistence: This is a method used by Application Delivery Controllers to ensure that for a prescribed duration, the user always comes back to the same server (as there is a chance that the ADC might push them to a different server each time they connect to) where they were previously associated with. This is critical for applications like e-commerce performing multiple transactions (through a web based ‘cart’ etc) as the first server ‘needs’ to remember all the previous transactions to complete the purchase procedure.

This can be done based on the source IP address, but with the advent of proxies and NAT mechanisms, this becomes ineffective. To solve this problem, cookie persistence was introduced, which uses browser cookies to identify users. The ADC or application can serve cookies to users at the start of a session and the user’s browser would automatically return the cookie during each return hit, which helps the ADC to identify that the user needs to be sent to the same server during the subsequent visits too. In a SSL based transaction, such cookie persistence is hard to achieve. But with SSLv3, there is a unique session ID (SSL session ID which is a 32 bit session identifier) which is used by the ADC to identify and balance the user to the appropriate server.

Direct Server Interface: In some applications, it may be required for the real servers to interface directly to the client requests (instead of going through the ADC). This becomes important especially in certain applications like transferring large payloads of video traffic etc (to avoid latency by interfacing with one more device like ADC), and hence certain ADC’s provision and allow the same, selectively.

Transparency: Certain Application Delivery Controllers can allow to preserve the client’s original IP address while sending requests to the server (normally IP address is changed by ADC as it acts like a NAT here). This is required for maintaining client IP address logs etc directly in the host servers, which are required for some applications.

excITingIP.com

You could stay up to date on the various computer networking technologies by subscribing to this blog with your email address in the sidebar box that says, ‘Get email updates when new articles are published’.




3 Comments

  1. Not a bad start, but for me you have missed out the most important aspects of what makes an ADC an ADC and not just an old fashioned Load Balancer.

    You touched on it when you rushed past the “Application Layer Operation” point. This is the hot spot that makes these products what they are. It’s not just about making decisions based on the App layer information, but being able to change/manipulate/replace this data that makes an ADC what it is.

    For this you need scripting language that enables you to describe in logical terms what it is the “business” wants to achieve with this traffic. For example, the business might say, when it’s busy I want to make sure our gold card holders continue to get a good service.

    Using an ADC with a scripting language enables you to translate this business requirement into what really happens to the traffic on the network. so in this case the ADC would monitor the performance levels, then when they start to fall off, either redirect the gold card members, or slow down the other users, or speak to the Hypervisor API and get more resource added or… you get the point.

    It’s beyond application intelligence, it’s application like agility.

    Nick

    • I am reminded of the old Analog/Digital PABX systems. When compared to the customization/ business process integration of the open source/ soft switches of today, they quite pale in comparison! Thanks for your comment, and good to see that load balancers are moving in that direction.

      excITingIP.com

  2. This is a really good introduction to Traffic Management but Frintonboy is right to highlight the ability to script traffic rules as a big differentiator between load balancing and traffic management.

    A couple of things worth highlighting when considering software vs hardware ADCs are:
    Wider range of licencing options with software
    Software based solutions are easier to scale quickly
    Software products do match the attributes of the virtual and cloud environments in terms of flexibility of deployment and scalability

Comments are closed