Pragmatic IT

IT Infrastructure and Software Development from the Customer's Perspective

The Case for SAN Part II

When I did a total cost of ownership calculation for SAN-attached disk arrays during a recent assignment, the biggest factor in favour of SAN was the usage factor. With direct-attached disk on servers, you typically over-allocate the disk by a wide margin, because adding disk at a later time is a pain. With SAN-attached storage you can pop some more disks into the disk array and, depending on the operating system, you can increase the storage available in a relatively easy way.

Therefore if you manage your SAN-attached storage on a just-in-time basis, you can achieve perhaps 80 percent utilization of the disk, whereas in a typical group of servers using direct attached storage you might have 20 percent utilization. This four-t0-one price difference is significant.

Earlier I calculated that there’s roughly a ten to one difference between consumer disk and the top-of-the-line SAN disk in at least one manufacturer’s offerings. So a four-to-one price difference goes some way to fixing that, but not all the way. And to chip away further at the disk usage argument, a lot of the disks that contribute to the 20 percent utilization number are the system disks on small servers. These days you can’t get much less the 72 GB on a system disk, and most servers need far, far less than that. My technical experts recommend that you don’t boot from SAN, so you’ll still have that low utilization rate even after installing a SAN.

I’m not making much of a case for SAN, am I?

Decision Making Without All the Facts

When I read my previous post, I got the feeling that I was saying you needed an objectively measurable financial benefit in order to justify using SAN-attached storage. All my experience in IT has shown that you make no progress if you wait for all the questions to be answered. So reading my post got me thinking, how do I decide when I have enough information to move forward?

That reminded me of another recent project I led, where we set up a VMWare farm, then over the course of half a year virtualized over 130 physical servers and created about 70 new virtual servers. With minimal research we had established that VMs were C$380 per month cheaper, based on hard, quantifiable data (floor space lease, power consumption, server lease, and server maintenance). That’s a savings of C$76,000 per month.
The Case for SAN Part I

One pays more than ten times as much for storage on a big SAN-attached disk array than one does for direct attached storage (DAS). A raw terabyte of disk to put in a desktop computer casts about C$400. Storage on a SAN-attached mid-range disk array from one manufacturer costs about C$17,000 per raw TB. Storage on another manufacturer’s low-end disk array costs about C$7,000 per raw TB. (Those are prices for health care, so a business could expect to pay a fair bit more.) And for SAN-attached storage you also have to pay for the SAN network itself, which can cost about C$3,500 per port for quality equipment.

Of course, you don’t buy a big, SAN-attached disk array for reduced cost per TB. You buy it for some combination of:

  • lower total cost of ownership
  • reliability
  • availability
  • manageability
  • performance
  • the brute capacity to store multiple terabytes.

However, $10 to $1 is an awfully steep premium to pay for those advantages. Before you make that significant investment, you need to evaluate whether you really need those advantages, and in some cases whether you’re really going to realize the benefits.

A few examples will show what I mean.

How about availability? I’m aware of a disk array manufacturer that doesn’t support a hot firmware upgrade for one series of disk arrays (they say you can do it, but you have to sign a waiver for any data loss during the upgrade). The upgrade itself takes very little time, but you still need to shut down all the servers that connect to that disk array, and then start them up and test them after the upgrade. If you have fifty servers connected to the disk array, you’re looking at an hour or more to shut them all down, and typically more than that to start them all up again. Suddenly your uptime numbers don’t look so good anymore. And heaven help you if the users of those fifty servers have different preferred downtime windows, as was the case in my experience.

Reliability? In one year, in a population of four disk arrays of the same model, there were three significant unplanned downtimes, including one with significant data loss. (The data was eventually recovered from backup.) From sources inside the manufacturer of that disk array, I’ve heard that they’ve had a data loss event in almost one percent of their installations.

In a population of two disk arrays from another manufacturer, one required periodic reboots from the day it was turned on until the firmware was upgraded. Why did one work fine and the other not, in similar although not identical environments? The reality is, disk arrays are big, complicated pieces of IT and there’s ample opportunity for software defects to manifest themselves in production use.

So far I’m not making much of a case for SAN-attached storage. I believe that one challenge with SAN is that it’s sold as the solution to all problems, when in reality it has the potential to create two new problems for every one it solves. I think SAN-attached storage has its place, and in many cases it’s the only technology that can do what we need. In follow-up posts I hope to give some guidelines that I think would help you realize the benefits of SAN and to avoid the pitfalls.

As always, I’d like to hear from you about your experience. Please leave a comment on this blog.
Introduction to Pragmatic IT

In this blog I’m going to write about issues that I run into when trying to implement information technology in the real world. Most of my life has been spent as a software developer, but over the last few years (and at certain times in the past) I’ve worked on the infrastructure side. I started in IT when an IBM S/370 (predecessor of the computer that my son Marc is standing beside) filled a room.

Archive