cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus <shadow...@gmail.com>
Subject Re: Network QoS (not bandwidth limiting)
Date Sun, 22 Feb 2015 07:07:39 GMT
The points raised are certainly valid from an enterprise networking
standpoint, and don't fall on deaf ears, but we should keep things in
perspective. To provide the aforementioned features would be
relatively uncharted territory in the cloud orchestration world (at
least not considering vendor provided networking solutions that only
handle the network part of the equation), so while it would be good to
aspire to providing those things, it should be no surprise that the
platform works that way and lacks such features.

For further perspective, keep in mind that cloud orchestration in
general has been a pitch to software developers and management for
"easy infrastructure". Cloud consumers are end users, web developers,
application developers, so again it should be no surprise that the
product provides features that cater to that, rather than providing
the bells and whistles that a network admin would want to see in their
infrastructure. CloudStack was never built to be pitched to network
teams as a cure for managing their infra deployments, the only cloud
product providers doing that are network vendors who have cloud
networking products. This is of course why a VPC needs IPs defined, as
applications care more about how to serve up a web page than network
engineering and managing distinct layer 2 and 3, so the whole network
stack is sandwiched into a simple orchestration mechanism that gets
the application what it needs.

In designing and deploying cloud, the most common complaint I see from
people who are infrastructure maintainers is "why can't I just build
the infrastructure the way I want and then have it orchestrated?".
Unfortunately, we can't just automate and integrate with anyone's pet
design. CloudStack supports many novel and custom network designs
simply by allowing the option of letting you manage the network
hardware and being hands-off (shared/public networks), while also
being pluggable to allow vendors to take over whatever features and
they wish. I've seen some pretty advanced overlay networking provided
through third party plugins to CloudStack that take over all network
functionality and provide more.

What's really being asked for here is for CloudStack to provide and
maintain a fully fledged and featured router distribution in its
provided virtual router. It's an admirable project to have if we can
get support for it. My guess is there's a bit of a disconnect in
interest though, because many (but not all) enterprises who want
CloudStack for infrastructure automation are skeptical about a VM as
software router and prefer to bring in aforementioned enterprise
vendors who have their own plugins. People who provide cloud hosting
and other services tend to use the routers, but their interest in
enterprise level routing and redundancy varies greatly, and their
customers are designing their apps to be resilient to infrastructure
loss (e.g. most AWS customers). That's of course not entirely the
whole truth, as is evidenced by the work we are seeing on redundant
routers, but I do believe that's why we haven't seen these things from
the beginning. They just haven't been all that important to the target
customers, even though infrastructure engineers are used to providing
them.

So now comes my philosophy. In the end, I think the great thing about
open source communities is that if there's the right level of
interest, it will happen.  I'm the kind of person who feels a pang of
stress at the idea that something I work on can't be all things to all
people, but after building a hosting business over the last few years
I've begun to realize that it's really only practical to try to be
good for a subset of the market and focus on that. You'll never please
everyone, there are limits to what you can accomplish, and sometimes
it's OK to just concede that your product is not going to work for
everyone. If you don't, you'll spread yourself too thin and fail
everyone. In order to make something great you have to have a limit on
your scope. That's not to say you don't listen to your customers, but
you sometimes have to make hard choices on who to listen to and who to
upset.

None of this should be taken as a discouragement to the topics at
hand, but again as someone to takes it personally when I don't deliver
I wanted to provide some follow up to address the "rant" and try to
provide perspective on why the things are the way they are.

On Sat, Feb 21, 2015 at 1:58 PM, Somesh Naidu <Somesh.Naidu@citrix.com> wrote:
> Adrian,
>
> Rant or not, I believe you have raised a valid point and reflect certain group of peoples
requirement.
>
> Based on your requirement, I believe you are looking for something like Vyatta.
>
> Regards,
> Somesh
>
> -----Original Message-----
> From: Adrian Lewis [mailto:adrian@alsiconsulting.co.uk]
> Sent: Friday, February 20, 2015 8:50 PM
> To: users@cloudstack.apache.org
> Subject: RE: Network QoS (not bandwidth limiting)
>
> Tempted to suggest some sort of special interest group where networking
> people can have some input into the dev process despite not necessarily
> being able to produce any code themselves. As an example, Schuberg Philis
> have recently done some great work on the redundant VPC VR but to a
> network person, this sort of functionality is almost taken for granted
> (please don't take this as a lack of appreciation). Similarly, the lack of
> end-to-end QoS for applications running on ACS seems to me at least to be
> a fairly significant oversight. ACS is known as having very flexible
> networking compared with some of the alternatives but there does still
> appear to be an enterprise focus on most elements that a 'typical'
> developer (dare I say it, web developer) faces but more of a home network
> approach to the networking side (aside from some pretty impressive niche
> features).
>
> We shouldn't need to rely on proprietary 3rd party products to provide a
> similar level of versatility for networking in ACS in my opinion. It seems
> bizarre to me that we have load balancing, distributed routing & ACLs with
> the OVS controller, PVLANs for isolation,  etc, but yet still don't have
> what I would consider basic functions such as better control over NAT,
> firewalling, routing (no dynamic routing protocols at all), IPsec, having
> to specify IP related attributes to what should simply be L2 constructs
> (why does a VPC need to be given a CIDR?!?) etc. AWS had a similar issue
> that lead to the VPC being introduced - enterprises consistently rejected
> the weird and illogical way that they did networking back in the day that
> was overly focussed on web/cloudy workloads.
>
> This sounds like a rant and to an extent it is but I'd like to turn it
> into a positive. I feel fairly helpless when the typical response to
> feedback like this is that I should just contribute code. There are a
> number of people that embrace the concept that the community should be a
> collective of not just developers, but at the same time it's pretty
> difficult to feel part of a community that's run almost uniquely by
> developers; it's even a bit intimidating at times. I've seen too many
> commercial companies that abandon innovation in favour of satisfying the
> 'large account' RFC/RFPs and in my opinion the same may apply to a project
> driven largely by the needs of those that can contribute code.
>
> To flip the concept on its head, it would be like a network guy creating
> an amazing cloud orchestration platform but where you can only run centos
> 6 with a LAMP stack - yes this might work for a lot of people (and it
> would likely only be adopted by those people) but for those that just want
> to do something a bit different, it would be a fairly frustrating
> experience.
>
> Am I simply being a spoilt kid here or is there room for input that might
> be constructive? Is there anyone here on the list with a networking focus
> that can corroborate these concerns?
>
> Adrian
>
> -----Original Message-----
> From: Somesh Naidu [mailto:Somesh.Naidu@citrix.com]
> Sent: 20 February 2015 18:31
> To: users@cloudstack.apache.org
> Subject: RE: Network QoS (not bandwidth limiting)
>
> I don't think we can. QoS in CS is mostly throttling traffic on the
> virtual interface.
>
> Regards,
> Somesh
>
>
> -----Original Message-----
> From: Len.Bellemore@alternativenetworks.com
> [mailto:Len.Bellemore@alternativenetworks.com]
> Sent: Friday, February 20, 2015 5:18 AM
> To: users@cloudstack.apache.org
> Subject: Network QoS (not bandwidth limiting)
>
> Hi All,
>
> Does anyone know if it's possible to do network QoS in Cloudstack?  I
> don't mean bandwidth limiting, but rather, prioritising different traffic
> types for voice, etc.
>
> Thanks
> Len

Mime
View raw message