Home | Articles | About | Contact | Forum |
Thursday, August 21, 2014



Lunarpages.com Web Hosting

Mailing List

E-mail:
By Joining the mailing list you will be notified of site updates.


Show Your Support For
This Site By Donating:











Audience: Self Learners - System Admins
Last Updated: 6/24/2011 6:08:51 PM
**All times are EST**



Active-Passive Load Balancing Configurations

By Erik Rodriguez

Tags: redundant load balancing, load balancer configuration, active-passive load balancing, fail-over cluster, failover clustering

This article provides information on load balancing using an active-passive configuration. Active-passive clusters are commonly used for mission critical applications that need high availablity. Another common load balancing configuration is active-active.

Overview

Active-passive (I will refer to as AP throughout this article) is commonly used to achieve uptime. AP configurations can be used for websites, databases, mail servers, and more. Another common form of load balancing is called active-active. Active-active is used to achieve performance. Load balancing in a form of clustering. Servers in a cluster are referred to as nodes.


Active-Passive Configurations

Active-Passive configurations usually exist with business operations where uptime is critical. AP configurations can be configured clusters with many different roles. This includes database servers, mail server, and more.
  • Round Robin (using DNS)
  • Hardware-based Device
  • Software-based Appliance
Round Robin is the cheap and simple way to configuration to run an AA configuration. This is done by simply adding 2 or more A records for the host which needs to run as AA. The diagram below shows a cluster of 4 servers running an AA configuration with round-robin AA:



While this method does work, it can have several problems. Let us take a look at a sample of A records:
root@amber [~]# host cluster.skullbox.net
cluster.skullbox.net has address 172.17.55.100
cluster.skullbox.net has address 172.17.55.101
cluster.skullbox.net has address 172.17.55.102
cluster.skullbox.net has address 172.17.55.103
Shown above you can see 4 A records for a web cluster. In this configuration, the A records will be returned to the requester in the order you see them. Meaning, visitor 1 will resolve cluster.skullbox.net as 172.17.55.100. Vistor 2, will resolve it as 172.17.55.101, so on and so fourth. While this seems good enough, the following events can occur:
  • DNS caching
  • Cluster node failure
  • Session overload


DNS caching can occur on a local machine or from an ISP. If vistor 1 and vistor 2 have the same ISP, that ISP may cache the record once vistior 1 performs a lookup. This will result in both visitor 1 and visitor 2 requesting data from the same server. Therfore, cached DNS records are defeating the round robin operation. Excessive caching may cause 1 or more servers to become overloaded. I have seen this happen in production environments before. Server 1 and 2 had heavy loads while servers 3 and 4 had almost none. Depending on the configuration of the actual web server software, excessive traffice can cause session overloads. When this happens visitors may receive a number of different error messages. Most commonly, the server will be too busy to handle the request and simply time out. A 404 error will be displayed and the visitor will simply think the site is down. While in fact, the site is not down, but the server they are trying to request data from is overloaded. If they were to manually using another IP address from the cluster, the site would display fine.

Node failures are another problem when using round robin. Round robin has no way of knowing if nodes in the cluster are online or if they even exist. There is no intelligent hardware or software at work and because of this, visitors will receive a 404 error if an A record of a failed node is returned to them. From an administrative side, site operators must either make sure all servers are running 24x7 or add the IP address of a failed node to active one. If you have bad hardware, this can become a cat and mouse game and it always seems to happen at the worst time.

Hardware-based devices are more common, but they come with a price. These devices can be tricky to configure, but allow more flexibility for active-active configurations. Unlike round robin, you do not need multiple A records. A hardware load balancer is usually configured with 1 IP address. The same device also knows the IP addresses of every server in a the cluster. It makes intelligent decisions based on the existing traffic and decides which server in the cluster to route the next request to. This more effecient and effective than round robin. See the example below:

active-passive load balancing


The active-active configuration above is commonly done with hardware devices. The big players in this market include F5, Foundry, Radware, and others. Cisco and Juniper do have products for load balancing although they never launched as well as hoped. The Juniper DX line has a very short life before being discontined. Cisco's Global Site Selector and Load Director did not sell as expected either. Other vendors such as Zeus offer software that can be loaded on a generic server therefore making it a "software-based appliance." These and other solutions are primary Linux-based and range from free to outragously expensive. Barracuda, a company that originally produced spam filtering appliances, also provides load balancing, SSL VPN, and other network solutions. Some vendors are even offering virtual appliances for use on platforms like VMware, Xen, and others.

Contact Us

If you found this information useful, click the +1 button



Your E-mail:


Subject:


Type verification image:
verification image, type it in the box

Message:


NOTE: this form DOES NOT e-mail this article, it sends feedback to the author.


TCP vs. UDP
Extreme Networks: Downloading new software image
Juniper SRX save config to USB drive
Juniper SRX logout sessions
Extreme Networks Syslog Configuration
Command line drive mapping
Neoscale vs. Decru
Data Security vs. Data Protection
Juniper SRX Cluster Configuration
HOWTO - Create VLAN on Extreme Switch
Using a Non-local Colocation Facility
Linux Server Administration
IT Chop Shops
Flow Viewers: SFLOW, NetFLOW, and JFLOW
Exchange 2007 Back Pressure
IPtables open port for specific IP
Politics in IT Departments
HOWTO - Block Dropbox
Cisco IOS Cheat Sheet
Subnet Cheat Sheet
Design a DMZ Network
How DNS works
Firewall Configuration
Juniper SSG Firewalls
Server Management
Configuring VLANs
Runlevels in Linux
Server Clustering
SONET Networks
The Red Hat Network
Server Colocation
Complicated Linux Servers
Dark Fiber
Data Center Network Design
Firewall Types
Colocation Bandwidth








Copyright © 2002-2014 Skullbox.Net All Rights Reserved.
A division of Orlando Tech Works, LLC
By using this site you agree to its Terms and Conditions.
Contact Erik Rodriguez