|
Using NAS for high performance applications like SAP, Peoplesoft, Oracle, SQL, Exchange, etc. is in my opinion never a good idea. On some applications it's not even supported. NAS is file based rather than block based and needs to traverse the IP stack for access to the data. This means CPU overhead when accessing the data, which takes away from application performance.
FC is a low latency transport meant for pushing large amounts of data. IP is good for error free data access over long distances. There is more overhead in the stack on IP as there is with FC. Some NAS vendors are now moving to put the IP overhead into silicon (BlueArc for one) that may help on the NAS end. But the server still uses a NIC.
NAS is a great fit for applications like file/print or WEB data, but I like to use a SAN for performance. (Benchmarks bear this out.) NAS will most likely be cheaper, since you don't need HBAs and switches but a SAN will provide better performance and most likely be more reliable.
(This is only my opinion, and I'm sure to get hate mail on this from the NAS folks out there.)
I think iSCSI based SANs, which are also block based and will use TOE NICs (TCP/IP offload engines), will move IP-based network storage towards faster speeds. (As will 10GB Ethernet!)
I guess you can see my bias in this area. I usually use NAS to consolidate file/print servers and use SAN with clusters to consolidate application servers. You could buy both! File/print on NAS and applications on the SAN.
As for which vendor, do your homework. Do an RFP if you want. The best bet, especially for 15TB worth of data, would be to evaluate each vendor's product at your site. I'm sure all the vendors would be more than happy to help you there. Test connectivity, performance, management, service and support, value add, competence of the team, etc. and then make up your mind about who you feel more comfortable with.
Chris
Editor's note: Do you agree with this expert's response? If you have more to share, post it in our Storage Networking discussion forum.
|
