Close

See How Your Peers Are Moving Forward in the Cloud

New research from CDW can help you build on your success and take the next step.

Mar 07 2012
Networking

5 Tips for Optimizing Load Balancers

Load balancers operate best when they’re configured properly. Here’s advice to keep your website humming.

Load balancing is a basic function for managing a website, distributing traffic among multiple web servers and adding needed fault tolerance. But load balancers don't run well without being configured properly. Here are five tips that will keep your website humming.

Tip 1: Check out clock synchronization.

Network managers can't count on different server clocks for writing data to the database or presenting the data to a user. The reality is that most server clocks skew by as much as several minutes a day, which can build up over time until applications no longer work. The best way to avoid this is to use the database server's clock for all read and write actions, or to synchronize network servers by using the Network Time Protocol. Most recent operating systems support using a public NTP server to confirm that the time on the server clock is set regularly to one of the national atomic clocks. That ensures a steady time across various actions, no matter how many servers are in the pool. IT managers can set up one server as a local NTP server, have it poll one of the public NTP servers, and then configure all other servers to synchronize with that server.

Tip 2: Determine the application session type.

If an application makes calls to other servers, it's often better to use persistent sessions. This will keep the user session alive no matter which server makes the request. Many load balancers have several types of persistent sessions, tailored for database calls, shopping carts or other types of applications. When a persistent connection is used, even if the user session is moved from one server in the pool to another, the back-end connection to the database is preserved. To do this, the load balancer maintains session information for all users. Decide how long to keep user sessions alive — for instance, if a user leaves a browser window open, the session information will be held indefinitely unless the window is configured to drop persistent sessions after a period of inactivity. Too many persistent sessions can use up memory resources on the load balancer, so it's best to set some kind of maximum session length.

Tip 3: Prepare for emergencies.

Configure e-mail and SNMP trap alerts for major incidents when servers are unavailable. This helps identify problems in the system and offers information when the environment is degraded. Look at the cost and complexity issues of clustering or other high-availability solutions for databases and other ancillary systems to ensure that hardware problems or OS crashes don't take the system completely offline. IT managers can script tests for each server in a load-balancer pool to ensure that if a server or a service stops responding, the load on that server will be transferred to another server in the pool.

Tip 4: Measure all network activity.

Graph all interfaces, the bandwidth used by each service, the hits on each service and anything else that can possibly be graphed. Capturing this data offers a historical perspective on network traffic, which enables IT managers to identify trends and proactively add capacity when necessary to keep from overloading the system. It also aids in diagnosing problems when they occur.

Tip 5: Set up access lists.

Use access lists to restrict traffic going through the load balancer. IT managers can also utilize a directory or other user authentication system to limit access, whether to the entire website or specific areas. If the organization uses a Windows-based web server, use Active Directory for this. For Linux, use a commercial product or simply implement the Lightweight Directory Access Protocol for storing user names and other data. If the IT staff anticipates thousands of users, use a dedicated database or directory server, rather than a separate organizational unit on the production directory server.