With the advent of SDN, questions have arisen about the continuing need for application delivery controllers (ADCs)....
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
ADCs were developed to distribute and balance loads across a group of Web servers. Could SDN controllers take over the role of ADCs -- becoming in effect SDN load balancers-- and thus eliminate their place in the network?
Like an ADC, an SDN controller is capable of monitoring Web servers' individual loads based on queue lengths and processing delays, sending incoming data requests to the least heavily loaded server. If simple load balancing had remained an ADC's sole function, an SDN controller would likely render it obsolete. However, the former can do more than just distribute application demand between servers.
In conventional networking, data flows through the device that makes routing decisions. Because ADCs are located directly in the data path, they can implement application-specific, software-driven functions that are not readily moved to an SDN controller. SDN separates the network control function from data movement, which means an SDN controller can make simple load balancing decisions based on server activity, but not on the contents of the data itself.
ADCs have been -- and continue to be -- delivered as standalone network appliances. Leading vendors have recognized the growth of virtualized systems and the increasing acceptance of SDN, developing virtual ADC implementations in response to this trend. These ADC vendors have formed alliances and integrated their products with virtual network environments, such as those from Cisco, VMware and OpenStack. They have also added script-driven features so network administrators can develop application-specific functions the ADC can execute.
Network security and monitoring
Firewalls, antivirus scanners and intrusion prevention systems have traditionally existed in separate devices. An ADC's location in the data path and its ability to execute application-specific scripts ideally positions it to scan incoming data for malware. Eliminating discrete security components reduces network complexity and capital cost.
ADCs can also protect servers from denial-of-service attacks by blocking problematic requests. A large, distributed attack would likely consume ADC resources, so many legitimate requests would fail to get through, but servers could support the few they did receive.
In addition, ADCs are ideally suited to gather performance and usage statistics due to their location in the data path. They can monitor server delays and also measure traffic by application, by end-user network or by individual end user.
How ADCs improve network efficiency
ADCs can improve network efficiency in ways other than balancing the load. In an environment without an ADC, each end-user browser would create one or more Transmission Control Protocol (TCP) connections to a Web server. Use of network address translation (NAT) in the end-user interface to the Internet reduces the number of connections, but websites managing access from a large number of end-user networks would still be burdened with a very large number of connections. Furthermore, TCP connections are created and torn down for each request, a resource-intensive operation.
Using TCP multiplexing, ADCs establish persistent connections with back-end servers. Individual browsers or NAT functions create connections to the ADC, offloading TCP connection management from the Web servers, and thereby reducing the total number of servers required.
The TCP Slow Start algorithm prevents a new connection from choking the network with an initial burst. By multiplexing TCP connections, Slow Start happens only once. Without an ADC, each browser-to-Web server connection would need to endure the Slow Start process.
Today's Web-based applications commonly require a long sequence of requests and responses. When an initial request reaches a Web server, the server creates a session in which to store information about the request. Simple load balancing might then direct the next set of requests to a different server. The second server creates another session while the session on the initial server times out and is eventually deleted. This is obviously inefficient. ADCs maintain information about ongoing transactions and ensure each subsequent request is directed to the same server.
This technique -- known as session persistence -- is especially critical for supporting Secure Sockets Layer (SSL). With session persistence and TCP multiplexing, ADCs can offload the session creation handshake as well as data decryption and encryption. Without an ADC, Web servers would bear this burden, and without TCP multiplexing, the handshake would need to be repeated each time a session moved to a different server.
Traffic shaping is another way that ADCs improve overall network and application performance. TCP contains mechanisms such as delayed and selective acknowledgement signals (ACKs), adaptive window sizing and explicit congestion notifications. ADCs use these techniques to increase efficiency by reducing bursts and combining short packets into larger ones.
Differentiating servers based on the type of request could improve reliability by simplifying application software. Each application would handle one type of request. Network administrators would supply an ADC script that scans incoming data and directs each request to the application designed to handle it.
ADC vendors are prepared for SDN
ADCs continue to be sold pre-installed in hardware appliances, but the leading vendors, in adapting to SDN, have also developed virtual units that can be quickly inserted in virtualized service chains. These chains, along with other NFV components, can be moved as needed by cloud automation systems.
If the term "software-defined networking" can be extended beyond a controller connected to switches via OpenFlow, then we can certainly consider virtual ADCs -- with enhanced scripting -- as components in an SDN network.
About the author:
David B. Jacobs of The Jacobs Group has more than 20 years of networking industry experience. He has managed leading-edge software development projects and consulted to Fortune 500 companies as well as software startups.
Brocade plans to acquire virtual ADC product line
Why ADCs are relevant in a programmable world
Get the guide on buying the right ADC