<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>This is pretty much how we are using neutron. </div>
<div><br>
</div>
<div>We have multiple shared provider networks that have "real" ip's, backed by real vlans, using a real network device as the gateway. The are only two drawbacks to this approach (that I have found). The first is that floating ip's wont work (unless the
gateway device happens to do a firewall and you are doing natting there, we aren't). We are currently in the process of changing floating ip's to do routed ip address (which means the routed ip also need to be bound to a non-arping interface in the vm). The
second depends on your network design and the fact that neutron defines a network at layer2 and assumes that that network is available on any compute node.</div>
<div><br>
</div>
<div>Since our networking is a folded clos design – layer3 is terminated at the access switches so layer2 only exists on an access pair. We have modified both neutron and nova to support the ability of metadata placed on compute nodes (actually I think its
a host aggregate) to target which network a vm will live on (along with adding a network scheduler to both neutron and nova). This was needed because neutron, as I mentioned earlier, defines a network as layer2 segment *and* assumes that layer2 segment is
available anywhere in the cloud. Under our implementation that is not true, a particular layer2 segment is only available to servers directly attached to that access switch. So without these changes you have the possibility of boot of a vm on a compute node,
on a network that the compute node is not attached to and can never be attached to it without the node being moved. The scheduler additions that we did also make it possible for you to boot a vm without specifying a network and it will "just work".</div>
<div><br>
</div>
<div>Either way, from experience the solution that you have chosen, with a simpler more traditional network design, can/will scale out well beyond the 3-5 compute nodes you are talking about, without any changes to neutron/nova.</div>
<div>
<div>
<div>____________________________________________</div>
<div> </div>
<div>Kris Lindgren</div>
<div>Senior Linux Systems Engineer</div>
<div>GoDaddy, LLC.</div>
</div>
<div><br>
</div>
</div>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>matt <<a href="mailto:matt@nycresistor.com">matt@nycresistor.com</a>><br>
<span style="font-weight:bold">Date: </span>Monday, December 22, 2014 at 2:46 PM<br>
<span style="font-weight:bold">To: </span>George Shuklin <<a href="mailto:george.shuklin@gmail.com">george.shuklin@gmail.com</a>><br>
<span style="font-weight:bold">Cc: </span>"<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a>" <<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Openstack-operators] Small openstack<br>
</div>
<div><br>
</div>
<div>
<div>
<div dir="ltr">
<div>Sounds like a solid way to approach it george. I hope you can document and share your methods and experiences.<br>
<br>
</div>
Sounds like this would be helpful to folks setting up small test environments.<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Dec 22, 2014 at 4:35 PM, George Shuklin <span dir="ltr">
<<a href="mailto:george.shuklin@gmail.com" target="_blank">george.shuklin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thank you for everyone!<br>
<br>
After some lurking around I found rather unusual way: use external networks on per-tennant based with directly attached interfaces. This will not only eliminate neutron nodes (as heavy server), but will remove NAT and simplify everything for tenant. All we
need just a some VLAN/VXLANs with few external networks (per tenant).<br>
<br>
Tenants will have no 'routers' and 'floatingips', but still will have DHCP and other yummy neutron things like private networks with overlapping numbering plans.<br>
<br>
Future reports follow.
<div class="HOEnZb">
<div class="h5"><br>
<br>
On 12/21/2014 12:16 AM, George Shuklin wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello.<br>
<br>
I've suddenly got request for small installation of openstack (about 3-5 computes).<br>
<br>
They need almost nothing (just a management panel to span simple instances, few friendly tennants), and I curious, is nova-network good solution for this? They don't want network node and do 'network node on compute' is kinda sad.<br>
<br>
(And one more: did anyone tried to put management stuff on compute node in mild production?)<br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.<u></u>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-operators</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</span>
</body>
</html>