71–80 of 122 posts
If you're curious to see NLB in action, here's a live demo: http://nlb-34dc3b430638dc3e.elb.us-west-2.amazonaws.com/ , it took about 5 minutes in the console to set it up and no changes on the targets/backends. Massive disclaimer: I work on NLB.
Earlier quoted context omitted.
There must be some magic happening somewhere, because otherwise outgoing packets would have the wrong source address.
You can use direct server return to manipulate the Ethernet frames so that packets don't travel back through the load balancer on the way to the parent switch.
Earlier quoted context omitted.
Chances are it's IPVS[1], maybe with some patching. Why would one reinvent the wheel when Linux already lets you do that. In that case it would be C since it's implemented in the Linux kernel. [1] https://en.wikipedia.org/wiki/IP_Virtual_Server
I should have read the blog instead of skimming before responding. This appears as Layer 4 load balancing, IPVS is more of Layer 3. So the person who was voted down by mentioning HAProxy might not be too far off. It could be implemented through HAProxy + TPROXY enabled in the kernel[1]. Then just make sure that default gateway configured on targets routes back to the load balancer or it is the load balancer. [1] http…
No, IPVS is L4 load balancing. L3 load balancing would be a routing protocol plus ECMP.
I love the concept, because not being able to handle TCP traffic was one shortcoming of the new ALB. But that pricing model: Bandwidth – 1 GB per LCU. New Connections – 800 per LCU. Active Connections – 100,000 per LCU. Would be nice to have it added to the simple monthly calculator: https://calculator.s3.amazonaws.com/index.html but I had to read the FAQ to find out what those were: https://aws.amazon.com/elasticloa…
A large number of services are not even featured on the calculator as an option (e.g. Lambda)
I was just wondering if this is something purely developed inside amazon or is it backed by an ADC like NetScaler or F5. does anyone know any detail ? I'm assuming that classic load balancer is some third-party or old framework and this is something amazon developed internally.
Seems to remarkably decrease latency (380ms -> 109ms). Running some tests: # ab -n 400 http://nlb-34dc3b430638dc3e.elb.us-west-2.amazonaws.com/ Time per request: 108.779 [ms] (mean, across all concurrent requests) # ab -n 400 381.933 # ab -n 400 380.632 # (for reference) ab -n 400 https://www.google.com/ 190.536 # (for reference) ab -n 400 https://sandbox-api.uber.com/health/ 107.680 If you're wiling to terminate SSL…
Time per request: 88.400 [ms] (mean, across all concurrent requests)
Time per request: 415.859 [ms] (mean, across all concurrent requests)
$ ab -n 400 https://www.google.com/
Time per request: 168.438 [ms] (mean, across all concurrent requests)How does failover across zones work? The blog post says there's one static ip per zone. I suppose www.mydomain should have multiple A records each pointing to an elastic ip in a zone. What happens when one zone entirely fails? Does it need a DNS change at this point? Or does the NLB have a different IP with which it can do BGP failover?
Still waiting on that fix, AWS.
No chance that I'll jump into another new load balancer product from Amazon any time soon. ALB has significant deficiencies that AWS don't warn you about, and you only find then at tens of thousands of RPS. Still waiting on that fix, AWS.
If you're curious to see NLB in action, here's a live demo: http://nlb-34dc3b430638dc3e.elb.us-west-2.amazonaws.com/ , it took about 5 minutes in the console to set it up and no changes on the targets/backends. Massive disclaimer: I work on NLB.
Demo page states "Your browser may keep a connection open for a few seconds and re-use it for a reloaded request. If it does, you'll get the same target", but when I attempted to abuse the power of F5, I was alternated between ice cream and bumblebee. If you are going to look at it, attempt time - ~04:50 UTC, remote address from 88.119.128.0/20 network