On Fri, Jul 9, 2021 at 9:54 AM Ben Pfaff <b...@ovn.org> wrote: > > On Wed, Jul 07, 2021 at 05:17:17PM -0700, Han Zhou wrote: > > On Wed, Jul 7, 2021 at 3:39 PM Ben Pfaff <b...@ovn.org> wrote: > > > > > > Hi, I've been talking to Shay Vargaftik (CC'd), also a researcher at > > > VMware, about some work he's done on optimizing load balancers. What > > > he's come up with is a technique that in many cases avoids putting > > > connections into the connection-tracking table, because it can achieve > > > per-connection consistency without needing to do that. This improves > > > performance by reducing the size of the connection-tracking table, which > > > is therefore more likely to fit inside a CPU cache and cheaper to > > > search. > > > > > > I'm trying to determine whether this technique would apply to OVN's load > > > balancer. There would be challenges in any case, but one fundamental > > > question I have is: is the OVN load balancer also supposed to be a > > > firewall? If it's not, then it's worth continuing to look to see if the > > > technique is applicable. On the other hand, if it is, then every > > > connection needs to be tracked in any case, so the technique can't be > > > useful. > > > > > > Anyone's thoughts would be welcome. > > > > > For my understanding OVN LB doesn't directly relate to FW (OVN ACLs), > > although they both use conntrack. For LB, we use conntrack for NAT (convert > > the client IP to an LB owned IP) purposes. Does this technique support NAT > > without using conntrack? > > Some kinds of NAT just change IP addresses. These kinds of NAT don't > fundamentally need to track per-connection state, so this kind of NAT > would not demand conntrack. Other kinds of NAT pull a port number from > a pool and assign it to each connection. The latter kind does need to > track per-connection state, so it does need conntrack. I'm not sure > which category the OVN LB is in. > There are both in OVN LB. Let me have a more detailed description.
The basic part of OVN LB is DNAT: convert the destination VIP (and port, optionally) to a group of backend IPs (and ports, optionally). CT is not needed for the conversion itself, but is used to: 1) avoid the calculation for following packets (in theory, this could be avoided) 2) handle the possible IP fragments, which don't have the L4 headers for bucket selection 3) make sure the return packets' source IP/port can be converted back from the backend IP/port to VIP/port (unDNAT). This may fall into the first category you described. This applies to LBs for logical switches, and LBs for routers WITHOUT "lb_force_snat_ip" configured. The second part (optional) of OVN LB is SNAT: convert the source (client) IP to an IP owned by the logical router. CT is used here to make sure the return packets' destination IP is converted back from the SNATed IP to the real client's IP (unSNAT). For this to work, during SNAT it converts the source port to a new port selected from a range (otherwise, when there are two clients using the same source port it is impossible to distinguish the return packets for the two clients). This falls into the second category you described. It applies to the use case of LBs on LRs when "lb_force_snat_ip" is configured. > > Moreover, maybe for the future, we also need to consider the cases when a > > LB is applied on a OVN gateway, for HA purposes the NAT tracking entries > > need to be able to be replicated across nodes, so that when failover > > happens the existing connections can continue working through another > > gateway node. > > I don't think this is a problem for Shay's technique, which is called > JET (for Just Enough Tracking). JET is designed to gracefully cope with > failover. In fact, this is possibly an even better case for JET, > because fewer entries mean less replication. > > > There are also OVN LB use cases that don't require NAT. If this technique > > doesn't support NAT, it is probably still useful for those scenarios. Sorry that this was not accurate. I should in fact say "there are also ... SNAT". > > That makes sense. > > Do you have any idea which of the various cases that OVN supports are > commonly used? Or whether performance is an issue for them in practice? > It would be silly to spend a lot of time optimizing the performance of > something that is already fast enough. Regarding performance, since the current OVN LB relies on CT, and a recirculation is required in OVS, there is definitely some impact. It also depends on CT performance and how heavy the CT is used in such an environment (e.g. connection rate). In an environment where CT is already a bottleneck, of course the techniques that avoid CT should help. In the past there were other efforts in OVN trying to avoid/reduce CT for performance reasons, such as "stateless ACL" support. Thanks, Han _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
