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
