Thank you Leslie, Erik and Tom for your insight. Will take a look at the alternatives!
On Fri, Jul 10, 2015 at 4:00 PM, Tom Walsh < [email protected]> wrote: > We are currently building up our latest iteration of OpenStack to handle > this exact setup. I was a bit confused as well as to where the different > parts fit together, but I have had some good phone calls with the guys at > Cumulus to help me understand how things work together and what > technologies are out there to get everything working together. > > So the basic concept at work here is that right now there are two > different parts of Neutron that are working. The first part is the actual > networking of the L2 infrastructure. The other portion is the L3+ layers > (routing, dhcp, FWaaS, LBaaS). > > Currently L2 is being handled by OVS and GRE, but the GRE portion can be > replaced with whatever technology you want to use (VLAN, GRE, VXLANs, etc). > When you integrate with something like Cumulus Networks, you are pushing > this functionality out to the switch. So you will have a given > project/tenant in OpenStack have a specific VLAN and that is used between > the compute nodes and the leaf (TOR switch). Beyond that level you use > VXLAN to push traffic between the leaf and spine switches to keep tenant's > traffic isolated. So basically you have VLAN 5 being tenant 5, and that > tenant has instances in multiple zones if the connectivity is intra-zone > then they just use the VLAN to talk to each instance. However if you have > the tenant in a different zone, then it will be pushed up to VXLAN to route > the traffic to the correct zone seamlessly. (At least that is how I > understood it.) > > L3 and up is another layer to Neutron. In order to avoid the SPoF and > overloading you mentioned, we are looking into http://Akanda.io (the > Cumulus link Eric provided is done with one of the Akanda guys). Basically > what Akanda is doing is using the compute infrastructure to scale the L3 > functionality of Neutron. Using hooks into the L3 portion of Neutron, they > spin up a VM that acts as a router for a given tenant (and they monitor it > and make sure it is up and running, outside of the tenant's VMs). This > allows you to scale your network load... As you add more compute resources > you also scale your networking capabilities. This is another DreamHost > project that has been spun out and following the same "enterprise services" > model that Ceph/InkTank took. I haven't really started using this yet as we > are in the process of purchasing the gear to build things out (QuantaMesh > LY9 with Cumulus Networks, etc), but from what I understand of the Akanda > project, it fits the bill and ticks most of the boxes for mitigating the > problems you are talking about. About the only problem I see with it, is > that it is missing a portion of the functionality that Neutron is providing > (specifically FWaaS as the API was in a state of flux and they are waiting > for it to stabilize). > > Let me know if you have any other questions or need further clarification > on anything. Also if I made some mistakes in my explanations. Right now a > lot of my knowledge is strictly theoretical as I haven't actually > implemented anything yet, but this is the direction we are heading. > > Tom Walsh > https://expresshosting.net/ > > On Wed, Jul 8, 2015 at 12:35 PM, Gustavo Randich < > [email protected]> wrote: > >> Hi, >> >> We are trying to figure out how to transition from a network model using >> nova-network and a single VLAN to a model using Neutron and multiple VXLAN >> tunnels. >> >> The main issue is not how to configure and setup the tunnels, but how to >> expose the new virtual machines born inside the tunnels to our "legacy", >> non-VXLAN, non-Openstack networks, i.e. DNS serrvers, databases, hardware >> load balancers, monitoring/metrics servers, etc. >> >> We are trying to avoid assigning a floating IP to every instance, and >> also avoid the SPoF and bottlenecks of Network Nodes. >> >> What are the alternatives? (Hardware switches supporting VXLAN and acting >> as gateways?) >> >> Thanks in advance. >> >> >> _______________________________________________ >> Mailing list: >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> Post to : [email protected] >> Unsubscribe : >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> >> > > _______________________________________________ > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : [email protected] > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > >
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : [email protected] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
