STEC may not have been quite ready to reveal their next-generation ZeusRAM solid-state disk (SSD), but they are demonstrating it anyway at EMC World in Boston this week. The ZeusRAM is a fundamentally different animal from the existing ZeusIOPS drive in one critical way: Rather than using flash memory for primary data storage, the ZeusRAM uses DRAM. This improves reliability and longevity and ought to raise the bar on performance as well.

STEC has introduced ZeusRAM, a SDRAM-based drive

The ZeusRAM is small (just 8 GB) but STEC claims massive performance: 80,000 IOPS for both read and write (versus 80,000 read and 45,000 write for the 6 Gb SAS ZeusIOPS) and 500 MB/s sustained read and write (versus 350 and 300 for the ZeusIOPS). These numbers are well beyond the capabilities of whole shelves of traditional hard disk drives.

Should it lose power, the ZeusRAM will de-stage its content to flash RAM using power stored on internal super-capacitors. This is a major differentiator from in-system RAM disks which require whole-system battery backup and software to de-stage.

STEC has not announced pricing or availability information for the ZeusRAM drive at this point. We noted much interest in the drive from EMC staff at the EMC World show, and would not be surprised to see the ZeusRAM show up in a future Symmetrix or CLARiiON.

© Stephen Foskett for Gestalt IT, 2010. | STEC Spills the Beans on ZeusRAM SSD
Read more posts categorized as Storage

Over the past few years I’ve been asked to troubleshoot and explain why cloning a virtual machine (VM) from a master template would take a longer time than expected more than once. Usually when I’m asked the virtualization admin is frustrated at the hypervisor. “This shouldn’t take this long. It needs to be fixed!” they say. “I definitely agree,” I say, “but let’s take a deeper look at what is happening here first before we flame the vendor’s help desk technician on the phone.”

So, this post is about taking a deeper look at where the master template VM resides versus where the cloned template is destined. My math my be a little off or may not account for every factor involved, but my point is to be close enough to demonstrate that the disk/array/LUN design is can be the culprit more times than not.

When I started this post I emailed for some help. I asked for a sanity check from some storage experts. I’ve been reasonably happy with my own answer until now, but I figured I do some research before adding the content to VM /ETC. I got back a single reply that I am paraphrasing: “Sounds about right. Let me think about it some more and if I can stump you with anything else I’ll let you know.” He never did so I’ll take that as a positive confirmation meaning “yes VM moron, it is that simple.” Good enough for me! If anyone can point out any other factors I am not properly accounting for please leave a comment.

The following is part of my email for help. It not only explains my test scenario but it illustrates the problem and resolution as well. At the end of this post I make some suggestions for bettering the time it takes to clone a VM.

The email for help

Oh wise and all powerful masters of the disk,

I humbly submit the following concept for your review. Guide me to a greater disk performance understanding when cloning a VM in VMware ESX environment.

Here’s the scenario:

• Cloning a VM takes a long time – 10 GB VM using only 3.5 GB of space takes roughly 45 min to an hour to clone.
• The master template and the clone reside on the same disk and NFS mount.
• Yeah, it’s a single SATA disk in a lab. I know, it should suck.

I’m trying to explain the expected speed of read and writes using the IOPs calculator here: http://www.wmarow.com/strcalc/

See the attached screen shot for the values I put in the calculator, but the results I’m interested in are:

• with 50% reads and 50% writes (master and clone on same disk) average throughput (MB/s) is 1.2
• I used 50% reads and 50% writes for the cache.

which means to me that

• 3548 MB / 1.2 (MB/s) = 2957 secs or 0.82 hrs.

Here’s the screen shot of the IOPS Calculator I linked in the email for help:

Suggestions for improvement

Obviously, the type/performance of the disks, the number of disks, and the type of array makes a huge difference. I should also point out that I am using 8 ms as the value for the seek latency. I’m not as focused on technical accuracy because my point is served without it, but changing this value makes a significant difference as well. If you want technical accuracy and more explanation about some of the numbers to use in the calculator check out these posts on the topic of IOPS and the impact on a virtual environment:

• http://www.yellow-bricks.com/2009/12/23/iops/
• http://vmtoday.com/2009/12/storage-basics-part-ii-iops/
• http://virtualgeek.typepad.com/virtual_geek/2010/02/solving-a-weird-slow-performance-cloning-issue.html
• http://vpivot.com/2009/09/18/storage-is-the-problem/

In my case, moving the VM template to another disk/array or increasing the number of disks used on my NFS server would help because the reads and writes would be separated when the cloned VM resides on a different disk/array and the number of IOPs possible would be increased with more disks. Yes, this post uses a single SATA disk as a simple example, but the point is hopefully clear. Use the same logic and math for shared storage scenarios, all storage protocols, any vendor’s storage device, and all RAID types. Plug those values in the IOPs calculator to calculate your own results.

My ultimate point is to make everyone think about how the disk/array/LUN design decisions impact the behaviors of the virtual infrastructure.

As an example, if my lab NFS server was using 6 SATA disks configured as a RAID 5 array the calculation for expected time to clone changes as follows:

• 3548 MB / 2.99 (MB/s) = 1187 secs or 0.33 hrs.

Better, right? Hey, it’s a basement lab. It’s supposed to suck!

© Rich for Gestalt IT, 2010. | Why Does Cloning A VM From Template Take A Long Time?
Read more posts categorized as Featured, Server Virtualization, Storage

Although it’s rare in the PC world, multipath I/O is not new in enterprise IT. I’ve been juggling paths to storage and networks as long as I’ve been a systems administrator, and that’s a bit longer than I care to admit. But the proliferation of technologies has made it difficult to understand path management. What’s the difference between “dual active” and “active/active”? Is “active/passive” really that bad?

What is Multipath? And Why?

The good old days: One device, one path

In the beginning, computers connected to peripherals and other computers through a single bus or channel and life was easy. Although one might mistake the names of the dominant printer connection (parallel) for some kind of multipath system when compared to the modem connection (serial), this was not the case. Only the bits traveled in parallel – the logical connection was a simple single path.

Early-90′s servers might confuse admins with two SCSI connections to a single device

Then things got complicated. The SCSI protocol allowed for multiple devices in a chain, and even for two different “initiators” (computers or controllers) to interact with these “targets”. Some folks even dual-attached devices to a single computer with multiple controllers.

Why would one device and one computer need more than one connection? It boils down to two factors:

1. Performance – I/O channels have typically been slower than the computer could handle, so multiple channels might be used to increase the amount of data that can flow in and out.
2. Reliability – If one connection failed, the other might still be usable, reducing the risk of an outage.

Late-90′s enterprise systems might have four or more paths to a single storage array

Pretty soon, enterprise computer architecture had gotten incredibly complex. I remember connecting a massive HP V-class server to an EMC Symmetrix with eight separate Fibre Channel cables. Each disk “LUN” showed up twice, and we had hundreds of them. We managed all of these virtual storage paths using HP’s PVLinks dynamic multipathing software. We used Veritas DMP and EMC PowerPath to do pretty much the same thing on Solaris and other UNIX systems.

Active/Passive to Active/Active

The earliest path management software provided two incredibly important functions: It figured out which of the SCSI targets it saw were actually different names for the same one, and it allowed the operating system to choose one and fail over to the other in case of an interruption. These were Active/Passive links – no matter how many paths were presented (and Fibre Channel switches sometimes presented eight or more), only one was active at any one time.

Modern systems have abstracted and virtual I/O channels, making path management much more important

But the EMC Symmetrix and similar high-end storage systems changed all this. Symmetrix storage was fully virtualized – the presentation of LUNs to servers was entirely disconnected from the actual disks and RAID sets in the array. This meant the Symmetrix could handle I/O requests across different paths and controllers for the same LUN. EMC and the rest responded with Active/Active path management software, allowing I/O to travel in parallel for the first time.

How is Dual Active Different?

Not everything called Active/Active is created equal. In fact, many supposed Active/Active setups really shouldn’t be called that since they don’t use both paths for all data. Instead, I like to call these Dual Active – both paths are active but with different data.

Consider the differences between the following two solutions:

A true active/active setup uses all paths for all data all the time

A “dual active” setup uses both paths, but each target is directed to one or the other

See the difference? Although the paths are active in both cases, they are not the same. Both approaches have merit, and neither is inherently superior, but they should have different names applied. Even active/passive has its place, since simplicity is often a virtue.

Dual Active Outside Storage

These same concepts apply outside the field of storage and I/O. Many server clustering systems use the same terminology, right down to the misapplication of “active/active” when “dual active” is more appropriate. It’s easy to miss the significance of this difference, but it can make more of an impact in clustering since CPU workloads are harder to balance.

Let me know what you think. If there is interest, I might dive into path management strategies like round robin!

© Stephen Foskett for Gestalt IT, 2010. | Multipath: Active/Passive, Dual Active, and Active/Active
Read more posts categorized as Storage

Chris Mellor over at the Register put an interview online with NetApp CEO Tom Georgens.

To quote from the Register piece:

He is dismissive of multi-level tiering, saying: “The simple fact of the matter is, tiering is a way to manage migration of data between Fibre Channel-based systems and serial ATA based systems.”

He goes further: “Frankly I think the entire concept of tiering is dying.”

Now, for those who are not familiar with the concept of tiering, it’s basically moving data between faster and slower media in the background. Clasically tiering is something that every organization is already doing. You consider the value of the information, and based on that you decide if this data should be accessible instantly from your more expensive hardware, and even at home you will see that as the value decreases you will archive that data to a media that has a different type of performance like your USB archiving disk or for example by burning it to a DVD.

For companies the more interesting part in tiering comes with automation. To put it simply, you want your data to be available on a fast drive when you need it, and it can remain on slower drives if you don’t require it at that moment. Several vendors each have their own specific implementation of how they tier their storage, but you find this kind of technology coming from almost any vendor.

Aparrantly, NetApp has a different definition of tiering, since according to their CTO tiering is limited to the “migration of data between Fibre Channel-based systems and serial ATA based systems”. And this is where I heartily disagree with him. I purposely picked the example of home users who are also using different tiers, and it’s no different for all storage vendors.

The major difference? They remove the layer of fibre channel drives in between of the flash and SATA drives. They still tier their data to the medium that is most fitting. They will try to do that automatically (and hopefully succeed in doing so), but just don’t call it tiering anymore.

As with all vendors, NetApp is also trying to remove the fibre channel drive layer, and I am convinced that this will be possible as soon as the prices of flash drives can be compared to those of regular fibre channel drives, and the automated tiering is automated to a point that any actions performed are transparent to the connected system.

But, if NetApp doesn’t want to call it tiering, that’s fine by me but I hope they don’t honestly expect customers to fall for it. The rest of the world will continue to call it tiering, and they will try to sell you a purple unicorn that moves data around disk types as if by magic.

© Bas for Gestalt IT, 2010. | “Storage tiering is dying.” But purple unicorns exist.
Read more posts categorized as Storage

I took part in a podcast last night that discussed the XIV platform.  One of the “key features” of XIV is the wide striping of data across all spindles.  It’s a concept we’re seeing more and more in contemporary storage hardware architectures and one that’s being shoe-horned into older storage arrays too.  Have you ever wondered what the point is?  Take a look at the following graphic.  It shows the number of write operations per RAID group, ordered by the busiest RAID group to the least active.  It’s real data from a real system.  What you see is the Long Tail effect, where a small number of RAID groups are doing most of the I/O.  In this example, 80% of the workload is performed by 50% of the RAID groups; only 3 RAID groups account for 20% of the workload.

The chart shows that in some array designs (typically the older Enterprise arrays), I/O distribution was not evenly balanced and so not all drives were being used to their full capacity.  This was mitigated by using tools to move LUNs or sub-LUNs around; alternatively concatenated devices like metas and LUSEs were employed to spread the load.

The only real solution to the I/O balancing problem is genuine wide striping.  Manual or even automated rebalancing, or the use of metas are just workarounds.  Once wide striping is in place, either more work can be performed or the number of spindles or their “quality” can be reduced, i.e. you can build a complete SATA array like XIV.

There are of course disadvantages to having your data more widely spread.  The most obvious is the increased risk of data loss when the RAID system fails – i.e. a double disk failure.  The wider the striping, the wider the impact.  The tradeoff is the benefit of increased performance.  You have to choose what level of risk/impact you consider acceptable versus the potential gains.

If you’re not doing wide striping today then you should seriously be considering it.  After all, you’re only harnessing performance capacity within the array that you’ve already paid for.

© Chris for Gestalt IT, 2010. | The Benefits of Wide Striping – Avoiding A Long Tail
Read more posts categorized as Featured, Server Virtualization, Storage

Ever since Microsoft and Intel declared that the combination of Windows and Nehalem could deliver over a million iSCSI IOPS, I’ve been curious about just how they did it. What black magic could push that many I/Os over a single Ethernet connection? And what was on the other end? Now Intel has revealed all in a whitepaper, and the results are surprising!

What iSCSI Did

Let’s review the test for a moment. In March, Microsoft and Intel demonstrated that the combination of Windows Server 2008 R2 and the Xeon 5500 could saturate a 10 Gb Ethernet link, pushing iSCSI throughput to wire speed. That’s 1,174 MB/s, right around the theoretical maximum of a ten-gigabit link, given a tiny bit of overhead. The pair reunited in January to show that this same combination could deliver an astonishing million I/O operations per second, too.

Both of these results are astonishing. Sure, many high-end Fibre Channel SANs and storage systems blast out gigabytes of data and millions of I/O operations every second, but these tests are much more focused. Benchmarks are perilous, but the folks at Microsoft and Intel devised a fairly clever and focused set. Rather than a “mine’s bigger” contest, the pair only needs to prove that iSCSI can play with the pros.

The side effect is a demonstration of the capabilities of Microsoft and Intel components. Microsoft showed off the capabilities of Windows Server 2008 R2, Hyper-V, and their software iSCSI initiator, while Intel can brag about the Xeon 5500 server platform and X520-2 10 Gb Ethernet Server Adapter with their 82599EB controller. Your mileage may vary, but it is possible to construct a true storage monster on an average server budget.

Intel Inside

Let’s start by looking at the configuration of the local end of the tested configuration. I’m a storage guy so I think of it as the initiator, but you might say it’s the server, the client, or the host. Regardless, the system under test (SUT) is what was put under the microscope. The configuration was a common one: A high-end computer packing an Intel Xeon CPU and 82599-based 10 Gb Ethernet adapter. Most data centers have a machine or two just like this one.

Looking closely, we see that the test in question relied on the following key components:

• Intel’s “Shadycove” S5520SC workstation-class motherboard
• The Intel Xeon W5580 CPU (4 cores, 8 MB cache, 3.20 GHz)
• 24 GB of DDR3 RAM
• Intel “Niantic” 82599EB 10 Gb Ethernet controller
• Microsoft Windows Server 2008 R2 x64

This combination would set you back about $7,500 – $450 for the motherboard, $1,500 for the CPU, 6 2 GB DDR3 SDRAM modules at $80 each, $1,200 for the Intel X520 NIC, and $4,000 for an Enterprise copy of Windows Server 2008 R2. Not cheap, but not an exotic server either.

Initiate and Optimize

The secret to push the tested system to perform like it did is in the optimizations in the server platform, the NIC, and Windows Server itself.

• The Xeon 5500 processor series includes many enhancements:
  • An integrated memory controller allows for faster RAM access
  • QuickPath interconnect (QPI) replaces the old front-side bus and enhances I/O off the core
  • A new I/O subsystem with PCIe integrated into the CPU
  • MSI-X expands the number of interrupts a PCI device can use
  • New instructions for on-board CRC-32C decoding, speeding up iSCSI digest processing
• The 82599 Ethernet controller also includes enhanced capabilities:
  • VMDq maps I/O queues to multiple cores and virtual machines, reducing I/O bottlenecks
  • Offload of TCP segmentation and receive-side coalescing
  • Interestingly, it does not appear that VMDc/SR-IOV was employed in the test
• Microsoft Windows Server 2008 R2 and Hyper-V are ready to use all of these features and more:
  • R2 uses multi-core CPUs more effectively in general
  • Receive-side scaling (RSS) spreads the I/O workload across all four Xeon cores
  • The iSCSI initiator now allows CRC digest offload (using the new Xeon command set)
  • Numerous “NUMA I/O” optimizations in the initiator
  • TCP/IP Nagle can be disabled in the registry
  • Hyper-V VMQ allows the network packets to be copied directly into the guest virtual machine’s memory

Whew! Put all of these optimizations in a blender and Hyper-V virtual machine iSCSI access will be twice as fast as before. No kidding!

Stay On Target

But we knew all of this back in January. We also saw that a Cisco Nexus 5020 switch was used to fan out to 10 software iSCSI targets. But until now there was no mention of what targets were used exactly.

The final footnotes in Intel’s whitepaper reveals that the storage backing the million IOPS test was none other than StarWind Software’s iSCSI SAN! It is unclear what led Microsoft and Intel to use this particular iSCSI target (the earlier throughput tests ran on NetApp filers), but it does speak to the quality of this product.

It is not clear how many disk drives were used, but I would guess that SSDs or ramdisks might have been employed to pull a million IOPS. Network optimizations are also not mentioned, though jumbo frames would not be a benefit in an IOPS test.

StarWind’s software runs on Microsoft Windows and creates a full-featured iSCSI target, complete with data mirroring, automatic failover and failback, replication, snapshots, and thin provisioning. The company prices their iSCSI SAN at $6,000 for two nodes and competes with the likes of DataCore and Open-E. But the StarWind solution seems at a glance to be more full-featured than these other offerings.

Try It Yourself!

I imagine many folks like me might be tempted to try to reproduce these results. More valuable would be a set of best practice guidelines for the deployment of software iSCSI in Windows Server 2008 R2 and Hyper-V environments. Given the relatively modest hardware involved, there should be nothing stopping us!

These test results also prompted me to get in touch with StarWind to try their iSCSI target software. I was pleasantly surprised to learn that they are currently offering free non-production licenses to VMware vExperts, VCPs, and VCIs as well as Microsoft MVPs, MCPs, and MCT Professionals. Many of my readers fall into one (or more) of those buckets, and I applaud the company for this offer. If only more companies realized the value in giving away test licenses to influencers and thought leaders!

© Stephen Foskett for Gestalt IT, 2010. | How Did Microsoft and Intel Get 1 Million iSCSI IOPS?
Read more posts categorized as Server Virtualization, Storage

HP recently commissioned Tolly Group to benchmark their BladeSystem c7000 against the Cisco UCS 5100. The short report focuses on two results, and reads like so many competitive benchmarks in the IT industry: Tolly focuses on metrics that highlight the strength of HP’s solution and the weaknesses of Cisco’s. I do not dispute the accuracy of these results, and HP and Tolly are doing exactly what tech companies do. But what’s the real value of pinpoint maximum-performance benchmarks like this?

0-100-0

Automotive media like Car and Driver and Top Gear frequently test the maximum performance of cars, racing to 100 mph or beyond, sliding around a skidpad, and slamming on the brakes. These tests can be enlightening when it comes to high-performance cars, and the punishing 0-100-0 test is especially impressive. But what’s the point of hammering an economy car or pickup truck like this? Maximal acceleration and cornering are entirely irrelevant to buyers of commuter cars and work vehicles.

Even though a given test can be conducted, it may not be enlightening. The Tolly report demonstrates two key findings:

1. Although 4-blade configurations perform the same under maximum stress, Cisco UCS performance declines with 6 blades while HP’s remains steady.
2. When using a shared blade uplink, Cisco UCS performance fell by half.

These are not startling results. Cisco blades sometimes need to share one I/O channel, and this can’t match the performance of an HP blade with dedicated I/O. Would it shock you to learn that a one-gallon bucket requires twice as many trips to the well as one that holds two gallons? Does it shock anyone to learn that a V6-powered Toyota RAV4 accelerates quicker than a four cylinder Honda CR-V? HP’s c7000 is bigger than Cisco’s UCS and offers more I/O channels, so HP beats Cisco whenever larger configurations with more I/O are tested.

Innocent Benchmarks

Greta examines the marks on an 18th century cooper’s bench

I’ll leave the deeper commentary on blade performance to experts like Kevin Houston and Martin Macleod, but these maximum-utilization benchmarks are only half the story. I’m much more interested in how the different approaches to I/O impact everyday (20%-40% load) performance and how oversubscription impacts performance as more blades are installed and workloads are moved around. In automotive terms, I’d like to know how well a car handles in the snow or how economical it is with three or four passengers. These real-world scenarios are much more telling than a test of a few blades under 100% load!

Clearly, HP wanted to call attention to specific shortcomings of a competitor’s product, and it was wise to do so with objective numbers instead of mudslinging and name-calling. I hope that future tests and releases include real-world workloads and logical configurations, not the extreme situation used in this report. The same lesson applies to all tech companies: Simple, objective tests of maximum performance are welcome, but customers need many more metrics!

Note: Along with 9 other independent bloggers, I attended HP’s Blades Tech Day in Houston on February 25 and 26. Most of my travel and living expenses were paid for by HP, and the company provided a small gift bag (pictured here).

© Stephen Foskett for Gestalt IT, 2010. | Innocence, Fairness, and Technology Benchmarks
Read more posts categorized as Networking, Server Virtualization

How fast can iSCSI get?

“Maximizing Hyper-V iSCSI Performance with Microsoft and Intel” might sound like another “blah blah” marketing piece, but a little birdy tells me that this webcast will drop a bombshell about iSCSI performance.

Lots of storage and networking folks don’t give iSCSI and Microsoft the credit they deserve. “iSCSI is cheap and easy,” they say, “but real performance requires Fibre Channel.” Those of us who have an open mind about such things know that this is simply not the case. The fastest SAN I ever saw was based on iSCSI, and Microsoft demonstrated wire-speed iSCSI over 10 Gb Ethernet in March. I never saw a Fibre Channel SAN (even an 8 Gb/s one) push over a gigabyte per second over a single link!

Still, ask the average sysadmin and they will tell you that iSCSI isn’t for high performance applications. That’s why folks should tune in to this webcast, as Microsoft and Intel knock down another iSCSI performance myth. Note that even though Hyper-V is called out in the title and description, this discussion is really about Windows Server 2008 R2 and applies equally regardless of whether or not you use Microsoft’s hypervisor.

Watch this space for a summary of the news immediately following the announcement.

• What: Maximizing Hyper-V iSCSI Performance with Microsoft and Intel webcast
• When: Thursday, January 14, 2010 8:00 AM Pacific Time
• Where: MSEvents.Microsoft.com
• Who: Anyone interested in high-performance storage and server I/O

© sfoskett for Stephen Foskett, Pack Rat, 2010. |
Microsoft and Intel Pushing iSCSI Performance Limits


This post was categorized as Enterprise storage, Gestalt IT, Virtual Storage. Each of my categories has its own feed if you’d like to filter out or focus on posts like this.

© Stephen Foskett for Gestalt IT, 2010. | Microsoft and Intel Pushing iSCSI Performance Limits
Read more posts categorized as Server Virtualization, Storage

Some discussions on twitter last week triggered the topic of performance relating to the Drobo’s. This is the 5^th consecutive post on Drobo Series of products.

To read other Drobo related posts:

Drobo S and DroboElite – Introduced 11/23/2009

Some very interesting articles on Drobo S and DroboElite

The Drobo Math

I totally love my Drobo but

PLEASE SEE THE ATTACHED PDF FOR PERFORMANCE DATA

Here are some performance stats collected with running Drobo as a direct attached storage and using some benchmarking tools to compile these results.  All the performance stats are collected using different criteria’s that can affect the performance of the Drobo. Also used various connection methods including USB and Firewire to obtain these stats.

The entire series of tests have been performed using Mac OSX 10.6.2 host with either USB attached or Firewire attached to the Drobo.

These results are limited to the Drobo and cannot be compared to the Drobo Pro or Drobo Elite or Drobo S.

The test were carried out with using various combination of drives, rebuilt data protection, best-case scenario, worst-case scenario, 1 drive, 2 drives, 4 drives, different drive cache & capacity.

Enjoy!!!

© Devang for Gestalt IT, 2009. | Drobo Performance Stats
Read more posts categorized as Desktop, Featured, Storage

I usually welcome discussion (and even argument) about the things I know best: There is always more to learn, and the best insights come through engaging those who disagree with us. But some ideas have been argued so well for so long that they deserve enshrinement. For example, although non-scientists like to argue about evolution and climate change, the scientific community no longer feels that their theories in these areas require much discussion. Like gravity and relativity, they have been accepted as a foundation upon which to build more interesting hypotheses.

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

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

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

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

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

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

© sfoskett for Stephen Foskett, Pack Rat, 2009. |
We Hold These (Storage) Truths…


This post was categorized as Computer history, Enterprise storage, Everything, Gestalt IT. Each of my categories has its own feed if you’d like to filter out or focus on posts like this.

© Stephen Foskett for Gestalt IT, 2009. | We Hold These (Storage) Truths…
Read more posts categorized as Server Virtualization, Storage