So here’s an answer to the great myth of SAN, it isn’t always going to be faster than local disk (or DAS, JBOD, etc.). The reason for this is actually pretty straight forward.
Local disk is cheap. That’s the reason in a nut shell. Let me see if I can’t explain in a little more detail.
Because local disk is so cheap, I can buy a 300 Gig SAS drive from Dell for $469, we can easily throw a lot of them at the problem, getting really, really fast storage really, really cheaply (at least compared to a SAN). Throwing 10 or 20 disks at a server is only ~$4600 or ~$9200 respectively which in the grand scheme of things isn’t all that much.
Those same 300 gig disks in an EMC array as an example will retail for ~$2500 each (~$25,000 for 10 or ~$50,000 for 20). So why would I purchase SAN storage, instead of buying a ton of local disks? The local disk is faster, and cheaper so where is the benefit?
The benefit from the SAN storage comes in a few places.
1. Centralized Administration
2. Better use of resources
3. Lower power utilization
4. Lower TCO
Lets look at each of these one at a time (and yes there is some overlap).
Centralized Administration
Instead of having to get bad disk alerts from all the servers that the company owns I get them all from one place. Instead of having to connect to each server to manage its storage configuration I have a single point that I can do this from.
Better use of resources
When using local disk I have to purchase storage for each server as a one off purchase. If a server I bought 6 months ago doesn’t need anywhere near the amount of storage that I purchased for it I’m stuck. That storage will sit there eating power doing nothing while I go out and purchase new storage for my next server.
When using a storage array, each server only has what it needs. If a server needs more storage later, that can be easily assigned. If a server has more storage than it needs you can shrink the LUN (only a couple of vendors can do this so far, the rest will catch up eventually) and that storage can be easily reallocated to another server in the data center for use. If a server needs faster storage, or is on storage which is just to fast and the faster storage could be better utilized somewhere else these changes can be made on the array, with no chance for loss of data on the array, and with no impact to the system.
Lower Power Utilization
This goes back to the better use of resources point above. When you have shelves of disks sitting around doing nothing, or next to nothing, those disks need to be powered. Power costs money which effects the bottom line. When you can re-utilize the disks the over all power costs are lower, especially when multiple servers are all sharing the spindles.
Lower TCO
This goes back to the Power Utilization above. When you are using more power, you are generating more heat. The more heat you generate the more cooling that you need to keep everything up and running. Along with this, and tied into the better use of resources, when you need 50 Gigs of storage you use 50 Gigs of storage. When you need 1 TB of storage you use 1 TB of storage, no more no less. So while you have to purchase a bit more up front (which is always recommended so that you can get the best possible prices), when you use the storage, you’ll only need to use the storage that you actually need. If you do charge backs this will be very important.
Storage arrays also provide all sorts of extra goodies that they can do. The array it self can help with your backup and recovery process. It can help present full data sets to your Dev/QA/Test/Staging systems without using up full sets of data via the built in snapshot technologies. When migrating or upgrading from one server to another, the storage array can make this very easy.
Migrating between servers is just a matter of disconnecting the LUN(s) from the old server, and attaching them to the new server.
Upgrading SQL Server? That’s no problem. Disconnect the LUNs from the old server, and take a snapshot of the LUNs. Then attach the LUNs to the new server. You can then fire up the database engine, and in the event of a failure to upgrade the databases, just roll back the snapshot and attach the LUNs back to the original system, or take another snapshot and try attaching the databases again.
Want to keep a copy of every database that you have in the company, no matter the version of SQL Server at your DR site? Storage based replication can replicate the data for any application, it doesn’t matter if that application supports replication or not, from one array to another. Every time a new or changed block is written to the array, the array will grab that block and sent it over the wire to the remote array. This can be done in real time (synchronously) or on a delay as specified by the admin (asynchronously).
Hopefully this opened up the array a little to you, and gave you some insight into how the magic box works.
Denny
