Layer 7 Load Balancing
One of the great things about late-model load balancing hardware is the ability to balance on data from the application layer (layer 7 of the OSI model). Traditional load balancers balance traffic based on the virtual IP that was assigned to a cluster. Requests sent to the virtual IP are routed to a destination based on the algorithm used on the nodes in that cluster. With layer 7 load balancing, specific information within the request itself can be used to balance the request to the appropriate destination.
INetU used this technology primarily on our Cisco ACE 4710 load balancers. This dedicated network appliance is capable of various layer 7 functions, ranging from simple keyword or response code health probes to full-fledged layer 7 load balancing. A common example of request-based decision making is static content hosting. Images, style sheets, scripts and so on may be served up by a content delivery network that is standalone from an application platform. To implement this, we can simply create a classification on the load balancers as follows:
class-map type http loadbalance match-any PICS
3 match http url /*.jpg
4 match http url /*.png
When the above is assigned to a policy map in a config, any traffic that matches the pattern will divert it to a serverfarm unique to that traffic. Any traffic not matching will be routed along the standard path to one of the many application server nodes it resolves to based on the conventional distribution algorithm.
Read the full post »
Thank you to all who attended the ITX Data Security Summit on July 13th, 2011! Over the next couple of weeks I will attempt to summarize some of the highlights 
Scott Walter, Director of Client Services from INetU Managed Hosting started the day off with a bang! Scotts exemplified the passion he has for security as he spoke on Confidentiality, Integrity, and Availability.
Scott prefaced his presentation with a fitting quote from Donna Scott, the VP & Research Director at Gartner. She states, “80% of unplanned downtime is caused by people and process issues, including poor change management practices, while the remainder by technology failures and disasters.” Scott recommends avoiding poor change management by applying security in layers. He recommends investing your money in this order:
Read the full post »
Session management is relatively easy for a simple website handled by a single web server. Session information is typically stored in memory or disk and all is well. What about when you have a large website that’s served by a number of web servers? You could store sessions in memory or on disk in the same manner, but that creates a problem. The session information will not be accessible by the other web servers. Since the HTTP protocol is stateless, it is your responsibility to maintain sessions as HTTP requests are spread among the various web servers.
What about “sticky sessions”? Most hardware load balancers support an option called sticky sessions. Sticky sessions can be enabled to keep all HTTP requests from a given user on the same web server. This avoids some of the session management problems, but it introduces a potentially more serious problems. To name a few:
- The distribution of load between web servers can become uneven.
- Scheduled maintenance is more difficult since you cannot simply remove a web server from the load balancer without impacting users.
- High availability is impacted since users will lose their session information if the web server they are “stuck” to crashes. When they are directed to another web server, they might have lost the shopping cart they spend an hour filling. Even worse, they might not go through the effort to refill it!
How are these problems avoided?
Read the full post »
High availability is a necessity for any high performing web application today. Consumers want access to their information anytime, and not having high availability means your potential clients will go somewhere else for their needs or experience frustration.
One of the first areas to consider for a high availability network is the firewall. After all, it is usually your first line of defense and when it doesn’t work, it leaves your business down. Many people think the way to fix this is to add a second firewall and call it a day, but there are many options within the configuration that can improve your client’s experience and site availability. Here are two important considerations:
Current Sessions
The first things to think about are your current sessions. Most firewalls can perform what is known as stateful failover. In a regular failover, all connections are dropped. Clients then need to re-establish their connections when the other firewall takes over. In a stateful failover, however, the active unit shares connection information with its peer, so in the event of a failover the other firewall already has the connection information. This may seem like a trivial issue, but it decides whether the client sees the failure or not.
Typically, entry level models do not have stateful failover, so this is a business decision that needs to be made before purchasing or upgrading firewalls. Also, you will need to make sure your application qualifies for stateful failover. HTTP is sometimes not enabled for stateful failovers by default, since they are typically not long lasting connections.
Redundant Links
Another item to think about is redundant links. Failover should only happen if the primary firewall is unresponsive, because the failover process takes some time to happen. Depending on firewall models, failover times can vary. I typically see Cisco ASA firewalls reliably failover in under 10 seconds with default settings, but that still leaves a window of downtime. Redundant links is a technology I setup for clients who want added HA by reducing the chance of failover. With redundant links, there are 2 cables used per interface rather than one.
So, picture a circumstance like this:
Read the full post »
Recently INetU Labs put Dell’s low cost workgroup SAN through its paces to see how it compares to the more robust (and costly) Equallogic and EMC offerings. The results are in, and it seems that correctly configured, the MD3000i is great product with plenty of bang for your buck.
Configuration
For testing we used an MD3000i populated with a mix of 146GB SAS and 500GB SATA drives. The SAN shipped with a single controller but a second was added to test failover. A word of warning here – Dell configures the duplex mode based on how the SAN is ordered; if you add a second controller later you’ll need to use the command line tool to enable it, a process that’s not stated as a clear requirement and takes a little digging on the Internet to find documentation for. That being said, once you find the docs you’ll have it set in no time. Our test unit was a major firmware revision behind, and bringing it up to date took a good twenty minutes. Minor revision updates probably won’t take as long, but this is something to keep in mind if you’re striving for multiple nines of availability.
Once the hardware was configured and updated, the software install was a snap. The management software is somewhat cumbersome but gets the job done, and configuring the LUNs is a simple process. We were testing multipath (MPIO), and Dell requires a specific version of the iSCSI initiator on Windows servers, so be careful here, too. Fortunately, the supplied driver CD made sure the right version was installed.
Benchmarking
Read the full post »
