So I have this new job now and I’m being introduced to some new technology. One of the first things I was able to get my fingers into was the Storage Area Network (SAN). I’m quite familiar with Network Attached Storage (NAS), and was under the belief that SANs were just the same technology with dedicated servers. I was mistaken, however, and the differences are quite interesting.
Network Attached Storage is used quite widely, perhaps even in your own home. NAS uses protocols such as NFS and Samba/CIFS. You may not recognize Samba/CIFS, but this is the protocol used when you share a directory on a Windows machine. NFS is essentially an equivalent protocol used in the UNIX community. (Ok, ok, it’s not *really* equivalent, but let’s not start a holy war here…) In short, you identify which location on the server you want to share, and then you mount that share on the client. Shares are commonly identified by the server address and the directory or path that is being shared. Additionally, the type of filesystem used is abstracted away, preventing the local server from optimizing the storage based on the usage type.
Storage Area Networks, on the other hand, generally use the SCSI protocol for communication. In order to mount a SAN volume, you typically identify it just like any other hard drive. (Note: My experience here is on *nix systems, not Windows. As such, I’m not entirely sure how SANs are mounted via Windows) One fairly large benefit to mounting in this manner is that you can boot a server directly from the SAN rather than using local drives. SAN devices are presented to the operating system as a typical block device, allowing the administrator to choose the filesystem to use, as well as any of the associated filesystem management tools.
There are a number of different SAN types including Fibre Channel (FC), iSCSI, ATA over Ethernet, and more. The SAN I worked on is a Fibre Channel SAN from EMC. Fibre Channel is a high-speed transport technology, originally designed for use in supercomputers. It has since become the transport of choice for SANs. Typically, fiber optics are used as a physical medium, though transport over twisted-pair copper is also possible.
Fibre Channel itself is very similar to Ethernet technology. FC switches are used to provide connectivity between the SAN and the various clients using the SAN. Multiple switches can be connected together, providing both transport over long distances as well as expanding the number of available ports for clients. Multiple SANs can be connected to the switches, allowing clients to connect to shares in multiple locations. More advanced switches, such as the Cisco FC switch, use technology similar to Ethernet VLANs to isolate traffic on the switches, providing additional security and reducing broadcast traffic.
iSCSI is essentially Ethernet-attached storage. The SCSI protocol is tunneled over IP, allowing an existing IP infrastructure to be used for connectivity. This is a major advantage as it reduces the overall cost to deploy a SAN.
A major drawback of SANs is the overall cost to deploy them. While hard drives are relatively inexpensive, the rest of the hardware that makes up a SAN is rather expensive. Even a small SAN can cost upwards of $25,000 or more. But if you’re in the market for extremely high-speed storage, SANs are hard to beat.
Properly configured, SANs can offer a high level of redundancy. Typically, servers are connected to a SAN via multiple paths. As a result, the same storage device is presented to the server multiple times. A technology known as multipath can be used to abstract away these multiple paths and present a single unified device to the server. Multipath then monitors each path, switching between them when necessary, such as when a failure occurs. On the SAN itself, the storage is handled by one or more hard drive arrays. Arrays can be configured with a variety of RAID levels, providing redundancy between hard drives.
SANs are a pretty cool technology. It has definitely been interesting learning about them, and setting them up for the first time. I have to admit, however, that I mostly dealt with the server end of the setup. The SAN itself was already in place and the shares had already been created. After dealing with the software involved in creating these shares, I can’t say I would look forward to using it again. It’s amazing how confusing and unusable such software can be. Overall, though, I’m glad I had the chance to learn.