<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>The Storage Architect &#187; Wide Striping</title>
	<atom:link href="http://thestoragearchitect.com/tag/wide-striping/feed/" rel="self" type="application/rss+xml" />
	<link>http://thestoragearchitect.com</link>
	<description>Storage, Virtualisation &#38; Cloud</description>
	<lastBuildDate>Wed, 23 May 2012 22:20:49 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>Enterprise Computing: The Benefits of Wide Striping &#8211; Avoiding A Long Tail</title>
		<link>http://thestoragearchitect.com/2010/03/18/enterprise-computing-the-benefits-of-wide-striping-avoiding-a-long-tail/</link>
		<comments>http://thestoragearchitect.com/2010/03/18/enterprise-computing-the-benefits-of-wide-striping-avoiding-a-long-tail/#comments</comments>
		<pubDate>Thu, 18 Mar 2010 22:12:15 +0000</pubDate>
		<dc:creator>Chris M Evans</dc:creator>
				<category><![CDATA[Featured]]></category>
		<category><![CDATA[GestaltIT]]></category>
		<category><![CDATA[Long Tail]]></category>
		<category><![CDATA[Wide Striping]]></category>
		<category><![CDATA[xiv]]></category>

		<guid isPermaLink="false">http://www.thestoragearchitect.com/?p=1268</guid>
		<description><![CDATA[<p>I took part in a podcast last night that discussed the XIV platform.  One of the &#8220;key features&#8221; of XIV is the wide striping of data across all spindles.  It&#8217;s a concept we&#8217;re seeing more and more in contemporary storage hardware architectures and one that&#8217;s being shoe-horned into older storage arrays too.  Have you ever [...]<!--Begin ClixTrac.com Rotator Code -->
<script type="text/javascript" language="javascript" src="http://www.clixtrac.com/rotate/321"></script>
<!--End ClixTrac.com Rotator Code -->]]></description>
			<content:encoded><![CDATA[<div id="attachment_1270" class="wp-caption alignleft" style="width: 310px"><a href="http://31.222.189.99/wp-content/uploads/2010/03/StackedIOPS.jpg" ><img class="size-medium wp-image-1270" title="Stacked IOPS" src="http://50.57.85.110/wp-content/uploads/2010/03/StackedIOPS-300x196.jpg" alt="IOPS Per RAID Group, ordered by most to least" width="300" height="196" /></a><p class="wp-caption-text">IOPS Per RAID Group, ordered by most to least</p></div>
<p>I took part in a podcast last night that discussed the XIV platform.  One of the &#8220;key features&#8221; of XIV is the wide striping of data across all spindles.  It&#8217;s a concept we&#8217;re seeing more and more in contemporary storage hardware architectures and one that&#8217;s being shoe-horned into older storage arrays too.  Have you ever wondered what the point is?  Take a look at the following graphic.  It shows the number of write operations per RAID group, ordered by the busiest RAID group to the least active.  It&#8217;s real data from a real system.  What you see is the <a rel="nofollow" href="http://en.wikipedia.org/wiki/Long_Tail" >Long Tail</a> effect, where a small number of RAID groups are doing most of the I/O.  In this example, 80% of the workload is performed by 50% of the RAID groups; only 3 RAID groups account for 20% of the workload.</p>
<p>The chart shows that in some array designs (typically the older Enterprise arrays), I/O distribution was not evenly balanced and so not all drives were being used to their full capacity.  This was mitigated by using tools to move LUNs or sub-LUNs around; alternatively concatenated devices like metas and LUSEs were employed to spread the load.</p>
<p>The only real solution to the I/O balancing problem is genuine wide striping.  Manual or even automated rebalancing, or the use of metas are just workarounds.  Once wide striping is in place, either more work can be performed or the number of spindles or their &#8220;quality&#8221; can be reduced, i.e. you can build a complete SATA array like XIV.</p>
<p>There are of course disadvantages to having your data more widely spread.  The most obvious is the increased risk of data loss when the RAID system fails &#8211; i.e. a double disk failure.  The wider the striping, the wider the impact.  The tradeoff is the benefit of increased performance.  You have to choose what level of risk/impact you consider acceptable versus the potential gains.</p>
<p>If you&#8217;re not doing wide striping today then you should seriously be considering it.  After all, you&#8217;re only harnessing performance capacity within the array that you&#8217;ve already paid for.</p>
]]></content:encoded>
			<wfw:commentRss>http://thestoragearchitect.com/2010/03/18/enterprise-computing-the-benefits-of-wide-striping-avoiding-a-long-tail/feed/</wfw:commentRss>
		<slash:comments>11</slash:comments>
		</item>
		<item>
		<title>Enterprise Computing: Run My Storage At 60%?  No Way!</title>
		<link>http://thestoragearchitect.com/2010/03/17/enterprise-computing-run-my-storage-at-60-no-way/</link>
		<comments>http://thestoragearchitect.com/2010/03/17/enterprise-computing-run-my-storage-at-60-no-way/#comments</comments>
		<pubDate>Wed, 17 Mar 2010 19:52:53 +0000</pubDate>
		<dc:creator>Chris M Evans</dc:creator>
				<category><![CDATA[Featured]]></category>
		<category><![CDATA[dynamic provisioning]]></category>
		<category><![CDATA[Hu Yoshida]]></category>
		<category><![CDATA[thin provisioning]]></category>
		<category><![CDATA[Wide Striping]]></category>

		<guid isPermaLink="false">http://www.thestoragearchitect.com/?p=1261</guid>
		<description><![CDATA[<p>Hu Yoshida has an interesting view on his <a href="http://blogs.hds.com/hu/2010/03/how-do-you-increase-storage-utilization.html" >recent post</a> discussing storage utilisation rates.  His concluding remark suggests running at a maximum of 60% utilisation &#8211; even with Dynamic Provisioning.  Hu, you must be joking, right?</p> <p>Point 1: I&#8217;ve paid for my 100% of storage and I&#8217;m going to use it.  I don&#8217;t [...]<!--Begin ClixTrac.com Rotator Code -->
<script type="text/javascript" language="javascript" src="http://www.clixtrac.com/rotate/321"></script>
<!--End ClixTrac.com Rotator Code -->]]></description>
			<content:encoded><![CDATA[<p>Hu Yoshida has an interesting view on his <a href="http://blogs.hds.com/hu/2010/03/how-do-you-increase-storage-utilization.html" >recent post</a> discussing storage utilisation rates.  His concluding remark suggests running at a maximum of 60% utilisation &#8211; even with Dynamic Provisioning.  Hu, you must be joking, right?</p>
<p><strong>Point 1:</strong> I&#8217;ve paid for my 100% of storage and I&#8217;m going to use it.  I don&#8217;t remember any vendor suggesting only paying 60% of their invoice and calling it quits.  Granted, spending an inordinate amount of time to reach the 80%+ goal isn&#8217;t necessarily cost effective, however it can be achieved.</p>
<p><strong>Point 2:</strong> It&#8217;s perfectly possible to run at 80% utilisation.  It just takes some thought and planning.  As Hu rightly points out, Dynamic Provisioning helps significantly towards this.  The features of wide striping and thin provisioning mean storage can be more easily provisioned and requires less manual balancing.</p>
<p><strong>Point 3: </strong> Achieving high utilisation isn&#8217;t all about technology.  It&#8217;s also about process.  That means Demand Planning, Capacity Planning, efficient processes for deployment of new hardware and for provisioning of customer requests.  All this is possible without incurring additional expense.</p>
<p>So, don&#8217;t think 80%+ isn&#8217;t an achievable target.  After all, it&#8217;s your money you&#8217;re wasting if you don&#8217;t try!</p>
]]></content:encoded>
			<wfw:commentRss>http://thestoragearchitect.com/2010/03/17/enterprise-computing-run-my-storage-at-60-no-way/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>Enterprise Computing: The Wide Striping Debate</title>
		<link>http://thestoragearchitect.com/2009/07/12/enterprise-computing-the-wide-striping-debate/</link>
		<comments>http://thestoragearchitect.com/2009/07/12/enterprise-computing-the-wide-striping-debate/#comments</comments>
		<pubDate>Sun, 12 Jul 2009 11:17:47 +0000</pubDate>
		<dc:creator>Chris M Evans</dc:creator>
				<category><![CDATA[GestaltIT]]></category>
		<category><![CDATA[Virtualisation]]></category>
		<category><![CDATA[EMC]]></category>
		<category><![CDATA[HDS]]></category>
		<category><![CDATA[Hu Yoshida]]></category>
		<category><![CDATA[Martin Glasborow]]></category>
		<category><![CDATA[storagebod]]></category>
		<category><![CDATA[Switch It On]]></category>
		<category><![CDATA[thin provisioning]]></category>
		<category><![CDATA[Wide Striping]]></category>

		<guid isPermaLink="false">http://thestoragearchitect.com/?p=638</guid>
		<description><![CDATA[<p>I&#8217;ve read with interest this week the posts on wide striping and the consequent expansion to thin provisioning.  Here are some of the highlights:</p> <p>First there&#8217;s Martin Glasborow&#8217;s <a rel="nofollow" href="http://storagebod.typepad.com/storagebods_blog/2009/07/wide-stripes.html" >post</a>, which discusses whether wide striping and thin provisioning should be chargeable items.  I&#8217;d go a step further than Martin and suggest that thin [...]<!--Begin ClixTrac.com Rotator Code -->
<script type="text/javascript" language="javascript" src="http://www.clixtrac.com/rotate/321"></script>
<!--End ClixTrac.com Rotator Code -->]]></description>
			<content:encoded><![CDATA[<p>I&#8217;ve read with interest this week the posts on <strong>wide striping</strong> and the consequent expansion to <strong>thin provisioning</strong>.  Here are some of the highlights:</p>
<p>First there&#8217;s Martin Glasborow&#8217;s <a rel="nofollow" href="http://storagebod.typepad.com/storagebods_blog/2009/07/wide-stripes.html" >post</a>, which discusses whether wide striping and thin provisioning should be chargeable items.  I&#8217;d go a step further than Martin and suggest that thin provisioning (TP) should also be free; after all, over time thin provisioning becomes fat provisioning without some kind of reclaim technology and there&#8217;s only value to TP with something like Zero Page Reclaim to get back those unused blocks.</p>
<p>Then there&#8217;s Hu Yoshida&#8217;s <a href="http://blogs.hds.com/hu/2009/07/overheads-for-thin-provisioning.html" >post</a> referring to the Overheads of Thin Provisioning.  In it, Hu makes a very interesting claim that wide striped LUNs have <em>&#8220;greater protection from multiple disk failures&#8221;</em>.  On this point I have to <strong>disagree</strong>.  Firstly, if a disk fails within a RAID group, then the impact on a LUN is only experienced if the subsequent failure is also in the same RAID group.  <em>This is a fact whether then LUN is wide striped or not</em>.  For wide striped LUNs which are spread across multiple RAID groups, there&#8217;s <strong>more</strong> chance of a failure because a double disk failure could occur within <strong>any</strong> of the RAID groups supporting the presentation of that LUN.</p>
<p>In addition, wide striping has more <strong>impact</strong> if a failure occurs.  One benefit of having LUNs created from a single RAID group is that the impact of that RAID group failing is limited to only those LUNs.  Imagine a 300GB 3+1 RAID group divided into 18x 50GB LUNs.  Failure of that RAID group impacts only the 18 LUNs.  So, wide stripe across 10 RAID groups &#8211; now the impact of <strong>any</strong> RAID group failure is <strong>180</strong> LUNs.  Remember that&#8217;s <strong>any</strong> RAID group failure, which is much more likely as we have more RAID groups on which every LUN is dependent.</p>
<p>Finally there&#8217;s EMC and their free Virtual Provisioning &#8211; free that is on <strong>new</strong> purchases, not existing DMX-4 deployments.  While laudible, this offering is less generous compared to <a href="http://www.hds.com/go/free-storage-virtualization/" >HDS&#8217; Switch It On</a> promotion which offers free UVM, Dynamic Provisioning (first 10TB only) and Tiered Storage Manager on <strong>existing</strong> USP-V deployments.  </p>
<p>Wide striping and thin provisioning are clearly becoming features where vendors are looking to differentiate their products.  This must be vindication for the likes of 3Par who&#8217;ve had these features from day 1.</p>
<p>P.S.  You can find two EMC blogger references to the free Virtual Provisioning <a rel="nofollow" href="http://thestorageanarchist.typepad.com/weblog/2009/07/2015-challenge-accepted-free-vp.html" >here</a> and <a rel="nofollow" href="http://storagezilla.typepad.com/storagezilla/2009/07/virtual-provisioning-for-symm-included-at-no-extra-charge.html" >here</a>.</p>
]]></content:encoded>
			<wfw:commentRss>http://thestoragearchitect.com/2009/07/12/enterprise-computing-the-wide-striping-debate/feed/</wfw:commentRss>
		<slash:comments>12</slash:comments>
		</item>
	</channel>
</rss>

