Open Stack

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 <openstack at medberry.net
> <mailto:openstack at 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 <urotrip2 at gmail.com
>     <mailto:urotrip2 at 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 at lists.openstack.org
>         <mailto:openstack at 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 at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>