Re: [Xen-users] XCP bandwidth management

["msgbox450@xxxxxxxxx" <msgbox450@xxxxxxxxx>]

Thanks Peter,

This is very interesting...

It looks like OpenFlow would be the best solution, although it seems very complicated and scarcely documented at the moment so I doubt I'd have much chance at implementing anything in a few days work. It is perhaps more something that I could tag on later in a year or two when the tools and APIs start appearing.

We've already had a go at implementing an sFlow collector, but seem to get multiple readings for the same interface which is a bit confusing :P

It always seems like I'm trying to play with things that aren't ready yet, but as by the time I find something that's ready, its all old news and I'm the last one using it :)

On Sat, May 21, 2011 at 8:05 PM, Peter Phaal <peter.phaal@xxxxxxxxx> wrote:

On Fri, May 20, 2011 at 9:38 AM, msgbox450@xxxxxxxxx
<msgbox450@xxxxxxxxx> wrote:
> Hi all,
> I've got XCP 1.0 up and running nicely and would like to use it in
> production. However I'm struggling with the concept of bandwidth management.
> It seems like such a common problem that everyone must have, but I can't
> find any clear direction in which to go.
> The dedicated host I am using (Hetzner) gives me a 5TB monthly bandwidth
> quota which needs to be shared between all the VMs on the XCP.
> Ideally I would like something to automatically manage the bandwidth such
> that each VM is capable of using the full 100mbps speed of the connection,
> but will be throttled back if the throughput is sustained, so we have e.g.
> 24 x 1GB VMs on the host with average of 213GB/month bandwidth usage each.
> Alternatively it might be easier to just route all the virtual interfaces
> though a VM than runs pfsense or use tc on the host to just set some sort of
> shaping on the physical interface itself, but I really don't know the best
> way to go about it.
>
> Things I've found so far aren't so good:
> 1 - Limit the interface using the XenCenter GUI... but that means the VM
> would never be able to go above about 1mbps, even if it's sat there and used
> no bandwidth for the past week and is well within its quota, so that's not
> ideal.
> 2 - Use sFlow in XCP to capture the data. Well this works for looking at how
> much bandwidth they are using, but I haven't found any existing tool that
> will act on that data to do traffic shaping.
> 3 - Use the XAPI calls to check the bandwidth usage.
>
> With methods 2 and 3 I guess I could write something that collects the data
> and stores it a database table, somehow work out how much the connection
> needs to be slowed by and then apply it using the XAPI, but that seems
> rather hacky and difficult and there must be a better way?
>
> If anyone could give some tips on how to do this I'd really appreciate it.
> Basically I just want the quickest and easiest way to make it so that the
> server as a whole doesn't go over its bandwidth limit without limiting all
> the guests to a tiny speed individually.
> Thanks!

> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
>

I don't know of any shrink wrap solutions that would meet your
requirements today, but XCP does contain the APIs needed to develop a
bandwidth manager.

http://blog.sflow.com/2011/05/openflow-and-sflow.html

It is important to distinguish between the amount of local traffic
that a VM generates (inter-VM traffic, backup etc) and non-local
traffic that counts against the 5TB quota. XAPI calls just give the
traffic totals. sFlow monitoring in the vSwitch easily distinguishes
between the local and non-local traffic.

On the control side, Open Flow allows the controller to create
separate policies for forwarding local and non-local traffic.
Combining the two, allows for adaptive management.

http://blog.sflow.com/2009/10/network-edge.html

OpenFlow has only recently started to be available in production
environments so the management tools are still lagging. There are many
open source and commercial OpenFlow controllers in development and I
expect that there will be a number of solutions available for managing
XCP in the near future.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users