[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-users] XCP bandwidth management
Do you know of any better documentation for the ovs-vsctl?
Maybe there is an answer there but I can't seem to find a full
syntax explanation :(
I have found a lot of useful info here
http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf (also see
http://openvswitch.org/?page_id=14). I don't expect you will find a
full solution there.
For the sFlow collector, it's one we wrote ourselves...not
really too sure it's working right though because we seem to get
multiple readings for the same interface. Also, not sure how to
stop it being easily floodable (sFlow would be in a domU so if
another domU floods it with these sFlow packets it would screw
up the results I guess).
Would creating a dedicated network for sFlow-collector domU solve
the problem? Normally your management network should be isolated
from untrusted domUs already, so you could use it for
sFlow-collector domU too.
I guess the ideal solution for me would be to have a VM guest
that logs all the traffic, does some calculations. I want to
check if the VM is averaging too fast across the month to meet
its monthly target, and if it is,slow it down until the target
is met (using 95 percentile perhaps to ignore spikes of
activity).
Really don't know how to achieve that with what's available
:(
As far as I can see, there are three pieces in this puzzle: 1)
traffic usage metering; 2) control algorithm to decide when it is
time to apply a quota; 3) policing mechanism to cap the bandwidth of
the offending VMs
Problem #1 is pretty much solved. It can be done with sFlow
collector or like this
http://www.falsyana.com/2011/loeniks/xenserver-customization-bandwidth/.
I currently use approach similar to the latter, but I save interface
counters in RRD files, for the history.
Exact solution for problem #2 will probably vary greatly from
installation to installation. Effectively we are talking about
developing a system which takes set of timestamped values (vm_uud;
vif_uud; rx_bytes; tx_bytes) as input and produces (vif_uuid;
ingress_poliing_rate; ingress_poliing_burst) values as
output.
Regarding problem #3 -- it is easy to limit traffic from VM, I trust
it is possible to limit it in other direction too, but I didn't have
enough time to make it work. One catch with limiting egress traffic
is that here we actually have no control over how much stuff
Internet hosts send to the IP address of VM. By limiting we are
talking about dropping the excess of the traffic and hoping TCP will
throttle down accordingly, which normally it will do.
Another aspect of problem #3 is how to transfer the policy from
sFlow domU to dom0. I would do it by publishing desired policy on
sFlow domU. It can be a simple as putting a plain text file on HTTP
server, or maybe having LDAP server on sFlow domU, if it is
justified. Then a cron job in dom0 would poll the desired policy
from sFlow domU and reconfigure vswitch accordingly. Alternatively,
one can push the config from sFlow domU into dom0 over native
vSwitch API, but I feel it is less preferable from security point of
view. I would prefer to keep my dom0 shut, even from trusted systems
I own.
Wanna trade ;) your sFlow collector for vif script patch? The patch
does bandwidth limiting (hardcoded value) and MAC/IP spoofing and
ARP poisoning protection (allowed IP taken from VM other-config
parameter). Actually I was going to publish the it anyway, if there
is any interest...
Cheers,
Alex
|
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
