Load balancers are a cornerstone of any big computing application. By spraying traffic across lots of servers, they let companies turn many unreliable machines into one reliable service. But that service has a lot of moving parts, and sometimes they break. If it keeps happening, it may signal that a new class of networking device is needed for the demands of cloud computing.
According to Amazon’s Web Services Developer Connection, a load balancer was deployed in its S3 storage service on June 20, and removed two days later. During that time, it was corrupting bytes of data sent to the S3 storage service when under load.
This isn’t the first time load balancers have been implicated in an outage at Amazon. At O’Reilly’s Velocity conference, conference co-chair Jesse Robbins talked about a “redundant array of inexpensive data centers” as the basis for tomorrow’s computing platforms. Load balancing is what makes this possible.
Storing data in a server is a tried and tested process. We’ve had decades to optimize the way we store and retrieve data, with standards like iSCSI and IDE proven out worldwide. And RAID is pretty reliable these days.
But the cloud’s still figuring out storage. There are competing models: S3, SimpleDB, BigTable and so on. And with more and more applications relying on S3 for their data, outages are bound to be visible and public.
The cloud model puts increased pressure on networking and server equipment, and on vendors to make their components reliable. Load balancers built for enterprise data centers may not be suited for the cloud, just as domestic power generators wouldn’t work for utility companies. This may be one reason Google is reputed to be building its own switches.
Expect clouds to require significantly different kinds of networking equipment. It’s either an opportunity for networking vendors like Cisco and Juniper, or a huge threat to them.

mysql-proxy defaults to round-robin load balancing. There are fancy tricks around to get mysql-proxy to balance connections based on how many idle connections there are in a proxy-based connection pool.
But there is no code that I found that would simply load balance based on “always go to one server, go to another server only when the first server is down.”
Well, I spent way too long figuring this out today, again running into the problem where the manual hasn’t been updated. I have indeed made a Forge snippet of this code, but it does not hurt to post it here.
This was in fact taken from http://jan.kneschke.de/projects/mysql/mysql-proxy-learns-r-w-splitting, which I referenced above as having the fancy trick above — but there is one very important difference — the internal structure proxy.servers has been changed to proxy.backends. Sadly, the manual page for the Internal Structures has not been updated to reflect this.
At least now there’s a comment on the documentation page that states that.
function connect_server()
for i = 1, #proxy.backends do
local s = proxy.backends[i]
if s.state ~= proxy.BACKEND_STATE_DOWN then
proxy.connection.backend_ndx = i
-- print ("connecting to " .. i)
return
end
end
end
function read_query(packet)
for i = 1, #proxy.backends do
local s = proxy.backends[i]
if s.state ~= proxy.BACKEND_STATE_DOWN then
proxy.connection.backend_ndx = i
-- print ("connecting to " .. i)
return
end
end
end
opensource: del.icio.us tag/opensource
Apache
load
balancer
opensource
url/dbe818518a6c7781c1b3fa88d5e34e35
opensource: del.icio.us tag/opensource
load
linux
network
balancer
proxy
scalability
opensource
ha
loadbalancing