Open Stack

Thanks Kevin,

If I understood you well, scalability isn't impacted by number of tenants,
but rather by number of ports by network / security group / tenant router;
so, if I have a single giant tenant network with several thousands ports,
perhaps I'll have a problem.

Partitioning the load into various "tenant networks" should mitigate these
problems, independently of the total number of tenants. So I could I keep
running the cloud fine with a *single* tenant owning *several* internal
networks, right?

Gustavo


On Thu, May 14, 2015 at 6:56 PM, Kevin Benton <blak111 at gmail.com> wrote:

> 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.randich at 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-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
>
>
>
> --
> Kevin Benton
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150514/3aeb787b/attachment.html>