<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Kommentare zu: NetApp Performance-Counter</title>
	<atom:link href="http://blog.netapp-monitoring.info/2009/11/30/netapp-performance-counter/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.netapp-monitoring.info/2009/11/30/netapp-performance-counter/</link>
	<description>Überwachen von NetApp Geräten</description>
	<lastBuildDate>Mon, 06 Dec 2010 12:04:22 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>Von: current netapp</title>
		<link>http://blog.netapp-monitoring.info/2009/11/30/netapp-performance-counter/#comment-4</link>
		<dc:creator><![CDATA[current netapp]]></dc:creator>
		<pubDate>Fri, 19 Feb 2010 07:55:48 +0000</pubDate>
		<guid isPermaLink="false">http://blog.netapp-monitoring.info/?p=77#comment-4</guid>
		<description><![CDATA[(privates reply)

In diesem Zusammenhang bietet sich auch an, die Histogram-Counter des Filers direkt auszuwerten. Diese sind leider nicht für alle Objekte und alle Instances in der gleichen Tiefe verfügbar.

Allerdings kann man damit zB eine tail-heavy IO Last relativ rasch erkennen, und als zusätzliche Dimension in die Kapazitätsplanung mit aufnehmen.

Histogramme sind verfügbar

für jede Backend Disk (LUN bei V-Series)
für jede LUN (Frontend), getrennt nach lese/schreib IOs
für jedes &quot;professionelle&quot; Protokoll (NFS, FCP, iSCSI)
für jedes Volume
für jedes IP-Interface (Frame-Size)
für Raid 
für die system-CPU / Last

Allerdings sind noch nicht alle Histogramme via CM verfügbar...

Die Auswertung dieser Histogramme kann jedoch zB einen Netwisdom (FCP protokoll performance Analyser) teilweise überflüssig machen (legacy arrays liefern diese Daten meist einfach nicht).]]></description>
		<content:encoded><![CDATA[<p>(privates reply)</p>
<p>In diesem Zusammenhang bietet sich auch an, die Histogram-Counter des Filers direkt auszuwerten. Diese sind leider nicht für alle Objekte und alle Instances in der gleichen Tiefe verfügbar.</p>
<p>Allerdings kann man damit zB eine tail-heavy IO Last relativ rasch erkennen, und als zusätzliche Dimension in die Kapazitätsplanung mit aufnehmen.</p>
<p>Histogramme sind verfügbar</p>
<p>für jede Backend Disk (LUN bei V-Series)<br />
für jede LUN (Frontend), getrennt nach lese/schreib IOs<br />
für jedes &#8222;professionelle&#8220; Protokoll (NFS, FCP, iSCSI)<br />
für jedes Volume<br />
für jedes IP-Interface (Frame-Size)<br />
für Raid<br />
für die system-CPU / Last</p>
<p>Allerdings sind noch nicht alle Histogramme via CM verfügbar&#8230;</p>
<p>Die Auswertung dieser Histogramme kann jedoch zB einen Netwisdom (FCP protokoll performance Analyser) teilweise überflüssig machen (legacy arrays liefern diese Daten meist einfach nicht).</p>
]]></content:encoded>
	</item>
</channel>
</rss>

