Diego is definitely correct. The drawbacks with VLANs are well documented but they remain the primary solution for providing per-tenant L2 domains for many shops today, due to skill set, comfort level, etc. The L3-integrated solutions on the horizon will be vast improvements, but until they arrive/mature we need to ensure the VLAN model is a first class citizen.
Carl Citrix Systems [email protected] On 2/3/11 6:32 AM, "Diego Parrilla Santamaría" <[email protected]> wrote: >Thanks Paul. Your explanation really helps. A vlan is a scarce >resource in cloud infraestructures and most of the people don't know >about it. > >I asked about this topic in this thread because I see two different >approaches that colides. And can have a huge impact in the 'account' >entity. > >The truth is that most of the datacenter professionals I have talked >about reject the Flat Network model and embrace the VLAN (or more than >one VLAN) per customer model because it is what they know and they >feel 'secured' using them. Openstack let us choose what model to use, >and this great and I think should not change. So, creating an account >entitty directly linked to the network model is dangerous because it >can limit this flexibility. > >I know, I have not given any valid answer... but it's something to >consider due to the efforts to support a more complex network >management. > >Cheers >Diego > >- >Diego Parrilla >nubeblog.com | [email protected] | twitter.com/nubeblog >+34 649 94 43 29 > > > > >2011/2/3 Paul Voccio <[email protected]>: >> Diego, >> >> Due to our networking topology, having a vlan per customer isn't really >> feasible. Most switches are limited at 4k or 8k or even 32k. With more >> customers than these switches can reasonably accommodate, having a >>single >> vlan per customer either limits the portability within a cloud or limits >> the scale at which you can build your cloud. Open vSwitch will alleviate >> some of this pain, but until we get it in XenServer, we're somewhat >>stuck >> on flat networking. >> >> Paul >> >> On 2/3/11 4:20 AM, "Diego Parrilla Santamaría" >> <[email protected]> wrote: >> >>>Hi Monsyne, >>> >>>it's a very interesting topic and I'm curious about the reason why you >>>are using the Flat Networking set up. From the conversations in other >>>threads it seems the Service Providers prefer different networking >>>approaches: VLAN oriented basically. >>> >>>Regards >>>Diego >>> >>>- >>>Diego Parrilla >>>nubeblog.com | [email protected] | twitter.com/nubeblog >>>+34 649 94 43 29 >>> >>> >>> >>> >>>On Thu, Feb 3, 2011 at 2:37 AM, Monsyne Dragon <[email protected]> >>>wrote: >>>> I am sorting out some possible implementations for the >>>> multi-tenant-accounting blueprint, and the related >>>>system-usage-records >>>>bp, >>>> and I just wanted to run this by anyone interested in such matters. >>>> >>>> Basically, for multitenant purposes we need to introduce the concept >>>>of >>>>an >>>> 'account' in nova, representing a customer, that basically acts as a >>>>label >>>> for a group of resources (instances, etc), and for access control (i.e >>>> customer a cannot mess w/ customer b's stuff) >>>> >>>> There was some confusion on how best to implement this, in relation to >>>> nova's project concept. Projects are kind of like what we want an >>>>account >>>> to be, but there are some associations (like one project per network) >>>>which >>>> are not valid for our flat networking setup. I am kind of >>>>straw-polling on >>>> which is better here: >>>> >>>> The options are: >>>> 1) Create a new 'account' concept in nova, with an account basically >>>>being >>>> a subgroup of a project (providers would use a single, default >>>>project, >>>>with >>>> additional projects added if needed for separate brands, or resellers, >>>>etc), >>>> add in access control per account as well as project, and make sure >>>> apis/auth specify account appropriately, have some way for a default >>>> account to used (per project) so account doesn't get in the way for >>>> non-multitenant users. >>>> >>>> 2) having account == nova's "project", and changing the network >>>> associations, etc so projects can support our model (as well as >>>>current >>>> models). Support for associating accounts (projects) together for >>>> resellers, etc would either be delegated outside of nova or added >>>>later >>>> (it's not a current requirement). >>>> >>>> In either case, accounts would be identified by name, which would be >>>>an >>>> opaque string an outside system/person would assign, and could >>>>structure to >>>> their needs (ie. for associating accounts with common prefixes, etc) >>>> >>>> -- >>>> >>>> -- >>>> -Monsyne Dragon >>>> work: 210-312-4190 >>>> mobile 210-441-0965 >>>> google voice: 210-338-0336 >>>> >>>> >>>> >>>> Confidentiality Notice: This e-mail message (including any attached or >>>> embedded documents) is intended for the exclusive and confidential use >>>>of >>>> the >>>> individual or entity to which this message is addressed, and unless >>>> otherwise >>>> expressly indicated, is confidential and privileged information of >>>> Rackspace. >>>> Any dissemination, distribution or copying of the enclosed material is >>>> prohibited. >>>> If you receive this transmission in error, please notify us >>>>immediately >>>>by >>>> e-mail >>>> at [email protected], and delete the original message. >>>> Your cooperation is appreciated. >>>> >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~openstack >>>> Post to : [email protected] >>>> Unsubscribe : https://launchpad.net/~openstack >>>> More help : https://help.launchpad.net/ListHelp >>>> >>> >>>_______________________________________________ >>>Mailing list: https://launchpad.net/~openstack >>>Post to : [email protected] >>>Unsubscribe : https://launchpad.net/~openstack >>>More help : https://help.launchpad.net/ListHelp >> >> >> >> Confidentiality Notice: This e-mail message (including any attached or >> embedded documents) is intended for the exclusive and confidential use >>of the >> individual or entity to which this message is addressed, and unless >>otherwise >> expressly indicated, is confidential and privileged information of >>Rackspace. >> Any dissemination, distribution or copying of the enclosed material is >>prohibited. >> If you receive this transmission in error, please notify us immediately >>by e-mail >> at [email protected], and delete the original message. >> Your cooperation is appreciated. >> >> > >_______________________________________________ >Mailing list: https://launchpad.net/~openstack >Post to : [email protected] >Unsubscribe : https://launchpad.net/~openstack >More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
