Live data from Hacker News

Google Open Source Load Balancer in Go

github.com

41–50 of 75 posts

Re: Google Open Source Load Balancer in Go

#41

LVS load-balancing is amazing. You can use a tiny instance to load balance huge amounts of traffic since the instance itself doesn't need to process and pass the traffic. the part that makes it difficult to implement is that the hosts have to be on the same network. I didn't dive too much into the code but it looks like you also assign an additional interface to use as a VIP. I believe you'll need to be in your own n…

Would it be possible to set this up with Digital Oceans Floating IP[1] and LVS? I know they use HA-Proxy[2,3] as a standard setup here. [1]: https://www.digitalocean.com/community/tutorials/how-to-use-... [2]: https://www.digitalocean.com/community/tutorials/how-to-crea... [3]: https://www.digitalocean.com/community/tutorials/how-to-set-... The reason I ask, I worked with one hosting provider who leveraged LVS for we…

The third link that you posted is for keepalived. keepalived uses LVS as the actual load balancer (which is what seesaw uses as well). So as long as you can setup seesaw to run a few scripts to inform DisitalOcean which droplet currently has the ip, then it should work fine. There is an example for keepalived in the link that you posted.

Re: Google Open Source Load Balancer in Go

#42

Official announcement: http://google-opensource.blogspot.com/2016/01/seesaw-scalabl... . Note that this is a network-level load balancer that is tightly coupled with LVS, not a Layer 7 load balancer like HAProxy.

HAproxy can do Layer 4.

It can, but not (I believe) without actually reading the packets, using sockets to connect to the destination, and sending them onwards.

Seesaw is just a traffic cop. The kernel does all the work.

Re: Google Open Source Load Balancer in Go

#45
post #34

Earlier quoted context omitted.

Like near-copy pasta: https://codebeat.co/projects/github-com-google-seesaw/report... ?

Yes, horrible to duplicate standard boilerplate... Are you adding something to the discussion or are you getting a commission for selling that crappy code quality tool? EDIT: ok, apparently it is your product. Congratulations on successfully leaving a bad impression.

Guilty - my apologies. Except rather than sell it I'm simply looking for feedback. While the culture of using similar tools (reek, rubocop, flay, flog etc.) exists in the Ruby ecosystem and it's easier to calibrate algorithms and expectations Go is an uncharted territory. This is something I'm really after and again sincere apologies for my previous misdemeanor.

Re: Google Open Source Load Balancer in Go

#47
post #5

Earlier quoted context omitted.

It is a load balancer Google is using in production: http://techcrunch.com/2016/01/29/google-open-sources-its-see... Edit: Here's the official Google announcement: http://google-opensource.blogspot.com/2016/01/seesaw-scalabl...

It's not used in production, it's used in "corp" which is totally disjoint from production at Google.

At least 2 years ago it was already not always the case and things were moving towards unification rather than the other way around. Unless the general direction has drastically changed since I left I can only assume your statement is even less accurate now than it used to be.

Re: Google Open Source Load Balancer in Go

#48

Earlier quoted context omitted.

HAproxy can do Layer 4.

It can, but not (I believe) without actually reading the packets, using sockets to connect to the destination, and sending them onwards. Seesaw is just a traffic cop. The kernel does all the work.

I know HAproxy will aggressively use kernel features to reduce the amount of actual packet handling it does. For example, it does zero-copy forwarding using the splice system call. How this compares to what seesaw does is over my head, though. I just wanted to point out that HAproxy isn't strictly Layer 7.

Re: Google Open Source Load Balancer in Go

#49

Earlier quoted context omitted.

It's not used in production, it's used in "corp" which is totally disjoint from production at Google.

At least 2 years ago it was already not always the case and things were moving towards unification rather than the other way around. Unless the general direction has drastically changed since I left I can only assume your statement is even less accurate now than it used to be.

You're right but this particular piece of software is an artifact of the old way, not the new unified way.

Re: Google Open Source Load Balancer in Go

#50
post #34

Earlier quoted context omitted.

Yes, horrible to duplicate standard boilerplate... Are you adding something to the discussion or are you getting a commission for selling that crappy code quality tool? EDIT: ok, apparently it is your product. Congratulations on successfully leaving a bad impression.

Guilty - my apologies. Except rather than sell it I'm simply looking for feedback. While the culture of using similar tools (reek, rubocop, flay, flog etc.) exists in the Ruby ecosystem and it's easier to calibrate algorithms and expectations Go is an uncharted territory. This is something I'm really after and again sincere apologies for my previous misdemeanor.

Finding a popular project where your tool finds good issues and writing a blog post analyzing them might be a good way to get attention and feedback.

(the team making PVS-Studio (a static code analyzer for C/C++) does this)

Post reply on HN