Dean Anderson wrote: > On Wed, 3 Oct 2007, Brian Dickson wrote: > > >> Dean Anderson wrote: >> >>> The load balancer is really just a special kind of stateful NAT. >>> >>> >> No. >> >> Load balancers can load balance, without any translation being done at all. >> >> And a load balancer is by definition doing *anycast*. The same address >> is used as a destination, and the packets are delivered to multiple >> hosts. That is anycast. >> > > No, that isn't anycast. A loadbalancer is actually a stateful NAT with > several different hosts behind the load balancing NAT. Those > loadbalancer devices you buy from cisco and other companies are > specialized NAT boxes. A load balancer is a device that balances load. A load balancer *may* be stateful. A load balancer *may* do L3 address rewriting. It is possible too that it *may not* rewrite L3 headers.
The address rewriting is orthogonal to the stateful-ness of the device. And both of *those* are orthogonal to the load balancing function of the device. It is possible that a device do stateless load balancing, with L3 rewrite. It is possible that a device do stateful load balancing with L3 rewrite. It is possible that a device do stateless load balancing without L3 rewrite. It is possible that a device do stateful load balancing without L3 rewrite. > The servers behind the load balancer have > all have different ip addresses. This is not a strict requirement. There are other methods and kinds of devices that work with servers with the same IP addresses. > The loadbalancer makes it appear they > servers share the same address through stateful address translation > techniques. > Address translation is only one of the techniques available. Others involve activity only on L2 frames. Those make the choice of which L2 destination to use, from a set of devices with *identical* L3 config (i.e. which all have the *same* IP address). The company that practically *owns* the load-balancing market for high-end service load balancing, is F5. F5 make devices that, among other things, can be configured to do stateful, L4 "fast" switching, which does *not* rewrite L3 headers at all. > By contrast, anycast is a load distributing technique that doesn't > involve any load balancing hardware. There is no box, there is not state > maintenance. One just gives several computers the same IP address and > drops them on the network. Obviously, TCP doesn't work, but stateless > services can work. > > Load balancers that do not keep state information, and forward "flows" (same source IP+port) to consistent destinations, are known to be harmful to TCP. It does not matter whether the stateless load balancer has the label "load balancer", or "router" on the front. If it makes decisions about where to send packets/frames, where the choices of destination link for the same L3 destination vary over a short duration, it is a load balancer. PPLB *is* a stateless load balancer. Cache-flow based routers doing load balancing, where there is significant churn in the cache and premature age-out of entries, is functionally identical to a load balancer. May so-called load balancers act in a stateless manner, with or without NAT on the back end. If it is load balancing, either it is stateful and TCP-friendly, or it is stateless and TCP-unfriendly. Network operators doing PPLB in ways that result in paths being chosen that are not topologically congruent, are not TCP-friendly. (Detailed explanation for those who are still listening follows. Feel free to use it to refute anyone who disagrees with the above assertions, if you encounter someone who doesn't get it.) Examples of topologically-congruent paths would be where loads are balanced across the set of links between the same pair of routers on both ends. *Only* topologies where this kind of parallel link is the only source of multiple paths, can divergence *across* the topology be avoided. Divergence within the topology itself is a local phenomenon, and expected. Consider a pair of routers, with three parallel links between them. A and B are routers and L1, L2, L3 are links. The paths from A to B are A-L1-B, A-L2-B, and A-L3-B. There is a risk of packet reordering, but no risk of divergence in the tail end of paths to the same destination, in the absence of route churn. Every path that includes A and any of the parallel links, also includes B, *after* the parallel link. If we presume these are the only parallel links in use, then at B, the per-hop behavior is fully deterministic, even if the behavior between A and B is only probabilistic. By induction, then, if we only add links of this parallel nature, then unless the destination is in some other way non-deterministic, then any path including the topology with lots of parallel links, is still deterministic. When load is balanced across a more complex topology, the cycle parity (of nodes) is critical. A ring of routers with an even number of nodes *may* be free of divergence. A ring of routers with an odd number of nodes, is *very likely* to result in divergence. Some day I may decide to do a PhD thesis on this subject, but for now, it is merely a reasonably open "trade secret" - known by not enough people, practised by fewer, and not something that vendor software will handle on its own. It's why backbone is an *engineering* discipline. >> Anycast can be either, or both of, global load balancer (using network >> announcements for accomplishing anycast), or local load balancer >> (using L2/L4 to serve multiple servers from a single apparent host >> address.) >> > > You quite obviously don't understand the difference between anycast and > ordinary load balancing devices. > I beg to differ. See the detailed explanation above, and then I suggest you retract your assertion. I know about as much as anyone on both subjects. Brian
begin:vcard fn:Brian Dickson n:Dickson;Brian org:Afilias Canada adr:;;;Toronto;;;Canada email;internet:[EMAIL PROTECTED] title:Internet Operations Specialist tel;work:+1 416 673 4121 url:www.afilias.info version:2.1 end:vcard
_______________________________________________ DNSOP mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dnsop
