June 15, 2004 at 2:28 pm
We are evaluating the possibility of expanding our existing NAS to hold the data for SQL 2000 Clusters in active/passive configuration. In a perfect world we would implement our clusters using a SAN solution. That is not likely to happen in the near future, so we are trying to make the best with what we already have. I would appreciate any feedback, positive or negative, from anyone that has implemented or has considered a similar solution. Thank you for your input.
June 16, 2004 at 1:09 am
One article I read on this topic (quite some time ago) is regarding the latency of the connection. Even though you may be connected through a Gigabit LAN, with a throughput similar to a SCSI/fibre SAN solution, you have to remember that there is far more overhead on the OS in regards to networking (ie TCP/IP stack, SMB, security, etc). Given that there are possibly thousands of operations per second that you are attemping on a database file, the small millisecond differences will certainly add up quite quickly! When you're using a SAN, it appears as a local device and therefore isn't subject to the same overhead.
The best way to emulate this would be to create thousands of very small files and copy them over the network. Do the same to a separate local hard disc. You'll notice a reasonable difference in the time it takes to complete the operation.
On our site, we ended up biting the bullet and going with a SAN.
June 16, 2004 at 6:01 am
I have to agree with Mark. You just won't be able to sustain the I/O required with a NAS. For more info, check out this article:
http://www.sql-server-performance.com/ew_san.asp
Adam
June 16, 2004 at 7:28 am
We beta this few months ago. We compare NAS (from Network Appliance), FCAL (Fibre, IBM), and SCSI-3 solution as infrastructure guideline.
FCAL outperform the others by at least 2 folds (in terms I/O), SCSI comes second, NAS is third. I think the answer is clear.
The baseline tool we use is SQLIOStress from MSFT.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply