The Storage Architect » thin provisioning

Data Robotics Releases Business-class Arrays

Chris M Evans — Tue, 08 Feb 2011 08:24:53 +0000

Today Data Robotics (Drobo) are announcing a new range of storage devices specifically targeted at business customers. However this is a market that already has many players; what are they offering and how will they fare in this already competitive market?

New Devices

First of all, let’s take a look at the new storage devices. Nomenclature has been changed over previous models (business people like nice code names) and so we have the following new devices:

B800fs – 8-bay NAS model
B800i – 8-bay iSCSI SAN model
B1200i – 12-bay iSCSI SAN model

It’s a pretty easy guess that the codes mean “B” for business, “fs” for file sharing “i” for iSCSI and the numbers designate the drive count in the chassis. What’s new here from a hardware perspective is the 12-drive model, specifically designed as a rack-mount device. Now business-class storage devices are very different from those used in an office environment by (for example) media developers or for local backup. Consequently Drobo have had to step up to the mark and improve the resiliency of the existing hardware. Therefore the new B1200i support all hot-swappable components (except the passive backplane) and additional power supplies and Ethernet connections have been added. Note that the B800 models have not been upgraded in this way and still have a single power supply and dual Ethernet connections. Images of the new devices are shown in this post. It’s interesting to see that the B1200i rear view shows four expansion slots for connectivity, of which only two appear to be used. Presumably the other two are for future expansion.

Software and Features

As mentioned earlier, the small device business market is a competitive place; EMC have just released their VNXe product, HP have the P2000 array; IBM recently released the StorWize v7000. These storage appliances are fully specified devices offering advanced features for a low cost. The features and software component could be an issue for Drobo. The new models offer the excellent BeyondRAID functionality and only an additional tiering option.

BeyondRAID is Drobo’s thin provisioning and RAID technology combined. In essence, data is laid out across the disks using RAID at the block level rather than replicating whole disks. This methodology enables dis-similar disk capacities to be used in the device and for disks to be replaced or upgraded over time in order to increase capacity. BeyondRAID provides the customers many advantages; disks can be purchased and added to the system as required, even though a greater logical capacity of storage has been configured. This logical capacity doesn’t need to be changed as physical capacity increases. Drives of greater capacity can be added over time, so customers can purchase the most effective price/capacity drive for their needs. Also a single drive can be replaced without rebuilding the entire RAID set, only copying data that was on any removed drive.
Data-aware Tiering. The new Drobo model now support automated tiering of data across different device types, including SATA, SAS and SSD disks. Tiering uses fixed algorithms to determine the best placement for data based on usage. My first thoughts were that a fixed tiering algorithm might not be appropriate, however taking a step back and looking at the market this device is targeted for, many customers taking their first steps into SAN technology may not want or need to understand how things work under the covers.

However good the hardware is, ease of management is all about the software. As a result, Drobo have released a new version of their dashboard, screenshots of which can be seen in the attached images. Better management software for Drobo was always a requirement. The existing dashboard doesn’t scale easily with multiple devices and there are a few major flaws within the software that would reduce the appeal to business. It appears that the scalability issues have been addressed, but only a test-drive will tell how much better the software really is.

Summary

The entry-level SAN array market is becoming increasingly competitive. There are many companies targeting this space, not including the big storage names I’ve mentioned earlier. Data Robotics are pitching the new business models from £1409 ($2000) upwards, which presumably is for the B800i rather than the 12-bay model. Although this does exclude disks, the price does seem competitive, as drives can be purchased by the customer at the lowest cost and added as required. The competition will cite lack of features, but these are easily added with software releases and will be key to the success of the new devices. In addition, the management software needs to be business-class or will be a major stumbling block. Here are just a few features of the existing software that need to be improved:

Pre-emptive hot-swap - currently a drive replacement is a recovery operation. When a drive is removed, the Drobo rebuilds RAID from the remaining disks. It would be better to allow this replacement process to happen pre-emptively, copying data off to a new disk (if slots are available) before the a disk is removed. This also reduces the impact on performance as RAID rebuilds need to happen as quickly as possible, whereas planned data migrations can be run as background tasks.
iSCSI Management - the existing iSCSI interface isn’t fully featured. The dashboard only indicates when a single host has logged into an iSCSI target/LUN but doesn’t indicate the server name or IP address. This can be frustrating in large environments where, for instance, an over-zealous VMware host acquires all LUNs on a device. Sharing of LUNs is also not permitted today.
Capacity Management - although the Drobo understands thin provisioning, it only reports utilised capacity for devices that have a recognised file system and are connected to a host running the Drobo dashboard. However the device itself must know how much data is being used by each LUN, irrespective of the file format. That data needs to be presented to the user, otherwise real capacity planning can’t be done.

Overall, I think Drobo are making an exciting move into the business space. Price sensitivity is an issue in this market and the initial costs are low enough to be attractive to many new customers. Data Robotics also offer a maintenance contract (DroboCare) for replacement parts, another key business feature. Key success factors will be the improvement management interface and addition of new features to the device over time. With 150,000 devices sold to date, Drobo appears to be a force to be reckoned with for the future.

Virtualisation: DroboPro – Hyper-V’s Best Friend!

Chris M Evans — Thu, 25 Mar 2010 10:00:22 +0000

I’ve had my DroboPro for some time now and initially I had mixed results with it. Although I was aware of the single connection to an iSCSI target restriction, I was slightly disappointed with the lack of vmfs support within the Drobo operating system, especially as the product sells itself on understanding the filesystem format. My next move has been to test the DroboPro with Hyper-V and guess what? Thin Provisioning is back on the agenda; Hyper-V uses NTFS to store hypervisor guests, making it perfect for use with DroboPro.

The first screenshot shows my DroboPro configuration. It’s currently up to 7 drives and 9.4TB; although I’m only using a fraction of that space at the moment while I do some testing (the majority of disks in the unit were also purchased for testing). I’ve created seven 2TB drives (more than the Drobo capacity) and connected them to my Hyper-V server. From there, I’ve formatted four of the drives and you can see those as drive letters H: through to K: on the second screenshot. Two of the volumes are hosting Hyper-V guests occupying around 19GB of storage in total. This is directly reflected by the capacity of space used on the DroboPro and the two C: drives, one of which is shown in the third screenshot.

The DroboPro is ’thinning’ the thin provisioned Hyper-V virtual disks, enabling me to in effect scale my Hyper-V storage requirements to the absolute minimum I need to, even if the virtual disks for the operating systems are bigger (in this instance 126GB per virtual drive). The next step is to extend the storage usage on the virtual guests and see what happens.

My first attempt is to use an old favourite, fsutil and create a few large empty files. Unfortunately this strategy doesn’t work; the NTFS file system on the Hyper-V guest seems to detect that this is a sparse file and even though the virtual file system shows the storage as being allocated, this isn’t passed back and allocated on the Hyper-V server. This seems to indicate that Hyper-V itself is truly filesystem and thin provisioning aware.

My second attempt consisted of finding a large file and copying it repeatedly. This process was more successful and the results can be seen in the 6th screenshot; I added around 9GB of additional files, pushing up the DroboPro capacity and the space stored in the VHD snapshot by equal amounts.

I then deleted my snapshots, effectively merging them into the main VHD file. As the merge took place, the base VHD file increased, taking more overall capacity on the DroboPro. After the merge had completed and the Hyper-V guest restarted, the capacity used returned to the total in actual use; the DroboPro reclaimed the released storage.

Summary

What have I learned? Without any additional configuration, the DroboPro is thin provisioning aware with Hyper-V. This is “thin on thin” as the Hypervisor and the DroboPro both implement thin provisioning at their own level. Snapshots need some consideration, especially when merging into the main virtual disk (VHD). Thought also needs to be given to the best way to lay out the Hyper-V storage; bear in mind that to get the thin provisioning benefits, each DroboPro drive must be configured with a single NTFS volume – spanned and striped volumes will not work.

I’d say the DroboPro was good to go with Hyper-V. All we need now is vmfs support!

DroboPro – Hyper-V’s Best Friend!

Chris M Evans — Thu, 25 Mar 2010 10:00:22 +0000

Summary

I’d say the DroboPro was good to go with Hyper-V. All we need now is vmfs support!

Enterprise Computing: Run My Storage At 60%? No Way!

Chris M Evans — Wed, 17 Mar 2010 19:52:53 +0000

Hu Yoshida has an interesting view on his recent post discussing storage utilisation rates. His concluding remark suggests running at a maximum of 60% utilisation – even with Dynamic Provisioning. Hu, you must be joking, right?

Point 1: I’ve paid for my 100% of storage and I’m going to use it. I don’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’t necessarily cost effective, however it can be achieved.

Point 2: It’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.

Point 3: Achieving high utilisation isn’t all about technology. It’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.

So, don’t think 80%+ isn’t an achievable target. After all, it’s your money you’re wasting if you don’t try!

Enterprise Computing: 3par and HDS – 50% Saving – Guaranteed?

Chris M Evans — Fri, 29 Jan 2010 20:39:46 +0000

In the past week, both 3Par and HDS have announced a 50% guarantee on reclaimed storage if customers move data from existing “fat” legacy arrays to 3Par storage or use HDS thin provisioning technologies. The 3Par news release is here; the Hitachi news release is here.

The 3Par guarantee is presented with a caveat:

The above is intended to highlight certain aspects of our Get Thin Guarantee and does not contain the full terms, conditions, limitations, definitions, and other provisions (“Terms”) of the Get Thin Guarantee. The Terms shall be contained in a written Get Thin Offer which shall take precedence over the above. Qualification for our Get Thin Guarantee is subject to your acceptance of a Get Thin Offer containing the Terms and satisfaction of those Terms.

This, no doubt is the legalese to satisfy the lawers, however it probably also holds the specific terms and conditions of the data to which the 50% applies.

Hitachi’s caveat restricts the 50% savings to migrations from RAID-1 to dynamic provisioned RAID-5, otherwise the guarantee is only 20%. Well duh. Moving from RAID-1 to RAID-5 alone gives a saving of up to 42% depending on how you choose to calculate it.

You may remember Netapp also have a 50% space guarantee (details here). I wonder how that is going….

It too had a number of restrictions on the type of data which would be classed as suitable and also required customers to implement the storage in a certain way.

Whilst these sorts of programs are welcome if they genuinely result in savings for customers, what we need to be wary of is clever marketing which in reality results in configurations that customers wouldn’t implement.

One final thought; Hitachi guarantee to cough up the difference between used and predicted savings in storage. That’s great (and I don’t know if Netapp and 3Par agreed the same), but there’s always a tradeoff between storage efficiency and performance. Will the vendors also guarantee that performance won’t be impacted?

One final final thought…. I bet EMC don’t try and match the competition…

Enterprise Computing: Thin Provisioning and The Cookie Monster!

Chris M Evans — Tue, 17 Nov 2009 21:45:35 +0000

The Gestalt IT Field Day was a great success in bringing together a mixture of delegates from varying discplines. Following the presentations from 3Par and Symantec, there was heated debate about the implementation of Thin Provisioning and the ability to reclaim released storage resources. This post covers the basic concepts of Thin Provisioning and more importantly how deleted resources can be recovered over time.

Thin Provisioning Primer

The underlying concept of thin provisioning is pretty simple; provide storage resources to those requesting it only as they need it.

Think of a standard ‘thick provisioned’ environment. As thick LUNs are created, the storage is assigned and mapped to that LUN to the full extent of the size requested. See, the first graphic, which shows a RAID group of four 5GB drives. I’ve assumed “RAID-0″ here for simplification, i.e. no RAID overhead. Each LUN (coloured separately) is made up from a 1GB slice of the available disks. Thick provisioning is great if the LUNs are all 100% allocated. In that instance, 100% of the available physical space is used up. However, it is never the case that 100% of a LUN is used and so wastage exists.

Look at the second graphic. This shows how thin provisioned LUNs work. As storage is requested by the LUN, the space is mapped to physical blocks of storage. In this example, none of the logical LUNs are fully utilised and so don’t consume their full theoretical capacity. This means that the pool of space can be over-subscribed and a sixth new LUN created. Obviously there’s no such thing as a free lunch or infinite storage resources and in this example if a further five blocks are requested then physical space would be exhausted. The next request for a new storage block would result in an error situation and this represents the main concern with over-subscribing thin provisioned volumes.

Now we get the concept of thin provisioning, there are a further two aspects to consider. Firstly, when we say a LUN isn’t 100% utilised, what to we mean? Second, how can deleted blocks be returned to our free physical pool?

As LUNs are presented to hosts, they are formatted with a file system, for example on Windows it’s NTFS; a VMware environment would use VMFS. The file system will have a standard layout which determines where the file index sits and the method in which files are allocated onto the disk. Have a look at the third graphic. This is a map of the C: drive for one of my servers. Each block represents approximately 22MB. You can clearly see the MFT (NTFS index) in the centre of the volume. A large percentage of the disk is unused. In a thin provisioned environment, storage would have been requested only for the blocks with valid data and in this way, a LUN can be less than 100% allocated.

OK, so what happens if I create some files then delete them on the file system? Most file systems remove a file by deleting the entry in the index rather than physically overwriting the file contents with binary zeros. This is quick and efficient (if not slightly unsafe security wise). The actual data isn’t overwritten and it is this ‘logical’ deletion that enables undelete utilities to work. The trouble is, most disk arrays are not file system aware and so can’t detect the logical deletion of a file. Those arrays that offer thin provisioning typically detect unwanted space by looking for blocks containing only ‘binary zeros’. This means simply deleting files will not release unused space back to the free block pool (except for one storage device I’ll discuss in more detail another time, that’s Drobo). Arrays which are capable of recovering unused space need to see data overwritten in order to recover it.

This (finally) brings us to the cookie analogy. Imagine cookies are my free pool blocks. There are a number of ways in which storage arrays operate in handling thin provisioning – different cookie monster personalities:

The Greedy Cookie Monster; grabs all the cookies he thinks he might eat, but never eats all of them and never returns any – this is the thick provisioning model.
The Selfish Cookie Monster; only grabs cookies as he gets hungry but if he doesn’t eat them immediately, doesn’t give them back – this is thin provisioning with no zero block reclaim. Eventually thin provisioning will become thick as all logical blocks in a LUN become mapped to physical storage.
The Nice Cookie Monster; takes the cookies as he gets hungry but only returns uneaten cookies if asked – this is thin provisioning with manual zero block reclaim. A manual process is required to zero out the unused space and to return it to the free pool.
The Saintly Cookie Monster; takes the cookes as he gest hungry and offers them back immediately he realises he can’t eat them – this is thin provisioning with automatic zero block or free space reclaim.

So, of the storage arrays out there offering thin provisioning, which fit the various Cookie Monster personality types? I’ll leave that for you to guess.

Review: StarWind Enterprise Server – Part II

Chris M Evans — Wed, 28 Oct 2009 07:37:46 +0000

This is the second of a series of posts reviewing the StarWind Enterprise Server iSCSI software target. The posts relate to version 4 of the product. Previous post(s) can be found at:

Review: StarWind Enterprise Server – Part I

In the first post of this review, I explained how StarWind’s server product provided the ability to turn a Windows server into an iSCSI storage device. In this post, I’ll focus more on the specific LUN types available to the user.

Image File Device – this type is a standard iSCSI LUN – fully occupying the disk space of the creation size. LUNs can be both compressed and encrypted, however it’s not clear from the documentation exactly how these features are implemented and to what security standards.

RAM Drive Device – an iSCSI LUN emulated purely in memory on the server. This device exists purely in memory on the server and so is a volatile device; if the power goes and the server reboots, then the data is lost. I’m not sure of the merits of this kind of device when the data is so transient.

Virtual DVD Device – this device type presents an ISO file as a iSCSI DVD-ROM device. This useful for sharing out ISOs across multiple clients; up to 16 may connect at any one time. One drawback though; the ISO file must exist on the local machine running StarWind, which is sort of limiting.

Disk Bridge Device – a passthrough device representing a single physical disk on the server. Think of this in the way RDM devices work on VMware – the device itself is virtualised through to the host.

Snapshot and CDP Device – this is an iSCSI LUN which supports Point In Time snapshots and thin provisioning. A LUN can be created from an existing device; either as a snapshot or full/linked clone. The thin functionality is pretty obvious (more on this in a moment). As for the CDP functionality, I had issues attaching this device type to my Windows client, which wouldn’t let me assign a drive letter to the LUN. In addition, the volume was already formatted as a raw device.

Mirror Device – an iSCSI LUN mirrored with RAID-1 or replicated to another server. Mirroring of the logical iSCSI LUN can be done on the local machine (providing some level of fault tolerance in a single server with multiple hard drives) or using a remote LUN on another server capable of presenting out iSCSI devices.

SPTI Device – a raw (non-emulated) version of a Disk Bridge Device. This is more closely aligned to an RDM device then the Disk Bridge type. All devices (including read-only media such as DVD-ROM) can be externalised as iSCSI devices.

Virtual Tape Device – an iSCSI LUN representing a tape device. This feature has been removed from the current product and is now available separately as StarWind VTL.

There’s not doubt the range of supported devices is comprehensive, although some features such as encryption and compression need more explanation to understand how they are implemented and how data could be recovered in a server failure scenario.

Thin Provisioning

It’s pretty much taken for granted that thin provisioning needs to be provided as a feature in storage arrays, whether physical or virtual. Fortunately StarWind Server offers this as part of the CDP device type. As a test, I created an iSCSI thin LUN using the console and connected it to a Windows host. As expected, copying files to the LUN grew the device by the size of the copied files. Unfortunately, deleting the files and/or reformatting the drive did not reclaim the released space. In fact, a full format of the drive, rather than a quick format resulted in the full capacity of the drive being allocated and the benefits of thin provisioning wasted. (Tip: Use Quick format on Windows). In this release of the product there appears to be no way to reclaim unused resources within thin provisioned devices. Thin Provisioning implementations need to add this functionality as the value of using thin LUNs simply diminishes over time.

Summary

Overall, the product offers a wide range of device types. A more detailed understanding of some specifics (e.g. encryption standards) is required. Thin LUNs need some space release technology added to ensure thin doesn’t simply revert to thick over time.

In the next post, I’ll look at security, performance and the competition.

Disclaimer: I have no connection or relationship to StarWind Software. A free copy of the StarWind Server software was provided by the company for this evaluation.

Review: StarWind Enterprise Server – Part I

Chris M Evans — Mon, 26 Oct 2009 22:41:10 +0000

This is the first of a number of posts reviewing the StarWind Enterprise Server iSCSI software target. The posts relate to version 4 of the product.

Not everyone wants or can afford to buy dedicated storage arrays, especially in current climates. So if you don’t want to spend money on a bespoke storage solution, are there any other options available? One of them might suit your budget – StarWind Enterprise Server from StarWind Software.

Background

Classic SCSI predicates a client/server architecture for storage transactions, where the client or host is known as an initiator and the storage device as the target. This is replicated in the iSCSI architecture and today we already see free iSCSI initiator implementations in host operating systems such as the Windows family.

StarWind Enterprise Server is a software product which turns a traditional Windows server into an iSCSI Target, meaning the server can act as a storage device, serving out LUNs to other servers across the IP network. These LUNs operate exactly as iSCSI devices would if they were presented from a more expensive and dedicated storage array.

The Technology

StarWind Enterprise Server installs two components; the Windows service and the management console for creating and administering iSCSI devices. Administration is pretty simple; see the screenshots below. One shows my list of devices and the second shows the starting process to creating a new iSCSI LUN, of which there are currently eight types:

Image File Device – a standard iSCSI LUN.
RAM Drive Device – an iSCSI LUN emulated purely in memory on the server.
Virtual DVD Device – an ISO of a DVD-ROM, exported as an iSCSI device.
Disk Bridge Device – a passthrough device representing a single physical disk on the server.
Snapshot and CDP Device – an iSCSI LUN which supports PIT snapshots.
Mirror Device – an iSCSI LUN mirrored with RAID-1 or replicated to another server.
SPTI Device – a raw (non-emulated) version of a Disk Bridge Device.
Virtual Tape Device – an iSCSI LUN representing a tape device.

When any of the above devices are created (excluding the RAM device), the new device is mapped to a number of files on disk. An Image File Device is created as a simple flat file with the extension .img. A Snapshot and CDP Device is created with three separate files to hold the structure, as these devices can also act as thin provisioned LUNs. I’ll discuss more on the various flavours of LUN type in a future post.

Now the first question has to be why bother using this software? In large organisations with dedicated equipment then that question is a fair one, however not every company wants or can afford to deploy storage arrays across their environment. There are scenarios where block-based storage is still required, however cost of acquisition and management precludes the deployment of traditional solutions. More important, the StarWind iSCSI target can be deployed as part of a virtual environment, leveraging the storage deployed in say, a branch VMware server to provide centralised storage resources.

So, this first post is to set the scene. In coming posts I’ll be looking in more detail at LUN allocation types, the thin provisioning aspects of StarWind Server, security, the competition and of course performance.

Disclaimer: I have no connection or relationship to StarWind Software. A free copy of the StarWind Server software was provided by the company for evaluation.

Enterprise Computing: So EMC, Where’s Your Thin Persistence?

Chris M Evans — Tue, 13 Oct 2009 06:34:58 +0000

Following on from yesterday’s announcement by 3Par, I’m wondering just where EMC is in the thin reclamation market. HDS have ZPR, which although working as a background collection process, does reclaim zeroed out blocks of data. I believe SVC has similar functionality too.

We all know that over time, Thin volumes transition back to Thick volumes as data is created and deleted. I suspect virtualisation platforms such as VMware will make that even worse. So where are EMC in this market? Bearing in mind FAST has been announced well ahead of potential availability, I can only assume EMC don’t have anything on the horizon. Make sure you consider this when you’re weighing up the benefits of a thin strategy.

Oh and its nothing to do with block size – after all, 3Par have the smallest block allocation and still see the need to provide persistent thin technologies.

If you’ve not read it, here’s my recent summary on thin reclaim.

Enterprise Computing: The Wide Striping Debate

Chris M Evans — Sun, 12 Jul 2009 11:17:47 +0000

I’ve read with interest this week the posts on wide striping and the consequent expansion to thin provisioning. Here are some of the highlights:

First there’s Martin Glasborow’s post, which discusses whether wide striping and thin provisioning should be chargeable items. I’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’s only value to TP with something like Zero Page Reclaim to get back those unused blocks.

Then there’s Hu Yoshida’s post referring to the Overheads of Thin Provisioning. In it, Hu makes a very interesting claim that wide striped LUNs have “greater protection from multiple disk failures”. On this point I have to disagree. 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. This is a fact whether then LUN is wide striped or not. For wide striped LUNs which are spread across multiple RAID groups, there’s more chance of a failure because a double disk failure could occur within any of the RAID groups supporting the presentation of that LUN.

In addition, wide striping has more impact 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 – now the impact of any RAID group failure is 180 LUNs. Remember that’s any RAID group failure, which is much more likely as we have more RAID groups on which every LUN is dependent.

Finally there’s EMC and their free Virtual Provisioning – free that is on new purchases, not existing DMX-4 deployments. While laudible, this offering is less generous compared to HDS’ Switch It On promotion which offers free UVM, Dynamic Provisioning (first 10TB only) and Tiered Storage Manager on existing USP-V deployments.

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’ve had these features from day 1.

P.S. You can find two EMC blogger references to the free Virtual Provisioning here and here.