<div dir="ltr">Yes, thats also an option. But we would like to get the flexibility and features that a floating IP provides.<br><div><br>So, in that case, there wont be any floating IPs , openstack will assign public IPs like it assigning private IPs , right?<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 26, 2016 at 12:57 PM, gustavo panizzo (gfa) <span dir="ltr"><<a href="mailto:gfa@zumbi.com.ar" target="_blank">gfa@zumbi.com.ar</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Apr 26, 2016 at 12:03:03PM +0530, Jaison Peter wrote:<br>
> Hi all,<br>
><br>
> I  was working in an openstack project to build a small to medium level<br>
> public cloud on the top of openstack. We are researching lot more about<br>
> scalable large openstack deployments and planning our design accordingly.<br>
> Initially we will be having 50+ compute nodes and planning to grow up to<br>
> 200 compute nodes in an year by migrating the existing clients to new<br>
> platform.<br>
><br>
> I have many concerns about the scaling and right choices , since openstack<br>
> is offering lot of choices and flexibility, especially in networking<br>
> side.Our major challenge was choosing between simplicity and performance<br>
> offered by Linux bridge and features and DVR offered by OVS.  We decided to<br>
> go with OVS, though some were suggesting like OVS is slow in large<br>
> deployments. But the distributed L3 agents and bandwidth offered by DVR<br>
> inclined us towards OVS. Is it a better decision?<br>
><br>
> But one of the major drawback we are seeing with DVR is the public IP<br>
> consumption. If we have 100 clients and 1 VM per client , eventually there<br>
> will be 100 tenants and 100 routers. Since its a public cloud, we have to<br>
> offer public IP for each VM. In DVR mode, fip name space in compute will be<br>
> consuming one public IP and if 100 VMs are running among 20 computes, then<br>
> total 20 public IPs will be used among computes. And a router SNAT name<br>
> space will be created for each tenant router(Total 100)  and each of it<br>
> will be consuming 1 public  IP and so total 100 public IPs will be consumed<br>
> by central SNAT name spaces. So total 100 + 20 = 120 public IPs will be<br>
> used by openstack components and  100 will be used as floating IPs (1:1<br>
> NAT) by VMs. So we need 220 public IPs for providing dedicated public IPs<br>
> for 100 VMs !! Anything wrong with our calculation?<br>
><br>
> From our point of  view 120 IPs used by openstack components in our case<br>
> (providing 1:1 NAT for every VM) is wastage of IPs and no any role in<br>
> network traffic. Centrallized SNAT is useful , if the client is opting for<br>
> VPC like in AWS and he is not attaching floating IPs to all instances in<br>
> his VPC.<br>
><br>
> So is there any option while creating DVR router to avoid creating central<br>
> SNAT name space in controller node ? So that we can save 100 public IPs in<br>
> the above scenario.<br>
<br>
</div></div>I've never used DVR, so I won't speak about it but I've run private<br>
clouds without wasting public ip address using provider networks.<br>
<br>
most of VM's had a single vNIC attached to a private network, shared or<br>
private to the tenant, optionally a VM may had a second vNIC attached to<br>
a public shared network.<br>
<br>
first i wanted to avoid the network node as it was a SPF, also it<br>
limits the bandwidth available to VM, also it allowed us to use our<br>
existing, proven, networking gear.<br>
<br>
my 0.02$<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
--<br>
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333<br>
<br>
keybase: <a href="http://keybase.io/gfa" rel="noreferrer" target="_blank">http://keybase.io/gfa</a><br>
</font></span></blockquote></div><br></div>