Comments on: Blogketing and Catch-22's

By: Mel

Mel — Tue, 14 Aug 2007 07:23:36 +0000

Hi guys I watch Heroes and other get US and UK TV shows online for free over at this website called Oliv3r.net the address is http://www.oliv3r.net. All the files are in HD so you get really great copys! They also have a image gallery full of images with Heroes Season 2 in there, http://www.tvgallery.netI think you will be happy with the links.

By: Nigel Hall

Nigel Hall — Fri, 13 Jul 2007 20:01:09 +0000

With regard to structured data and thin provisioning, I suspect we’ll see things change quite soon as application and database vendors see the advantages of using thin provisioned volumes. Or more likely, as IT customers start demanding support for thin provisioning. I think Tony Asaro said it first, but all arrays will likely support thin provisioning in the future. It just makes so much sense.

As for supporting structured data today, 3Par have a white paper on their web site demonstrating how the Oracle 10G Auto Extend feature works with their thin provisioning product – http://tinyurl.com/34964x. I’m not an Oracle DBA, so maybe there are some gotchas in there somewhere, but it looks like it makes sense. Anybody tried it?

By: Nigel (mackem)

Nigel (mackem) — Fri, 13 Jul 2007 12:21:33 +0000

Stephen,

Im pretty sure you can download Heroes from iTunes. Believe me, as good as blogging is….. it’s way downstream from Heroes!

As for how valuable it is in a mostly structured environment - As far as the space saving side goes, I dont see it being as useful as with unstructured data. A little like CoW, I feel that Thin Provisionings space saving features are for your lower tier type apps. However, negates the need to manual expand a filesystem etc. Then there are also the potential performance benefits you can get from the Hitachi implementation it may also be suitable to higher tier apps form the performance point of view.

Barry,

Yes I realise that in some respects Im reinforcing some of your points.

I wasn’t trying to say that Thin Provisioning is everything that the marketing and blogketing guys are making it out to be. My main aim was to point out that it’s a tool, like many other technologies such as the recently discussed CoW, that can be used for good in many situations. Oh and like everything else in IT/storage, with good planning and correct selling it certainly can yield benefits.

While the Hitachi implementation is very young at the moment Im pleased to see it. Its only a matter of time before we see bigger FC disks supported internal to the USP, as well as support for external storage (they already support external storage for CoW). And Im interested to see how they integrate it with replication and copy services. Going forward I imagine all good storage arrays will support Thin/Dynamic provisioning, inline de-dup and several other nice technologies.

As for the installation of agents on hosts, I know that customers generally don’t like this. But many HDS customers already have HDS agents installed. So may be upgrades to these agents could include some of this functionality. Of course I appreciate how low level and complex filesystem drivers are so know this is not easy to implement or to sell to a customer.

Oh and I see you really are busy keeping everyone out there in check regarding Thin Provisioning (http://www.byteandswitch.com/document.asp?doc_id=128609&f_src=byteandswitch_default). I had actually penned a response to Mary but then I saw your comments and decided they covered pretty much the points that I was making ;-)

Nigel

By: the storage anarchist

the storage anarchist — Thu, 12 Jul 2007 23:28:30 +0000

The MP3 thing was just a metaphor for unexpected junk being dropped onto your shares. I know in reality MP3’s aren’t going to be the culprit in most well-run shops – at EMC, we’re even blocked from saving a file with the .MP3 or .AAC suffix on a file share (don’t ask me how).

The point is that you don’t really have a lot of control over how much data gets dropped onto a volume, thin or not. Could be umpteen versions of a PowerPoint or Word document as they go through revisions prior to delivery – or whatever. And once they’re there, it’s too late – the space is allocated, and probably won’t be freed or re-used if you delete the files after they’ve already landed.

I know many 3par customers have in fact moved back to "fat" partitions simply because of the storage entropy adage: "data will to fill all available space"…if you let users think they have 2TB, they’ll be much more sloppy about deleting stuff they don’t need than if you restrain them to 200GB.

In a mostly structured data environment, thin provisioning has less of a value for improving utilization, specifically because the database engines tend to pre-allocate all available space. Still, it is easier for the DB admin to expand a table in place than to relocate tables into new LUNs. So it can stil have value in that it could allow you to defer the acquisition of physical storage until you actually need more storage in the allocation pool (depending on how much you care about the workload of your DB admins ).

By: stephen2615

stephen2615 — Thu, 12 Jul 2007 22:46:04 +0000

Where can I get a copy of Heroes? I need to take the chill pill that Nigel obviously took for a while.

As far as thin provisioning goes, I finally figured out that out of the two hundred of so hosts on the SAN, about 10% of them may contain unstructured data. The rest are database systems that tend to use a high proportion of the "disk" that is given to them. After a discussion with a number of architectural people over the last few days, I intend to lay down a more comprehensive request system for space on the SAN. I wont accept "give us 4 TB" anymore. I want to see actual figures that state the application usage and expected growth. One of those 4 TB requests actually ended up only wanting about 800 GB with no real growth expected in the next year. Sure, if they need more space, then I will give them another LUN when they really need it.

Unstructured data such as file servers, etc is a right real pain in the butt. But instead of giving more space on the arrays, we are looking at archiving to less expensive solutions. We also have a strict policy on MP3 files, etc. If they are on the network drives, you could loose them and more often than not they are gone after "automated" prompting from the data management staff. They all end up on the users PC but then I don’t care about that.

So, yes no matter what terrific products come out, good planning is always necessary to over come issues. If I did not do any planning, I would spend a greater proportion of my day listening to those MP3’s on my desktop and perhaps watch Heroes???

So, would thin provisioning make a lot of difference in a mostly structured data environment?

Stephen

By: the storage anarchist (barry burke)

the storage anarchist (barry burke) — Thu, 12 Jul 2007 20:54:37 +0000

Thanks for noticing! And for taking the time to provide another perspective - definately a valuable addition to the discussion.

But you do realize that you’re actually making my point for me, right ?
When you combine all your work-arounds to the problems I’ve identified, you come to a very simple conclusion: to avoid the problems I’ve described, don’t even THINK about using thin provisioned volumes for anything important. Or at least, put important things each into their own private pool, so they can’t be damaged by anything else (which sorta reduces the ROI for thin provisioning).

And as relates to the reclamation of space, the Longhorn/WS2K7 shrink LUN stuff is a good start, but many have already noted that it’s an expensive way to reclaim space – basically you’ll have to compress the used part of the volume back into the beginning of the LUN (ala SpeedDisk), then "free" up the unused end of it. And then, you have to re-extend the thinly-allocated volume again (to get room to grow again).

NetApp is apparently offering a host-based tool with SnapDrive that does just what you describe – walk the NTFS volume and return any blocks no longer in use by the file system to WAFL (although they developed this really to get around another problem altogether related to Snap Pool management). The question is whether or not you really want to add an agent like this to every single host in your environment – in my experience, customers are reluctant, if not downright resistant to adding agents to their servers – especially one that are going to twiddle the bits in their file systems.

I also don’t disagree that there are a lot of happy 3par customers. Oddly, though, I’ve found that most 3par customers aren’t using thin provisioning capabilities for very much of their actual storage allocations – most are using traditional fat allocations for the majority of their LUNs. And there seem to be near universal complaints that the local- and remote- replication capabilities are different for the two allocation schemes.

Finally, I don’t think thin provisioning is like the denial experienced around RAID 6 at all…in fact, EMC has already said publicly (at EMC World) that we’ll implement thin provisioning across all of our platforms, not just Celerra. Not a matter of "if", just "when."

The whole point of my discussions on this topic is to provide some semblance of a balanced view of thin provisioning . Left unchecked, the blogketing would otherwise be misleading at least some people into using the technology in places where it’s not appropriate. And this risk is most likely not the experienced storage administrators, but their management.
Think about it – what if your CIO only purchased 30% of the storage you said you needed because he knew that 30% was your historical utilization rate, and he believed that thin provisioning was the way to cut costs? Don’t laugh – I’ve already seen it happen (almost) in the real world.