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