Methodologies for Scaling SLB Environments January 2007
Network Working Group
Internet Draft Z. Naseh
Document: draft-naseh-scaling-slb-02.txt Cisco Systems
Expires: July 2007 January 2007
Methodologies for Scaling Server Load Balancing Environments
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Naseh Expires – July 2007 [Page 1]
Methodologies for Scaling SLB Environments January 2007
Abstract
This document defines details of several design methodologies and
current best practices for scaling server load balancing (a.k.a.
content switching) environments in today’s enterprise data centers.
The scenarios covered in this document covers utilization of
protocols and technologies ranging from IPv4 routing to DNS for
scalability of server load balancing.
Table of Contents
1. Introduction...................................................2
2. Benefits of Scaling Content Switching..........................3
2.1 Scalability................................................3
2.2 Performance................................................3
3. Scaling Methodologies..........................................4
3.1 Distribution of Applications...............................4
3.2 Using DNS for Application Scalability......................4
3.3 Using IP Routing for Application Scalability...............4
4. Application Distribution Approach..............................5
5. DNS-Based Scaling Approach.....................................5
5.1 Predictable Traffic Flow...................................7
5.2 Ease of Management and Maintenance.........................7
6. IP Routing Based Scaling Approach..............................7
7. Scaling Beyond Server Capacity.................................8
8. IANA Considerations............................................9
9. Security Considerations........................................9
10. Acknowledgments...............................................9
11. Author's Addresses............................................9
12. Copyright Notice..............................................9
13. Disclaimer....................................................9
14. Intellectual Property........................................10
1.
Introduction
An enterprise Data Center is a complex environment which is used to
host mission critical internal and external applications servers,
data bases and data storage devices. The Data Center infrastructure
is tied together using Layer2 and Layer3 devices. The security of the
compute infrastructure and the networking devices is made possible
using firewalls and intrusion detection devices. In order to scale
the applications, the key service provided within the data center is
server load balancing. This is also known as content switching. The
idea is to distribute user requests across a group or farm of servers
hosting the same application or daemon.
Naseh Expires – July 2007 [Page 2]
Methodologies for Scaling SLB Environments January 2007
In this document will focus on how a load-balanced environment can be
scaled. With the passage of time as the user base increases, the key
question that comes up is how to scale an application such that user
experience is not compromised. Typically, an application is scaled
simply by adding more servers to the load-balanced server farms
within the same data center or by replicating the application in
another data center. Having the same application exist in two in-
service data centers achieves dual purposes - one being scalability
and the other being disaster recovery. There are several ways to
provide redundancy between the data centers. These approaches are not
covered in this memo.
This document introduces the concepts and design methodologies of
scaling load-balancing services within a single data center. It will
be discussed how load-balanced applications can be scaled using DNS
or IP and also how they are scaled when server capacity within a load
balancer is maximized. In other words, we will cover how the same
application is load balanced in two different SLB devices, the
approaches to SLB device selection, and the methods of scaling when
the servers within an SLB device have reached their maximum capacity
or have failed health checks.
2.
Benefits of Scaling Content Switching
The motivations behind scaling content switching within a data center
are similar to the motivations for server load balancing. Scalability
and performance are the main reasons behind server load balancing in
general.
2.1
Scalability
A server load-balancing device can be fully utilized in connections
per second, concurrent connections, probes or health checks to
servers, slow path or process-switching performance, or software
configuration limits. Once any of the above-mentioned functionality
is maximized, another server load-balancing device would have to be
deployed.
2.2
Performance
Performance of the load balancer in terms of packet switching and raw
throughput is another key reason to deploy multiple pairs of server
load-balancing devices in the same data center. To overcome
performance limitations of the load balancer, one option is to design
the SLB device so that only load-balanced traffic passes through the
SLB devices. If this does not help, another pair of load balancers
Naseh Expires – July 2007 [Page 3]
Methodologies for Scaling SLB Environments January 2007
can be deployed for a different application or the same application.
In the next few sections, several design methodologies that can be
used to scale SLB environments will be discussed.
3.
Scaling Methodologies
In this section, some of the design approaches and technologies that
can be used to scale within a data center will be introduced. The key
scaling methodologies are distributing applications over multiple SLB
devices, using smart DNS to distribute the same application traffic
over multiple SLB devices and using IP Routing to distribute the same
application traffic over multiple SLB devices.
3.1
Distribution of Applications
Distributing applications across multiple SLB devices is the simplest
and the most manageable of all the design approaches. The idea is to
segment an existing fully utilized SLB device’s configuration with
respect to applications. One set of applications will reside in the
old SLB device, and a different set of applications will reside in a
new SLB device.
In this approach, each application owner would have to service a
particular SLB device. Routing infrastructure changes or DNS changes
are not required.
3.2
Using DNS for Application Scalability
In a situation where the SLB device is overloaded by a single
application, distribution of applications will not help. In that
case, the particular application traffic will have to be split across
multiple pairs of SLB devices. One way to do this is to host the
application using different sets of server farms and different
virtual IP addresses on separate pairs of SLB devices. A smart DNS
server (a DNS device that can do health checks and verify
availability of the virtual IP addresses) can be used to distribute
the users across the two virtual IP addresses being hosted on
separate pairs of SLB devices.
A typical smart DNS appliance does have source IP-based stickiness or
source IP-based hash functionality available that can be used to
provide client persistence to a particular SLB device.
3.3
Using IP Routing for Application Scalability
In environments where the use of DNS is not desired and where the
client base is internal, an IP-based load-balancing solution can be
Naseh Expires – July 2007 [Page 4]
Methodologies for Scaling SLB Environments January 2007
used to scale the SLB device. This design requires the application to
be hosted using different sets of server farms but same Virtual IP
address on separate pairs of SLB devices. Based on the availability
of the servers, the Virtual IP address will be injected into the
routing table of the adjacent routers. For this methodology the SLB
device will need to establish routing peering with its adjacent
router. If servers are operational in both SLB devices, then two
host-based routes for the same Virtual IP address will show up in the
routing domain. As client requests are routed, they will end up at
the SLB device closest to them in terms of routing metrics.
4.
Application Distribution Approach
The application distribution approach is fairly straight forward
conceptually. It requires the configurations of the SLB device to be
split along the lines of different applications or business units or
owners. The segmented configuration resides on different SLB devices.
The complex part of this approach is to distribute the server
resources. The servers belonging to a particular application should
have their default gateway pointing to the SLB device hosting that
specific application. This becomes difficult when load-balanced
servers associated with different applications reside in the same
VLAN.
To ensure that load-balanced server return traffic traverses the
appropriate SLB device, we can take several measures. These methods
range from re-IP addressing and placement of the servers in
appropriate VLANs behind the SLB device to redesigning the SLB
environment to a one-armed design approach where the physical and
logical presence of the application servers does not matter.
For example, partner.example.com and shop.example.com resided on the
same SLB device. As the usage of the SLB device went to 100 percent,
clients started experiencing delays. These delays were resolved by
splitting the SLB device configurations into two different units, one
hosting partner.example.com and the other shop.example.com.
5.
DNS-Based Scaling Approach
DNS is typically used to load balance applications across multiple
data centers. This is known as global site (or server) load balancing
(GSLB). Similarly, we can use DNS to perform GSLB within a data
center to scale SLB devices.
The DNS-based scaling approach is simple to integrate in most
existing infrastructures and can be migrated over time. For example,
a pair of intelligent DNS appliances is deployed within a data center
and the DNS appliances are authoritative for the domains
Naseh Expires – July 2007 [Page 5]
Methodologies for Scaling SLB Environments January 2007
shop.example.com and partner.example.com. These applications are load
balanced by the SLB pairs within the data center. Each SLB pair load
balances traffic across a local set of servers for the same
application.
Let’s take the example of shop.example.com. The virtual IP addresses
for this are 10.11.12.15 in data center segment 1 and 10.12.13.15 in
data center segment 2. The idea is that if any client would like to
access shop.example.com, the DNS appliance will respond with the next
available VIP, 10.12.13.15 or 10.11.12.15, based on the load-
balancing algorithm. The load-balancing methods on the DNS appliance
range from simple round robin to static proximity based on the
requestor’s source IP address. Let’s say a client with an IP address
in subnet 10.11.0.0 queries the DNS appliance; the response should
have the VIP of data center segment 1 unless that VIP is down. The
DNS appliance accomplishes that by looking at the source IP of the
requestor. If the source IP is that of a client or server in subnet
10.11.0.0, for example, then answer within the DNS response has the
data center segment 1 VIP (10.11.12.15). Following are the steps of
DNS resolution:
1. A client with IP address 10.11.42.31 issues a DNS query for
shop.example.com.
2. The internal example.com name server receives the request and
responds with both DNS appliances’ IP addresses; that is,
10.11.10.171 and 10.12.11.161.
3. The client sends the request to the first member in the answer
list; that is, 10.11.10.171. (If 10.11.10.171 times out, the
client queries 10.12.11.161.)
4. DNS appliance inspects the query and finds a match for
shop.example.com; the policy configured on the DNS appliance
indicates to look at the source IP address of the requestor and
respond back appropriately. Static policy configuration is
similar to that detailed here:
a. If the source address is 10.11.0.0/16, then respond with
10.11.12.15; if 10.11.12.15 is down, respond with
10.12.13.15.
b. If the source address is 10.12.0.0/16, then respond with
10.12.13.15; if 10.12.13.15 is down, respond with
10.11.12.15.
c. Alternatively, do a source IP hash and balance between
10.11.12.15 and 10.12.13.15.
5. As the client gets the response of the local SLB device VIP
(10.11.12.15), it initiates the TCP connect to that VIP.
The DNS-based solution meets the requirements of proximity and
stickiness to the selected SLB device. The key advantages of the DNS-
based approach are:
. Predictable traffic flow
Naseh Expires – July 2007 [Page 6]
Methodologies for Scaling SLB Environments January 2007
. Ease of management and maintenance of each SLB node
5.1
Predictable Traffic Flow
The DNS-based solution is independent of routing protocol issues like
flaps (rapid fluctuation of routing information) or slow convergence.
The decision about which SLB device will be used is made before the
session is initiated by the data center client. The SLB node
selection is based on the IP address and configured policy, thus the
flow is known. The configured decision will be taken unless the SLB
node in the policy is unavailable. Several balancing methods similar
to the ones used in SLB devices are available to load balance client
DNS requests.
5.2
Ease of Management and Maintenance
In the DNS approach previously mentioned, the DNS appliance is
configured with the virtual IP addresses on the SLB devices in all
the data center segments. In order to take down an application,
services, or the entire SLB node, the process is fairly simple. The
service can be easily suspended on the DNS appliance by a click of a
button.
6.
IP Routing Based Scaling Approach
The IP Routing based approach works best when the client base is
internal or in a controlled routing environment. In this solution,
the application is hosted on multiple SLB devices with different
servers but the same Virtual IP address.
In this design methodology the SLB device injects a host route for
the Virtual IP address in the adjacent router as long as at least one
of the servers in the respective server farm is operational.
Extensive probing is available on the SLB device to check the health
of the server and the appropriate application daemon that runs on the
server. When we use this method on multiple SLB devices hosting the
same application with the same Virtual IP address, the routing domain
will have multiple paths to the same VIP address. The next hop on
these host routes will be the SLB devices IP address. As the user
request enters the routing domain, it is sent to the SLB device
closest to the user based on the routing metrics.
Naseh Expires – July 2007 [Page 7]
Methodologies for Scaling SLB Environments January 2007
7.
Scaling Beyond Server Capacity
In the preceding sections; it is discussed how to scale SLB devices
beyond their capacity limits. In this section, it will be discussed
how to scale the server’s capacity within an SLB device. Let’s say we
have an SLB device with 10 servers configured on it for a particular
resource-intensive web-based application. Each server is capable of
serving only 100 user sessions concurrently. So at any given time,
the SLB environment can service 1000 users - beyond that, if any new
user is load balanced to a server, the server becomes unstable.
There are several approaches to resolve this server capacity issue.
These solutions range from increasing the server CPU/memory resources
to using multiple features on the SLB devices to form a scalable
environment. The complex but comprehensive solutions rely on the max
connections feature on the real server or virtual server level. The
max connections configuration within a real server informs the SLB
device that the server can only handle the configured number of
sessions concurrently. This protects the real servers from excessive
user requests that may in turn cause them to become unstable. The
idea is not to disrupt the existing users’ sessions.
So, the first step is to detect the max connections on the servers
and the second step is to take appropriate action. If the SLB device
detects that all the servers in the server farm of a particular
application have reached their maximum capacity, any of the following
measures can be taken:
. Have a server that will serve a turn-away page or a sorry
message to the clients. The user will be informed to return to
the site at a later time.
. Send an HTTP 302 redirect to the new clients and send them to
another SLB device hosting the same application.
. Deploy the SLB devices in conjunction with a smart DNS appliance
like DNS appliance. When max connections are reached, the SLB
device will inform the DNS appliance to service the user DNS
query with a VIP from another SLB device.
. Send the user request to another SLB device, but source
translate the packet. This ensures that the packet from the
second SLB device will traverse the first SLB device. In other
words, the session path will be symmetric.
The overall solution can use a combination of approaches to come up
with an environment that best services the hosted application.
The document introduced the concepts and design methodologies of
scaling load-balancing services within a single data center. The memo
covered how load-balanced applications can be scaled using DNS or IP,
and how they are scaled when server capacity within a load balancer
is maximized.
Naseh Expires – July 2007 [Page 8]
Methodologies for Scaling SLB Environments January 2007
8.
IANA Considerations
This document requests no action by IANA.
9.
Security Considerations
The scenarios and design methods identified in this document should
only be implemented in accordance with the network security policies.
The SLB environment identified MUST be behind a firewall perimeter.
Components of effective information security architecture, including
network infrastructure and server infrastructure security, physical
security, security awareness, incident monitoring and response,
audit, and security improvement processes are assumed to be in place
and active.
10.
Acknowledgments
The author gratefully acknowledges the contributions of Haroon Khan
of Cisco Systems, Inc.
11.
Author's Addresses
Zeeshan Naseh
Cisco Systems
San Jose, California
znaseh@cisco.com
12.
Copyright Notice
Copyright (C) The Internet Society (2007). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
13.
Disclaimer
This document and the information contained herein are provided on an
'AS IS' basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
Naseh Expires – July 2007 [Page 9]
Methodologies for Scaling SLB Environments January 2007
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.'
14.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the ISOC's procedures with respect to rights in ISOC Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Naseh Expires – July 2007 [Page 10]