SAN versus Individual Servers

[Steve_597]

Hello,
We have a debate going on within our IS department. The controversy surrounds whether or not to go with a SAN or DAS for consolidation of apps and sql databases. APP/Dev says the SAN will have terrible I/O performance and prefer larger/fewer servers with DAS or attached drive cages. Networking Services says the opposite preferring the SAN with fewer servers. Net Svcs also loves the Virtualization/snapshot, backup, and DR possibilities with a SAN environment.
Any thoughts?

Thanks,
Steve
Mpls

[Ivan Ferreira]

One of the features of the SAN is the capacity of expasion. You can grow the SAN and make the storage available to the servers any time you want, without too much complications.

I agree with the features described by your Net Svcs. Disaster recovery is a major point of consideration.

A switched SAN has excelent performance.

Maintenance and servicing on a SAN environment is more easy too.

Clustering and data sharing posibilities are other benefits of the SAN. You can clone a disk and present to other host to do backup jobs for example.

Replacing an existing server is easy to, because the data is in the SAN, not in the server. So replace the server, connect it to the SAN and import the data.

These are only a few features that can be described about the SAN environment. The flexibility provided by the SAN can't be compared with DAS.

[Mark Poeschl_2]

Absolutely agreed.

Not only do you get all the benefits that Ivan describes with a SAN, in my experience the performance is actually better than DAS.

Apps/Dev/DBA people have a bigger mindset shift to deal with when moving to SAN - and sometimes feel like they're losing control of their resources. I've run into this sort of resistance before.

"Larger/fewer servers" as your Apps people want plus SAN storage would be the way I'd jump.

[Steve_597]

Thanks for the advice. Our app/dev group is adamant in their assertion that I/O will be a bottleneck in the SAN. Any way to prove the contrary is true? Resources?

Thanks,
Steve
Mpls

[Ivan Ferreira]

FC devices support 500-700 MB/s. The performance usually is restricted by other factors, like filesystem, block size, cache, I/O patterns, application eficiency.

You can use the storage specifications and verify is the database is performing withing the values listed, collecting statistics of your current/planned I/O load.

You can compare the specifications of a DAS with a SAN Storage device.

Virtual arrays have even better performance because of the I/O load distribution among all disks independently of the RAID level.

[Duncan Edmonstone]

Well of course SANs can introduce IO bottlenecks - so can DAS, but of course a well designed SAN with a fast disk array won't have bottlenecks and will perform faster.

To be brutal, its none of the app/dev teams business what sort of storage you deploy on, as long as it provides the throughput they require. I'm sure your team don't tell them what development tools to use?

Turn this around - get the app/dev to provide their IO requirements in terms of peak IO operations per second, peak MB/s throughput and desired IO response times, then give this to a vendor or VAR and they'll design you a SAN that meets your IO requirements.

HTH

Duncan

[Steve_597]

Thank you for the ideas and Duncan's brutal response and the turnaround idea. We will see what happens.

Steve

[Steven Clementi]

Steve:

I mostly agree that a SAN is a better choice than DAS in most cases and agree with what everyone here is saying.

One thing you can present to your dev team is...

"How do you increase the performance of a Disk Array?"

When they answer... "well, depending on the read/write characteristics.. the best way to increase I/O performance is to increase the number of spindles the data resides on." (this could be one of the answers, not the only answer from them)

How will you respond?...

"Well, assuming that the maximum number of drives I can have in ONE DAS array is 56 (one 6404 with 4 4314R's attached) vs. a new EVA (specs below), I think it is safe to say that we can hit much higer performance levels with a SAN and ANY DAS solution"

Of course, if the APP they are using hits it's peak performance with only 8 drives, then a SAN may not be feasible.

EVA 4000/6000/8000:
Max Drives: 56/112/240
Max Capacity: 16.8TB/33.6TB/72TB (currently)
Read bandwidth: >300/>600/>1000 MB/s
Write bandwidth: >250/>400/>500 MB/s
Max Random Read I/O: >12,000/>20,000/>40,000


You can NOT get these specs form DAS. Having a SAN will...

1. Centralize your storage.
2. allow you to perform on-demand capicity expansion.
3. spread your I/O over a GREATER number of drives for better performance (in most cases)
4. many other things others have stated already.

A SAN also currently operates at 2GB/s front side and 4GB/s very soon. Unless you were putting on a VERY HEAVILY used SQL Cluster with multiple Virtual Servers and an 8 node Exachnage cluster with 7 active nodes and a user base of 1 million, I doubt that the SAN would be the bottleneck. Of course, design matters which is why I agree with Duncan. Get the specs THEY need, go to a VAR or even HP direct (if your company is big enough) and have a SAN designed to meet and exceed those specs.


Steven

[Greg Riedesel]

I've gone through that sort of with with a DBA at my past job. These are people who grew up customizing hardware for their applications and know how it is supposed to go. More spindles beats out bigger/faster. For this I offer one man's experience.

In order to test out our EVA, I ran some throughput tests. Three different servers doing a virtual backup of local hosted EVA resources, so we were just testing FC and EVA throughput and no network I/O was needed. All three servers were pounding out a datarate of about 2.3 Gb/Min for an aggregate rate of 6.9 Gb/Min out of the EVA. With all three pounding away like that, total utilization on the EVA's FC switch-port never broke 25%. The data-rate of one server going flat out was 2.7 Gb/Min, so there was some overhead with serving multiple servers, but no where near the .9 Gb/Min you'd expect if it were getting everything out of the EVA it could.

What this tells me is that one server can't stress the EVA enough to cause contention on either the FC or the disks. Three servers running hard were able to cause it to sweat a little, but no dramatic drops in data-rate.

So unless your Dev-group is deploying some really heavy transactional databases, as in multiple 4-cpu query processors, then SAN will not bottleneck you.