On Thu, May 12, 2016 at 5:59 PM, Guru Shetty <g...@ovn.org> wrote: > >> >> >> >> With respect to the other questions, I think its best approach would >> be to >> >> ask direct questions so those >> >> direct questions get answered. >> >> >> >> 1) With 1000 HVs, 1000 HVs/tenant, 1 distributed router per tenant, you >> >> choose the number of gateways/tenant: >> >> >> >> a) How many Transit LS distributed datapaths are expected in total ? >> >> >> > >> > One (i.e the same as the distributed router). >> > >> >> >> i.e. >> 1000 distributed routers => 1000 Transit LSs >> > Yes. > >> >> >> >> > >> > >> >> >> >> b) How many Transit LS logical ports are needed at the HV level ? >> >> >> >> what I mean by that is lets say we have one additional logical port at >> >> northd level and 1000 HVs then if we need to download that port to 1000 >> >> HVs, I consider that to be 1000 logical ports at the HV level because >> >> downloading and maintaining state across HVs at scale is more expensive >> >> than for a single hypervisor. >> >> >> > >> > 1000 additional ones. It is the same as your distributed logical switch >> or >> > logical router (this is the case even with the peer routers) >> > >> >> Did you mean 2000 including both ends of the Transit LS ? >> > > No. One end is only on the physical gateway to act as a physical endpoint. > >> >> >> >> > >> > >> > >> >> >> >> c) How many Transit LS arp resolve entries at the HV level ? >> >> >> >> what I mean by that is lets say we have one additional arp resolve >> flow at >> >> northd level and 1000 HVs then if we need to download that arp resolve >> >> flow >> >> to 1000 HVs, I consider that to be 1000 flows at the HV level because >> >> downloading and maintaining state across multiple HVs is more expensive >> >> that a single hypervisor. >> >> >> > >> > 2 ARP flows per transit LS * 1000 HVs. >> > >> >> oops; I underestimated by half >> >> >> >> > Do realize that a single bridge on a single hypervisor typically has >> flows >> > in the 100,000 range. Even a million is feasbile. >> > >> >> I know. >> I am thinking about the coordination across many HVs. >> > > There is no co-ordination. HV just downloads from ovn-sb. This is > absolutely not different than any of the other distributed datapaths that > we have. If introduction of one additional datapath is a problem, then OVN > has a problem in general because it then simply means that it can only do > one DR per logical topology. >
Coordination here does not mean strict synchronization. Rather, something like this: https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=coordination > A transit LS is much less resource intensive (as it consumes just one > additional port) than a DR connected to another DR (not GR) as peers (in > this case have 2 additional ports per DR and then whatever additional > switch ports that are connected to it). > The apples to apples comparison that I am looking at is: DR<->Transit LS<->GR vs DR<->GR I looked at this from efficiency POV and manageability POV. I'll send an update on a combined thread. > > If the larger concern is about having 1000 tenants, then we need to pass > more hints to ovn-controller about interconnections so that it only > programs things relevant to local VMs and containers which are limited by > the number of CPUs and Memory and is usually in the order of 10s. > This is a somewhat orthogonal topic. However, I am working on some limiting scope of DR flows. I started that with "local_router", but it breaks VM scheduling for Openstack :-). I thought about tracking a DR to those LSs it services instead and that seems that is also done in other products, so that would be more viable albeit slightly more complicated from internal OVN POV. Some other folks may be looking at this as well. > > >> >> >> >> > Microsegmentation use cases has 10000 ACLs per logical switch. So that >> is >> > 10000 * 1000 for your case form single LS. So do you have some >> comparative >> > perspectives. > > > >> > >> > >> > dev mailing list >> >> dev@openvswitch.org >> >> http://openvswitch.org/mailman/listinfo/dev >> >> >> > >> > >> _______________________________________________ >> dev mailing list >> dev@openvswitch.org >> http://openvswitch.org/mailman/listinfo/dev >> > > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
