Disk Is Dead? Says Who?

INTRODUCTION

Before we begin, I want to state right up front that I am not anti-flash, nor am I anti-hardware. I work for DataCore Software which has mastered the ability to exploit hardware capabilities for nearly two decades for the sole purposes of driving storage I/O. Our software needs hardware and hardware needs software to instruct it to do something useful. However, over the last the last year I have read a lot of commentary about how disk (aka. HDDs or magnetic media) is dead. Colorful metaphors such as “spinning rust” are used to describe the apparent death of the HDD market, but is this really the case?

According to a report from TrendFocus, the number of drives that shipped in 2015 declined by 16.9% (to 469 million units), however the amount of capacity that shipped increased by more than 30% (to 538 exabytes, or 538,000 petabytes, or 538,000,000 terabytes). In other words, a lot of HDD capacity.

Please note however, this is NEW capacity added to the industry on top of the already mind-blowing amount of existing capacity in the field today (estimated at over 10 zettabytes, or 10,000 exabytes, or, well, you get the idea). Eric Brewer, VP of Infrastructure at Google recently said,

“YouTube users are uploading one petabyte every day and at current growth rates that they should be uploading 10 petabytes per day by 2021.”

The capacity trend certainly doesn’t show signs of slowing which is why new and improved ways of increasing HDD density are emerging (such as Helium-filled drives, HAMR, and SMR). With these new manufacturing techniques, HDD capacities are expected to reach 20TB+ by 2020.

So, I wouldn’t exactly say disk (HDD) is dead, at least from a capacity demand perspective, but it does raise some interesting questions about the ecosystem of drive technology. Perhaps the conclusion that disk is dead is based on drive performance. There is no doubt a battle is waging in the industry. On one side we have HDD, on the other SSD (or flash). Both have advantages and disadvantages, but must we choose between one or the other? Is it all or nothing?

MOVE TO FLASH NOW OR THE SKY WILL FALL

In addition to the commentary about disk being dead, I have seen an equal amount of commentary about how the industry needs to adopt all-flash tomorrow or the world will come to an end (slight exaggeration perhaps). This is simply an impossible proposition. According to a past Gartner report,

 “it will be physically impossible to manufacture a sufficient number of SSDs to replace the existing HDD install base and produce enough to cater for the extra storage growth

Even displacing 20% of the forecasted growth is a near impossibility. And I will take this one step further, not only is it impossible, it is completely unnecessary. However, none of this implies HDD and SSD cannot coexist together in peace, they certainly can. What is needed is exactly what Gartner said in the same report,

“ensure that your choice of system and management software will allow for seamless integration and intelligent tiering of data among disparate devices.”

The reason Gartner made this statement is because they know only a small percentage of an organization’s data footprint benefits from residing on high-performance media.

THE SOLUTION TO THE PROBLEM IS SOFTWARE

One of the many things DataCore accomplishes with the hardware it manages is optimizing the placement of data across storage devices with varying performance characteristics. This feature is known as auto-tiering and DataCore does this automatically across any storage vendor or device type whether flash or disk based.

Over the last six years, DataCore has proven with its auto-tiering capability that only 3-5% of the data within most organizations benefit from high-performance disk (the percentage is even less when you understand how DataCore’s Parallel I/O and cache works, but we will touch on this later). Put another way, 95% of an organization’s I/O demand occurs within 3-5% of the data footprint.

While the 3-5% data range doesn’t radically change from day to day, the data contained within that range does. The job of DataCore’s auto-tiering engine is to ensure the right data is on the right disk at the right time in order to deliver the right performance level at the lowest cost. No need to wait, schedule, or perform any manual steps. By the way, the full name of DataCore’s auto-tiering feature is: fully automated, sub-LUN, real-time, read and write-aware, heterogeneous auto-tiering. Not exactly a marketing-friendly name, but there it is.

WAIT A SECOND, I THOUGHT THIS WAS ABOUT DISK, NOT FLASH

While DataCore can use flash technologies like any other disk, it doesn’t require them. To prove the point, I will show you a very simple test I performed to demonstrate the impact just a little bit of software can have on the overall performance of a system. If you need a more comprehensive analysis of DataCore’s performance, please see the Storage Performance Council’s website.

In this test I have a single 2U Dell PowerEdge R730 server. This server has two H730P RAID controllers installed. One RAID controller has five 15k drives attached to it forming a RAID-0 disk group (read and write cache enabled). This RAID-0 volume is presented to Windows and is designated as the R: drive.

The other RAID controller is running in HBA mode (non-RAID mode) with another set of five 15k drives attached to it (no cache enabled). These five drives reside in a DataCore disk pool. A single virtual disk is created from this pool matching the size of the RAID-0 volume coming from the other RAID controller. This virtual disk is presented to Windows and is designated as the S: drive.

DellOMSAThe first set of physical disks forming the RAID-0 volume as seen in the OpenManage Server Administrator interface – larger

 

DC_DiskPool
The second set of physical disks and disk pool as seen from within the DataCore Management Console – larger

 

Win_LogicalDrivesThe logical volumes R: and S: as seen by the Windows operating System – larger

DRIVERS, START YOUR ENGINES

I am going to run an I/O generator tool from Microsoft called DiskSpd (formally known as SQLIO) against these two volumes simultaneously and compare the results using Windows Performance Monitor. The test parameters for each test are identical: 8K block, 100% random, 80% read, 20% write, running 10 concurrent threads, with 8 outstanding I/Os against a 10GB test file.

DiskSpdDiskSpd test parameters for each logical volume – larger

The first command on line 2 is running against the RAID-0 disk (R:) and the second command on line 5 is running against the DataCore virtual disk (S:). In addition to having no cache enabled on the HBA connecting the physical disks presented to DataCore within the pool, the DataCore virtual disk also has its write-cache disabled (or write-through enabled). Only DataCore read cache is enabled here.

SingleVDWrite-cache disabled on the DataCore virtual disk – larger

PerfMon_1Performance view of the RAID-0 disk – larger

 

PerfMon_2Performance view of the DataCore virtual disk – larger

As you can see from the performance monitor view, the disk being presented from DataCore is accepting over 26x more I/O per second on average (@146k IOps) than the disk from the RAID controller (@5.4k IOps) for the exact same test. How is this possible?

This is made possible by DataCore’s read cache and the many I/O optimization techniques DataCore uses to accelerate storage I/O throughout the entire stack. For much more detail on these mechanisms, please see my article on Parallel Storage.

In addition to Parallel I/O processing, I am using another nifty feature called Random Write Accelerator. This feature eliminates the seek time associated with random writes (operations which cause lots of armature action on the HDD). DataCore doesn’t communicate with the underlying disks the same way the application would directly. By the time the I/O reaches the disks in the pool the I/O pattern is much more orderly and therefore more optimally received by the disks.

So now as any good engineer would do, I’m going to turn it up a notch and see what this single set of five physical so-called “dead disks” can do. I will now test using five 50GB virtual disks. Remember, these virtual disks are coming from a DataCore disk pool which contain five 15k non-RAID’d disks. Let’s see what happens.

DiskSpd_2DiskSpd test parameters for five DataCore virtual disks – larger

The commands on lines 8-12 are running against the five DataCore virtual disks. Below are the results of the testing.

PerfMon_3Performance view of the five DataCore virtual disks – larger

Note, nothing has changed at the physical disk layer. The change is simply an increase in the number of virtual disks now reading from and writing to the disk pool which in turn has increased the degree of parallelism in the system. This test shows for the same physical disks we have achieved greater than a 63x performance increase on average (@344k IOps) with bursts well over 400k IOps. This test is throwing 70-80,000 write I/Os per second at physical disks which are only rated to deliver 900 random writes per second combined. This is made possible by sequentializing the random writes before they reach the physical disks and therefore eliminating most of the armature action on the HDDs. Without adding any flash to the system, the software has effectively returned greater than flash-like performance with only five 15k disks in use.

Another important note. This demonstration is certainly not representative of the most you can get out of a DataCore configuration. On the latest SPC-1 run where DataCore set the world-record for all out performance, DataCore reached 5.12 million SPC-1 IO per second with only two engines (and the CPUs on those engines were only 50% utilized).

CONCLUSION

There are two things happening in the storage industry which has caused a lot of confusion. The first is an unawareness of the distinction between I/O parallelization and device parallelization. DataCore has definitively proven its I/O parallelization technique is superior in performance, cost, and efficiency. Flash is a form of device parallelization and can only improve system performance to a point. Device parallelization without I/O parallelization will not take us where the industry is demanding we go (see my article on Parallel Storage).

The second is a narrative being pushed on the industry which says “disk is dead” (likely due to my first concluding point). The demonstration above proves “spinning disk is very much alive”. Someone may argue I’m using a flash-type device in the form of RAM to serve as cache. Yes, RAM is a solid state device (a device electronic in nature), but it is not exotic, has superior performance characteristics, and organizations already have tons of it sitting in very powerful multiprocessor servers within their infrastructures right now. They simply need the right software to unlock its power.

Insert DataCore’s software layer between the disk and the application and immediately unbind the application from traditional storage hardware limitations.

DataCore drops SPC-1 bombshell delivering 5.1 Million IOps

The Fort Lauderdale boys have struck again, with a record-breaking run of 5 million IOPS, and maybe killed off every other SPC-1 benchmark contender’s hopes for a year or more.

DataCore Software, head-quartered in Fort Lauderdale, Florida, has scored 5,120,098.98 SPC-1 IOPS with a simple 2-node Lenovo server set-up, taking the record from Huawei’s 3 million-plus scoring OceanStore 18800 v3 array, which needs multiple racks and costs $2.37m. The DataCore Parallel Server configuration costs $505,525.24, almost a fifth of Huawei’s cost.

It is astonishing how SPC-1 results have rocketed in the past few years, as Huawei and Hitachi/HPE and Kaminario have sent results above the 1 million IOPS mark.

What seemed ground-breaking at first is now viewed as ordinary; a million SPC-1 IOPS? Okay, move on. Five million, though, is more than the previous top two results combined and comes from just a pair of hybrid flash/disk servers, not a super-charged all-flash array.

Find full article here: http://www.theregister.co.uk/2016/06/15/datacore_drops_spc1_bombshell/

Inline vs. Post-Process Deduplication: Good vs. Bad?

INTRODUCTION

Over the last several months I have spoken with many clients interested in deduplication. There is good reason for this interest, but one aspect of deduplication always gets more attention. The question of whether a solution performs deduplication via “inline” or “post-process” is always of significant interest. The prevailing mindset in the industry, it would seem, is that inline is superior to post-process. Let’s pull back the covers to see if there is any real truth to it. To ensure we are on the same page, let’s define these terms before proceeding.

CONCEPT REVIEW

Deduplication effectively gives you some percentage more usable storage capacity above the native capacity (albeit, this gain is highly variable based on the data types involved). You can either look at it as a given amount of data consuming less space, or the normalized approach of increasing the total effective usable storage space. In other words, if you reduce your data to 1/2 of the original size then you have effectively doubled (or 2x) your usable storage capacity.

Inline refers to deduplicating ingress data before it is written to the destination device. Post-process refers to deduplicating ingress data after it has been written to the destination device.

INLINE ANALYSIS

First let’s look at why a vendor would choose one method over the other. Take all-flash vendors for example which always use inline duplication.  Without some sort of data reduction, the economics of all-flash systems are not nearly as attractive. Besides the need to reduce the $/GB of all-flash (which makes a lot of sense in this case), there is another issue that deduplication must address. This issue is related to the inherent disadvantage that all flash solutions suffer from: write amplification.

Flash blocks that already contain data must be erased before they can be rewritten. Before the flash can be erased, existing valid data has to be moved prior to the erase. This ultimately causes many more reads and writes to occur for a single ingress write operation increasing response time and wearing. This is where inline deduplication comes in. The best way to reduce write amplification (which cannot be totally eliminated) is to reduce the amount of ingress data to be written. For all-flash systems there simply is no other choice but to use inline.

Not surprisingly however, there are costs involved. Placing another intensive operation in the I/O path before committing the data to the disk slows overall performance. This processing overhead coupled with the reality that write amplification cannot be completely eliminated leads to some unpredictable performance characteristics especially as the total amount of valid data increases on the system (which increases the metadata that needs to be tracked).

POST-PROCESS ANALYSIS

With systems that utilize post-process (mainly non-all-flash array systems) the performance impact is almost entirely eliminated. I say “almost” because the deduplication process needs to happen at some point and it does generate some amount of additional load (albeit, small). I say “small” because the impact of the eventual deduplication is mitigated by monitoring overall system activity to determine when the best time is to perform the operation thus minimizing contention. Interestingly, the net resultant data reduction is at least as good if not better than inline deduplication. Most importantly, the write commit response time as seen by the application is not impacted since the data is committed immediately with no intermediate operation standing in the way. This ensures the user and application experience is not negatively impacted when the write is initially generated.

The tradeoff here is that the capacity consumption is slightly higher for a period of time until the deduplication process kicks in. In today’s world where most shops have 10 or 100’s of unused TB’s, this is seemingly and increasingly a non-issue.

CONCLUSION AND RECOMMENDATIONS

It should be apparent by now that it is not really an issue of “Good vs. Bad”. It is more a matter of necessity on the part of the vendor. But, if we were to consider which method has the least amount of negative impact on overall system operation, post-process would seem to have the upper hand.

On a related note, one thing I would highly recommend being careful of is promises related to the actual data reduction ratio. Anyone saying they are going to reduce your data footprint without first knowing what the data consists of, is lying to you. The only guaranteed data reduction method I know of is a method that gives you 100% data reduction and it’s called FORMAT! (Kidding of course, please do not attempt this at home).

Below is an example of Microsoft’s deduplication and compression ratios based on common file types:

Scenario Content Typical Space Savings
User documents Documents, photos, music, videos

30-50%

Deployment shares Software binaries, cab files, symbols files

70-80%

Virtualization libraries Virtual hard disk files

80-95%

General file share All of the above

50-60%

Great candidates for deduplication:
Folder redirection servers, virtualization depot or provisioning library, software deployment shares, SQL Server and Exchange Server backup volumes, VDI VHDs, and virtualized backup VHDs

Should be evaluated based on content:
Line-of-business servers, static content providers, web servers, high-performance computing (HPC)

Not good candidates for deduplication:
Virtualization hosts (running workloads other than VDI or virtualized backup), WSUS, servers running SQL Server or Exchange Server, files approaching or larger than 1 TB in size

** Random writes are detrimental to the performance and the lifespan of flash devices. Look for systems that are able to sequentialize I/O which will help to reduce the write-amplification effect.

** There are tools available that will estimate your data reduction savings prior to implementation. Microsoft includes one with Windows Server 2012 if the deduplication services are installed (DDPEval.exe).

DataCore Announces Enterprise-Class Virtual SANs and Flash-Optimizing Stack in its Next Generation SANsymphony-V10 Software-Defined Storage Platform

Scales Virtual SANs to More Than 50 Million IOPS and to 32 Petabytes of Pooled Capacity Surpassing Leading Competitors; End-to-End Storage Services Reconciles Virtual SANs, Converged Appliances, Flash Devices, Physical SANs, Networked and Cloud Storage From Becoming ‘Isolated Storage Islands’

FORT LAUDERDALE, Fla.–(BUSINESS WIRE)–Amidst the pent up demand for enterprise-grade virtual SANs and the need for cost-effective utilization of Flash technology, DataCore, a leader in software-defined storage, today revealed a new virtual SAN functionality and significant enhancements to its SANsymphony™-V10 software – the 10th generation release of its comprehensive storage services platform. The new release significantly advances virtual SAN capabilities designed to achieve the fastest performance, highest availability and optimal use from Flash and disk storage directly attached to application hosts and clustered servers in virtual (server-side) SAN use cases.

DataCore’s new Virtual SAN is a software-only solution that automates and simplifies storage management and provisioning while delivering enterprise-class functionality, automated recovery and significantly faster performance. It is easy to set up and runs on new or existing x86 servers where it creates a shared storage pool out of the internal Flash and disk storage resources available to that server. This means the DataCore™ Virtual SAN can be cost-effectively deployed as an overlay, without the need to make major investments in new hardware or complex SAN gear.

DataCore contrasts its enterprise-class virtual SAN offering with competing products which are:

• Incapable of sustaining serious workloads and providing a growth path to physical SAN assets.
• Inextricably tied to a specific server hypervisor, rendering them unusable in all but the smallest branch office environments or non-critical test and development scenarios.

The Ultimate Virtual SAN: Inexhaustible Performance, Continuous Availability, Large Scale

There is no compromise on performance, availability and scaling with DataCore. The new SANsymphony-V10 virtual SAN software scales performance to more than 50 Million IOPS and to 32 Petabytes of capacity across a cluster of 32 servers, making it one of the most powerful and scalable systems in the marketplace.

Enterprise-class availability comes standard with a DataCore virtual SAN; the software includes automated failover and failback recovery, and is able to span a N+1 grid (up to 32 nodes) stretching over metro-wide distances. With a DataCore virtual SAN, business continuity, remote site replication and data protection are simple and no hassle to implement, and best of all, once set, it is automatic thereafter.

DataCore SANsymphony-V10 also resolves mixed combinations of virtual and physical SANs and accounts for the likelihood that a virtual SAN may extend out into an external SAN – as the need for centralized storage services and hardware consolidation efficiencies are required initially or considered in later stages of the project. DataCore stands apart from the competition, in that it can run on the server-side as a virtual SAN, it can run and manage physical SANs and it can operate and federate across both. SANsymphony-V10 essentially provides a comprehensive growth path that amplifies the scope of the virtual SAN to non-disruptively incorporate external storage as part of an overall architecture.

A Compelling Solution for Expanding Enterprises

While larger environments will be drawn by SANsymphony-V10’s impressive specs, many customers have relatively modest requirements for their first virtual SAN. Typically they are looking to cost-effectively deploy fast ‘in memory’ technologies to speed up critical business applications, add resiliency and grow to integrate multiple systems over multiple sites, but have to live within limited commodity equipment budgets.

“We enable clients to get started with a high performance, stretchable and scalable virtual SAN at an appealing price, that takes full advantage of inexpensive servers and their internal drives,” said Paul Murphy, vice president of worldwide marketing at DataCore. “Competing alternatives mandate many clustered servers and require add-on flash cards to achieve a fraction of what DataCore delivers.”

DataCore virtual SANs are ideal solutions for clustered servers, VDI desktop deployments, remote disaster recovery and multi-site virtual server projects, as well as those demanding database and business application workloads running on server platforms. The software enables companies to create large scale and modular ‘Google-like’ infrastructures that leverage heterogeneous and commodity storage, servers and low-cost networking to transform them into enterprise-grade production architectures.

Virtual SANs and Flash: Comprehensive Software Stack is a ‘Must Have’ for Any Flash Deployment

SANsymphony-V10 delivers the industry’s most comprehensive set of features and services to manage, integrate and optimize Flash-based technology as part of your virtual SAN deployment or within an overall storage infrastructure. For example, SANsymphony-V10 self-tunes Flash and minimizes flash wear, and enables flash to be mirrored for high-availability even to non-Flash based devices for cost reduction. The software employs adaptive ‘in-memory’ caching technologies to speed up application workloads and optimize write traffic performance to complement Flash read performance. DataCore’s powerful auto-tiering feature works across different vendor platforms optimizing the use of new and existing investments of Flash and storage devices (up to 15 tiers). Other features such as metro-wide mirroring, snapshots and auto-recovery apply to the mix of Flash and disk devices equally well, enabling greater productivity, flexibility and cost-efficiency.

DataCore’s Universal End-to-End Services Platform Unifies ‘Isolated Storage Islands’

SANsymphony-V10 also continues to advance larger scale storage infrastructure management capabilities, cross-device automation and the capability to unify and federate ‘isolated storage islands.’

“It’s easy to see how IT organizations responding to specific projects could find themselves with several disjointed software stacks – one for virtual SANs for each server hypervisor and another set of stacks from each of their flash suppliers, which further complicates the handful of embedded stacks in each of their SAN arrays,” said IDC’s consulting director for storage, Nick Sundby. “DataCore treats each of these scenarios as use cases under its one, unifying software-defined storage platform, aiming to drive management and functional convergence across the enterprise.”

Additional Highlighted Features

The spotlight on SANsymphony-V10 is clearly on the new virtual SAN capabilities, and the new licensing and pricing choices. However, a number of other major performance and scalability enhancements appear in this version as well:

• Scalability has doubled from 16 to 32 nodes; Enables Metro-wide N+1 grid data protection
• Supports high-speed 40/56 GigE iSCSI; 16Gbps Fibre Channel; iSCSI Target NIC teaming
• Performance visualization/Heat Map tools add insight into the behavior of Flash and disks
• New auto-tiering settings optimize expensive resources (e.g., flash cards) in a pool
• Intelligent disk rebalancing, dynamically redistributes load across available devices within a tier
• Automated CPU load leveling and Flash optimizations to increase performance
• Disk pool optimization and self-healing storage; Disk contents are automatically restored across the remaining storage in the pool; Enhancements to easily select and prioritize order of recovery
• New self-tuning caching algorithms and optimizations for flash cards and SSDs
• ‘Click-simple’ configuration wizards to rapidly set up different use cases (Virtual SAN; High-Availability SANs; NAS File Shares; etc.)

Pricing and Availability

Typical multi-node SANsymphony-V10 software licenses start in the $10,000 to $25,000 range. The new Virtual SAN pricing starts at $4,000 per server. The virtual SAN price includes auto-tiering, adaptive read/ write caching from DRAM, storage pooling, metro-wide synchronous mirroring, thin provisioning and snapshots. The software supports all the popular operating systems hosted on VMware ESX and Microsoft Hyper-V environments. Simple ‘Plug-ins’ for both VMware vSphere and Microsoft System Center are included to enable simplified hypervisor-based administration. SANsymphony-V10 and its virtual SAN variations may be deployed in a virtual machine or running natively on Windows Server 2012, using standard physical x86-64 servers.

General availability for SANsymphony-V10 is scheduled for May 30, 2014.

About DataCore

DataCore is a leader in software-defined storage. The company’s storage virtualization software empowers organizations to seamlessly manage and scale their data storage architectures, delivering massive performance gains at a fraction of the cost of solutions offered by legacy storage hardware vendors. Backed by 10,000 customer sites around the world, DataCore’s adaptive and self-learning and healing technology takes the pain out of manual processes and helps deliver on the promise of the new software defined data center through its hardware agnostic architecture. Visit http://www.datacore.com or call (877) 780-5111 for more information.

DataCore, the DataCore logo and SANsymphony are trademarks or registered trademarks of DataCore Software Corporation. Other DataCore product or service names or logos referenced herein are trademarks of DataCore Software Corporation. All other products, services and company names mentioned herein may be trademarks of their respective owners.

Contacts

Media & PR:
Horn Group
Joe Ferrary, 646-202-9785
datacoreteam@horngroup.com

Exploring how DataCore SANsymphony-V leverages DRAM and Flash differently

Introduction

I want to differentiate between two very important types of high speed storage devices within a DataCore SANsymphony-V node. The first is DRAM, or more generally, memory. The second is a solid-state disk or Flash device (referred to as SSD/Flash from this point forward). At first glance these devices may appear to have overlapping purposes. While they both serve to increase the overall performance within the system, they go about this in very different ways, each one providing benefits based on their design and fabrication.

DRAM vs. SSD/Flash


In general, cache is any storage medium that is used to reduce the amount of time required to move data in and out of a system. The movement of data blocks between application servers and the storage system is referred to as input/output (I/O). With this definition, DRAM and SSD/Flash could both fulfill this requirement. So what are the differences then? Simply put:

  1. DRAM is orders-of-magnitude faster then SSD/Flash.
  2. DRAM is volatile and SSD/Flash is non-volatile (DRAM requires power to retain the information stored therein, SSD/Flash does not).
  3. DRAM doesn’t have wearing or write amplification issues like SSD/Flash. DRAM’s lifespan is much greater than that of SSD/Flash.

Due to these significant differences, it is very important to leverage these technologies for tasks best suited for what they were built for.

DataCore High Speed Cache (HSC)


SANsymphony-V leverages main system board memory (RAM) as HSC in order to provide performance critical caching and I/O optimization functions. The RAM cache is extremely low latency, with a response time measured in nanoseconds, and provides four significant functions: write buffering, write coalescing, read pre-fetch, and read cache.



Write Buffering: The purpose of write buffering is to reduce the amount of time it takes to receive the I/O from the application server and acknowledge back that the I/O has been received. This type of buffering is also known as a Speed Matching Buffer. This eliminates any delay the application server may have experienced if it was writing to the back-end storage directly.

Write Coalescing: Under certain conditions, coalescing will occur whereby write I/Os are optimized into larger blocks before destaging to the back-end storage device. Destaging with larger blocks is a more efficient transfer method than with smaller blocks.

Read Pre-Fetching: During a read request from the back-end storage system, SANsymphony-V may also request adjacent logical blocks thereby by increasing the chances of near-future read cache hits against the related data set.

Read Caching: Either during a read pre-fetch or a write buffering operation, data will be staged in cache in order to reduce the amount of time required to retrieve the desired data blocks again in the future. By caching as much data as possible in memory (v9.x supports up to 1TB per node – a true mega-cache), the chances of a cache hit (finding the requested data block in cache) are greatly increased and therefore the overall application performance is significantly improved.

SSD/Flash Disk Devices


In the world of SANsymphony-V, SSD’s exist as persistent disk devices within a disk pool, similar to any other disk device, except with outstanding relative performance properties. SSD has very low latency, with a response time measured in microseconds. This allows SANsymphony-V to leverage the SSD device for acceleration AND storage capacity. This is notable since many storage platforms available today allocate the SSD device as a global cache device, thus preventing it from contributing to the total usable storage capacity.

SSD serves to enhance the write-coalescing/destaging and read pre-fetching operations performed by DataCore’s high-speed cache functions by providing a much faster downstream device, orders-of-magnitude faster than spinning disk. Traditional spinning disks have a response time measured in milliseconds.

In this scenario where SSD is participating within a disk pool that has auto-tiering enabled, the recommended amount of SSD really depends on how much high intensity (or hot) data you have. Some say 10% of total storage capacity, others say replace it all with SSD. Although you could certainly replace all your storage with SSD, most environments do not require this. This is because a very small percentage of the live production data is accessed with any notable frequency.

I would recommend estimating what the total amount of hot data is on your platform, add 20% for growth purposes, and use this value as the starting amount of SSD in the pool. Once the SSD is in the pool along with your traditional spinning disk, you can use the heat maps feature to really see how much hot data you have. SANsymphony-V will move all the hot data to the faster SSD. This is a perpetual process, but if you find that you have completely filled tier 1 with hot data and hot data remains on your lower tiers, then you may need more SSD in the pool.



You can see in the heat map shown above that the 10% value works very well. Tier 1 is not completely filled with hot-spots and there are no hot-spots in tier 2. This shows a good balance between SSD and spinning disk.

Conclusion: Importance of High-Speed Cache


Besides accelerating disk I/O within the system, HSC also increases system-wide reliability by reducing stress on back-end disks (whether spinning disk or SSD) thus decreasing hardware failures, eliminates the need for more drive spindles or lots of expensive SSD to achieve higher overall storage system performance, decreases platform footprint, and lowers power requirements. All of these benefits result in lower operating costs and higher application performance and reliability.

For more information about SANsymphony-V, please visit DataCore Software.

DataCore’s SANsymphony-V overcomes the shortcomings of DIMM and PCIe based Flash

From the ComputerWeekly article: Smart and Diablo launch Ulltra DIMM memory channel storage

Full article found here: Smart and Diablo launch ULLtra DIMM memory channel storage

I wanted to comment on one of the last paragraphs in the article:

ULLtra DIMM does, however, suffer the shortcomings of PCIe flash in that it is isolated without any method of sharing or protecting data between separate instances of memory channel storage in different servers. Spanjer said redundancy would need to be built in at the level of the application.

The point I want to make is, DataCore’s SANsymphony-V (SSV) is that application. You can not only protect data by providing redundancy across multiple flash modules within the server (whether it be DIMM-flash, SSD, or PCIe SSD), but you can also protect data through synchronous mirroring across the servers.

When SSV is installed on a server, it has access to all block storage devices connected to that server. SSV gives you the option to RAID-1 (mirror) those local block devices thereby protecting the data against failure (this is referred to as a Storage Pool Disk Mirror).

Additionally, SSV can provide the same level of protection across servers through synchronous mirroring. Of course SSV can provide both protection mechanisms simultaneously for maximum protection against failure.

I have only just scratched the surface of what SSV can do to safeguard your data. For more information about SANsymphony-V, please visit DataCore Software.

DIMM-connected Flash: The next evolution in flash acceleration

Well here we go again. But this time, we’re not talking about some new ultra responsive flash technology simply in terms of a new chip fabrication technique, but rather focusing on narrowing the distance between the flash memory and the CPU. This distance will be the focus of this article. You may ask, “why is that important?” (I’m glad you asked).

While it is true that not all flash memory is the same (SLC vs. MLC vs. TLC), that is only half the story. The rest of the story is how the flash memory is physically connected (and more specifically where it is connected) to the underlying system. There now exists four different ways to connect flash to a system:

The first method is direct attached. This involves connecting the flash memory to an internal storage port within the system, usually through some type of storage I/O controller.

The second method is array based. This involves connecting the flash memory to an external storage array, which has controllers of its own. These controllers are then connected to the system via a Host Bus Adapter (HBA).

The third method is PCIe based. This involves placing the flash memory on a PCIe card and connecting it via the PCIe slot within the system.

The fourth method is DIMM based. This involves placing the flash memory on a DIMM memory board and connecting it via the DIMM slots within the system.

The illustration below shows the various relationships described above:

General System Board Layout

With regard to the diagram above, you should immediately notice that the DIMM-connected option is the closest flash component to the CPU simply in terms of its electrical path. In order to communicate with the devices of the other three connection methods, the I/O to and from the CPU needs to traverse additional electrical circuits (on-board South-Bridge controller and additional controllers downstream from the CPU), therefore increasing latency for each operation.

So what is the bottom line? The bottom line is context switching, and more specifically Round Trip Time (RTT). Context switching is used to maintain the state of a process while waiting for a slower component of the system to respond (such as a disk). Context switching is generally considered to be expensive since it takes time to complete the switching operation (typically between 2 – 100 microseconds). The more time a process takes to complete, the slower the entire process runs. Pretty simple right?

Context switching is necessary in order to prevent holding up the entire system waiting for each process to complete. Without context switching, systems would not have the ability to multitask operations making the user experience extremely frustrating.

The motivation behind connecting flash at the DIMM slot is to reduce the number of context switches needed for each operation performed against the storage device. Below is a comparison of the number of context switches that are typically needed to move I/O through each connection method to the downstream storage device (these are general numbers and will vary based on manufacturer):

Connection Method Context Switches
Array Based 12-16
Direct-Attached 8-10
PCIe Based 2-4
DIMM Based 1-2

It is still very early in the DIMM-connected flash arena, but it offers some very exciting and affordable options for those looking to introduce flash into their environment. With all of these different flash options available in the industry, it will take an intelligent storage management system to efficiently coordinate access and unify all of these various storage devices (hint hint).