Hi Daniel, On Tue, Sep 07, 2010 at 12:30:18PM +0200, Daniel Storjordet wrote: > Hi! > > Current implementation of HAProxy is working great for us. The other day > we had a server failure without us or our customers' noticing. > > Today our HAProxy solution is hosted on the same location as our content > servers. Unfortunately we have experienced problems with our hosting > companies. Changing the IP for all the domain names for the web pages > hosted on our servers every time we need to switch to a new host is too > much work. > > To solve this we wish to relocate the HAProxy servers to a different > location than the content servers. The new host is placed at the > backbone of our countrys internet and the ips can be moved to another > host if needed. With this change we will be able to host our content > servers and backup servers at any location and can move them around > without updating all the domain names every time. > > However we are concerned about the performance penalty of hosting the > HAProxy servers at an different location that the content servers. Are > there any statistics on what kind of performance penalty we will > receive, and any other unforeseen effects this might have?
You must consider that you'll add a round-trip between your haproxy and your servers. If they are too far away, the users will notice the added time. Also, your internet access point will see the traffic in the two directions. This means that you will see in each direction the sum of what you currently have in both directions. I don't know if this can apply to your case, but haproxy supports a redirect-based type of servers. The principle is that if you specify "redir XXXX" on a "server" line, then for each GET or HEAD request, instead of connecting to the server, it will return a 302 with XXX as the prefix, so that the browser retries on the other server. Methods that are not GET or HEAD are still forwarded as usual. This is well suited for downloading large objects : the added RTT between the client and the server is then negligeable, and the client does not have any reason to stay on that server. It should be avoided for session logins for instance, because once the client targets the real server, it will not be redispatched if the server fails. Regards, Willy
