NetApp has begun to unify their Onaro and Akorri acquisitions under the OnCommand Insight name

NetApp has long wanted to be known for its “unified storage” offerings, storage arrays that combine NAS and SAN. But the company has expanded its storage software footprint as well, and recently unified these offerings under the “OnCommand” banner. Some of these products are intended solely for NetApp storage, but many are suitable for heterogeneous and even non-NetApp environments. Let’s take a look!

OnCommand: A Broad Banner

The whole OnCommand software line is extremely diverse

The “OnCommand” name applies generally to much of NetApp’s storage software, from their System Manager to the Insight analysis products to integration plug-ins for vSphere and Hyper-V. It took me a while to get my head around just what was and wasn’t part of this cadre of products, as well as what it all was useful for. Here’s my attempt, but I apologize in advance if I get it wrong!

OnCommand includes both management and integration software, much of which is specific to NetApp’s well-known “Filer” storage arrays. The “Manage” range includes the OnCommand Insight family, which draws from the Onaro (SANscreen) and Akorri (BalancePoint) acquisitions.

SANscreen had been part of the NetApp lineup since the company’s 2008 acquisition of Onaro, but the five SANscreen components have been rationalized into three:

1. OnCommand Insight Assure includes the Service Insight, Service Assurance, and VM Insight components of SANscreen
2. OnCommand Insight Perform maps to the former Application Insight software component
3. OnCommand Insight Plan is the Capacity Manager component of SANscreen

NetApp acquired Akorri in February of this year, and has moved quickly to begin integrating their BalancePoint software into the OnCommand family. As discussed at Tech Field Day, BalancePoint is now known as OnCommand Insight Balance and has been updated.

Customers can order all of OnCommand Insight as a single package including all four components, or can purchase them separately. NetApp is actively working to integrate these products, including updating the look and feel, combining authorization, and pulling everything into a portal with multi-tenant support.

Stephen’s Stance

NetApp picked some good products when they acquired Onaro and Akorri, and it is great to see them moving forward with cross-platform support. Frankly, if these were rolled into some NetApp-only suite they would have been wasted and withered on the vine. But it remains to be seen if customers will select NetApp software for storage and service management, especially if they are not NetApp storage shops!

© sfoskett for Stephen Foskett, Pack Rat, 2011. | NetApp Unifies and Consolidates Software, Not Just Storage Capacity
This post was categorized as Enterprise storage, Everything, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

I think this sentiment is just as valid today as when I posted it in 2008!

Although many discussions in the storage industry focus on the relative merits of one protocol or another, the conversation occasionally turns to the core issue at hand: We continue to patch together a system based on outdated concepts. Most storage protocols continue to mimic direct attached storage, and most of our so-called networks act as point to point channels. An ultra-modern virtualized storage infrastructure with all the latest bells and whistles still holds the concepts of block and file at its core. Whenever the storage industry has tried to bring about real storage management they have been stymied by a lack of context for data.

No amount of virtualization, and no new protocol, will fix this. Put simply, we need a storage revolution.

Channels, Blocks, and Files

Most innovation in the 1980s and early 1990s focused on moving storage out of the server. SCSI allowed disk to exist in a separate cabinet, RAID allowed multiple physical disks to become a single virtual one, and these were mixed to become the prototype storage array. Although SCSI allowed one-to-many connectivity, it was never a true peer-to-peer network, even once it was mixed with network concepts in the form of Fibre Channel.

Even today, SAN storage is focused on providing faster, more flexible, and feature-packed direct-attached storage. A modern virtual SAN hides a complex arrangement of caching, data protection, tiered storage, replication, and deduplication, masquerading the lot as a simple, lowly disk drive. It is sad but true that all of our work as an industry has been dedicated to recreating what we started with.

Networked file-based storage is no better. Although NAS devices have all the advanced features of their SAN cousins, they must present a simple file tree to the host to retain compatibility. File virtualization merely presents a larger homogenous tree.

Inside the server, too, features and complexity are hidden to retain a familiar file system format. Volume managers can do anything a virtualization device can, but must present their output as a simple (though virtual) disk drive. File systems, too, have added features but still present a familiar tree of mount points, inodes, and files. Even ZFS, possibly the most advanced combination of volume management and file system technology yet, must present a simple tree of storage to applications.

The Metadata Roadblock

This outdated paradigm, of disks and file trees, is ill-suited to today’s storage challenges. Data must be categorized so actions can be taken to preserve or destroy it based on policies. Data must be searchable so users and applications can find what they want. Data must be flexible so it can be used in new ways. Our antiquated notions are not capable of meeting these challenges.

One simple problem is that we lack context for our data. Most file systems merely assign to a file a name, location, owner, and security attributes. The most advanced can contain extended metadata, but this is rarely seen in practice since many applications cannot agree on how to use this data. Microsoft’s Office suite can store and share extended file attributes, for example, but these live inside the file rather than in the file system. The promise of expanded Office attributes is only realized in conjunction with a content management system like SharePoint which lies above the lowly file system.

What if the storage system could keep this data instead? What if it could logically group files according to project or client, mining keywords and authors, and maintaining revisions? These concepts are not new, having been implemented in content management systems for years, and certain elements appeared in file systems, like Apple’s HFS and VMS’ Files-11, for decades.

Cut Down the Tree

File metadata would allow advanced features, but truly taking advantage of them requires a more fundamental shift in the way applications access files. Rather than sticking to a traditional hierarchy of directories in a tree (which was, after all, simply a primitive metadata system), we should remove the tree altogether. Allow files to become data objects, identified by arbitrary attributes and managed according to an overarching policy.

This future vision is decidedly different from our current notion of storage, but is not so far off. Many organizations now rely on central data warehouses based on SQL-language relational databases. As many storage managers have grumbled, databases tend to ignore storage management concepts entirely, managing their own content independently.

But not all applications need a database back-end, so another initiative seeks to provide generic object storage for wider use. Called content-addressable storage or CAS, these devices have traditionally been used only for archival purposes, since that was their first market application. As vendors break free of proprietary interfaces in favor of open ones like XAM, CAS could transform storage itself by eliminating both file and block storage at once.

Similar concepts are already at work in the so-called Web 2.0 world. Non-traditional databases like Google BigTable, Amazon S3, and Hadoop allow massive scalability for object storage. API-sharing initiatives with many Web 2.0 companies can be seen as similar prototypical object storage frameworks. Any of these could be leveraged to provide a new world of data storage, and many are gaining traction even now.

Stephen’s Stance

Although traditional block storage is here to stay for disk drives, and tree-type file systems are likely to remain the foundation of operating system storage, new object-based concepts could change the world in fundamental ways. As applications become “web aware”, they also become object aware, increasing the likelihood of such a storage revolution. For the majority of applications, this new world would be a welcome one indeed.

© sfoskett for Stephen Foskett, Pack Rat, 2011. | We Need a Storage Revolution
This post was categorized as Apple, Computer History, Enterprise storage, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

Servers, storage, and networks may be interconnected, but most large IT organizations keep the administrative teams from mixing. But the next-generation virtual data center might change that!

Lots of my IT infrastructure management clients are talking about how the advent of Ethernet/IP and virtualization is changing the roles of storage, server, and network administrators. The evolution of the storage role in particular in enterprise IT organizations has been a topic of particular interest to me for a while: I definitely remember thinking about this as iSCSI and Cisco came on the scene a few years back, but the question of integration of storage, server, network, and application management areas is as old as IT.

Back in 2005, I wrote a column in Storage magazine, asking Who Watches the SAN? Although there were (and still are) reasons one might consider handing SAN management over to the network team, such as the use of iSCSI, Cisco FC, or (soon) FCoE, I concluded that many network teams just aren’t ready to take on SAN management. Storage is different – extremely sensitive to latency and outages and burdened with interconnect concepts that are similar, but not identical, to their network cousins. So most people are better off leaving SAN management in the hands of storage people, regardless of whether their SAN is made up of FC or iSCSI.

The Virtual Data Center

Things are changing, however. The modern data center is evolving to virtualize all three major IT infrastructure components: Servers, storage, and networks. Over the last year or so, we’ve seen the first fully-virtual infrastructure built, with all three areas combined in a single box, soup-to-nuts. Consider a VMware ESX server with virtual servers talking over virtual networks to a virtual storage array from FalconStor or LeftHand – it’s an entire data center in a box!

Server admins are normally tasked with everything “in the box”, including VMFS and virtual network connectivity, just as they always had to manage volume managers and path management software back in the “physical server” world. I doubt this will change. So we could see not just storage but network folks excluded entirely from the next-generation virtual datacenter!

This doesn’t have to be how things end up, though. I strongly believe that network and storage pros have critical insight into their areas, and cutting them out would be a tragic loss akin to what happened when open systems folks decided not to pay attention to the lessons of the mainframe generation. We would effectively repeat a decade of experience and learning that could, with minor modifications, be brought right into the modern world.

There are three things to do:

1. Re-combine the stovepipe IT infrastructure organizations (server, storage, network) into a single management organization with specialists in these areas and others like virtualization and cloud computing.
2. Spend the time and money to cross-train everyone to re-apply their experience and skills in this new world. Storage folks, for example, must know a good bit about server virtualization or their skills will have much less value!
3. Bring the mainframe, security, and records management folks to the party, too! They all have essential insights, and a failure to give them a seat at the table would be a critical loss.

Database and Applications

Then there are the DBAs and IT application folks. These teams have always been held at arms-length in the open systems world, and much closer on the mainframe side (especially the database people!) I think there has been a feeling that there were enough interests at the IT infrastructure planning meetings already without mixing them in as well! The current response is a service-based approach, where IT infrastructure adds an analyst role to develop SLAs and standard service offerings and act as a liaison between ITI and IT Apps.

This is probably enough for a conventional system, but there are changes here as well. Virtual appliances can step right into the apps arena, and the database/storage hybrid devices from Oracle/HP, Netezza, and the rest tromp right through the DBA world. Then there are the “webby dubby” (Web 2.0) storage services/devices like Amazon S3, Nirvanix, and EMC Atmos to consider.

Stephen’s Stance

I think we’re seeing another serious change to the status quo: Right after the data center is virtualized and IT infrastructure is recombined, applications themselves will fundamentally transform, demanding a merger of the current IT infrastructure and IT applications groups. This could all come within five years, or it could be delayed or diverted by organizational infighting and intransigence. It will be very interesting to see how it plays out!

© sfoskett for Stephen Foskett, Pack Rat, 2011. | Changes in Technology Drive Changes in IT Organizations and Roles
This post was categorized as Enterprise storage, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

How granular is your storage? This question is just as relevant today as when I first published this article in 2008!

Many storage challenges focus on correlating high-level uses of data (such as applications) with the nuts and bolts of storage infrastructure. These discussions often revolve around the conflict between data management, which demands an ever-smaller unit of management, and storage management, which benefits most from consolidation. Developing data management capability that is both granular enough for applications and scalable enough for storage is one key to the future of storage.

Storage Management: Scaling Up

As I discussed in a previous Sunday Series piece, Turning the Page on RAID, the data storage industry has traditionally focused on reducing granularity. Disk capacity has expanded, and RAID technology has multiplied this by combining multiple physical drive mechanisms into a single virtual one. Storage virtualization technologies, from the SAN to the server, have also often been touted primarily as a mechanism to reduce heterogeneity. From a technical perspective, therefore, granularity has been an obstacle to overcome.

The core organizational best practice for storage management is the reduction of complexity and the enforcement of standardization. Consolidation of storage arrays and file servers is a common goal, as IT seeks to benefit from economies of scale. The goal of both initiatives is the creation of a storage utility or managed storage service. This mirrors efforts on the server and network sides to consolidate and virtualize hardware.

Although both technological and organizational factors have traditionally driven granularity out of storage, this does not have to be the case. Virtual pools of storage are ideal for providing storage on demand, as disk-focused RAID groups give way to more flexible sub-disk storage arrangements. And an operational focus on standardized storage service offerings has the potential to enable scalable management of these smaller units.

Filing Service

File-based protocols would seem to have more potential for granular storage management, but they have been undermined by the hierarchical nature of modern file storage. Whether the connection to a file server uses NFS, CIFS, or AFP, the key unit of management is actually the shared directory, not the file. All files in the share \\firefly\backups would be located on the same server and would be managed as a unit.

NAS virtualization can change this somewhat, as can more specialized NAS servers. Although Microsoft DFS enables consolidation and virtualization of NAS shares, it does not allow subdivision of shares below the directory level – all files in a directory must be placed on the same server. Tricks like stubbing and links allow for some movement, but these do not solve the core issue. Specialized virtual NAS devices from F5 (the ARX, nee Acopia), NetApp, BlueArc, Symantec, and others have the ability to move files individually, providing as much a virtualized storage environment as any block-focused enterprise array. Avere is also beginning to talk about granular file management.

But even an ideal virtualized file server lacks the kind of granularity demanded by users. They care about data, not files, and most applications consolidate their data storage into a few files. Consider a database, for example, where users want each record treated uniquely but storage devices see just a few much larger files. We need a storage revolution, where someone creates an ideal storage platform in which each individual record or object includes custom metadata and is managed independently. This would truly be a massive change, however, and it is not clear that all applications will follow the object storage model of Google and Amazon.

Small is Beautiful

Barring a revolution in data management, our best hope is to allow greater granularity in storage management. As mentioned above, virtualization technology has the potential to enable management and protection of any unit of storage, right down to the individual block or record. But the reality of storage virtualization has not matched its promise.

What is needed is greater integration. Each layer of virtualization (file system, volume manager, hypervisor, network, array, and RAID) also hides necessary details from lower layers. Consider the case of a virtual server snapshot: The application and filesystem must be in a quiesced state to allow a snapshot to be taken at the storage level, but the storage array has no intrinsic information about how its capacity is used. A given LUN might contain dozens of servers on a shared VMFS volume, so all must be snapped together.

Integration can be enabled by sharing more information through APIs. VMware leverages Microsoft Volume Shadow Copy Service (VSS) integration for shared storage so a VMFS snapshot can call the operating system and even applications (Windows Server 2003 only, for now) to prepare the data. Similarly, VSS can communicate directly with supported iSCSI and Fibre Channel arrays, calling a snapshot at the right moment. And Microsoft is, no doubt, enhancing VSS as we speak.

As virtualization technology matures, expect this type of integration to improve. We hope to see more APIs exposed by VMware and Microsoft, allowing communication up and down the stack to break through the information barrier. Imagine a future where a standard API like VSS can pass a message through VMware, Xen, and Hyper-V to the underlying storage array to initiate a snap. I predict that this kind of integration-enabled granularity is not too far off.

© sfoskett for Stephen Foskett, Pack Rat, 2011. | Granularity: The Hidden Challenge of Storage Management
This post was categorized as Computer History, Enterprise storage, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

My field of enterprise storage has its share of generally-accepted theories:

• Availability, backup, and archive form a Data Protection Trinity: They are unique requirements calling for focused solutions.
• The Rule of RAID: Combining multiple disk drives in creative ways allows us to change the inherent reliability and performance of the system.
• When it comes to storage management, Homogeneity is Paramount: A single storage administrator can manage thousands of identical systems but would be hard-pressed to support a half-dozen unique ones.
• The entire history of computing demonstrates that Connectivity Trumps Capacity when sizing systems: Performance bottlenecks always limit the scalability of storage systems.

Each of these theories underpins the our industy’s daily routine of storing and retrieving the data that drives modern society. These storage theories are also targets for innovation, with the best minds constantly trying to bend or break them.

This album of storage theories also has a B-side, however. These are the no-longer-true theories that have been transcended, as well as the dubious beliefs that were never really true.

• Commutability of Management and Cost is highly suspect: Unless one is considering only identical and homogenous systems, the total cost of ownership (TCO) or number of administrators associated with a given system (TB/admin) cannot be compared between environments.
• The Price of Parity: The impact of parity calculations and multi-disk commits used to kill write performance, giving RAID-5 a bad name. But write-back caches and array intelligence have all but eliminated this “write penalty” for modern enterprise systems.
• Whenever the high cost of enterprise storage is to be refuted, someone is bound to trot out The Dumb Disk Fallacy, claiming that per-GB array costs ought to be comparable to the price of a bare disk drive. But the value of enterprise storage has always been greater than the sum of its parts.

Over the next few weeks, I will be sharing focused articles about these “holy cows” of the enterprise storage world. I encourage everyone in the industry to join me in taking a step back and shining some light on these and other truisms. Which do you agree with or dispute? Are there other theories that I have overlooked?

© sfoskett for Stephen Foskett, Pack Rat, 2009. | We Hold These (Storage) Truths…
This post was categorized as Computer History, Enterprise storage, Everything, Gestalt IT. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

I'm pleased to have been invited to write and speak on storage topics for a decade

I’m pleased to announce that I will be presenting at all four of TechTarget’s excellent end user-focused 2009 Storage Decisions conferences in North America! I’m also very excited to be developning two entirely new sessions for the show:

1. Tools and Tricks to Manage Capacity – Knowing how much disk capacity you have allocated, how much is actually being used, and what remains are basics for disk storage management. But it can be difficult to measure and describe storage capacity and make smart and effective decisions. In this session, we’ll cover the tools and best practices that are key to managing disk capacity.
2. Radical Tiered Storage to Reduce Cost and Expand Service – “Do more with less” is the slogan of the year, but storage pros have been doing exactly this for years. From HSM to tiered storage, data is moving away from simple disks and landing on flash memory, tape, and cloud services. Adopting an expansive tiered storage policy will not only reduce costs but can also improve performance and introduce new capabilities.

The 2009 show dates have been released, with more information at the official Storage Decisions site. Admission is free for qualified attendees, so register now for the session near you!

• Chicago – June 1-2, 2009
• Toronto – June 16, 2009
• New York – September 22-23, 2009
• San Francisco – November 17, 2009

Long-time readers of this blog know that both topics are top of mind for me, and I’ll be updating this blog and Gestalt IT with content on both capacity management and tiered storage over the coming year as I progress through the development and presentation of this content.

I spent the last two years presenting on the topics of storage virtualization and email archiving, and previously presented a two-hour “storage 101″ session. Although I loved that content, I’m never satisfied with my own work, so I’ll be happy to develop these two new presentations from scratch!

© sfoskett for Stephen Foskett, Pack Rat, 2009. | Two New Storage Decisions Sessions for 2009: Capacity Management and Radical Tiered Storage!
This post was categorized as Everything. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

First, let’s clarify just which products and capabilities Symantec is offering here:

• Veritas Storage Foundation version 5.0MP3 for Unix/Linux includes SmartMove and the Thin Reclamation API
• Veritas Storage Foundation for Windows 5.0 only includes SmartMove at this point, but it will be updated to include Thin Reclamation at some point in the coming year

Although there is no real information on Symantec’s web site about all this yet, Symantec’s director of Storage Management and High Availability, Sean Derrington, assures me that their software is available now. Although no compatible arrays are in end-user hands, 3PAR will update their T-Class firmware to support the API shortly, and HDS and HP are on the way as well.

Thin Aware Software

Next, contrary to what I inferred from the announcement, there is no native thin provisioning capability in the file system or volume manager. So the first item in my list is right out. However, the volume manager is now “thin aware”, which means that it will communicate up to the file system and down to the array to coordinate more effective use of space.

When the volume manager is used with Veritas File System (VxFS) on UNIX or NTFS on Windows Server 2003 or 2008, it will automatically keep track of deleted files and will pass this information down the stack to the array. This is a major piece of functionality to add, especially to NTFS, “hole punching” (like NetApp) to maximize thin provisioning.

The Storage Foundation tools have also been updated to properly report on thin provisioned volumes. For example, the following screenshot shows three disk devices where encl1 supports thin reclamation and encl0 does not.

# vxdisk list
DEVICE        TYPE   DISK          GROUP         STATUS
encl0_0       auto   encl0_0       mydg online   thin
encl1_0       auto   encl1_0       mydg online   thinrclm
encl1_1       auto   ecnl1_1       mydg online   thinrclm

Thin Reclamation API

The Veritas Thin Reclamation API allows the Storage Foundation volume manager and file systems to communicate with thin-capable arrays when data is deleted on thin-ified LUNs, maintaining their thin-ness as you go. When a file is deleted, the file system will communicate to the volume manager that that space is no longer needed. When the server administrator runs the “vxdisk reclaim” or “fsadm –R” commands, the volume manager will communicate this information to the array (using SCSI commands) that any vacated disk blocks can now be reclaimed. Symantec expects folks to set up a cron job to reclaim space, or perhaps just run it when they see the need.

This is brilliant stuff, and ought to make thin provisioning shine in terms of array utilization. In an environment of thin-enabled Veritas volumes and supported storage arrays, the amount of space used on an array will be awfully close to the amount of space used in the file systems. This is a massive win - a capacity gain of on the order of 50%-70% in an average environment!

For more on this topic, see my recent post on storage utilization

If the storage array fully supports Symantec’s API, the tools will also report physically allocated storage behind thin and thin_reclaim devices.

# vxdisk –o thin list
DANAME        DISK SIZE(Mb)        PHYS_ALLOC(Mb)       DISK GROUP TYPE
encl0_0       2000                 50 mydg              thin
encl1_0       200                  50 mydg              thinrclm
encl1_1       500                  500 mydg             thinrclm

SmartMove

SmartMove is Symantec’s new capability for online migration from “thick” to thin LUNs. It is included in Storage Foundation for Unix/Linux and Windows and works with any thin storage array, not just those that support the API. This is basically a tweak to the old storage migration support we have all known and relied on in Veritas Storage Foundation for over a decade, except that it’s smart enough to not request blocks that it won’t use. One could theoretically “SmartMove” a volume regularly to reclaim space without using the API at all, but those commands are sure a lot simpler.

Note that SmartMove speeds up migration too, even for thick volumes! When you use a SmartMove-enabled version of Storage Foundation to move a volume, it will only send the blocks that have changed over the wire. This reminds me a little of VMware’s new I/O deduplication capability talked about at VMworld, but it’s focused only on migrations, not other I/O situations.

For more on this topic, see my recent post on VMware vStorage

The Plot Thickens

So I was wrong about one item, but the other two remain true. Is Symantec’s new capability a winner? I give it a silver medal – it’s good stuff, but some issues remain.

1. My primary concern remains – thin provisioning does nothing to address the lack of storage management that is so prevalent. It enables greater utilization of capacity, but does nothing to control how that capacity is used. This isn’t a beef with Symantec’s Veritas Storage Foundation or 3PAR or HDS or EMC or anyone in the thin industry, really. Instead, it is a wake-up call to all of the storage organizations out there who have filesystems full of uncontrolled junk!
2. My second concern is the lack of capacity management. Thin provisioning is a lie, promising more capacity than is available. This might be acceptable in certain controlled circumstances like operating system or application volumes, but telling end users that they have plenty of available space is a recipe for disaster. Storage use is like air – it expands to fill all available volume. Without capacity management, your thin volumes will be “overdrawn” and your storage “account” will be bankrupt.
3. Then there is the issue of proprietary APIs versus standards. Let me say right away that I always support standards over proprietary technology. But, at the same time, given the choice between nothing and something, I’ll take the proprietary API. Thin provisioning is a good idea with poor implementation. This API helps to make it useful in the real world, and having a market leader like Symantec behind it makes it all the more relevant. I certainly hope the entire storage industry will come up with a standard thin API, and when that happens I hope Symantec will support it. Until then, at least we have something.

I will be writing more about thin provisioning in the coming weeks. Until then, I continue to applaud Symantec, 3PAR, HDS, and HP for their work in making this technology somewhat more practical. Now how about VMware, Microsoft, Sun, and the Linux guys get some thin technology going, too?

See my posts on Gestalt IT for similar enterprise IT infrastructure commentary

© sfoskett for Stephen Foskett, Pack Rat, 2008. | Symantec’s Thin API: The Plot Thickens
This post was categorized as Enterprise storage, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

What’s Wrong With Thin Provisioning?

As I have explained in my storage seminars, thin provisioning is the opposite of what storage management professionals should be doing: Instead of managing usage, we just throw up our hands and say “you want 500 GB? Fine, you’ve got it!” while all the while only provisioning a fraction of that space. It’s a lie, and is thus bound to catch up with us sooner or later, and probably at just the wrong time.

People use disk space like money – their needs tend to expand to use up all they can get. Tell the users that you just added another 8 TB to the file server and watch their usage spike. Tell a database manager that they need to buy 20 TB and watch as their tablespaces magically start using 19. It’s human nature, and fighting this impulse to consume is precisely what management is all about. Traditional thin provisioning (or “virtual provisioning” in EMC-speak) does exactly this – it “tells” the downstream users of a storage resource that they have more capacity than is actually assigned to them and then grows capacity as it is used. To say that it is controversial is an understatement.

In certain instances, including Drobo and VMware growable disks, this can be beneficial since it’s a pain for most end-user OS configurations to resize a volume after the fact. In these special cases, I concede that thin provisioning is the right way to go. The same could be said for deduplicating or compressed storage – these simply have to be thin provisioned, since the actual allocation is completely abstracted by the compression algorithm. Thin provisioning can also help (slightly) for the OS volumes of virtual servers. But mainstream enterprise users have storage, server, and application managers, so they shouldn’t resort to “tricks” like thin provisioning – instead, they should manage their storage!

But the worst thing about thin provisioning is that it can’t un-provision storage. Let’s say a user uses your thin-provisioned file server as a temporary landing zone while switching to a new laptop. Or your database folks load their LUNs up with SQL dumps after an outage. Or your application folks fill up their test servers prior to going into production. Predictably, that thin-provisioned storage will expand, using up real disk capacity, to take the load (presuming enough capacity is available). The problem arises when they delete this temporary data – the storage array has no way of knowing that those blocks are no longer in use, so it cannot un-provision them. Suddenly your 500 GB thin-provisioned LUN is really taking up 400 GB even though it only has 20 GB of actual data on it, and you feel like a chump. Time to go manage your storage…

Zero-detection helps a little

Now back to 3PAR. Their new T-class InServ storage array has a special ASIC designed to attack a small chunk of the un-provisioning problem. It scans allocated storage, looking for blocks filled with zeros, and de-provisions them. This is nice – it’s a great tool to convert traditional storage to thin-provisioned storage. It’s also the first practical un-provisioning approach I’ve heard about, and might yield some capacity improvements for already-provisioned LUNs in certain special cases, though I’m not sure 3PAR is aiming for this market.

See, it’ll only work for zeroed-out storage, which is sadly extremely rare in the world of storage. It will detect capacity that has never been used, but most filesystems simply change their pointers when a file is deleted – leaving the data just where it was. 3PAR’s effort won’t work in this case. Even decommissioned servers often leave their LUNs full of old data, a security risk to be sure, and not a case that 3PAR could deal with, either.

The only way to make this work for already-used storage would be to add another step to the decommissioning process – zero out LUNs that are no longer in use as a way to send a signal to the storage array that it can un-provision that storage. But of course, we could also just send an email to the storage administrator to de-allocate the LUNs, leaving us in a much better position since we no longer have unused LUNs sitting on the storage array. Maybe we could modify the filesystem to zero out unused storage. Anyone have the source code for NTFS?

Seriously, though, this is a practical step in the right direction. We need better communication between applications, operating systems, and storage in order to enable lots of beneficial features. 3PAR is trying to enable some communication, and I applaud them for that. Just don’t expect too much.

© sfoskett for Stephen Foskett, Pack Rat, 2008. | 3PAR’s Thin Un-Provisioning is Slightly Less Bad
This post was categorized as Enterprise storage, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

So without further ado, I present three lessons on SAN storage:

• SAN School Lesson One: Building a SAN - In this first lesson of SAN School, I discuss the different types of storage arrays, switches, and software that make up a storage network.
• SAN School Lesson Two: SAN Architecture and Topology - In lesson two, I discuss the evolution of SANs from standalone entities, to islands and beyond. Discover techniques that can make a substantial difference in the way data is moved and processed, as well as in your company’s consolidation plans.
• SAN School Lesson Three: SAN Management and Security - In this Podcast, I explain what the options are for management tools. I cover array management, change management, virtualization and more to help you manage your environment. 

© sfoskett for Stephen Foskett, Pack Rat, 2008. | SAN School Podcast Series Posted
This post was categorized as Enterprise storage, Personal. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

Curious about the current state of SAN technology?  Stephen Bigelow of TechTarget interviewed me (last summer) about SAN options, and the video is now live on their BitPipe site.

Topics covered include combined iSCSI and FC SANs, ups and downs of modular storage and oversubscribed switches, next-generation SAN management applications, storage virtualization, and best practices for SAN design.

Here’s a snip – the three best practices for SAN design are as follows:

1. Choose reliable high-quality hardware
2. Build dual redundant networks
3. Protect management interfaces

Watch the whole video (it’s 17 minutes long) and let me know what you think!

© sfoskett for Stephen Foskett, Pack Rat, 2008. | Where the SAN Stands
This post was categorized as Enterprise storage, Personal. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.