Load Sharing Network Address Translation (LSNAT)
Introduction
The explosive growth of intranets, extranets and the
Internet has caused both the amount and value of network
traffic to increase dramatically. Due to higher demands on
servers, network bottlenecks are appearing. Overloaded servers
are generating and sending corrupted data, or failing
altogether, leaving customers frustrated. Enterprise managers
and service providers are expected to solve these problems and
deliver data reliably and quickly. The ones who gain
performance and reliability while keeping costs down are the
ones who gain a competitive edge in the marketplace.
The first step taken to try to alleviate the problem was to
concentrate all servers into groups, or server farms. This
allowed the system administrator to put the servers onto
higher-speed network connections and take spurious traffic off
lower-speed client segments. Since then, server farms have
grown larger and larger, and a new phenomenon has occurred;
applications are being stored on server farms, then downloaded
when needed to either fat or thin clients. This puts a
tremendous amount of load onto the servers—some highly
desirable application servers are becoming swamped while other
servers sit by with minimal load. If one of these servers goes
down under a high demand, an entire company can be brought to
its knees.
This has lead to a demand for built-in features to increase
the performance, reliability and security of the network.
These features spread the load over the servers, eliminating
the need for dedicated servers per function, and they also
check the servers to ensure they are functioning. Today these
features are known collectively as Load Sharing Network
Address Translation (LSNAT).
How LSNAT Works
LSNAT is defined in RFC 2391. Simply described, LSNAT
allows an IP address and port number to become a Virtual IP
address and port number (VIP) mapped to many devices. When the
VIP is seen as a destination address and destination port
number by the LSNAT device, the device traps the packet and
translates it into a real IP address and port combination
using a selected algorithm such as Round Robin,Weighted Round
Robin, Least Load or Fastest Response. This allows the device
to choose from a group of server addresses and replace the VIP
with the selected IP address and port number. The device makes
the appropriate changes to packet and header checksums before
passing the packet along. On the return path, the device sees
the source and destination pair with the real IP address and
port number and knows that it needs to replace this source
address and source port number with the VIP and appropriate
checksum recalculations before sending the packet along.
The simplicity of the description above belies the
complexity of the feature. The network can see a tremendous
increase in performance by optimizing traffic to different
groups of servers.
Reliability is increased by allowing for scheduled
maintenance, and also by automatically taking defective
servers out of a group when they are detected. Security is
improved since only the VIP is known, not the specific server
addresses, ensuring that only the appropriate traffic goes to
the servers.
Connecting to a Server Before LSNAT
Prior to the implementation of LSNAT, a client contacted a
server directly. In Figure 1, Client A at address
196.86.100.12 has initiated an HTTP session with Server X at
194.86.13.2 in response to a TV commercial announcing $100 to
the first 500 users who log on to the site. Unfortunately for
Client A and the owners of Server X, thousands of users have
seen the commercial and are trying log on at once, bringing
Server X down. This frustrates users and leaves the owners of
Server X and its web site in a difficult position.
LSNAT can prevent situations like this one and frees server
administrators from these concerns. With LSNAT, networks have
100% uptime, even if a server goes down inadvertently or for
maintenance.
Using LSNAT with Enterasys's Xpedition The Xpedition
8600,
8000, 2100 and 2000
have LSNAT features embedded in version 3.0 of their firmware.
In Figure 2, the Xpedition is running LSNAT. With a Xpedition
running LSNAT, when Client A initiates a session with the same
IP address (194.86.13.2), the traffic goes to the router for
the IP address, in this case the Xpedition. The Xpedition
recognizes that this address is a VIP it needs to translate.
It looks at the pool of IP addresses associated with the VIP
and, using a pre-selected algorithm, assigns the session to
one of the four servers: W, X,Y or Z. On return paths, the
SmartSwitch Router knows that the IP addresses associated with
server and Client A need to be changed so that Client A sees
the VIP, not the server's real IP address. Translation from
and to the VIP and selected server IP are handled through
hardware for the duration of the flow, allowing for true
wire-speed load balancing. So as thousands of clients try to
initiate sessions with VIP 194.86.13.2 as described in our
previous scenario, the Xpedition load balances them and
translates them to the real server IP addresses. The servers
are not overwhelmed, all clients get access to the servers,
and contest winners and the server owners are successful.
Advanced LSNAT Features of the Xpedition
The previous scenario is a simplified version of what actually
occurs. A more elaborate example can illustrate the full power
of the Xpedition. In Figure 3, the Xpedition is configured to
support two VIPs. Traffic sent to each VIP is routed to
different server groups based on the port numbers. There is no
software constraint on the number of VIPs the Xpedition can
support. The HTTP traffic for VIP 1 is assigned to the group
of servers that includes Server "W" and Server
"X" while HTTP traffic for VIP 2 is assigned to the
group of servers that includes Server "Y" and Server
"Z." The FTP traffic for VIP 1 is assigned to the
group of servers that includes Server "W" and Server
"Z," and VIP 2 is assigned to the group of servers
that includes Server "X" and Server "Y."
The Xpedition discards all other traffic destined for VIPs 1
or 2.
The Xpedition configuration is relatively simple. For the
configuration described in Figure 3, the network administrator
uses the following commands in the configuration mode on the
Xpedition:
With these commands, HTTP traffic using port 80 with
destination IP addresses matching our VIP addresses are load
balanced between the servers in the associated group using a
Round Robin algorithm. The FTP traffic is similarly routed and
load balanced using a Least Loaded algorithm—the serv-er
with the least number of active flows is selected. No group
was created for port 20 because using FTP port 21 creates an
implicit binding to port 20 as well. Traffic for both ports 21
and 20 will be translated for the VIPs. If the servers use a
different port than port 21 for FTP control, then the
Xpedition is told through the "load-balance set
ftp-control-port
" command. If a group is set up with a port other than 21
without using the "set ftp-con-trol- port" command
and FTP traffic is passed through the Xpedition, then the
traffic will have incorrect data.
|
load-balance create group-name HTTP_VIP1
virtual-ip
194.86.13.2 virtual-port 80
load-balance create group-name FTP_VIP1
virtual-ip
194.86.13.2 virtual-port 21
load-balance create group-name HTTP_VIP2
virtual-ip
194.86.13.3 virtual-port 80
load-balance create group-name FTP _VIP2
virtual-ip
194.86.13.3 virtual-port 21
load-balance add host-to-group
10.10.125.1-10.10.125.2
group-name HTTP_VIP1 port 80
load-balance add host-to-group 10.10.125.1
group-name FTP_
VIP1 port 21
load-balance add host-to-group 10.10.125.4
group-name FTP_
VIP1 port 21
load-balance add host-to-group
10.10.125.3-10.10.125.4
group-name HTTP_VIP2 port 80
load-balance add host-to-group
10.10.125.2-10.10.125.3 group-
name FTP_ VIP2 port 21
load-balance set policy-for-group HTTP_VIP1
policy round-robin
load-balance set policy-for-group HTTP_VIP2
policy round-robin
load-balance set policy-for-group FTP_VIP1
policy least-loaded
load-balance set policy-for-group FTP_VIP2
policy least-loaded
|
|
Since we only created groups for HTTP and FTP traffic destined
for VIP 1 and VIP 2, all other traffic with different port
numbers destined for VIP1 and VIP2 is dropped by the
Xpedition. This protects servers from unauthorized users who
attack them using other ports. Since the addresses of the real
servers are known only to the SmartSwitch Router, there is
another level of protection. This way, if the network
administrator needs to access to the servers directly from
outside the network, there is no need to put them into the
routing table and make them visible to others. The
administrator can use a bypass command allowing specific IP
source addresses to have access to the servers. As an example,
this command,
"load-balance allow access-to-servers client-ip
194.86.13.10 group-name HTTP_VIP1,"
allows the client with address 194.86.13.10 to have access to
the servers in HTTP_VIP1. But that client would not be able to
use VIP 1 to access the servers.
Session Persistence
It is possible for a client, in the middle of a session, to
want to visit another site and then come back to the same
session picking up where it left off without starting over
again on a new server. This is known as Session Persistence.
The LSNAT load-balance routine keeps a listing of the
associations or "bindings" between client and real
server for each group. There is a timer that counts down for
each binding after the line card has removed it from its
memory for inactivity. This timer can be set per group from
one minute to two days in length. This allows the load balance
to remember bindings for servers where it is critical to
return to the same server, such as a shopping cart site, for
an extended amount of time, and drop off bindings on other
sites where it is less critical to return to the same server.
If a client were to "leave" a session, then come
back, the Xpedition would remember the client and VIP pair and
reassign the client to the same server.This feature makes for
a more reliable web experience for the clients of a web site.
Server Aliveness Checking
This all sounds good, but what happens when a server goes
down for any reason? How does the Xpedition know not to
continue sending traffic to the server that is down? The
answer is the aliveness-checking feature of the Xpedition. The
Xpedition will send a ping to the server of each defined group
every five seconds. If it does not see a response after five
consecutive pings, the Xpedition takes the server off the list
for the associated group. The Xpedition continues to send
pings to the server; as soon as the server is back on line and
responds to the ping, the Xpedition will put the server back
on the available list. This aliveness checking further
maintains the overall reliability of the network.
Load Balancing Maintenance
The Xpedition also keeps track of load-balancing statistics on
source mappings and loading. This is helpful to determine if a
server should come down for maintenance, or if another server
should be added to a group. When a server needs to be taken
down for maintenance, the network administrator just enters a
command on the SmartSwitch Router and no more sessions are
initiated. By viewing the status of the servers, the network
administrator can see when all the sessions have ended, and
can safely take down the server, knowing that new sessions are
being balanced on the remaining servers. When the maintenance
is complete, another simple command puts the server back on
line and into the queue again, further increasing the
reliability of the network.
Xpedition Performance, Reliability and Security
Load balancing using the LSNAT standard is yet another feature
that takes advantage of the unique, high-performance
switch/router ASICs powering the Xpedition. LSNAT improves
network performance by leveling traffic over many systems. It
improves the reliability of the network by taking away the
single point of failure, a single server, and mapping requests
to one of multiple servers.
Using LSNAT in conjunction with SmartTrunking removes the
performance bottleneck and reliability concerns of one
physical link to a server by bundling multiple links, with
fail over if a link goes down. Utilizing the IP-Policy and QoS
features of the Xpedition with the LSNAT feature further
improves the performance and security of the net-work. The
servers are easily removed and replaced in the queue making
maintenance a transparent activity, eliminating downtime for
the site. When tied with the Virtual Redundant Router Protocol
(VRRP) found in the Xpedition, the network becomes even more
reliable and secure.
Conclusion
In summary, the load-balancing feature, LSNAT, found in the
Xpedition helps to dramatically improve the performance,
reliability and security of the network. Users also benefit
from the industry-leading, wire-speed Layer 3 switching of the
Xpedition. This feature is ideal for enterprise accounts for
their web servers, their application servers or their database
servers. Server load balancing is also suited to service
providers with news servers or the web servers.
LSNAT support is standard on all Xpeditions: 8600, 8000,
2100 and 2000.
|
|
E-Mail
Related