After some initial quick 'n dirty experiments with a NodeBalancer, I noted a few items:

1. I can't seem to enter an IPv6 node address on the manager. Private IPv4 addresses work, and a public IPv4 address gives an error that aside from private addresses, seems to indicate I should be able to use IPv6, but attempts with an IPv6 say I need to use address:port. Could the colons in the IPv6 address be confusing things or is there special syntax to use?
2. If I leave state checking off, it seems to always say all the back-end nodes are down, which I found confusing. I had guessed that without explicit checking it would determine a node up/down based on passing a successful connection to it, but I guess not. If that status is strictly from the health check, then perhaps that column should say something different (like "I don't know") or be left blank if health checking is disabled.
3. There seems to be a noticeable latency (at least in terms of some number of seconds) between making a configuration change (say to the stickiness parameter, or adding a node) and it taking effect. It would be great if there was some sort of status in the manager to know when the cluster was up to date with the manager/API configuration.

and came up with a few questions:

1. When using an HTTP protocol configuration, does the balancer pass in any headers with original client address information? (I haven't tried dumping a request yet).
2. Is it possible to identify (aside from watching connection logs) the private address(es) for the cluster? I guess filtering the back-end private interfaces is sort of dumb due to the nodebalancer itself being public, though that leads to my last item...
3. More a feature than a question, and probably a kettle of worms, but any chance at any simple firewalling on the balancer? There are some private services I might like to balance, or something I want to test balancing on but not open up to the world, and even having a simple hardcoded list of allowable addresses for testing purposes would be helpful.

-- David

I haven't tried it myself, but I believe the standard syntax for an IPv6 address with port is:

[::1]:80

I've not tried this service but load balancers usually set a X-Forwarded-For header when proxying requests rather than doing port forwarding.

X-Forwarded-For can look a little strange as if there are multiple proxys they all get stuck in there and end up looking like "X-Forwarded-For: client, proxy-something, proxy-somethingelse, loadbalencer".

Also before jumping in and trusting the values bear in mind that you can easily spoof the initial header value.

-- Damian

Yes, it supports X-Forwarded-For (Both IPv4 and IPv6)

Click to see a large screenshot:


Some feature request:

1. Show the current connection count in the Web GUI
2. The ability to specify "Host:" header in the healthy checker
3. A static private IP address for each load balancer, therefore we can make sure the X-Forwarded-For header is from the balancer, not a forged request.
4. A graph of network status
5. Support HTTPS Load Balancing

_________________
Blog: http://en.jnlin.org/

Oops, should have mentioned - that was the one form (beyond plain address:port) that I did try, with the same error.

-- David

Being able to balance HTTPS would be useful to me as well, since one of my more likely applications to spread horizontally is an internal tool that is accessible solely over HTTPS.

Though I'd also want to know (3) in order to take advantage of (5), since presumably the internal traffic would be reduced to HTTP, and I'd want to lock it down strictly to the node balancing cluster.

-- David

It should be doable in "dumb" mode, with TCP load balancing of port 443. Being able to intelligently handle the traffic would amount to a MITM "attack," with the load balancer needing to present a valid and signed certificate for the request. Ideally, it would then open a HTTPS session to the backend and check its certificate for validity before bridging the traffic.

This is doable, but a little creepy. Definitely would require a lot more configuration, interaction, and integration testing.

_________________

/* TODO: need to add signature to posts */

Yeah, that's a good point. Of course, with TCP balancing you lose some of the HTTP-specific benefits like the forwarded host info, and cookie based stickiness.

But yes, I was more thinking of your second point, where you configure your certificate/key in the balancer, and then it becomes the termination of the HTTPS session, but then regular HTTP to the back-ends. I suppose you could have a second HTTPS hop, but I'm not sure of the point (providing I can filter by balancer private address(es)), given that both the balancer and back-end nodes are in the same DC, communicate over the internal network, and both balancer and back-ends are under the same administrative control.


Having the balancer be your SSL endpoint doesn't seem especially creepy. Configuration would basically be a new connection type and ability to upload a certificate chain and private key. I expect supporting SSL connections themselves ought not to be much of a hurdle, though there's an argument to be made for where best to have the SSL overhead (as this will place more CPU burden on the balancer).

After all, the balancer is a resource - clearly modeled similarly to Linodes themselves - on your account. I'm assuming that any certificate/key management would be secure in the balancer cluster, but in practical terms can't imagine it would be any less secure than local Linode standard filesystems.

-- David

define "dumb". there are a few things you can do to put some intelligence into https load balancing (note, I'm speaking from experience with internal stuff at my job, not linode or nodebalancer). the load balancer can do health checks of pages by initiating its own https client session to hit a health check page. you can also do stickiness via source IP.

Actually, this is very common in the load balancer world. In this configuration, quite often, the traffic from the LB to the node isn't even encrypted, which can offer a substantial performance gain from both the reduction in encryption and connection caching behind the LB. Granted that's in a controlled data center, and perhaps you might not like to do that with a cloud provider; if it's valuable data encrypt it at all times, both it in-transit and at rest.

The alternative you mention, using a raw TCP connection, is not only viable if you terminate the SSL at the node (HTTPS straight through, no intelligence at the LB), but it's sometimes necessary, albeit in very specific applications.