Thanks Brian. That's a very much needed implementation.
On Tue, Apr 26, 2016 at 10:55 PM, Brian Haley <brian.ha...@hpe.com> wrote: > On 4/26/16 12:05 PM, Jaison Peter wrote: > >> Hi George, >> >> Thanks for letting me know that we can create distributed router by >> disabling SNAT in central router. >> >> Even though we use VRRP HA router, it will consume 100 public IPs in the >> scenario I mentioned above, but can save IPs used in compute fip >> namespace. >> >> Yes, compute node do not need public IPs, but the fip name space in them >> uses it. >> > > Hi Jaison, > > I've been working on a spec to address the public IP usage in the FIP > namespace, it's at https://review.openstack.org/#/c/300207/ (it needs an > update). Basically, it would change the allocation strategy to use > addresses from an "infrastructure" subnet for ports that don't need to be > publicly reachable. It should also support the case where the default SNAT > IP doesn't need public reach-ability either, you only need it for floating > IPs. > > Plan is to finish this in the Newton cycle. > > -Brian > > > On Tue, Apr 26, 2016 at 7:57 PM, David Medberry <openst...@medberry.net >> <mailto:openst...@medberry.net>> wrote: >> >> Hi Jaison, >> >> This is an issue that the Neutron team is aware. They will likely be >> addressing this (at some point) but your understanding aligns with >> my own. So, public IPV4 usage is a well known, well documented issue >> and DVR / HA exacerbates it. >> >> On Tue, Apr 26, 2016 at 1:33 AM, Jaison Peter <urotr...@gmail.com >> <mailto:urotr...@gmail.com>> 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. >> >> >> >> >> >> _______________________________________________ >> Mailing list: >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> Post to : openstack@lists.openstack.org >> <mailto:openstack@lists.openstack.org> >> Unsubscribe : >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> >> >> >> >> >> _______________________________________________ >> 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 >> >> >
_______________________________________________ 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
