> If you've known the Alteon, then you have the best example of a product > that does extremely well (and fast) a small set of things and extremely > badly a large set of other things.
The set of things it did well was VERY small. Nauticus (did) and A10 do a much wider set of things very well. > DNS supports many fantaisies so that it could be proxied, but it was > designed to run without any need for load balancing since the client > is responsible for querying multiple servers. The only real reason > I see to load balance it is when you're an ISP who needs to always > give the same DNS IP address to millions of customers and who need > several servers for that task. But for this case, it looks rather > counter-productive to move that to clouds, considering that the DNS > part of the work is low compared to the per-packet processing which > will basically be doubled in a cloud environment. Actually, we're not load balancing DNS to the outside world. It's an internal/proprietary use of DNS that's used directly by the application not by the standard OS resolver which points elsewhere. We SLB in front of it for very fast failover. > > From your description, it appears complex precisely because you're > multiplying the number of load balancers. Running many LBs on many > hosts is often complex to manage and troubleshoot. It only saves > two servers at the beginning, and none once you start to scale > because normally you keep your two servers for load balancing and > the other ones have more spare resources to do their job. > It's complex because of the number of tiers. Currently, we have one subnet per tier, which allows the pair of appliances model to work well, as the appliances are the default gateway for each subnet...thereby each tier is forced back through the SLB. With a cloud model, you don't get the luxury of putting your tiers in different private subnets and defining one of your boxes as the default gateway for them. Hence, the approach we're taking of putting the SLB local to the app. > I've already looked for simple UDP load balancers several times but > never found anything usable. Most of the time, the need is just DNS > which is finally covered natively. Commercially it's a pretty common feature, not so much in open source. If you're using DNS internally for a latency sensitive operation, faster failover than resolver timeouts is desirable. -J
