See inline. ____________________________________________ Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC.
On 6/17/15, 5:12 AM, "Neil Jerram" <[email protected]> wrote: >Hi Kris, > >Apologies in advance for questions that are probably really dumb - but >there are several points here that I don't understand. > >On 17/06/15 03:44, Kris G. Lindgren wrote: >> We are doing pretty much the same thing - but in a slightly different >>way. >> We extended the nova scheduler to help choose networks (IE. don't put >> vm's on a network/host that doesn't have any available IP address). > >Why would a particular network/host not have any available IP address? If a created network has 1024 ip's on it (/22) and we provision 1020 vms, anything deployed after that will not have an additional ip address because the network doesn't have any available ip addresses (loose some ip's to the network). >> Then, >> we add into the host-aggregate that each HV is attached to a network >> metadata item which maps to the names of the neutron networks that host >> supports. This basically creates the mapping of which host supports >>what >> networks, so we can correctly filter hosts out during scheduling. We do >> allow people to choose a network if they wish and we do have the neutron >> end-point exposed. However, by default if they do not supply a boot >> command with a network, we will filter the networks down and choose one >> for them. That way they never hit [1]. This also works well for us, >> because the default UI that we provide our end-users is not horizon. > >Why do you define multiple networks - as opposed to just one - and why >would one of your users want to choose a particular one of those? > >(Do you mean multiple as in public-1, public-2, ...; or multiple as in >public, service, ...?) This is answered in the other email and original email as well. But basically we have multiple L2 segments that only exists on certain switches and thus are only tied to certain hosts. With the way neutron is currently structured we need to create a network for each L2. So that¹s why we define multiple networks. For our end users - they only care about getting a vm with a single ip address in a "network" which is really a zone like "prod" or "dev" or "test". They stop caring after that point. So in the scheduler filter that we created we do exactly that. We will filter down from all the hosts and networks down to a combo that intersects at a host that has space, with a network that has space, And the network that was chosen is actually available to that host. > >> We currently only support one network per HV via this configuration, but >> we would like to be able to expose a network "type" or "group" via >>neutron >> in the future. >> >> I believe what you described below is also another way of phrasing the >>ask >> that we had in [2]. That you want to define multiple "top level" >>networks >> in neutron: 'public' and 'service'. That is made up by multiple >>desperate > >desperate? :-) I assume you probably meant "separate" here. Sorry - yes. > >> L2 networks: 'public-1', 'public2,' ect which are independently >> constrained to a specific set of hosts/switches/datacenter. > >If I'm understanding correctly, this is one of those places where I get >confused about the difference between Neutron-as-an-API and >Neutron-as-a-software-implementation. I guess what you mean here is >that your deployment hardware is really providing those L2 segments >directly, and hence you aren't using Neutron's software-based simulation >of L2 segments. Is that right? > >> We have talked about working around this under our configuration one of >> two ways. First, is to use availability zones to provide the separation >> between: 'public' and 'service', or in our case: 'prod', >>'pki','internal', >> ect, ect. > >Why are availability zones involved here? Assuming you had 'prod', >'pki','internal' etc. networks set up and represented as such in >Neutron, why wouldn't you just say which of those networks each instance >should connect to, when creating each instance? Because neutron doesn't support our networking configuration, so we need to present a way for the end user to choose what network "zone" they end up on. Neutrons current model is "any network, anywhere" where network here is really defined as L2 domain. Which is simply not the way networks in our data centers are being built theses days. We have moved from that model to a "folded clos" Design. In this design a "spine" interconnects all of the TOR's (leafs). Each TOR Terminates the L2 boundary for servers attached to it. All communication across the spine is routed (L3). This design pushes the ARP/Broadcast traffic down to the TOR's and frees up the CAM table space in the spine. Allowing it to scale much much better. We put together an RFE on this. [1] [1] - https://bugs.launchpad.net/neutron/+bug/1458890 > >Regards, > Neil > _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
