Once you get to a certain number of disks for a database server, it is no longer makes sense to manage the disks simply on a server level. The RAID controllers to handle a large number of disks near the cost of a small SAN device. The SAN may be a shared device, hosting disk storage for more than one server. Now you can have all your disks and failover capabilities serving multiple servers, reducing the cost for the necessary redunancy.
Most Database Administrators do not get to manage a SAN because of the unique skills for managing a SAN. Moreover, a SAN is often a shared device. So, it is not optimized for database activity. If you are able to have all or a portion of a SAN dedicated to your database server, then you can use any of the other disk separation and RAID techniques discussed earlier in this series, hosting them instead on the SAN device, instead of directly attaching them to the dateabase server.
I have purchased space on a large SAN, shared with many different companies, having different disk access methods, and had excellent performance. However, the SAN was configured with a LARGE cache. Most of our disk access was found in the cache, and eventually written to disk. The SAN consisted of 150 disks combined into a single RAID 5 virtual disk. RAID 5 is the slowest RAID configuration. But, with 150 disks, well, that just kind of says it all Again, the CACHE really made the difference for overall performance.
One neat thing about a SAN is that it can often host different kinds of drives, having different performance characteristics. One implementation that is popular is to have a lower performing virtual disk that is “Just a Bunch of Disk”, JBOD. The JBOD is used for things like backups, import, and export files, etc. It doesn’t have to be extremely fast because it isn’t used for online work necessarily. It just provides a nice playground to store external files relevant to your database.
There are some really cool SAN controllers that provide you with different disk performance characteristics. You can assign your data to the appropriate performance target, and the SAN will direct the data to the appropriate devices. Sometimes these can include SSD, as well as other Hard Disk options.
Your server connects to the SAN using different networking capabilities. ISCSI allows you to connect to a SAN using eithernet, emulating a SCSI drive over TCP/IP. This is the cheapest, but slowest performing connection. A Fiber Optic connection may be used if your server has a Fiber network card. The Fiber connection can run at very high speeds allowing the SAN to deliver and receive data as fast as your server can create or consume it.
SAN prices have dropped for entry level configurations such that a SMB can consider hosting their own device.
But why do all this yourself? Why not purchase this as a service? Sounds like a topic for tomorrow.
Cheers,
Ben