Now, as a member of the storage vendor community, I will answer for EMC. I will do so with detailed text from an outstanding TechBook I recently discovered on EMC’s Powerlink. This paper, Using Symmetrix Storage in VMware vSphere Environments (Version 7), provides incredible detail on the relationship between VMware thin disks and Symmetrix virtual provisioning. Its guidance is clear and simple.

My summary observations are as follows, with more detail below.

• The decision about thin/virtual provisioning is primarily a management one: trust your vSphere capacity management processes?  Use vSphere thin provisioning.  Trust your array capacity management processes?  Use virtual provisioning.
• VMware’s lazy zeroed thick disks reserve the space in VMFS.  But because blocks are left uninitialized until the first write, these disks are thinly provisioned in the virtual pool.  Choose this configuration when you have mature storage capacity management processes but questionable capacity management processes in vSphere.
• VMware’s thin disks do not reserve space in VMFS nor in the virtual pool.  This “thin-on-thin” configuration presents the most flexibility but requires mature capacity management in vSphere and the array.
• Even if your storage capacity management processes are mature, there are some cases where you may want eliminate the chance of an out-of-capacity problem.  This might be true with a mission critical application. In this case you have two options:
• Do not use virtual provisioning in the array, which may greatly increase your storage consumption.
• Use VMware’s eager zeroed thick disks on EMC virtual provisioning, which reserve capacity in VMFS and the virtual pool.  With VAAI, Enginuity records but does not perform the zeroing.  This means the zeroing is instantaneous and the block is reserved.

Here is a long quote from the TechBook, starting from page 128:

In general, before vSphere 4.1, EMC recommended using “zeroedthick” instead of “thin” virtual disks when using Symmetrix Virtual Provisioning. The reason that “thin on thin” was not always recommended is that using thin provisioning on two separate layers (host and array) increases the risk of out-of-space conditions for the virtual machines. vSphere 4.1 (and even more so in vSphere 5) in conjunction with the latest release of Enginuity integrate these layers better than ever. Consequently, using thin on thin is now acceptable in far more situations, but it is important to remember that risks still remain in doing so. For this reason, EMC recommends “zeroedthick” (for better reliability as only the array must be monitored) or “eagerzeroedthick” (for absolute reliability as all space is completely
reserved) for mission critical virtual machines.

It is important to remember that using “thin” rather than “zeroedthick” virtual disks does not provide increased space savings on the physical disks. As previously discussed, since “zeroedthick” only writes data written by the guest OS, it does not consume more space on the Symmetrix thin pool than a similarly sized “thin” virtual disk. The primary difference between “zeroedthick” and “thin” virtual disks is not a question of space, but a question of the quantity and capacity of the Symmetrix thin devices presented to the ESX server. Due to the architecture of Virtual Provisioning, binding more thin devices to a thin pool or increasing the size of them does not take up more physical disk space than fewer or smaller thin devices would although it does require a small amount more Symmetrix cache. So whether 10 thin devices are presented to an ESX host, or 1 thin device, the storage usage on the Symmetrix is essentially the same. Therefore, packing more virtual machines into smaller or fewer 128 thin devices is not necessarily more space efficient. Prior to ESXi 5, a single-extent VMFS volume was limited to approximately 2 TB and this led customers to use “thin on thin” to keep the number of devices presented to a host minimal as a way to ease management. “Thin” virtual disks allowed for fewer presented devices and a higher virtual machine density. Now with the larger allowable single-extent VMFS volume size in ESXi 5 (up to 64 TB) the need to add more thin devices is reduced as larger, more appropriately sized thin devices can be presented and used and expanded as necessary. With ESXi 5, customers therefore do not need to make the virtual disks “thin” in order to fit a large number of them on a single volume as it is no longer constrained by the 2 TB minus 512 byte limit.

However, as previously mentioned, VMware and EMC have recently ameliorated the practicality of using thin virtual disks with Symmetrix Virtual Provisioning. This has been achieved through refining vCenter and array reporting while also widening the breadth of direct Symmetrix integration through features such as the vStorage API for Storage Awareness (VASA—vSphere 5 only). Additionally, the slight performance overhead that existed with thin VMDKs
which was caused by zeroing-on-demand and intermittent expansion of the virtual disk as new blocks were written to by the guest OS has been significantly diminished with the advent of Block Zero and Hardware-Assisted Locking (ATS). The introduction of Storage Dynamic Resource Scheduler in vSphere 5 (SDRS) further reduces the risk of running out of space on a VMFS volume as it can be configured to migrate virtual machines from a datastore when that datastore reaches a user-specified percent-full threshold. This all but eliminates the risk of running out of space on VMFS volumes, with the only assumption being that there is available capacity elsewhere to move the virtual machines to. These improvements can make “thin on thin” a much more viable option—especially in vSphere 5. Essentially, it depends on how risk-averse an organization is and the importance/priority of an application running in a virtual machine.

If virtual machine density is valued above the added protection provided by a thick virtual disk (or simply the possible risk of an out-of-space condition is acceptable), thin on thin may be used. If “thin on thin” is used, alerts on the vCenter level and the array level should be configured.

If you want the full copy of this document, go to Powerlink and search for the paper’s title, “Using EMC Symmetrix Storage in VMware vSphere Environments”. If you change the “Filter by Content Type” drop-down to “Technical / White Papers” this document will appear first in your search.

Non-VI workload detected on the datastore

Or you may see the following warning in the vSphere client:

An external I/O activity is detected on datastore …

It is from this message that a bunch of smart questions arose from a former colleague of mine.  The bright guys at VMware–including Joey Dieckhans, a man I am very proud to have brought into VMware–provided a lot more detail about this situation.  There were so many interesting questions and answers that I will present a summary of our conversation in FAQ form.

What does SIOC do?

When VMFS volume latency passes a user-definable threshold, SIOC throttles throughput to the datastore.  Decreasing storage throughput should alleviate congestion on the datastore, hopefully resulting in a decreased latency.

What does this alarm mean?

If SIOC reduces throughput but latency does not decrease, SIOC assumes there is another workload driving storage IO to the volume and impacting latency.  This alarm informs the administrator that latency is not decreasing as virtual machine throughput is reduced.

How does behavior change once this alarm has been raised?

This alarm is effectively a sign that SIOC has given up and is no longer trying to throttle virtual machine access to the storage device.  This was deemed the proper behavior to guarantee that the virtual machines do not starve as non-virtualized workloads continue to access the shared datastore.

Has this alarm’s behavior changed in vSphere 5?

In Joey’s words, in vSphere 5 the SIOC alarm is no longer on a “hair trigger”.  It will make sure that there are several observed anomalies before raising the alarm.  This should reduce the alarm’s frequency, which was usually the result of a false positive.  Also, the alarm is no longer enabled by default in vSphere 5.  If you want to see it–and I recommend that you all do–you should enable the “Unmanaged workload detected on SIOC-enabled Datastore” alarm.

What type of configurations would raise this alarm?

In any environment where VMware is sharing storage with non-VMware workloads. Examples include two partitions on a LUN, or two LUNs in a RAID group, or two LUNs in a storage pool, or even two LUNs on different arrays but sharing common interconnect. The degree to which competing workloads will impact each other on a single array is highly specific to the workload and storage architecture. But since the alarm’s sensitivity was decreased in vSphere 5 the later possibilities of the above list are much less likely.

What does EMC recommend with respect to this alarm?

I do not want to speak for all storage vendors, but I think there should be no vendor-specific recommendation for this alarm.  Administrators should enable SIOC and they should be informed when SIOC is unable to provide its advertised value.  Administrators need not act on the alarm but they should be aware that SIOC has stopped trying. If SIOC functionality is required and this alarm is frequently raised, consider separating physical workloads to different pools or even arrays.

Where does SIOC run?

SIOC runs in the VMkernel using values configured by vCenter.  As a result, if vCenter goes offline SIOC will continue to function normally.

What exactly is done to throttle virtual machines?

Using the parameters passed to it by vCenter, SIOC can calculate the relative priority of each of the virtual machines on that ESX host.  SIOC can then parcel out queue slots based on relative priority of each virtual machine that shares the VMFS volume.

Is there a cool video that would put this feature to demonstration with clever graphics and a catchy song?

Why, yes!  See the video Joey created around SIOC’s release.

I will update this entry as questions arise.

First, let me quote what I know Steven got right:

Flash memory is the dominant underlying chip technology for solid-state storage. But solid-state disk drives are just one packaging option for flash.

Steven then explains that flash can be added to the enterprise in a variety of ways.  Today’s most common alternative to SSD is the PCI expansion card.  Steven next extols the benefits of PCI-based flash and the drawbacks of SSD-based flash.  These include:

• Simplicity of design in PCI flash.  No SCSI or ATA controllers needed for PCI flash.
• Improved performance of PCI flash, for lack of bottleneck-inducing SCSI or ATA controllers.

Steven then concludes:

In a decade, SSD will seem a quaint throwback while flash memory will roar ahead.

I doubt this conclusion.

First, the argument that flash in PCI is faster than flash in SSD because SSD controllers will always be a bottleneck is nonsense.  Those controllers are created in the same silicon that creates microprocessors.  They can be implemented as fast as the hardware that drives the PCI-e bus.  The reason why PCI cards are faster is because the PCI-e bus can support up to 16GB/s of throughput while no storage array (today) can drive a single connection beyond 10Gb/s.  There is no need to create an SSD disk that supports 16 GB/s of throughput because no flash can serve it and no array can deliver it.  This is an example of designing to the current needs and this limitation will change.

A Standard Interface Common In the US.

But more importantly, one of the things we have learned in decades of computer science is that interfaces matter. Interfaces endure. Examples abound of good interfaces outliving their initial implementations. Instead of deciding to throw away a design and start from scratch, we improve the implementation and keep the interface, even if it is sub-optimal. One such example is the x86 architecture. It seems that the entire world has nearly agreed that this interface is how we want enterprise operating systems to communicate to processors.

(The funny thing about x86 is that years ago Intel abandoned the basic principle of their early architecture: complex instruction set computing (CISC). They designed their processors so programming the CPU would be easy but implementing it would be tough. Decades later, Intel introduced decoders on their processors that effectively translated CISC instructions to RISC microcode. They simultaneously offered a “better” pure RISC/VLIW architecture in the Itanium line. But the industry responded loudly: stay with the x86 interface that an ecosystem has come to depend on.)

I believe hard drives should be thought of as an interface.  Not just the protocol and connection by which data is read and written, but also the form factor that humans handle and that hardware vendors build around.

Why is it that the industry likes the hard drive “interface”?  Consider the following:

1. Hard drives have reasonable high-density form factors.  They are uniform size, fully enclosed, and rugged enough that an exposed component will not snag on a sweater and break.
2. Hard drive interfaces (SCSI, SATA, SAS, etc.) are created to be used frequently.  They are designed to be plugged and unplugged.  Pull and replace a SATA plug a thousand times and the connector will survive.  Try pulling and replacing a PCI-e card 1000 times.
3. We have existing means of aggregating thousands of hard drives into an array.  Because of the capacity drain of more PCI devices it is tougher to scale PCI cards to the same limits.

As it turns out, familiarity with these abstract concepts is not needed to size flash in your environment.  The same principles that Intel and AMD apply in sizing microprocessor cache can be applied to storage.  There are generalizations that will suit the majority of deployments.

First, a little background.  In building EMC’s Fully Automated Storage Tiering Virtual Pools (FAST VP), EMC studies the access patterns of over 3,500 arrays.  We measured skew and performance, capacity and footprint.  We experimented with storage layout and FAST VP block sizes.  We tried two-tier and three-tier configurations and sized each to find a best fit for the average case.  The results are summarized in the following figure.

The EMC study that preceded the launch of FAST VP identified three basic tier configurations to improve performance and footprint in 94% of environments.

Of the 3,500 arrays we analyzed, 12% of the workloads met criteria that we describe as “heavy skew”.  This means 95% of the IO occurred on 5% of the data.  In these configurations nearly all the hot blocks can be stored in flash when it is sized to 3% of the storage footprint.  In “moderate skew” environments, the addition of 15% Fibre Channel maintained performance with a footprint only slightly larger than optimal.  ”Low skew” environments still showed improvement over flash-less configurations in both performance and footprint, while at the same cost.

It was this analysis that led us to recommend the low skew configuration for unknown environments.  This has the following benefits:

• The cost of storage is the same as the flash-less configuration.
• The footprint is half the size of the flash-less configuration.
• Storage will be at least 20% faster for 94% of workloads.  Because this measurement was provided at low skew, and higher skew environments will more heavily exercise flash, and performance will exceed non-flash deployments by more than 40% under some workloads.

EMC’s Tier Advisor can help you produce a more precise guide to size your storage tiers.  But it is not strictly necessary.  Deploying a three-tier architecture will improve your existing array by reducing footprint and improving performance.  And if your environment has anything above low skew, adding rotating disks will capacity and improve efficiency.  This works because you will be approaching the more precise tier mapping for your environment’s workloads.

This ends my three-part series on flash in the enterprise.  I will conclude the series where it began.  I fell in love with flash when I installed an SSD disk in my MacBook Pro.  The impact to my own user experience was so dramatic as to revolutionize my own thinking about the nature of storage.  If your mind has not yet been similarly transformed, go get SSD for your consumer computers right away.  And know that everything we can experience for our own equipment we can deliver in the enterprise, too.

This article will describe the theory behind optimal cache sizing.  Practical guidance will follow in part three, the last entry in this series. I will again lean heavily on Denis Vilfort’s presentation that I offer for download on my blog.

Every performance discussion starts with an “it depends”.  I will kick off this discussion on the characteristic on which flash sizing depends: skew (a topic I discussed once before). Skew is the degree to which different environments will touch different amounts of data. High skew environments will access 1% of their data 80% of the time. Low skew environments will access up to 10% of their data 80% of the time. This is depicted in the following picture.

Cache, flash or otherwise, can be thought of as a FIFO for data. As your users interact with their applications, they generate new data and touch old data. This places new blocks at the head of the flash FIFO, keeping them in SSD cache for a longer period of time. These blocks remain in that cache until newer data pushes it out of this logical FIFO.

Skew is a somewhat abstruse concept. But it is more easily understood when you think of it as a data cooling rate. The rate at which applications touch data can be described as cooling. High skew environments have high cooling rates, because the applications are spending most time on a little data.  This means a great deal of data becomes lightly used, or cool. Low skew environments have low cooling rates, because they frequently touch more data, keeping it warm. The following figure shows cooling in action.

At some rate–which we are leaving purely theoretical at this point–applications slough off a certain amount of data into the rarely used, or “cool”, category. This information should fall out of the flash FIFO and be relegated to lower cost storage. The above figure shows that data centers with a low cooling rate of 1.4% will take 120 days for 80% of their data to become cool. This means slowly cooling environments need larger flash-backed cache.

Cooling rate dictates the amount of flash needed in enterprise storage. Because flash for cache purchased today will be used for the array for the until the next storage purchase, environments with rapid growth of data require a higher percentage of flash on day one. But because cooling rate is non-linear, the amount of flash needed does not scale linearly with the data growth. In non-engineering jargon, this means that an environment with 100% year-over-year growth of data does not need twice the flash of an environment with 50% year-over-year growth.

This is better shown in the following figure.

You can now see that, assuming you have efficient flash usage via some technology like cache, you can predict your flash needs with only three variables:

1. The amount of data in your environment.
2. Your yearly growth rate of data.
3. Your cooling rate.

Two of these numbers are easy to find but cooling rate is not. In fact, it is so difficult that I am not sure it is even obtainable in most environments. But without it how are we to recommend flash purchases? The answer is simpler than you think and the subject of the final article in this series.

After this revolution of my own mind, I want to dedicate a few blog entries to the issue of solid state storage in the enterprise.  First I want to frame the problem that flash both solves and causes.  In the second entry I will introduce some of the theory behind flash sizing.  My last article will give you some very simple practical advice on how to use flash in your enterprise.

These entries lean heavily on a presentation EMC’s Denis Vilfort presented within EMC a few weeks ago.  I am providing a PDF version of that presentation on this blog for your own usage.

The fundamental problem that flash is solving is summarized in the following figure.

The speed of rotating disks is dictated by the time it takes the hard drive head reach data on the platter. These mechanisms–a spinning disk and a moving arm–are basically unchanged in the past many decades. Array performance has evolved through the introduction of DRAM cache, intelligent prefetch, clever file systems, and other techniques. But the metaphorical hands of all enterprise storage vendors were bound by the physics of spinning platters and actuating arms. While latencies in hard drive technologies have stuck in the milliseconds, solid state devices like CPU, memory, and flash have improved to microseconds and nanoseconds.

This huge chasm in performance between disk and memory increasingly devalued high performance servers. When storage becomes the bottleneck for a business application, the performance of a server becomes less important. VMware introduced the importance of capacity in server sizing by showing the world consolidation. But performance of data intensive applications was still dictated by storage.

The initial challenge of solid state disks (SSD) was their perceived high cost when compared to hard disks. I remember a couple years ago hearing EMC’s confused messaging around its enterprise flash disks (EFDs): “much more expensive but much, much faster”. Customers were left with a confusing, cost-benefit calculation to make a purchasing decision.

A year and a half ago that EMC started using a more clear message for flash: in some cases, it is actually cheaper than rotating disks. The key is to identify these use cases. This is best shown in the following figure.

Because of the exceptional improvement in latency, flash drives provide dramatically higher throughput on random access patterns than hard drives. When normalized by throughput–IOPS in the case of the above figure–flash storage is much cheaper than any hard drive.

But there is another angle to storage efficiency. Even “cheap” hard drive storage was never as cheap as people thought. When arrays aggregate striped disks to sum their maximum throughputs, utilization is low. Furthermore, in some performance environments hard drives were short stroked, which meant only a small, fast section of the platter was used so performance could be maximized. With low utilization and short stroking, hard drive efficiency is very low. This means the nominal cost of rotating disks is much worse than people realized.

The low cost of your hard drives depends on their high capacity utilization. But how can you drive high capacity utilization in an environment where you have a storage performance bottleneck? Obviously flash is the answer.

SSD storage can help you solve your utilization and efficiency problems with rotating disks. But this assumes that you and your storage can determine how much flash you need and how to use it. And that will be the subject of my next entry in this three part series.

This new API allows VASA-enabled arrays (such as EMC’s VMAX and VNX) to expose storage architecture details to vSphere. Instead of only seeing a block or file device with some amount of capacity, VASA allows vCenter to know about replication, RAID, compression, deduplication, and other storage features. With this new information VMware administrators can create storage profiles that map to volumes. Virtual machines can then be assigned storage by policy, and not just the availability of space.

This is a subtle change in the way applications are mapped to storage with a potentially very large impact to the efficiency of virtual environments. If you think about it, until the creation of VASA, administrators were forced to manually enforce the mapping between applications and storage. Mistakes in this mapping could result in critical applications residing on unprotected storage. The other mistake is when low priority applications find themselves hosted on very expensive storage backed by high performance media, replicated, and on the nicest arrays in the environment. The first mistake can mean data is lost in a failure. The second mistake means much more is being spent on storage than needed.

The promise of VASA is that applications will always be properly mapped to their ideal storage. This introduce a new mechanism for application deployment, where applications are deployed to storage based on policy which is enforced by vSphere. Policy-based deployment will be more efficient and suffer fewer mistakes. The potential value to customers is very large.

My expectation is that VASA will not immediately resonate among storage companies’ pre-sales teams the way VAAI did. And without storage companies pushing it, customers may not realize the incredible power of this new API. VAAI is simple and sexy and its value can be seen in a five minute demonstration, as Chad showed when vSphere 4.1 launched.

But VASA is subtle. How do you demonstrate the value of guaranteeing a print server does not end up on solid state disks? How do you quantify the cost of lost data from a mission critical application that was placed on unprotected storage? Because these questions are not easy to answer, I fear the world will not realize the might of VASA. But, day-by-day VASA will uncover mistakes and the word will spread of fortunes saved because of policy-based storage deployment. Some day VASA will be recognized as one of the great additions by vSphere 5.

Because some of the details are key to a proprietary technology, at my friend’s request I will omit some of the low-level details. Furthermore, VMware shared with me their intentions for future versions of vSphere that I cannot talk futures. Talk to your VMware representative under NDA and he can fill in the details on future products and their expected release dates.

Now that the boilerplate disclaimer is out of the way, let’s continue.

Regardless of virtual disk type–thick, thin, linked clone, whatever– from the guest operating system’s perspective it’s disk is a “normal” direct attached storage (DAS) disk. Operating systems play some tricks with this contiguous empty space and sometimes are just lazy about file placement. In the “tricks” category OSes will often place critical files near the disk’s edge to benefit from the faster read rates at the platter’s periphery. In the “lazy” category OSes will place new files in the first large unused space that is available. I learned this from my friend Bob Nolan at PerfectDisk (Raxco) during our joint work on guest defragmentation over a year ago. This lazy placement produces fragmented files and free space, both of which harm performance.

The point of this discussion on tricks and laziness is that file placement from the perspective of an OS user is arbitrary. But from the perspective of a vSphere administrator looking at a linked clone the result are minimally sized files. A curious admin will then ask: how does the mapping from the guest’s view to the VMDK work?

VMware has built above VMFS a management layer engineering calls the delta disk. (This is the same name used for snapshots’ delta disk files.) It is at the delta disk layer that guest IOs are mapped to the VMDKs on the VMFS volume. This mapping happens a very granular level. The delta disk tracks IOs that are small enough to avoid internal fragmentation for every IO size.

The benefit of this mapping process is that all IOs from the guest–no matter how logically distant they are from each other–can be placed contiguously in a VMDK. This is very good for storage efficiency. The downside is that the additional layer of indirection can increase latency for IOs. At its worse, one IO in the guest could result in many IOs at VMFS. The first to read the metadata contains the guest-to-VMDK mapping and then possibly many IOs to collect the data that may be spread throughout the VMDKs.

VMFS has for a long time buffered for linked clone metadata. This reduces the need to fetch metadata before every linked clone IO. Note that this is not the same thing as host-based file buffering, which has never been present in any version of ESX.

The fun thing about talking to VMware engineering is you learn all the amazing things they are working on in future releases. The bad thing about being a blogger is that I know all about these things but am prohibited from sharing them here. But for those of you with an NDA with VMware I recommend you buy your system engineer a beer and ask him to tell you about where VMware is going with VMFS. Linked clones are incredibly important to VMware’s strategy with end user computing (nee VDI) and VMware has some righteous plans for continued innovation with linked clones and a future version of VMFS.

And if you don’t have an NDA with VMware or access to a system engineer that can talk you through this stuff, try to attend VMworld this year in Las Vegas. I have no doubt that VMware’s engineering teams will be previewing all of these technologies if they have not already released them.

Many years ago I studied electrical engineering. I was an awful at it. Analog was never my thing. I much prefer ones and zeroes. But I challenge myself to think about electronics once every blue moon. So I decided to delve into SLC and MLC flash technologies to understand how they differ and why we should care.  The content below summarizes my online research and the little bit I remember from school. If you can add, correct, or update this article I would be happy to have your comments.

What is the Difference Between MLC and SLC Flash?

MLC flash uses many discrete voltage levels to store multiple values, or bits, per cell [1].  Single-layer Cell (SLC) technology uses fewer voltage levels to program a single bit of information to the cell.  MLC technology obviously produces greater density which means it stores more data cheaper.  But the higher density comes with a cost: MLC produces storage that is more sensitive to temperature changes, slightly slower, and more likely to fail than SLC flash.

SLC flash is ten times the endurance for write/erase operations [2].  At an average of 10,000 write/erase cycles an MLC flash cell will die.  SLC flash cells can sustain an average of 100,000 write/erase cycles.  But why do MLC flash cells fail more than SLC?

Why Do MLC Cells Fail More Than SLC Cells?

I am unable to find an answer to this anywhere on the web.  If you see one, I would love to read it.  But in the dark, dusty corners of my memory I remember enough about electronics to hazard a guess at this.  As I see it, there are two reasons why MCL flash should fail more than SLC: one reason is a statistical and the other is electronic.

The statistical argument is that MLC cells are being written two 50% more than SLC cells.  They will simply wear out sooner. An SLC cell is storing the value of zero or one.  When an application writes to the data being held by that cell there is a 50% chance that the cell’s value has changed and it requires reprogramming.  Because MLC flash stores two bits, there is a 75% chance that the new two-bit data differs from the existing value.  This means an MLC is written to 0.75 times for each 0.5 times an SLC cell is written. That’s a 50% increase.

The electronic argument is based on MLC flash programming requiring a wider range of voltages [3].  Higher voltages produce greater amperage.  This exacerbates electromagnetic migration.  And the higher voltage on the transistor’s gate will increase erosion of the polysilicon that separates the gate and the channel.  Both of these will result in circuit failure.

How Is MLC Being Made More Reliable?

Because MLC is so much more cost effective than SLC, industry innovation is improving MLC reliability.  Here are a few techniques I found online [4]:

• Hardware can level writes, which distributes writes throughout the device to avoid balance cell overuse and avoid hotspots.  This means an entire flash drive will tend to fail at once after a long time.  This as opposed to a small number overworked hotspots failing quickly.
• Hardware can include DRAM cache which can be used to coalesce writes, which decreases cell write count.
• Flash devices can be over-provisioned for error detection, correction, and dynamic bad cell replacement.
• There are also a variety of proprietary techniques from flash manufacturers.

One challenge with flash today is the lack of consistent and objective endurance measurements.  It is difficult for storage vendors to publish availability guarantees when the reliability of the underlying media is uncertain.  This means to support flash devices in its VMAX arrays–which are rated at six nines (99.9999%) availability–EMC has to do a tremendous amount of qualification of the devices. This qualification process should always mean that flash support in enterprise storage should consistently lag its support in consumer devices, where availability requirements are much lower.

Summary

No one denies that SSD storage is becoming more common in the enterprise. EMC’s support of MLC devices is only one of the items introduced by Project Lighting that will increase flash presence, producing better performing and more efficient storage. If you are interesting in learning more on the subject, follow the links below to the sources for this article. Also considering Googling “tlc flash” to see the higher density, less reliable Triple-layer Cell (TLC) that will certainly find its way to the enterprise after more innovation.

References

My information came from documents I found as a result of Google searches. Here are my recommendations for further reading.

1. http://www.smxrtos.com/articles/mlcslc.htm
2. http://www2.electronicproducts.com/Choosing_flash_memory-article-toshiba-apr2004-html.aspx
3. http://www.supertalent.com/datasheets/SLC_vs_MLC%20whitepaper.pdf
4. http://www.infostor.com/index/articles/display/1169849064/articles/infostor/disk-arrays/disk-drives/2010/july-2010/mlc-vs__slc_flash.html

But things started changing a couple years ago.  Through the heroic efforts of Chad Sakac, EMC stopped acting like it deserved the business of VMware’s customers and more like it had to earn that business.  I noticed this in the way we partnered at multiple EMC Worlds and VMworlds.  I started to hear EMC’s name mentioned when we were prototyping features and products like VAAI, SRM, and SIOC.  EMC employees started treating us more like partners than indentured servants.  And then EMC started releasing products that were making the lives of VMware’s customers easier.

Along this vein, I just watched Rick Scherer’s webcast on EMC’s integrations with VMware.  Watching that recorded demo put a wide smile on my face.  Wow, EMC, you have come a long way.

The recording is replete with forehead-smacking obvious improvements that VMware’s customers are going to love.  I snapped a few screenshots from the presentation and inserted them below with my comments. But if you want to see how much more easily your VMware environment can be managed with EMC you have to check out the full presentation.

Rick touched on the problem that VMware’s customers have been suffering through and I have been writing about for years: poor interlock between storage administrators and VI administrators. The VSI and Unisphere are major advancements in the fight to eliminate this problem. If you are an EMC customer, you should download the free VSI right away. And if you would like to have a vSpecialist help you with it just let me know. Anywhere in the world we have a vSpecialist near you.

Lastly, in addition to Rick’s great presentation, I will remind you of the great VMware/EMC integration demo released by an Indian vSpecialist named Shuja Mirza. Shuja’s video, which highlights Unisphere and the VSI, is embedded below. For more information on Shuja’s work and for a high resolution version of the video, see my previous post on the Shuja’s presentation.