Neutron scalability isn't impacted directly by the number of tenants so that shouldn't matter too much. The following are a few things to consider.
Number of ports per security group: Every time a member of a security group (a port) is removed/added or has it's IP changed, a notification goes out to the L2 agents so they can update their firewall rules. If you have thousands of ports and lots of churn, the L2 agents will be busy all of the time processing the changes and may fall behind impacting the time it takes for ports to gain connectivity. Number of ports per network: Each network is a broadcast domain so a single network with hundreds of ports will get pretty chatty with broadcast and multicast traffic. Also, if you use l2pop, each l2 agent has to know the location of every port that shares a network with the ports on the agent. I don't think this has as much impact as the security groups updating, but it's something to keep in mind. Number of ports behind a single tenant router: Any traffic that goes to an external network that doesn't have a floating IP associated with it needs to go via the assigned centralized SNAT node for that router. If a lot of your VMs don't have floating IPs and generate lots of traffic, this single translation point will quickly become a bottleneck. Number of centralized SNAT agents: Even if you have lots of tenant routers to address the issue above, you need to make sure you have plenty of L3 agents with access to the external network and 'agent_mode' set to 'dvr_snat' so they can be used as centralized SNAT nodes. Otherwise, if you only have one centralized SNAT node, splitting the traffic across a bunch of tenant routers doesn't buy you much. Let me know if you need me to clarify anything. Cheers, Kevin Benton On Thu, May 14, 2015 at 9:15 AM, Gustavo Randich <gustavo.rand...@gmail.com> wrote: > Hi! > > We are evaluating the migration of our private cloud of several thousand VMs > from multi-host nova-network to neutron/DVR. For historical reasons, we > currently use a single tenant because group administration is made outside > openstack (users don't talk to OS API). The number of compute nodes we have > now is approx. 400, and growing. > > My question is: > > Srictly regarding the scalability and performance fo the DVR/Neutron virtual > networking components inside compute nodes (OVS virtual switches, iptables, > VXLAN tunnel mesh, etc.), should we mantain this single-tenant / > single-network architecture in Neutron/DVR? Or should we partition our next > cloud into several tenants each corresponding to different groups/verticals > inside the company, and possibly each with their several private networks? > > Thanks! > > > _______________________________________________ > OpenStack-operators mailing list > openstack-operat...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > -- Kevin Benton _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack