Xen users - Feb 2010 - Dom U bandwidth monitoring - pmacct, bandwidthd?

I am looking for a way of recording internet bandwidth used by the domUs
on my servers.  I own the servers and switches but not the routers.  I
have multiple switches with aggregated links to the dom0s such that
depending on which one of the HSRP nodes they are currently connected to,
only one switch will be the uplink path to the internet. I hope this is
making sense - resisting the urge to draw an ascii network diagram :-)

Anyway, I wanted to ask if other people here have a similar topology and
how they account for bandwidth? - my initial thoughts are to have a SPAN
port on each switch mirroring the uplink and connect a separate box into
that which runs bandwidthd.  The only problem I can forsee is when the
HSRP moves from one switch to the other I might have a bit of a mess on my
hands.  Is pmacct a better option? Or perhaps something else?

I would prefer to do this at the egress point rather than run some kind of
accounting process on each dom0.

Grateful for any advice.


Thanks,

Matt.


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

On Fri, Feb 12, 2010 at 11:00 PM, Matthew Law <matt@webcontracts.co.uk>
wrote:
> I would prefer to do this at the egress point rather than run some kind of
> accounting process on each dom0.
Why? Will you be doing lots of domU moving?
The simplest method would be to give each domU a persistent vif name
and read their stats from /proc/net/dev

-- 
Fajar

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

every reboot this method " /proc/net/dev " start from zero

On Fri, Feb 12, 2010 at 11:11 AM, Fajar A. Nugraha <fajar@fajar.net>
wrote:
> On Fri, Feb 12, 2010 at 11:00 PM, Matthew Law
<matt@webcontracts.co.uk>
> wrote:
> > I would prefer to do this at the egress point rather than run some
kind
> of
> > accounting process on each dom0.
>
> Why? Will you be doing lots of domU moving?
> The simplest method would be to give each domU a persistent vif name
> and read their stats from /proc/net/dev
>
> --
> Fajar
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>

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

On Fri, February 12, 2010 4:11 pm, Fajar A. Nugraha
wrote:
> On Fri, Feb 12, 2010 at 11:00 PM, Matthew Law
<matt@webcontracts.co.uk>
> wrote:
>> I would prefer to do this at the egress point rather than run some kind
>> of
>> accounting process on each dom0.
>
> Why? Will you be doing lots of domU moving?
> The simplest method would be to give each domU a persistent vif name
> and read their stats from /proc/net/dev
I don''t currently do live migration or frequent moving of domUs but may
well need to cope with it in the future.  I can''t force anything to run
on
the domUs, so I think I have to do it either at the dom0 or at the egress
point(s), no?

My line of thought was that If I do it at the egress point I have at most
two points to account for, and gather the graph data from, then I can
create the graphs centrally and serve them up via a control panel web app.


Thanks,

Matt.


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

My Company developed a method via mrtg.  Each vm has a vif name that means
something within our tracking system.

an example of this would be user32.  On the Xen server, they have a vm called
user32 and within the config file of the VM, there vif name is user32.  We set
there MRTG files to pull data based on ''network card name'' (in
this case user32), and use rrd tool to store the information.   This makes it
very easy to pull all historical data from vm''s.  When ever a vm moves,
so does it''s .rrd file  thus keeping all bandwidth traffic together.

This may not solve your issue or question...  but I would try barking up the
mrtg tree to collect bandwidth totals.

________________________________
From: xen-users-bounces@lists.xensource.com
[xen-users-bounces@lists.xensource.com] On Behalf Of Alaa eldin
[sirash23@gmail.com]
Sent: Friday, February 12, 2010 11:15 AM
To: Fajar A. Nugraha
Cc: matt@webcontracts.co.uk; xen-users@lists.xensource.com
Subject: Re: [Xen-users] Dom U bandwidth monitoring - pmacct, bandwidthd?

every reboot this method " /proc/net/dev " start from zero

On Fri, Feb 12, 2010 at 11:11 AM, Fajar A. Nugraha
<fajar@fajar.net<mailto:fajar@fajar.net>> wrote:
On Fri, Feb 12, 2010 at 11:00 PM, Matthew Law
<matt@webcontracts.co.uk<mailto:matt@webcontracts.co.uk>>
wrote:
> I would prefer to do this at the egress point rather than run some kind of
> accounting process on each dom0.
Why? Will you be doing lots of domU moving?
The simplest method would be to give each domU a persistent vif name
and read their stats from /proc/net/dev

--
Fajar

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



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

On Fri, February 12, 2010 4:48 pm, Robbie A. Garrett
wrote:
> My Company developed a method via mrtg.  Each vm has a vif name that means
> something within our tracking system.
>
> an example of this would be user32.  On the Xen server, they have a vm
> called user32 and within the config file of the VM, there vif name is
> user32.  We set there MRTG files to pull data based on ''network
card name''
> (in this case user32), and use rrd tool to store the information.   This
> makes it very easy to pull all historical data from vm''s.  When
ever a vm
> moves, so does it''s .rrd file  thus keeping all bandwidth traffic
> together.
>
> This may not solve your issue or question...  but I would try barking up
> the mrtg tree to collect bandwidth totals.
I have unique vif names for each domU already (its against a unique ID in
a database table which maps back to the customer).  Only problem with
taking stats from the dom0 is that I wouldn''t like to penalise people
for
transferring data between their domUs on different hosts.  We get charged
for uplinked data transfer only.  Its starting to look like I might have
to do this at the switches...

Thanks,

Matt.


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

How would the switch know that traffic is for DomU or internet?

this would have to be on a presence router / switch and track by ip address
which I think is a bad idea.
What I would suggest is that you allow there vm''s to be able to use
there own private network to move the data from one vm to another.  A lot of
houses do it like this so they can let the customers who setup there
vm''s in a cluster have there cluster traffic bandwidth free.

________________________________
From: Matthew Law [matt@webcontracts.co.uk]
Sent: Friday, February 12, 2010 12:20 PM
To: Robbie A. Garrett
Cc: xen-users@lists.xensource.com
Subject: RE: [Xen-users] Dom U bandwidth monitoring - pmacct, bandwidthd?


On Fri, February 12, 2010 4:48 pm, Robbie A. Garrett
wrote:
> My Company developed a method via mrtg.  Each vm has a vif name that means
> something within our tracking system.
>
> an example of this would be user32.  On the Xen server, they have a vm
> called user32 and within the config file of the VM, there vif name is
> user32.  We set there MRTG files to pull data based on ''network
card name''
> (in this case user32), and use rrd tool to store the information.   This
> makes it very easy to pull all historical data from vm''s.  When
ever a vm
> moves, so does it''s .rrd file  thus keeping all bandwidth traffic
> together.
>
> This may not solve your issue or question...  but I would try barking up
> the mrtg tree to collect bandwidth totals.
I have unique vif names for each domU already (its against a unique ID in
a database table which maps back to the customer).  Only problem with
taking stats from the dom0 is that I wouldn''t like to penalise people
for
transferring data between their domUs on different hosts.  We get charged
for uplinked data transfer only.  Its starting to look like I might have
to do this at the switches...

Thanks,

Matt.



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

On Fri, February 12, 2010 5:27 pm, Robbie A. Garrett
wrote:
> How would the switch know that traffic is for DomU or internet?
>
> this would have to be on a presence router / switch and track by ip
> address which I think is a bad idea.
Thanks, Robbie.

I''m interested to know why you think that''s a bad idea? - one
of the
solutions I was considering is to setup a SPAN port against the uplink on
each switch and use bandwidthd on that.  I have very little network
experience at this level, so I''m likely missing something (and
that''s the
main reason I decided to ask here as it is very likely others have been
here and learned the lessons).
> What I would suggest is that you allow there vm''s to be able to
use there
> own private network to move the data from one vm to another.  A lot of
> houses do it like this so they can let the customers who setup there
vm''s
> in a cluster have there cluster traffic bandwidth free.
Thanks.  Definitely an option being considered!

Cheers,

Matt.


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

I suppose it''s been what''s been handed down to me, but as a
general rule...  I never run any kind of SNMP system on routers that link to the
internet / datacenter switch or router. SNMP is very insecure (unless my
information is out of date) and could open you up to someone at the very least
viewing your data.



if you must do this..  be sure that the snmp agent is listing on something
that''s on it''s own vlan and has a non routable Ip address.
With today''s firewalls..  it would be very easy to setup a P2P link
between racks / datacenters which would allow your vm''s access to a
private network across datacenters.



________________________________
From: Matthew Law [matt@webcontracts.co.uk]
Sent: Friday, February 12, 2010 1:16 PM
To: Robbie A. Garrett
Cc: xen-users@lists.xensource.com
Subject: RE: [Xen-users] Dom U bandwidth monitoring - pmacct, bandwidthd?


On Fri, February 12, 2010 5:27 pm, Robbie A. Garrett
wrote:
> How would the switch know that traffic is for DomU or internet?
>
> this would have to be on a presence router / switch and track by ip
> address which I think is a bad idea.
Thanks, Robbie.

I''m interested to know why you think that''s a bad idea? - one
of the
solutions I was considering is to setup a SPAN port against the uplink on
each switch and use bandwidthd on that.  I have very little network
experience at this level, so I''m likely missing something (and
that''s the
main reason I decided to ask here as it is very likely others have been
here and learned the lessons).
> What I would suggest is that you allow there vm''s to be able to
use there
> own private network to move the data from one vm to another.  A lot of
> houses do it like this so they can let the customers who setup there
vm''s
> in a cluster have there cluster traffic bandwidth free.
Thanks.  Definitely an option being considered!

Cheers,

Matt.



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

Robbie,

Do you have or would you be willing to do a cookbook style write up of setting
up mrtg for this kind
of monitoring? I''ve been looking to do just this and grok the basics,
but haven''t found the time to
dig into the config syntax and such.

I little how-to would be greatly appreciated.

Z

Robbie A. Garrett wrote:
> My Company developed a method via mrtg.  Each vm has a vif name that
> means something within our tracking system.
>  
> an example of this would be user32.  On the Xen server, they have a vm
> called user32 and within the config file of the VM, there vif name is
> user32.  We set there MRTG files to pull data based on ''network
card
> name'' (in this case user32), and use rrd tool to store the
> information.   This makes it very easy to pull all historical data from
> vm''s.  When ever a vm moves, so does it''s .rrd file  thus
keeping all
> bandwidth traffic together.
>  
> This may not solve your issue or question...  but I would try barking up
> the mrtg tree to collect bandwidth totals.
>  
> ------------------------------------------------------------------------
> *From:* xen-users-bounces@lists.xensource.com
> [xen-users-bounces@lists.xensource.com] On Behalf Of Alaa eldin
> [sirash23@gmail.com]
> *Sent:* Friday, February 12, 2010 11:15 AM
> *To:* Fajar A. Nugraha
> *Cc:* matt@webcontracts.co.uk; xen-users@lists.xensource.com
> *Subject:* Re: [Xen-users] Dom U bandwidth monitoring - pmacct, bandwidthd?
> 
> every reboot this method " /proc/net/dev " start from zero
> 
> On Fri, Feb 12, 2010 at 11:11 AM, Fajar A. Nugraha <fajar@fajar.net
> <mailto:fajar@fajar.net>> wrote:
> 
>     On Fri, Feb 12, 2010 at 11:00 PM, Matthew Law
>     <matt@webcontracts.co.uk <mailto:matt@webcontracts.co.uk>>
wrote:
>     > I would prefer to do this at the egress point rather than run some
>     kind of
>     > accounting process on each dom0.
> 
>     Why? Will you be doing lots of domU moving?
>     The simplest method would be to give each domU a persistent vif name
>     and read their stats from /proc/net/dev
> 
>     --
>     Fajar
> 
>     _______________________________________________
>     Xen-users mailing list
>     Xen-users@lists.xensource.com
<mailto:Xen-users@lists.xensource.com>
>     http://lists.xensource.com/xen-users
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users

-- 
Zane Rockenbaugh
President, Liquid Labs LLC
www.liquid-labs.com

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

Sure!
The example below will collect information for a vm named Robbie and has a vif
name of Robbie

Install mrtg with rrd tool.
Make the necessary changes to the mrtg.cfg file to ensure it creates and stores
all data information into a RRD database.

in your mrtg.cfg file be sure to include a setting like below.
/*start
Include: /index.conf (where /index.conf is a location of this file).
/* end

index.conf should like something like below
/*start
Include: /Robbie.cfg #(where /Robbie.cfg is the full location of this file).
/* end

the Robbie.cfg will look like below
/*start
Target[Robbie]: \Robbie:SNMP-COMMUNITY-STRING@localhost:
SetEnv[Robbie]:MRTG_INT_IP="" MRTG_INT_DESCR=""
MaxBytes[Robbie]: 1250000
Title[Robbie]: Traffic Analysis for Robbie
/* end
________________________________________
From: Zane Rockenbaugh [zane@liquid-labs.com]
Sent: Saturday, February 13, 2010 1:49 AM
To: Robbie A. Garrett
Cc: Alaa eldin; Fajar A. Nugraha; matt@webcontracts.co.uk;
xen-users@lists.xensource.com
Subject: Re: [Xen-users] Dom U bandwidth monitoring - pmacct, bandwidthd?

Robbie,

Do you have or would you be willing to do a cookbook style write up of setting
up mrtg for this kind
of monitoring? I''ve been looking to do just this and grok the basics,
but haven''t found the time to
dig into the config syntax and such.

I little how-to would be greatly appreciated.

Z

Robbie A. Garrett wrote:
> My Company developed a method via mrtg.  Each vm has a vif name that
> means something within our tracking system.
>
> an example of this would be user32.  On the Xen server, they have a vm
> called user32 and within the config file of the VM, there vif name is
> user32.  We set there MRTG files to pull data based on ''network
card
> name'' (in this case user32), and use rrd tool to store the
> information.   This makes it very easy to pull all historical data from
> vm''s.  When ever a vm moves, so does it''s .rrd file  thus
keeping all
> bandwidth traffic together.
>
> This may not solve your issue or question...  but I would try barking up
> the mrtg tree to collect bandwidth totals.
>
> ------------------------------------------------------------------------
> *From:* xen-users-bounces@lists.xensource.com
> [xen-users-bounces@lists.xensource.com] On Behalf Of Alaa eldin
> [sirash23@gmail.com]
> *Sent:* Friday, February 12, 2010 11:15 AM
> *To:* Fajar A. Nugraha
> *Cc:* matt@webcontracts.co.uk; xen-users@lists.xensource.com
> *Subject:* Re: [Xen-users] Dom U bandwidth monitoring - pmacct, bandwidthd?
>
> every reboot this method " /proc/net/dev " start from zero
>
> On Fri, Feb 12, 2010 at 11:11 AM, Fajar A. Nugraha <fajar@fajar.net
> <mailto:fajar@fajar.net>> wrote:
>
>     On Fri, Feb 12, 2010 at 11:00 PM, Matthew Law
>     <matt@webcontracts.co.uk <mailto:matt@webcontracts.co.uk>>
wrote:
>     > I would prefer to do this at the egress point rather than run some
>     kind of
>     > accounting process on each dom0.
>
>     Why? Will you be doing lots of domU moving?
>     The simplest method would be to give each domU a persistent vif name
>     and read their stats from /proc/net/dev
>
>     --
>     Fajar
>
>     _______________________________________________
>     Xen-users mailing list
>     Xen-users@lists.xensource.com
<mailto:Xen-users@lists.xensource.com>
>     http://lists.xensource.com/xen-users
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users

--
Zane Rockenbaugh
President, Liquid Labs LLC
www.liquid-labs.com
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users