I would just add that if I'm not mistaken the DVR work would also include the features currently offered by nova network's 'multi-host' capability. While DVR clearly does a lot more than multi host, keeping SNAT centralized only might not fully satisfy this requirement. Indeed nova-network offers SNAT at the compute node thus achieving distribution of N-S traffic.
I agree with Zang's point regarding wasting public IPs. On the other hand one IP per agent with double SNAT might be a reasonable compromise. And in that case I'm not sure whether sharing SNAT source IPs among tenants would have any security implications, so somebody else might comment there. Summarizing, I think that distributing N-S traffic is important, but I don't think that to achieve this we'd necessarily need to implement SNAT at the compute nodes. I have reviewed the l3 agent part of the DVR work, it seems that there will be floating IP distribution at the agent level - but I could not understand whether there will be also SNAT distribution. Salvatore On 3 July 2014 10:45, Zang MingJie <zealot0...@gmail.com> wrote: > Although the SNAT DVR has some trade off, I still think it is > necessary. Here is pros and cons for consideration: > > pros: > > save W-E bandwidth > high availability (distributed, no single point failure) > > cons: > > waste public ips (one ip per compute node vs one ip per l3-agent, if > double-SNAT implemented) > different tenants may share SNAT source ips > compute node requires public interface > > Under certain deployment, the cons may not cause problems, can we > provide SNAT DVR as a alternative option, which can be fully > controlled by could admin ? The admin chooses whether use it or not. > > >> To resolve the problem, we are using double-SNAT, > > > >> first, set up one namespace for each router, SNAT tenant ip ranges to > >> a separate range, say 169.254.255.0/24 > > > >> then, SNAT from 169.254.255.0/24 to public network. > > > >> We are already using this method, and saved tons of ips in our > >> deployment, only one public ip is required per router agent > > > > Functionally it could works, but break the existing normal OAM pattern, > which expecting VMs from one tenant share a public IP, but share no IP with > other tenant. As I know, at least some customer don't accept this way, they > think VMs in different hosts appear as different public IP is very strange. > > > > In fact I severely doubt the value of N-S distributing in a real > commercialized production environment, including FIP. There are many things > that traditional N-S central nodes need to control: security, auditing, > logging, and so on, it is not the simple forwarding. We need a tradeoff > between performance and policy control model: > > > > 1. N-S traffic is usually much less than W-E traffic, do we really need > distribute N-S traffic besides W-E traffic? > > 2. With NFV progress like intel DPDK, we can build very cost-effective > service application on commodity x86 server (simple SNAT with 10Gbps/s per > core at average Internet packet length) > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev