<?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; UVM</title>
	<atom:link href="http://thestoragearchitect.com/tag/uvm/feed/" rel="self" type="application/rss+xml" />
	<link>http://thestoragearchitect.com</link>
	<description>Storage, Virtualisation &#38; Cloud</description>
	<lastBuildDate>Tue, 07 Feb 2012 10:08:05 +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: What Next For Virtualisation?</title>
		<link>http://thestoragearchitect.com/2009/09/15/enterprise-computing-what-next-for-virtualisation/</link>
		<comments>http://thestoragearchitect.com/2009/09/15/enterprise-computing-what-next-for-virtualisation/#comments</comments>
		<pubDate>Tue, 15 Sep 2009 20:50:55 +0000</pubDate>
		<dc:creator>Chris M Evans</dc:creator>
				<category><![CDATA[GestaltIT]]></category>
		<category><![CDATA[barry whyte]]></category>
		<category><![CDATA[Hursley]]></category>
		<category><![CDATA[incipient]]></category>
		<category><![CDATA[iNSP]]></category>
		<category><![CDATA[Invista]]></category>
		<category><![CDATA[SAN]]></category>
		<category><![CDATA[svc]]></category>
		<category><![CDATA[UVM]]></category>
		<category><![CDATA[Virtualisation]]></category>

		<guid isPermaLink="false">http://thestoragearchitect.com/?p=732</guid>
		<description><![CDATA[<p><a rel="nofollow" href="http://thestoragearchitect.files.wordpress.com/2009/09/svcstack1.png" ></a>Earlier this month, <a href="http://www.ramsan.com/default.htm" >Texas Memory Systems</a> <a href="http://www.ramsan.com/pressrelease/2009-09-08.htm" >announced</a> they had acquired the intellectual assets of <a href="http://www.incipient.com/" >Incipient</a>, a company that produced SAN virtualisation hardware and software.  With Incipient gone, EMC hardly bothering to mention <a href="http://uk.emc.com/products/detail/software/invista.htm" >Invista</a>, what is the future of SAN LUN virtualisation? </p> <p>I talked about Incipient last [...]<!--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><a rel="nofollow" href="http://thestoragearchitect.files.wordpress.com/2009/09/svcstack1.png" ></a>Earlier this month, <a href="http://www.ramsan.com/default.htm" >Texas Memory Systems</a> <a href="http://www.ramsan.com/pressrelease/2009-09-08.htm" >announced</a> they had acquired the intellectual assets of <a href="http://www.incipient.com/" >Incipient</a>, a company that produced <strong>SAN virtualisation</strong> hardware and software.  With Incipient gone, EMC hardly bothering to mention <a href="http://uk.emc.com/products/detail/software/invista.htm" >Invista</a>, what is the future of SAN LUN virtualisation? </p>
<p>I talked about Incipient last year, <a href="http://thestoragearchitect.com/2008/06/12/storage-migration-costs/" >here</a> and <a href="http://thestoragearchitect.com/2008/06/23/incipient-revisited/" >here</a> when discussing the costs of performing migrations.  As I said at the time, I couldn&#8217;t see how much of a saving deploying their <strong>iNSP</strong> would bring to the burdensome migration work we all have to manage on an ongoing basis.  So there&#8217;s got to be a more compelling benefit out there for using virtualisation products.  If there is, then what is it?</p>
<p>Excluding the defunct <strong>Invista</strong>, that leaves Hitachi with <strong>Universal Volume Manager </strong>(UVM) and IBM with <strong>SAN Volume Controller </strong>(SVC) still in the market place.    From experience, I know UVM is a great product and surprise, I&#8217;ve commented on that recently too especially <a href="http://thestoragearchitect.com/2009/04/22/enterprise-computing-hds-switches-on-virtualisation-for-free/" >here</a>where I reference the fact that Hitachi are offering UVM for free.  Clearly, the drawback to UVM is that it is integrated into the array itself.  When the <strong>NSC55 </strong>first came out, I heard rumours that it may be a diskless virtualisation &#8220;head&#8221; and although it can be deployed in that way, it isn&#8217;t sold as that.  If Hitachi decided offer the USP VM or its successor as a diskless virtualisation controller, it would put them squarely in competition with SVC from IBM.</p>
<p>Earlier this year I was fortunate to have an invitation to meet <strong>Barry Whyte</strong>, &#8220;Master Inventor&#8221; and Performance Architect on the SVC product.  You can find Barry&#8217;s blog <a href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/storagevirtualization/" >here</a>if you&#8217;re already not subscribed to it.  I highly recommend it especially for understanding the in&#8217;s and out&#8217;s of the SVC itself.  During my trip I got to see some of the hardware used to do interoperability testing of SVC &#8211; with storage it virtualises as well as servers it connects to.  It&#8217;s by no means a trivial task; there are 80 people in Hursley alone, working on development and testing of the product as well as a further 64 scattered around the globe.  Obviously virtualising storage is a complex business and requires huge amounts of testing.  I&#8217;d go as far as suggesting that the testing takes way more cycles than writing the code itself.</p>
<p> 
<a href='http://thestoragearchitect.com/2009/09/15/enterprise-computing-what-next-for-virtualisation/svcstack/' title='SVCstack'><img width="150" height="112" src="http://thestoragearchitect.com/wp-content/uploads/2009/09/svcstack1.png" class="attachment-thumbnail" alt="SVC I/O Stack - copyright (c) IBM Corporation 2008" title="SVCstack" /></a>
</p>
<p>What&#8217;s all this got to do with the future of virtualisation?  Well, I think it highlights what a <strong>complex process</strong> it is.  Even though standards for interoperability exist, IBM (and presumably Hitachi, EMC and at one time Incipient) have to deal with complex interoperability issues and interleave that with additional features and functionality whilst guaranteeing <strong>data integrity</strong>.  The slide taken from an SVC presentation deck gives you an idea of what&#8217;s involved.  Thanks to Barry for permission to reproduce this.</p>
<p>Both Hitachi and IBM have been successful with a virtualisation product that doesn&#8217;t sit within the SAN fabric itself.  This seems to me to be counter-intuitive as I&#8217;ve always thought the fabric was the right place for virtualisation.  After all, every I/O leaving a host hits the fabric first and this naturally becomes the best place to route the I/O to its final destination, whether or not that is a &#8220;real&#8221; LUN or one created from a virtualisation product. </p>
<p>Perhaps SAN fabric virtualisation was simply too complex and costly to deploy.  After all, recent history has told us that <strong>paying </strong>for a fabric-based virtualisation product is a non-starter otherwise we&#8217;d see more Invista and iNSP.  Perhaps fabric-based virtualisation didn&#8217;t provide the feature set that mature IT organisations required from the technology.  Either way, virtualisation in the fabric needs a rethink.  Maybe FCoE provides/provided that opportunity?</p>
]]></content:encoded>
			<wfw:commentRss>http://thestoragearchitect.com/2009/09/15/enterprise-computing-what-next-for-virtualisation/feed/</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
		<item>
		<title>LUN Stacker</title>
		<link>http://thestoragearchitect.com/2008/11/04/lun-stacker/</link>
		<comments>http://thestoragearchitect.com/2008/11/04/lun-stacker/#comments</comments>
		<pubDate>Tue, 04 Nov 2008 13:00:00 +0000</pubDate>
		<dc:creator>Chris M Evans</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[FAT]]></category>
		<category><![CDATA[LUN consolidation]]></category>
		<category><![CDATA[MFT]]></category>
		<category><![CDATA[NTFS]]></category>
		<category><![CDATA[stacker]]></category>
		<category><![CDATA[svc]]></category>
		<category><![CDATA[UVM]]></category>

		<guid isPermaLink="false">http://thestoragearchitect.wordpress.com/2008/11/04/lun-stacker/</guid>
		<description><![CDATA[<p>A <a rel="nofollow" href="http://storagebod.typepad.com/storagebods_blog/2008/10/a-stacked-feature-request.html" >recent post</a> from Martin &#8220;The Bod&#8221; Glassborow got me thinking about the whole process of LUN consolidation. I&#8217;ve done lots of migrations where people quake at the thought of changing the LUN size from one array to another. Now, I almost always want to change LUN sizes, as the vendor specific [...]<!--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>A <a rel="nofollow" href="http://storagebod.typepad.com/storagebods_blog/2008/10/a-stacked-feature-request.html" >recent post</a> from Martin &#8220;The Bod&#8221; Glassborow got me thinking about the whole process of LUN consolidation. I&#8217;ve done lots of migrations where people quake at the thought of changing the LUN size from one array to another. Now, I almost always want to change LUN sizes, as the vendor specific ones &#8211; 8.43GB/13.59GB etc are pretty painful and wasteful at the same time.</p>
<p>There&#8217;s another good reason to standardise on LUNs. If you&#8217;ve implemented a good dual-vendor strategy and sorted your firmware driver stack out, then you can position to take storage from any of your preferred vendors. There&#8217;s nothing better than having all of your vendors sweating on that next 500TB purchase when they know you take your storage from either or EMC/HDS/HP/IBM.</p>
<p>If LUNs and the I/O stack are all standardised, you can move data around too. The difficult part as alluded to in Martin&#8217;s post is achieving the restacking of data.</p>
<p><a rel="nofollow" href="http://4.bp.blogspot.com/_b1B7GuxiR0o/SRBSWMGJjlI/AAAAAAAAAGg/kFxK7hRVCTE/s1600-h/Stacker+-+4-11-08+-+1.jpg" ><img style="float:right;width:320px;cursor:hand;height:181px;margin:0 0 10px 10px;" alt="" src="http://4.bp.blogspot.com/_b1B7GuxiR0o/SRBSWMGJjlI/AAAAAAAAAGg/kFxK7hRVCTE/s320/Stacker+-+4-11-08+-+1.jpg" border="0" /></a></p>
<p>Here&#8217;s the problem; SAN storage is inherently block based and the underlying hardware has no idea of how you will lay out your data. Have a look at the following diagram. Each LUN from a SAN perspective is divided into blocks and each block has a logical block address. The array just services requests from the host for a block of data and reads/writes it on demand. It is the operating system which determines how the file system should be laid out on the underlying storage. Each volume will have a standard location (or standard method of calculating the location) for what was called the VTOC (Volume Table of Contents), also known as the FAT (File Allocation Table) in DOS and MFT (Master File Table) in NTFS. There are similar constructs for other O/S versions like Linux but I&#8217;m not 100% certain of the terminology so won&#8217;t risk the rath of getting it wrong.</p>
<p>The layout of data on a file system is not a trivial task. Apart from keeping track of files, there&#8217;s the requirement to keep track of free space and to be able to recreate the file index in the case of corruption, so some kind of journalling is likely to be implemented. There are also features such as compression, Single Instancing, Encryption, etc which all add to the mix of understanding exactly how file data is laid out on disk.</p>
<p><a rel="nofollow" href="http://4.bp.blogspot.com/_b1B7GuxiR0o/SRBW-ENJzSI/AAAAAAAAAGo/w-bsTXUSRlY/s1600-h/Stacker+-+4-11-08+-+2.jpg" ><img style="float:right;width:320px;cursor:hand;height:153px;margin:0 0 10px 10px;" alt="" src="http://4.bp.blogspot.com/_b1B7GuxiR0o/SRBW-ENJzSI/AAAAAAAAAGo/w-bsTXUSRlY/s320/Stacker+-+4-11-08+-+2.jpg" border="0" /></a>Now think of how multiple LUNs are currently connected together. This will be achieved with either a Volume Manager (like <a rel="nofollow" href="http://en.wikipedia.org/wiki/Veritas_Volume_Manager" >VxVM</a>), supplied as a separate product, or a native LVM (logical volume manager). All of these tools will spread the &#8220;logical&#8221; volume across multiple LUNs and will format the LUN with information to enable the volume to be recreated if the LUNs are moved to another host. VxVM achieves this by having a private area on each LUN which contains metadata to rebuild the logical volume. Each LUN can be divided into sub-disks and then recombined into a logical volume, as shown in this diagram.</p>
<p>So a physical LUN from an array may contain a whole or partial segment of a host volume, including LVM metadata.  Determining what part, whether all the parts are on this array (and where) is a tricky task &#8211; and we&#8217;re expecting that the transmission protocol (i.e. the fabric) can determine all of this information &#8220;on the fly&#8221; as it were.</p>
<p>My thought would be &#8211; why bother with a fabric-based consolidation tool? Products like VxVM provide a wide set of commands for volume migration, although not automated they certainly make the migration task more simple. I&#8217;ve seen some horrendous VxVM implementations, which would require some pretty impressive logic to be developed in order to understand how to deconstruct and reconstruct a volume.  However life is not that simple, and host-based migrations aren&#8217;t always easy to execute on, so potentially a product would be commercially viable, even if the first implementation was an offline version which couldn&#8217;t cope with host I/O at the same time.  </p>
<p>Funny, what&#8217;s required sounds a bit like a virtualisation product &#8211; perhaps the essence of this is already coded in SVC, UVM or Incipient?</p>
<div class="blogger-post-footer">
<p>_uacct = &#8220;UA-1104321-2&#8243;;<br />
urchinTracker();
</p></div>
]]></content:encoded>
			<wfw:commentRss>http://thestoragearchitect.com/2008/11/04/lun-stacker/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
	</channel>
</rss>

