[collectd] [PATCH] New plugin - lpar

[Florian Forster]

Hi Aurélien,

sorry for the late reply :/

On Fri, Aug 20, 2010 at 12:47:58AM +0200, Aurélien Reynaud wrote:
> LPARs (Logical Partitions) and WPARs (Workload Partitions) are indeed
> similar as they are both virtualization techniques. Please note that
> I'm not familiar with WPARs, so I may be somewhat mistaken in my
> comparison.
> […]
> IMHO these concepts are different enough to warrant separate plugins.

Yes, I agree fully.

> As an example, imagine an IBM power system with 16 CPUs. […]

Thanks for the explanation, it helped greatly in understanding what your
plugin does :)

> >   * You are calculating the time difference yourself and calculating
> >     a rate from that. I'd prefer to use a DERIVE or COUNTER data
> >     source […]
> 
> Well, I find using a counter/derive more elegant myself. I just fail
> to understand how it can work. The original counters are expressed in
> 'processor time spent in xxx mode' where time is not in seconds but in
> custom cpu-clock dependent 'ticks'.

That's correct and is the same for other systems, for example Linux.
That's why we collect CPU usage in "jiffies", the Linux term for "ticks
per second". The question ("Why don't the rates add up to 100?") has
been asked a lot, so there's an extensive FAQ entry about this at
<http://collectd.org/faq.shtml#faq:cpu_jiffies>

> If I'm not mistaken, using the raw counters the graphs will show cpu
> usage scaled by a factor of 'ticks_per_second' which we cannot
> compensate for as this value isn't known outside the host running the
> plugin.

Many people expect the CPU usage to be in percent. You can easily
calculate that in the front-end as

  percent busy = 100.0 * busy / (busy + idle + <other states>)

For this to work, you'll need to track the time assigned to a different
partition and report that as a separate state. For example (assuming
only "busy" and "idle" states for brevity):

  time_diff = now  - time_old;
  busy_diff = busy - busy_old;
  idle_diff = idle - idle_old;
  /* unav == unavailable */
  unav_diff = (entitled_per_second * time_diff) - (busy_diff + idle_diff);
  unav_counter += unav_diff;
  *_old = *;

I'm not sure if and how the calculation needs to be modified if that
"donate_flag" is set. I could imagine that in this case all processor
ticks are accounted for and we wouldn't need to do any of the above.

> As shown in the example above, entitlement is the processor capacity
> each LPAR gets allocated by the hypervisor for its use. Once set, it
> does not change but it can be dynamically adjusted by the admin to
> meet workload changes. I find it useful to have both cpu usage and
> entitlement on graphs: this allows to tell at a glance whether the cpu
> resource are sufficent or overkill at a given time.

It makes sense with your explanation above. I'd track it in the way
described above, though, i.e. in terms of "processor ticks not available
to the partition" rather than in it's absolute form. Does that make
sense to you?

> >   * Why do you use the chassis serial number as plugin instance? […]
> 
> You're right, there is a secret purpose to this. ;-)
> I would like to graph the total cpu usage of the chassis itself, by
> adding up the individual metrics of each participating LPAR. But there
> is no static list of LPARs since they can be moved across chassis'.
> So I need to know which rrd's are to be considered when graphing a
> given chassis.

I see, that makes sense. Though I would imagine that a user (i.e. not a
sysadmin) cares more about a partition than a cassis, so I think it'd
make sense to allow for both scenarios.

> Another possibility would be a config option like "ReportByChassis =
> true" which would tell the plugin to use the chassis's serial instead
> of the hostname.

I think the "ReportBySerial" configuration option you have implemented
in the meantime is exactly what I had in mind ;)

> >   * What's this code doing?:
> 
> […]
> After all, who am I to argue with IBM coders ?

"IBM guys do it like this" is good enough an explanation for me ;)
Either there is no difference at all (i.e. we don't lose) or there's
some subtle difference we don't know about (i.e. we win ;).

Regards,
—octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x0C705A15
http://octo.it/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Digital signature
URL: <http://mailman.verplant.org/pipermail/collectd/attachments/20100903/85549d67/attachment.pgp>