Open Stack

On Wed, Jun 25, 2014 at 10:29 PM, McCann, Jack <jack.mccann at hp.com> wrote:

> > >> If every compute node is
> > >> assigned a public ip, is it technically able to improve SNAT packets
> > >> w/o going through the network node ?
>
> It is technically possible to implement default SNAT at the compute node.
>
> One approach would be to use a single IP address per compute node as a
> default SNAT address shared by all VMs on that compute node.  While this
> optimizes for number of external IPs consumed per compute node, the
> downside
> is having VMs from different tenants sharing the same default SNAT IP
> address
> and conntrack table.  That downside may be acceptable for some deployments,
> but it is not acceptable in others.
>
> In fact, it is only acceptable in some very special cases.




> Another approach would be to use a single IP address per router per compute
> node.  This avoids the multi-tenant issue mentioned above, at the cost of
> consuming more IP addresses, potentially one default SNAT IP address for
> each
> VM on the compute server (which is the case when every VM on the compute
> node
> is from a different tenant and/or using a different router).  At that point
> you might as well give each VM a floating IP.
>
> Hence the approach taken with the initial DVR implementation is to keep
> default SNAT as a centralized service.
>

In contrast to moving service to distributed CN, we should take care of
keeping them as centralized, especially FIP and FW. I know a lot of
customer prefer using some dedicated servers to act as network nodes, which
have more NICs(as external connection) than compute nodes, in these cases
FIP must be centralized instead of being distributed. As for FW, if we want
stateful ACL then DVR can do nothing, except that we think security group
is already some kind of FW.



>
> - Jack
>
> > -----Original Message-----
> > From: Zang MingJie [mailto:zealot0630 at gmail.com]
> > Sent: Wednesday, June 25, 2014 6:34 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [Neutron] DVR SNAT shortcut
> >
> > On Wed, Jun 25, 2014 at 5:42 PM, Yongsheng Gong <gongysh at unitedstack.com>
> wrote:
> > > Hi,
> > > for each compute node to have SNAT to Internet, I think we have the
> > > drawbacks:
> > > 1. SNAT is done in router, so each router will have to consume one
> public IP
> > > on each compute node, which is money.
> >
> > SNAT can save more ips than wasted on floating ips
> >
> > > 2. for each compute node to go out to Internet, the compute node will
> have
> > > one more NIC, which connect to physical switch, which is money too
> > >
> >
> > Floating ip also need a public NIC on br-ex. Also we can use a
> > separate vlan to handle the network, so this is not a problem
> >
> > > So personally, I like the design:
> > >  floating IPs and 1:N SNAT still use current network nodes, which will
> have
> > > HA solution enabled and we can have many l3 agents to host routers. but
> > > normal east/west traffic across compute nodes can use DVR.
> >
> > BTW, does HA implementation still active ? I haven't seen it has been
> > touched for a while
> >
> > >
> > > yong sheng gong
> > >
> > >
> > > On Wed, Jun 25, 2014 at 4:30 PM, Zang MingJie <zealot0630 at gmail.com>
> wrote:
> > >>
> > >> Hi:
> > >>
> > >> In current DVR design, SNAT is north/south direction, but packets have
> > >> to go west/east through the network node. If every compute node is
> > >> assigned a public ip, is it technically able to improve SNAT packets
> > >> w/o going through the network node ?
> > >>
> > >> SNAT versus floating ips, can save tons of public ips, in trade of
> > >> introducing a single failure point, and limiting the bandwidth of the
> > >> network node. If the SNAT performance problem can be solved, I'll
> > >> encourage people to use SNAT over floating ips. unless the VM is
> > >> serving a public service
> > >>
> > >> --
> > >> Zang MingJie
> > >>
> > >> _______________________________________________
> > >> OpenStack-dev mailing list
> > >> OpenStack-dev at lists.openstack.org
> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > >
> > >
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140626/c08e37cf/attachment.html>