<?xml version='1.0' encoding='UTF-8'?><?xml-stylesheet href="http://www.blogger.com/styles/atom.css" type="text/css"?><feed xmlns='http://www.w3.org/2005/Atom' xmlns:openSearch='http://a9.com/-/spec/opensearchrss/1.0/' xmlns:blogger='http://schemas.google.com/blogger/2008' xmlns:georss='http://www.georss.org/georss' xmlns:gd="http://schemas.google.com/g/2005" xmlns:thr='http://purl.org/syndication/thread/1.0'><id>tag:blogger.com,1999:blog-6079288930441486118</id><updated>2024-09-14T11:54:34.759-04:00</updated><title type='text'>Storage Pimpin Aint Easy</title><subtitle type='html'></subtitle><link rel='http://schemas.google.com/g/2005#feed' type='application/atom+xml' href='http://storagepimp.blogspot.com/feeds/posts/default'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/6079288930441486118/posts/default?redirect=false'/><link rel='alternate' type='text/html' href='http://storagepimp.blogspot.com/'/><link rel='hub' href='http://pubsubhubbub.appspot.com/'/><author><name>Storage Pimp</name><uri>http://www.blogger.com/profile/15618336561722762678</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='https://img1.blogblog.com/img/b16-rounded.gif'/></author><generator version='7.00' uri='http://www.blogger.com'>Blogger</generator><openSearch:totalResults>3</openSearch:totalResults><openSearch:startIndex>1</openSearch:startIndex><openSearch:itemsPerPage>25</openSearch:itemsPerPage><entry><id>tag:blogger.com,1999:blog-6079288930441486118.post-3102489734826268924</id><published>2009-04-16T22:55:00.004-04:00</published><updated>2009-04-16T23:31:05.692-04:00</updated><title type='text'>Storage Vs. Server Virtualization</title><content type='html'>The number one reason companies &lt;span class=&quot;blsp-spelling-corrected&quot; id=&quot;SPELLING_ERROR_0&quot;&gt;rolled&lt;/span&gt; out server &lt;span class=&quot;blsp-spelling-error&quot; id=&quot;SPELLING_ERROR_1&quot;&gt;virtualization&lt;/span&gt; was for consolidation. This was accomplished years ago in the storage world. Does this mean storage has been &lt;span class=&quot;blsp-spelling-error&quot; id=&quot;SPELLING_ERROR_2&quot;&gt;virtualized&lt;/span&gt; for years, and we just &lt;span class=&quot;blsp-spelling-corrected&quot; id=&quot;SPELLING_ERROR_3&quot;&gt;didn&#39;t&lt;/span&gt; use the buzz world properly? A new push behind server &lt;span class=&quot;blsp-spelling-error&quot; id=&quot;SPELLING_ERROR_4&quot;&gt;virtualization&lt;/span&gt; is the ability to move an entire entity from one piece of physical hardware to another with little or no downtime. &lt;span class=&quot;blsp-spelling-error&quot; id=&quot;SPELLING_ERROR_5&quot;&gt;VMware&lt;/span&gt; has &lt;span class=&quot;blsp-spelling-error&quot; id=&quot;SPELLING_ERROR_6&quot;&gt;Vmotion&lt;/span&gt; which can move virtual machines between physical servers within a single infrastructure. This feature is valuable for maintenance of a single physical server. However it does not fully address migrations, tech refreshes, data center strategies, and etc. Storage is in a &lt;span class=&quot;blsp-spelling-corrected&quot; id=&quot;SPELLING_ERROR_7&quot;&gt;similar&lt;/span&gt; spot. Several &lt;span class=&quot;blsp-spelling-error&quot; id=&quot;SPELLING_ERROR_8&quot;&gt;virtualization&lt;/span&gt; engines allow you to move &lt;span class=&quot;blsp-spelling-error&quot; id=&quot;SPELLING_ERROR_9&quot;&gt;luns&lt;/span&gt; between hardware sitting within or behind these pieces of hardware. However there are too many physical limitations for this to allow an entire enterprise environment to be &lt;span class=&quot;blsp-spelling-error&quot; id=&quot;SPELLING_ERROR_10&quot;&gt;virtualized&lt;/span&gt; behind a single &lt;span class=&quot;blsp-spelling-error&quot; id=&quot;SPELLING_ERROR_11&quot;&gt;virutalizaiton&lt;/span&gt; engine. Therefore I would argue the true value of server and storage &lt;span class=&quot;blsp-spelling-error&quot; id=&quot;SPELLING_ERROR_12&quot;&gt;virtualization&lt;/span&gt; has not been realized.&lt;br /&gt;&lt;br /&gt;&lt;span class=&quot;blsp-spelling-error&quot; id=&quot;SPELLING_ERROR_13&quot;&gt;VMware&lt;/span&gt; is working on &quot;Geo &lt;span class=&quot;blsp-spelling-error&quot; id=&quot;SPELLING_ERROR_14&quot;&gt;Vmotion&lt;/span&gt;&quot; to break out of this physical &lt;span class=&quot;blsp-spelling-error&quot; id=&quot;SPELLING_ERROR_15&quot;&gt;ESX&lt;/span&gt; infrastructure and even data center limitation. In the storage world some &lt;span class=&quot;blsp-spelling-error&quot; id=&quot;SPELLING_ERROR_16&quot;&gt;virtualization&lt;/span&gt; engines can move data between clusters, but this &lt;span class=&quot;blsp-spelling-corrected&quot; id=&quot;SPELLING_ERROR_17&quot;&gt;doesn&#39;t&lt;/span&gt; solve the solution in a multi petabyte shop. I have argued for the last 5 years that until &lt;span class=&quot;blsp-spelling-error&quot; id=&quot;SPELLING_ERROR_18&quot;&gt;virtualization&lt;/span&gt; solutions overcome physical limitations they offer little to no value in the storage world. How much value does the ability to move a &lt;span class=&quot;blsp-spelling-error&quot; id=&quot;SPELLING_ERROR_19&quot;&gt;lun&lt;/span&gt; between 2 or 3 arrays add if you have 100 arrays? How much are you willing to spend on additional software, hardware, professional services, training, and etc. for this ability? What are the performance and availability implications of adding another piece of complexity between your servers and disk drives?&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;Well I guess marketing does work.......</content><link rel='replies' type='application/atom+xml' href='http://storagepimp.blogspot.com/feeds/3102489734826268924/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://storagepimp.blogspot.com/2009/04/storage-vs-server-virtualization.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/6079288930441486118/posts/default/3102489734826268924'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/6079288930441486118/posts/default/3102489734826268924'/><link rel='alternate' type='text/html' href='http://storagepimp.blogspot.com/2009/04/storage-vs-server-virtualization.html' title='Storage Vs. Server Virtualization'/><author><name>Storage Pimp</name><uri>http://www.blogger.com/profile/15618336561722762678</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='https://img1.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-6079288930441486118.post-5881599110036269145</id><published>2009-04-14T18:30:00.002-04:00</published><updated>2009-04-14T18:47:12.176-04:00</updated><title type='text'>Pooled Storage the Necessary Evil</title><content type='html'>After years of being touted by startup vendors, and knocked as &quot;the communist&quot; way by the big boys pooled storage has now been embraced by all.  Now it is time to make sure everyone understands the downfall.  Sure your vendor will tell you all about how it results in an optimal back end disk layout.  How it will completely eliminate back end hot spots.  These are some of the compelling reasons to utilize pooled storage.  When you think about the fact that we are talking about shared resources and shared environments I think it makes perfect sense.  Once all the kinks are worked out of the ability to drain, grow, and spread pools on the fly there will only be a single valid arguement against Pooled storage.&lt;br /&gt;&lt;br /&gt;The loss of a Raid rank takes out the entire pool.  Vendors are taking different approaches to this issue.  Some are recommending Raid 6 across the board, some are completly ignorning the issue, and some are arguing that storage arrays are smarter today therefore drives almost never fail hard.  In my humble opinion the quickest solution is to get Raid 6 to perform as close to Raid 5 as possible.  How do you do this?  Calculate both sets of parity somewhere besides the physical drive.  This has been accomplished for Raid 5 by all the major players, and I am sure before long Raid 6 will also be similarly optimized.&lt;br /&gt;&lt;br /&gt;The only other option today is keeping more than a single copy of data.  I would even go as far to say this should be a requirement for any application in which downtime results in a significant loss of $$$$.  The question of where and how to keep these additional copies of data will be a topic for another day....  The message today though is that pooled storage is the future of shared storage, but dont jump head first into the pool without know how deep it is...</content><link rel='replies' type='application/atom+xml' href='http://storagepimp.blogspot.com/feeds/5881599110036269145/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://storagepimp.blogspot.com/2009/04/pooled-storage-necessary-evil.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/6079288930441486118/posts/default/5881599110036269145'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/6079288930441486118/posts/default/5881599110036269145'/><link rel='alternate' type='text/html' href='http://storagepimp.blogspot.com/2009/04/pooled-storage-necessary-evil.html' title='Pooled Storage the Necessary Evil'/><author><name>Storage Pimp</name><uri>http://www.blogger.com/profile/15618336561722762678</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='https://img1.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-6079288930441486118.post-1275019940318151591</id><published>2009-03-13T18:14:00.001-04:00</published><updated>2009-03-14T02:23:41.063-04:00</updated><title type='text'>Pooled Storage + Flash Drives = Innovation</title><content type='html'>Despite what some vendors would like you to believe, and have been somewhat &lt;span class=&quot;blsp-spelling-corrected&quot; id=&quot;SPELLING_ERROR_0&quot;&gt;successful&lt;/span&gt; in convincing all other storage vendors placing Flash drives into Enterprise Storage Arrays alone are not innovative in any sense of the word.  Solid state drives are not new, and storage arrays are not new.  Simply applying existing raid, provisioning, and etc. mentalities is not innovation.&lt;br /&gt;&lt;br /&gt;However it is a step in the direction of innovation.  By having the ability to utilize these devices in an Enterprise Storage Array it does open the door.  The next step is coming up with a full proof method of placing the data and only the data which benefits the most from this type of technology onto these devices intelligently and without an impact to the application.&lt;br /&gt;&lt;br /&gt;So what benefits the most from this technology?  This is an easy one.  Things that make the disk drives spin the most.  The biggest nightmare to anyone with storage performance experience drum roll please ..... Random Read Misses.  So lets put all our random read misses on flash drives.  Well this is where we run into the problem.&lt;br /&gt;&lt;br /&gt;Lets consider one application which is not performing up to par.  You have a case open with your storage vendor, and &lt;span class=&quot;blsp-spelling-corrected&quot; id=&quot;SPELLING_ERROR_1&quot;&gt;aren&#39;t&lt;/span&gt; making much &lt;span class=&quot;blsp-spelling-corrected&quot; id=&quot;SPELLING_ERROR_2&quot;&gt;lead way&lt;/span&gt;.  After a couple days the sales guy catches wind, and comes in with the solid state drive sales pitch.  So everyone is blown away by the &quot;innovation&quot; and jumps &lt;span class=&quot;blsp-spelling-corrected&quot; id=&quot;SPELLING_ERROR_3&quot;&gt;on board&lt;/span&gt;.  Now its time to actually spec out the hardware.&lt;br /&gt;&lt;br /&gt;Here in lies the problem what do you place on the solid state drives?  One option is to place the entire application on solid state drives.  The sales team will &lt;span class=&quot;blsp-spelling-corrected&quot; id=&quot;SPELLING_ERROR_4&quot;&gt;definitely&lt;/span&gt; be &lt;span class=&quot;blsp-spelling-corrected&quot; id=&quot;SPELLING_ERROR_5&quot;&gt;on board&lt;/span&gt; with this option.  However since the majority of writes go to cache, and the majority of sequential reads take advantage of &lt;span class=&quot;blsp-spelling-error&quot; id=&quot;SPELLING_ERROR_6&quot;&gt;prefetching&lt;/span&gt; algorithms this would result in &lt;span class=&quot;blsp-spelling-error&quot; id=&quot;SPELLING_ERROR_7&quot;&gt;alot&lt;/span&gt; of data on solid state drives that do not have an IO profile which warrants such placement.  The other option today is to look at the performance data and identify &lt;span class=&quot;blsp-spelling-corrected&quot; id=&quot;SPELLING_ERROR_8&quot;&gt;identify&lt;/span&gt; individual &lt;span class=&quot;blsp-spelling-error&quot; id=&quot;SPELLING_ERROR_9&quot;&gt;luns&lt;/span&gt; with high random read percentages.  Once these &lt;span class=&quot;blsp-spelling-error&quot; id=&quot;SPELLING_ERROR_10&quot;&gt;luns&lt;/span&gt; are identified they could then be manually moved &lt;span class=&quot;blsp-spelling-corrected&quot; id=&quot;SPELLING_ERROR_11&quot;&gt;utilizing&lt;/span&gt; a back end storage utility without an outage, or a planned host based mirror/migration.&lt;br /&gt;&lt;br /&gt;So whats the problem, and why is this not innovative?&lt;br /&gt;&lt;br /&gt;1.  All of this is a manual method.&lt;br /&gt;2.  Since a &lt;span class=&quot;blsp-spelling-error&quot; id=&quot;SPELLING_ERROR_12&quot;&gt;lun&lt;/span&gt; is the smallest object you can migrate today you are still moving too much data to solid state drives.&lt;br /&gt;3.  It is possible to have a small portion of data on a &lt;span class=&quot;blsp-spelling-error&quot; id=&quot;SPELLING_ERROR_13&quot;&gt;lun&lt;/span&gt; with a high random read miss percentage which cannot be &lt;span class=&quot;blsp-spelling-corrected&quot; id=&quot;SPELLING_ERROR_14&quot;&gt;identified&lt;/span&gt; because it is masked by the IO pattern of the remaining data on the &lt;span class=&quot;blsp-spelling-error&quot; id=&quot;SPELLING_ERROR_15&quot;&gt;lun&lt;/span&gt;.&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;So how do we address these issues?  Well the answer to the second and third is by moving towards pooled storage.  With pooled storage the smallest denominator becomes an extent.  Now for the innovative part is the array &lt;span class=&quot;blsp-spelling-corrected&quot; id=&quot;SPELLING_ERROR_16&quot;&gt;identifying&lt;/span&gt; the extents which are the best candidates for placement on solid state drives,  and being able to move them there on the fly without downtime.   Now that would be &lt;span class=&quot;blsp-spelling-corrected&quot; id=&quot;SPELLING_ERROR_17&quot;&gt;disruptive&lt;/span&gt; innovation.</content><link rel='replies' type='application/atom+xml' href='http://storagepimp.blogspot.com/feeds/1275019940318151591/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://storagepimp.blogspot.com/2009/03/pooled-storage-and-flash-drives-could.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/6079288930441486118/posts/default/1275019940318151591'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/6079288930441486118/posts/default/1275019940318151591'/><link rel='alternate' type='text/html' href='http://storagepimp.blogspot.com/2009/03/pooled-storage-and-flash-drives-could.html' title='Pooled Storage + Flash Drives = Innovation'/><author><name>Storage Pimp</name><uri>http://www.blogger.com/profile/15618336561722762678</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='https://img1.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry></feed>