Thin Is In -- Or Is It?
The downside of thin provisioning at the array level is not being fully articulated by any vendor.
Thin provisioning is all the rage in the storage industry trade press. Next to virtualization and de-duplication, it is being touted as a key technological innovation that will reduce cost, reduce risk, and green your IT infrastructure to boot.
The idea behind thin provisioning is as old as the hills, tracing back to IBM’s VM mainframe operating systems in the 1960s. It was first offered by StorageTek, prior to its acquisition by Sun Microsystems, in its Iceberg (mainframe) and Shared Virtual Array (SVA) (open systems) arrays. Later, thin provisioning (though it wasn’t called such at the time) was refined by DataCore Software, becoming a mainstay of its storage virtualization product, SANSymphony.
David Scott, 3PAR president and CEO, says he first coined the actual term at a Gartner symposium in June 2002. At the time, 3PAR was the leader of a group of up-and-coming array manufacturers seeking to add value to commodity gear by automating the management of storage capacity inside the array via built-in software. Since that time, vendors such as Compellent and Equallogic have introduced "intelligent" array products that incorporate thin provisioning functionality.
A few weeks ago, I heard a presentation by an IT manager in a state government office about the value of thin provisioning, which he was using on his Compellent array. Heading a small shop, the man explained that he had neither the staff nor the time to micromanage his storage capacity. He said that the thin provisioning features of his Compellent system meant that he didn’t have to.
With Compellent (as with most thin provisioning arrays) it is possible to over-allocate storage—that is, to allocate to applications and end users more capacity than is actually physically available on the array itself. The reason this is possible has to do with the way that many applications and operating systems use storage capacity, "reserving" more capacity than they need and holding the additional space hostage for future needs. Thin provisioning uses this allocated but unused space, making it available to other applications and users while spoofing the apps that reserved it into believing that it is still available.
It is a high tech "shell game" that some IT admins, such as the state IT manager, love and others disdain. The IT manager said he routinely allocated 100 GB to every server using the Compellent hardware, which was significantly in excess of the Compellent array’s physical capacity. Almost immediately, another IT manager in the room from a Fortune 500 financial services firm asked whether such a strategy was wise. What would happen, he wondered aloud, if there was ever the equivalent of a Wall Street margin call: a few space hungry apps want their reserved portion of disk space, only to find the space has already been thin provisioned to another application?
The speaker responded that there are "those problems that you read about in books about storage, and there is the real world." In his world, the problem simply never happens.
This position was reinforced by a technical speaker from Compellent, who said that such problems rarely if ever happen and that his product notifies the owner if the amount of space being thinly provisioned ever approaches a dangerous level so the customer will have adequate time to add more storage capacity.
Compellent offers its own array with expansion capabilities, while also supporting certain drive trays that the customer might already own, including those associated with older Network Appliance filers. Moreover, its Thin Provisioning technology helps enable the addition of capacity to the product without necessitating a reboot of the platform.
To avoid being caught up in an over-allocated state, vendors of thin provisioning arrays rely on workload forecasting algorithms to predict rates of data growth. This is what triggers messages to the owner that recommend when it is time to add disk drives. The problem with forecasting is that the patterns reflect past usage characteristics, not future spikes. What would happen if the "sudden margin call" described by the seminar attendee were to happen? The Compellent answer was simple enough: the application, and possibly the server that hosted it would probably crash.
Customers Still Uncertain
This uncertainty, while downplayed by vendors pushing thin provisioning in their interviews and press releases, is clearly still on the minds of consumers. According to a survey commissioned by MonoSphere last week, it remains a key impediment to the widespread adoption of the technology.
MonoSphere, which makes platform independent capacity monitoring software, asked 249 companies what they thought of thin provisioning arrays. According to the company, while 75 percent of 249 storage professionals cited increased utilization of storage hardware as the top expected benefit of thin provisioning, 77 percent indicated that the increased risk of running out of storage and added management complexity are major obstacles hampering the implementation or expanded deployment of this promising technology.
MonoSphere took this data to suggest that the safe way to deploy thin provisioning arrays was to deploy additional capacity monitoring software (MonoSphere’s) to watch over the thin provisioning process and to better predict potential capacity issues.
"This survey illustrates the increasing need for IT administrators to gain much better visibility into their current and projected storage usage to reduce the risk and complexity of implementing thin provisioning," said Frank Kettenstock, MonoSphere’s vice president of marketing. "MonoSphere’s storage capacity management solutions provide customers with the strategic insight they need to avoid the pitfalls of thin provisioning, allowing them to increase their deployment of this promising technology."
Interestingly, this seems to dovetail with another finding in the MonoSphere survey—both positively and negatively. Forty-two percent of respondents cited a lack of thin provisioning management tools as a reason for delaying their acquisition of arrays with this technology (good for products like those offered by MonoSphere), while 43 percent claimed that they were concerned that adding thin provisioning would add to the complexity of their environment. This might not be such a good thing for MonoSphere, since their claim seems to be that companies that deploy thin provisioning arrays then need to add another layer of management and monitoring to police the on-array utilities that are policing the capacity. Who will watch the watchers?
Still, there is probably something to the statement by the state government technologist. An IT manager might know to a degree of intuitive certitude that his workload doesn’t vary a great deal, and that sudden and unpredictable "margin calls" on storage are extremely unlikely. For such shops, thin provisioning might be trustworthy enough to garner its benefits in the form of reduced administrative costs and deferred storage purchasing, not to mention ease of provisioning, without losing a lot of sleep over its potential problems. EMC seems to think so: the company’s array of product announcements several weeks ago included a forward-looking statement that the company would be adding thin provisioning to some of its arrays by early- to mid-2008.
My take: thin provisioning is neither a panacea nor a remarkably new concept. Many of the benefits touted by makers of thin provisioning arrays are valid, up to a point. However, the downside of thin provisioning at the array level is not being fully articulated by any vendor. Adding to the uncertainty is the fact that vendors are not being very forthcoming about their secret sauce for modeling and predicting data growth, or for determining when capacity is over-allocated to such a degree that application data is being jeopardized. MonoSphere is correct with its arguments that more management will be needed, not less.
Your comments are welcomed, especially if you have experience—positive or negative—with thin provisioning arrays. Send them to me at firstname.lastname@example.org.