Oracle-L: RE: why SAN ? why not external storage ?

From: <Rich.Jesse_at_qtiworld.com>
Date: Wed, 12 Mar 2003 11:59:19 -0800
Message-ID: <F001.00568038.20030312115919@fatcity.com>

Bingo! One of the reasons my team lead wants a SAN in here is to limit the vast amounts of wasted storage (wasted storage = wasted $$$)we have on our individual disparate systems. That savings must be weighed against the downsides of a SAN, such as the possibility of I/O contention and the single (or greatly reduced) point(s) of failure by the consolidation. I think we'll do just fine with a little care taken on the purchase (dual GBit fiber, redundant power supplies, etc.) and on the setup (UPS, generator, decent disk layout, etc.).

I want it because of the promise of vast I/O thruput. While y'all can argue that one, our ERP/MRP database is on an HP AutoRAID 12h. Ain't no way in hell even a half-arsed SAN setup with multiple systems pounding it is going to be as slow as that.

My $.02,
Rich

Rich Jesse                        System/Database Administrator
rich.jesse_at_qtiworld.com           Quad/Tech International, Sussex, WI USA

-----Original Message-----
Sent: Wednesday, March 12, 2003 11:18 AM To: Multiple recipients of list ORACLE-L

Dick Goulet gave an excellent response to the list earlier -- I'd second him on each point he made.

There is no doubt that DAS is cheaper on the original purchase, because you're only buying the disk. Obviously, a SAN has a few more bits of iron and wire. But have those administrators toted up the cost of tying storage directly to servers over time? Without the ability to shift storage from server to server as needs change? As you migrate services (like databases, like shared drives, like email) from server to server, can you always migrate the storage? Or do you have to buy new storage for the new server? Oh, and once you buy the new storage, how are you going to move the data? Over the LAN?

People who are used to administering web servers and application servers don't think much about storage. A server is a server is a server. A server has disk attached. You can add to it. What's the problem? The problem starts when you start to have lots of servers that require lots of storage, and the services (a.k.a. applications) that they support change over time. They grow. They consolidate. Servers reach end of life. CIOs read a magazine article and get a wild idea.

If you don't have a lot of storage-intensive servers (such as database servers) and a CIO who sticks to financial journals, then a SAN is overkill.

I've not seen any evidence of performance problems with SANs, as opposed to DAS. I'd be interested to see numbers. A storage-area network (SAN) is merely a virtualization layer atop a bunch of direct-attach storage (DAS). If the underlying DAS is fibre-connected, then the SAN should be fibre-connected throughout, whereever appropriate. Of course, if the SAN head is connected to servers via 100Mb/s Ethernet instead of fibre (or some other obvious misconfiguration), there will be a problem. But attributing performance problems to the SAN virtualization is kind of like the old arguments when RAID0 was new (i.e. "all that CPU expended to keep track of the scattered blocks across all those drives will make performance worse, not better!").

A SAN is more complex on initial setup than just buying another DAS, but the sysadmins have to learn to keep up with technology also...
--

Please see the official ORACLE-L FAQ: http://www.orafaq.net
--

Author: Jesse, Rich
INET: Rich.Jesse_at_qtiworld.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).

--

Please see the official ORACLE-L FAQ: http://www.orafaq.net
--

Author:
INET: Rich.Jesse_at_qtiworld.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------