Why should one use SAN instead of local hard disk?
I am really a novice in hardware configuration.
asked
SAN or Local hard disk
Just to spell out my 2 cents in a separate answer:
- Performance. Most SANs allow you to attach extra shelves to the array, thereby giving you an easy way to up performance by throwing spindles at it.
- Scalability. Same reason again, more spindles = more space, as well as more performance.
- Redundancy. Using a SAN puts your data on a separate physical entity. SANs generally offer the facility for redundant controllers, fabric connections and power supplies. That way you can connect the SAN to multiple servers over a totally redundant fabric to achieve full redundancy. That fabric might be fibre channel, or it might be iSCSI, but either way, it's the redundant part that counts.
- Maintenance. When a disk dies (which it will), then on a SAN you just pop out the old disk, and pop in the new. If you have been sensible enough to assign a hot-swap spare or two, then one of those will have already caught up with the array, and the disk you put in will become the new hot-swap spare.
- Flashing lights. People who look round data centres are typically impressed by flashing lights, and SANs tend to have a lot of them.
Hope that helps.
Edit ->
If you have money to burn, you might want to check out RamSAN systems. They're pretty awesome. Actually, I had one in to test once, and it was pretty good on the whole IO front both in terms of rate and IOPS, but it didn't make our application much faster in practice because it was pretty well optimised, and most of the time taken was network latency anyway.
It depends what connects you to the SAN and how the local disks are configured. If you have the time then benchmark both and pick the one that will best suit your needs. There are so many different factors that impact on your situation it will be impossible to answer it here, based on the information you have provided. I would recommend reading up on your options in Books Online and some blogs of SQL Server performance tuning gurus like Brent Ozar
have 64 bit sql server running with some 300 gb hard disk. I hear everyone saying that they use SAN instead of local hard disk. IN my case, I think expected database size would remain under 100 GB for a couple of years. so not sure, if it is always ideal to go for SAN
Its not the size of your hard drive that matter - providing it is big enough to cope, its their configuration - how many spindles, what speeds, what RAID array and so on ... ... How close is the SAN, fibre connection, other systems accessing it. what access characterstics will your system have - Mostly Read, Mostly Write. will that suit the SAN ... ...
The reasons to use a SAN are not, strictly speaking, technical. We use a SAN because it provides a mechanism for rock solid high availability. In terms of shear performance, there are faster methods to store data. But few are as reliable. We use the SAN because it gives the business the warm & fuzzies it needs to know that it's data will always be available. Funny thing is, the vast majority of data on the SAN is unstructured data, not relational data.
+1 - just to say explicitly - if you want to run SQL Server in a failover clustering environment, then you need shared storage, and one method of getting shared storage is on a SAN. And SANs can be lightning quick too - at my last place we had a 120disk SAN and the IO you could put through it was just silly...
@Bhaskar No, it's not just high availability. That's one of the biggest selling points, but you get all sorts of mirroring capabilities, special types of disk only backups, lots of really cool functionality. And, depending on the configuration, SANs can run really, really fast. It's just that, as Timothy said so well, in general, local disks can be configured to run faster. Caveat Emptor, your mileage may vary, etc.
@Matt - 120 HDD?!?! really? We dont have that many in all of our servers added together!
@Fatherjack - Yep - 120 disks in 8 shelves @ 15 disks per shelf. Was an EMC CX3 - but I can't remember exactly which model. System was specced to run a reporting system for 5 years worth of data which equated to about 2 billion transactions.
It really isn't black & white.
SANs have tools for cloning, data backups etc.
SANs are typically supported by storage specialists so another group is caring for the physical aspect.
SANs are probably easier, from the O/S and SQL Server point of view, when it comes to adding space and/or spindles.
SANs are used for MSCS.
Local drives are easier to configure.
The entire server can be moved to a new location with relative ease if the drives are local.
Fewer support groups required to manage the system when local drives are used.
Basically it comes down to choosing what you need. As Fatherjack said benchmark the differences if you can and then weigh the differences.
Local disks are way cheap than SAN, but SAN gives you flexibility and Scalablity.
Check this page out. It has the right questions to ask before you decide. Like how many days of backup you want to store in disks? What kind of RAID do you want to use for Data, Log, Backup, tempdb? Also do you want to place these files in their own drives? etc..
Also if you are using SAN keep in mind you can make snapshot copy of your data etc.
Regarding performance of DAS Vs SAN check out an article by Linchi Shea (Which is Faster: SAN or Directly-Attached Storage?).
As many others have mentioned, there are a lot of variables floating around in your choice of storage. I am not going to rehash all the good points made by Matt and Grant and others, but I think two are worth reemphasizing/rephrasing.
You will generally get better performance from the same harddrive attached directly to the machine then you will from a San.
You will generally have more flexibility in the San. You can often more easily add storage space to a San without downtime than you can with direct storage. Also, you can generally do virtual reallocation of the space that is already there from one server or designated drive to another easily.
You may notice that I and many of the other posters are using a lot of caveats like generally and often. That of course is because a lot depends on the specific configurations and pieces of hardware that you are looking at and your use case. Fatherjack expressed this very well.
One of the big points Grant correctly made was that Sans are generally more reliable. Of course he is right, but remember that you can install a well configured RAID setup with automatic backup to another media all into one (large) computer box without problems and have enormous reliability on the storage side of things, and on the flip side, a poorly configured San with no redundancy could be unreliable.
If you really want to boil it down to a rule of thumb, if you have a very small number of servers (say 3 or fewer) then you are probably better using local drives. They will generally be faster and cheaper and if configured properly can be quite reliable. If you have numerous servers and do not have a need for physical separation of data (this is often required with some types of sensitive data), then you are better off with a San. The maintence tends to be easier and benefits such as greater flexibility and ability to set up failover clustering can be valuable.
Excellent comments. Very well constructed. I also like your general rule of application.
Thanks everyone for great insight , I talked to other people also and came to know that SAN has cache memory in GBs which enhances performance for high amount reads.
