I began by introducing the core problem: Storage isn’t getting any cheaper, even though raw capacity is cheap. Then I talked about storage utilization and provisioning problems. Now we’re going to talk about thin provisioning.

So, what is thin provisioning? I imagine everybody can just figure it out by the name. It means that instead of allocating storage that we’re not even going to use, we don’t allocate it, and give it to somebody else.

All right. We’re done. Anybody have any questions?

Ok, you caught me. This is actually not how it works. This is how you would like it to work, but this is not how it works. This is the “vendor illustrated” version of how it works. So let’s talk about why thin provisioning doesn’t work this way.

Thin provisioning is problematic. What happens is I allocate some space and suddenly I need a lot more. Perhaps I have temporary requirements and suddenly my application is spitting out log files like crazy, filling up all my storage, and locking everybody out. Oops, that’s a problem. But it’s probably exaggerated by thin provisioning opponents.

One of the biggest technical issues for thin provisioning is not the provisioning part: It’s fairly easy for a storage array to allocate on request:

1. Operating system: “I need a block; here’s some data I want you to write.”
2. Storage array: “I’ll just start allocating now.”
3. But, the operating system never goes back and says “I don’t need that block anymore.”

De-allocating (de-provisioning) is the challenge of thin provisioning. And that’s something that has to be tackled. And the reason that I say that thin provisioning isn’t quite as bad as it used to be is because that problem is being addressed.

Another problem we’re going to talk about is chunk sizes and formatting conflicts. We’re also going to talk about application conflicts.

There are a lot of problems with thin provisioning, but it’s getting better. I’ve been talking about this for years. I actually had a version of this slide that I used in 2003 or 2004, right when 3PAR started really pushing thin provisioning. And at that point I was saying “hold you horses everybody.” Now I’m getting a little more friendly to thin provisioning.

I realized, after years of griping, that my discomfort with so many technologies comes down to this: If people are trying to solve a business problem with a technical solution, they’re going to fail. It doesn’t matter if you’re talking about thin provisioning or anything else.

If your problem is that the organization won’t give you funds to actually buy storage, so you have to steal it from the next project that comes along and then reapply that storage to other projects just to keep your growth up, well, then thin provisioning is not going to solve your problem. If your problem is that you can only buy once a year, or you can only buy when the EMC salesman gives you a super discount and leaves something on the loading dock, well, thin provisioning is not your problem. Your problem is somewhere else.

But if your problem is that you have file systems that don’t like to grow and shrink, or if your problem is that you have a standard size allocation unit that everybody has to use and it always leaves some space empty, you are in luck. These are technical problems and those are things that you can solve with thin provisioning.

I wrote more about this topic in Use Process Solutions For Process Problems, Technical Solutions For Technical Ones

So, just think about it. Are you trying to solve a business problem or a technical problem? And again and again you’ll see that technical solutions should be applied to technical problems and business solutions should be applied to business problems. And there’s no solution to political problems, so what can you do?

© sfoskett for Stephen Foskett, Pack Rat, 2010. | De-Allocating is the Core Issue for Thin Provisioning
This post was categorized as Enterprise storage, Gestalt IT. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

• How to improve the receptivity of the e-mail archieve message to management to overcome the biases you mentioned? Consider what management is interested in most: They don’t necessarily care about email archiving, but they will respond to well-presented solutions to business objectives like cost avoidance for litigation and e-discovery or future reduced spending on IT infrastructure (storage).
• How do you get things moving when Legal is sponsor and can demonstrate that one lawsuit discovery failure will be the same cost as the project? This would be an ideal scenereo. Legal probably already understands the high cost of e-discovery and potential risk of adverse judgement. Now demonstrate the ways that email archiving can help. But be realistic – an email archiving app will help with e-discovery, but is definitely not a complete solution. You will still need policy and process for hold and discovery, and may even need additional e-discovery tools.
• Have you seen standard or default retention periods for email, and how are they determined? I would not want to suggest standard or “rule of thumb” retention periods. In my experience with many organizations, I have seen such a wide variety of carefully considered retention schedules that I have come to believe that there is no such thing as a standard. However, I would like to suggest not making a too-short maximum (say, less than three months) or else you will drive end users to underground archiving to get around the policy. Such a short retention period can work for certain classes of messages (company picnic, lunch invites, mass mailings), but I can’t imagine a business where no one would need to keep messages longer. Try to be realistic in setting your retention, balancing productivity with compliance. Setting retention periods is an exercise in consensus building, with representatives from IT, Legal, HR, Compliance, and others each contributing their own needs. It’s doable, though – I do it for a living!
• How many years back do people hold on to mail typically? Most organizations lack standards or policies for retention, so their typical retention varies based on employee actions. When they do have retention policies for email, they tend to classify messages (by organization or user, keywords, or through user action) into a few “buckets” with appropriate retention for each. Most have short retention (3 to 9 months) for some content, and longer retention (on the order of a few years) for other types. Most also have a “keep forever” category for special record types.
• Do you have an opinion on whether journaling is better or not for meeting legal requirements? Most legal groups desire the most complete set of messages possible. Both journaling and log shipping should meet this need.
• Have you seen much use for email archiving for supporting Audit to prove that an event was reviewed and approved? Many organizations use email as part of their workflow. In these cases, maintaining a complete set of messages is critical for audit and compliance. Many certainly do use email archives for this purpose, while others prefer to route such approvals to other content management systems to maintain these records.
• Is there a legal argument to be made that getting rid of pst files and having a central archive will help with privacy law issues? Decentralized personal archives like PST files are a privacy nightmare waiting to happen – they are highly mobile, can be copied and viewed easily, and tend to “live” on theft-prone devices like laptops and portable drives. Replacing PST files with a centralized archive has many many benefits, and the reduced risk of privacy breaches is certainly among these. However, most mail clients still maintain offline caches of mail server (and archive) data, so simply replacing PST with an archive will not elimate the privacy risk.
• You might want to mention that accelerating volumes of stored email are not necessarily bad because it is electronic and therefore searchable. Offline stuff dumped into file servers with no meta data is actually more of a nightmare because no one knows who created it or why it is needed (or not). Adding structure to electronic stored information is always valuable, and email archives certainly do make that data much more organized and searchable, along with enabling retention policies to be applied (assuming they exist!) Unstructured data on file servers is indeed a nightmare, and can pose a serious risk. There are other tools to tackle this type of data, however, and they might do a better job than relying on an email archive as a primary repository of critical records.
• Can you elaborate on user training needs? I was under the impression that changes to the end user were minimal. The amount of impact an email archiving system has on end users can vary from minimal to significant, based mostly on how much user interaction is desired for classification. However, even the most unobtrusive system is likely to change certain aspects of user behavior, from PST files to searches to stubbing and deletion of messages. Therefore, training is probably needed with every email archiving implementation.
• Litigation holds can last for YEARS !! Tape is DEAD especially to try to rebuild mail boxes. Tape remains non-dead for certain applications like backup, despite years of prognostication. However, you are correct that e-discovery of data on tape is incredibly difficult and time-consuming for most systems. There are tools to help, but an online archive is vastly more flexible and speedy than recovering backup data from tape. I’ve seen backup-sourced e-discovery costs rise into the millions of dollars, too!
• How important is classification in an archive solution? The importance of classification depends on the business objectives that an archive is meant to serve. However, most implementations will require at least some message classification mechanism in order to determine how long different messages should be retained, since a one-size-fits-all retention schedule is unlikely to meet anyone’s needs. Therefore, it is important to begin developing an overall record retention policy for email when implementing an email archive, and to consider how messages will be classified. Classification of email messages is a complicated topic – worthy of its own webinar at least!
• We are a globally dispersed organization which increases the complexity and cost. Do you feel implementation is an all or nothing scenario or does it make sense to focus on domestic and large campuses and then in a second phase chase funding for remote and international sites? Dispersed organizations face many unique technical challenges, especially when implementing email archiving. Certainly it is better to have some archiving than none at all, but unless your retention requirements are also segmented by geography, focusing on only a single location can be risky. I’d definitely suggest starting with the biggest fish, but you will probably have to get to everyone fairly soon afterward.
• Are there solution that do both email and file data (shared folders) archiving? Yes, some email archiving products also do file archiving. However, some choose to implement these functions separately to keep one from standing in the way of the other – it’s more important to have some archiving than to wait and wait for a complete solution.
• Not to mention, extremely short retention periods for email messages will NOT allow an enterprise to comply with litigation hold needs… Once a litigation hold is ordered, all retention schedules for covered data must be suspended. Therefore, a short retention schedule does not necessarily preclude compliance with a legal hold order. However, unreasonably short retention will not look good in court!

© sfoskett for Stephen Foskett, Pack Rat, 2008. | Answering Your Email Archiving Questions
This post was categorized as Enterprise storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.