Load balancing and its different types
wisdomgeek.com
Load balancing and its different types
1–10 of 30 posts
Re: Load balancing and its different types
#2Decent summary but a little out-dated on DNS load balancing.
Major cloud services like AWS support health/status checks through DNS these days: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/re...
It's also trivial to get around the client caching issue, just set a low TTL. Perhaps in the olden days providers had stricter limits on the minimum TTL you can set, but these days you can set it practically as low as you want.
EDIT: as a few commenters have fairly pointed out, TTL can easily be ignored by poorly-behaved ISPs and clients, so I'll admit calling it "trivial" to get around is not exactly accurate.
Re: Load balancing and its different types
#3I like this intro!
Good to see ‘random’ redefined as pick random two then assign to one with least connections, which works strictly better than either random or least connections alone.
Misses a couple categories that may be relevant: least hops or best transit type network-mapped balancing to get to the ideal set of servers globally, as well as a technique that not-so-simply connects the user to the geography with the fastest response for them right then.
While the article notes value of fewer connections for a stream, you can take a bit longer in setup for a stream to get it right, as you and the viewer will pay the price longer if you get it wrong.
All this gets much more complicated when balancing very large objects, as you have to consider content availability and cache bin packing among the servers you balance to.
Re: Load balancing and its different types
#4Decent summary but a little out-dated on DNS load balancing. Major cloud services like AWS support health/status checks through DNS these days: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/re... It's also trivial to get around the client caching issue, just set a low TTL. Perhaps in the olden days providers had stricter limits on the minimum TTL you can set, but these days you can set it practically as l…
I know about the caching issue is a little trivial but it was worth mentioning. Though I should have mentioned the low TTL piece. I will add that to the post. And also will add the health check part too. Reading up a bit about it. Thanks for the information!
Re: Load balancing and its different types
#5Decent summary but a little out-dated on DNS load balancing. Major cloud services like AWS support health/status checks through DNS these days: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/re... It's also trivial to get around the client caching issue, just set a low TTL. Perhaps in the olden days providers had stricter limits on the minimum TTL you can set, but these days you can set it practically as l…
Except it’s not trivial at all because isp resolver will just disregard your low ttl
Re: Load balancing and its different types
#6Decent summary but a little out-dated on DNS load balancing. Major cloud services like AWS support health/status checks through DNS these days: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/re... It's also trivial to get around the client caching issue, just set a low TTL. Perhaps in the olden days providers had stricter limits on the minimum TTL you can set, but these days you can set it practically as l…
Having executed several "no-downtime" cutovers between systems via DNS updates, I will warn you that a surprising number of clients never re-resolve DNS, so the TTL is effectively "forever" from their point of view.
For the rare case of lift-and-shift-ing for a system upgrade I felt morally okay about eventually pulling the plug on them, but I'd hesitate to design a system that relied on well-behaved DNS clients if I had a reasonable alternative.
Re: Load balancing and its different types
#7I like this intro! Good to see ‘random’ redefined as pick random two then assign to one with least connections, which works strictly better than either random or least connections alone. Misses a couple categories that may be relevant: least hops or best transit type network-mapped balancing to get to the ideal set of servers globally, as well as a technique that not-so-simply connects the user to the geography with…
Thank you. I am not sure how to introduce transit and the concept of hops in an introductory post without explaining in depth about the networking side of it. Maybe you could help me out with that?
Re: Load balancing and its different types
#8Software load balancing solutions have now more algorithms such as least time (nginx+ for example).
And yes some ISP cache DNS entries for a long time... But DNS load balancing should be used only on disaster scenarios to mitigate.
Re: Load balancing and its different types
#9Software load balancing solutions have now more algorithms such as least time (nginx+ for example). And yes some ISP cache DNS entries for a long time... But DNS load balancing should be used only on disaster scenarios to mitigate.
Added least time to the post as well. Thank you!
Re: Load balancing and its different types
#10Decent summary but a little out-dated on DNS load balancing. Major cloud services like AWS support health/status checks through DNS these days: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/re... It's also trivial to get around the client caching issue, just set a low TTL. Perhaps in the olden days providers had stricter limits on the minimum TTL you can set, but these days you can set it practically as l…
Having executed several "no-downtime" cutovers between systems via DNS updates, I will warn you that a surprising number of clients never re-resolve DNS, so the TTL is effectively "forever" from their point of view. For the rare case of lift-and-shift-ing for a system upgrade I felt morally okay about eventually pulling the plug on them, but I'd hesitate to design a system that relied on well-behaved DNS clients if I…
When I last updated a domain most clients saw the change within the TTL (1 hour)... except for my cable ISP at home. It took them the better part of a week.