Well, it is certainly true that the advantage of dedicated infrastructures is that they're guaranteed to be useless for other tasks. :) However, the notion that because TCP/IP is used by many applications it is unsuitable for storage traffic is simply not true.
Proper network and infrastructure design in general dictates that traffic is segmented based on business needs. A properly designed network infrastructure for a database generally includes two to four ethernet interfaces on the server. Two of these are dedicated for storage I/O (link aggregation strategies such as 802.3ad can be used if desired) and two are dedicated for host->database connectivity. With that configuration, properly implemented, there is no way that some idiot downloading a huge file will negatively impact the performance of your database. No way whatsoever. As an aside, there's no way to interconnect a Fibre SAN and a standard network without a conversion device - usually something like a NetApp, EMC Celerra, or even a standard UNIX box to handle the conversion from SCSI-over-Fibre to file-based NFS or CIFS. The real reasons to leverage IP networks for storage are as follows: -It's cheaper - Fibre channel today is roughly $800/port, and it isn't getting cheaper at an appreciable rate. Gigabit ports are on the order of $200/port, and that's assuming you're using host interfaces with intelligence built in for extra performance -It's more scalable - I worked on the design of the largest SAN in the world, which was only 1000 hosts, and it was pushing the limits of what is currently functional in a Fibre SAN. Whereas a 1000-host IP network is a commonplace thing to see, and doesn't even count as "large" -It's more mature - the behavior of IP networks under load and failure scenarios is well-documented. There are hundreds of network engineers that can in-detail describe how segmented networks converge, whereas I've only met a few storage folks who can explain how the equivalent process works in a SAN. -It's more stable - IP networks degrade. Fibre networks collapse. -It has more functionality - there currently is no concept of QoS in Fibre Channel, for example, and that's just the start of what's missing. The case for Fibre is getting less and less compelling all the time. The last holdout was those who are serious about block-based storage access (which is understandable), and iSCSI has effectively filled that gap. Fibre isn't going away anytime soon, but whenever it does, its not soon enough for me. Hrrrmm....the on-topic-ness of this has strayed far from Oracle. My apologies. Thanks, Matt -- Matthew Zito GridApp Systems Email: [EMAIL PROTECTED] Cell: 646-220-3551 Phone: 212-358-8211 x 359 http://www.gridapp.com > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Goulet, Dick > Sent: Friday, September 19, 2003 1:50 PM > To: Multiple recipients of list ORACLE-L > Subject: RE: Re: max parallel query > > > Matt, > > Question: What else do you have running on your Fiber > Channel? Answer: Nothing > Question: What do you have running on your TCP/IP > network? Answer: Everything. > > For this one can see that a SAN's fiber channel is > dedicated to handling data from one server to it's storage. > Sure you can attach part of your SAN to the network to act as > a NAS file system, but the SAN switch handles that separately > from the servers so that one does not get in the way of the > other. Therefore when some lummox decides to download that > 1GB MPG file from the internet, his traffic does not get in > the way of your database working with it's files. "Divide & > Conquer" still has it's place. > > Dick Goulet > Senior Oracle DBA > Oracle Certified 8i DBA > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Matthew Zito INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
