Which storage architecture is appropriate for you depends heavily on your environment. What is more important to you: cost, complexity, flexibility, or raw throughput? Communicate your storage requirements to both NAS and SAN vendors and see what numbers they come up with for cost. If the cost and complexity of a SAN isn't completely out of the question, I'd recommend you benchmark both.
Make sure to solicit the help of each vendor during the benchmark. Proper configuration of each system is essential ot proper performance, and you probably will not get it right on the first try. Have the vendors install the rest NSA or SAN - even if you have to pay for it. It will be worth the money, especially if you've never confiured one before.
Saturday, January 30, 2010
Monday, January 25, 2010
Pros and Cons of SANs
Many people swear by SANs and would never consider using NAS; they are aware that SANs are expensive and represent cutting edge technology. They are willing to live with these downsides in order to experience the advantages they feel only SANs can offer. The following is a summary of these advantages:
SANs can serve raw devices
Neither NFS nor CIFS can serve raw devices via the network; they can only serve files. If your application requires access to a raw device, NAS is simply not an option.
SAN are more flexible
What some see as complexity, others see as flexibility. They like the features available with the filesystem or volume manager that they have purchased, and those features aren't available with NAS. While NFS and CIFS have been around for several years, the filesystem technology that the filer is using is often new, especially when compared to ufs, NTFS, or vxfs.
SANs can be faster
As discussed above, there are applications where SANs will be faster. If your application requires sustained throughput greater than what is available from the fastest filer, your only alternative si a SAN.
SAN are easier to backup
The throughput possible with a SAN makes large-scale backup and recovery much easier. In fact, large NAS environments take advantage of SAN technology in order to share a tape library and perform LAN-less backups.
SANs are also not without their foibles: The following list contains the difficulties many people have with SAN technology:
SANs are often more hype than reality
Perhaps is a few years, the vendors will have agreed upon an appropriate standard, and SAN management software will do everything it's supposed to do, with SAN equipment that's completely interoperable. I sure hope this happens
SANs are complex
The concepts of Fibre Channel, arbitrated loop, fabric login, and device virtualization aren't always esay to grasp. The concepts of NFS and CIFs seem much simpler in comparison.
SANs are expensive
Although they are getting less expensive every day, a Fibre Channel HBA still costs much more than a standard Ethernet NIC, It's simply a matter of economics of scale. More people need Ethernet than need Fibre Channel.
SANs can serve raw devices
Neither NFS nor CIFS can serve raw devices via the network; they can only serve files. If your application requires access to a raw device, NAS is simply not an option.
SAN are more flexible
What some see as complexity, others see as flexibility. They like the features available with the filesystem or volume manager that they have purchased, and those features aren't available with NAS. While NFS and CIFS have been around for several years, the filesystem technology that the filer is using is often new, especially when compared to ufs, NTFS, or vxfs.
SANs can be faster
As discussed above, there are applications where SANs will be faster. If your application requires sustained throughput greater than what is available from the fastest filer, your only alternative si a SAN.
SAN are easier to backup
The throughput possible with a SAN makes large-scale backup and recovery much easier. In fact, large NAS environments take advantage of SAN technology in order to share a tape library and perform LAN-less backups.
SANs are also not without their foibles: The following list contains the difficulties many people have with SAN technology:
SANs are often more hype than reality
Perhaps is a few years, the vendors will have agreed upon an appropriate standard, and SAN management software will do everything it's supposed to do, with SAN equipment that's completely interoperable. I sure hope this happens
SANs are complex
The concepts of Fibre Channel, arbitrated loop, fabric login, and device virtualization aren't always esay to grasp. The concepts of NFS and CIFs seem much simpler in comparison.
SANs are expensive
Although they are getting less expensive every day, a Fibre Channel HBA still costs much more than a standard Ethernet NIC, It's simply a matter of economics of scale. More people need Ethernet than need Fibre Channel.
Tuesday, January 19, 2010
The Pros and Cons of NAS
NAS filers have become popular with many people for many reasons. The following is a summary of several:
Filers are fast enough for many applications
Many would argue that SANs are simply more powerful than NAS. Some would argue that NFS and CIFS running on top of TCP/IP creates more overhead on the client than SCSI-3 running on top of Fibre Channel. This would mean that a single host could sustain more throughput to a SAN-based disk than a NAS-based disk. While this may be true on very high-end servers, most real world applications require much less throughput than the maximum available throughput of a filer.
NAS offers multi host filesystem access
A downside of SANs is that, while they, do offer multihost access to devices, most applications want multihost access to files. If you want the systems connected to a SAN to read and write to the same file, you need a SAN or cluster based filesystem. Such filesystems are starting to become available, but they are usually expensive and are relatively new technologies. DIlers, on the other hand, offer multihost access to files using technology that has existed since 1984.
NAS is easier to understand
Some people are concerned that they don't understand Fibre Channel and certainly don't understand fabric-based SANs. To these people, SANs represent a significant learning curve, whereas NAS doesn't. With NAS, all that's needed ot implement a filer is to read the manual provided by the NSA vendor, which is usually rather brief; it doesn't need to belonger. With Fibre Channel, you first need to read about and understand it, and then read the HBA manual, the switch manual, and the manuals that come with any SAN management software
Filers are easier to maintain
No one who has managed both a SAN and NAS will argue with this statement. SANs are composed of pieces of hardware from many vendors, including the HBA, the HBA, the switch or hub, and the disk arrays. Each vendor is new to an environment that hasn't previously used a SAN. In comparison, filers allow the use of your existing network infrastructure. The only new vendor you need is the manufacturer of the filer itself. SANs have a larger number of components that can fail, fewer tools to troubleshoot these failures, and more possibilities of finger pointing, All in all, a NSA-based network is easier to maintain.
Filers are much cheaper
Since filers allow you to leverage your existing network ifrastructure, they are usually cheaper to implement than a SAN, A SAN requires the purchse of a Fibre Channel HBA to support each host that;s connected to the SAN, a port on a hub or switch to support each host, one or more disk arrays, and the appropriate cables to connect all this together. Even if you choose to install a separate LAN for your NAS traffic, the required components are still cheaper than their SAN counterparts.
Filers are easy to protect against failure
While not all NAS vendors offers this option, some filers can automatically replicate their filesystems to another filer at another location. This can be done using a very low bandwidth network connection. While this can be accomplished with a SAN by purchasing one of several third-party packages, the functionality os built right into some filers and is therefore less expensive and more reliable.
Filers are here and now
Many people have criticized SANs for being more hype than reality. Too many vendor's systems are incompatible, and too many software pieces are just now being released. Many vendors are still fighting over the Fibre Channel standard. While there are many successfully implemented SANs today, there are many that aren't successful. If you connect equipment from the wrong vendors, things just won't work. In comparison, filers are completely interoperable, and the standards upon which they are based have been around for years.
Fillers aren't without limitations. Here's a list of the limitations that exist as of this writing. Whether or not they still exist is left as an exercise for the readers
Fillers can be difficult to back up to tape
Although the snapshot and off-site replication software offered by some NAS vendors offers some wonderful recovery possibilities that are rather difficult to achieve with a SAN, filers must still be backed up to tape at some point, and backing up a filer to tape can be a challenge. One of the reasons is that performing a full backup to tape will typically task an I/O system much more than any other application This means that backing up a really large filer to tape will create quite a load on the system. Although many filers have significantly improved the backup and recovery speeds, SANs are still faster when it comes to raw throughput to tape.
Filers can't do image-level backup of NAS
To date, all backup and recovery options for fillers are file-based, which means the backup and recovery software is traversing the filesystem just as you do. There are a few applications that create millions of small files. Restoring millions of small files is perhaps the most difficult task a backup and recovery system will perform. More time is spent creating the inode than actually restoring the data, which is why most major backup/recovery software vendors have created software that can back up filesystems via the raw device - while maintaining file-level recoverability. Unfortunately, today's filers don't have a solution for this problem.
The upper limit is lower than a SAN
Although it's arguable that most applications will never task a filer beyond its ability to transfer data, it's important to mention that theoretically a SAN should be able to transfer more data than NAS. If your application requires incredible amounts, NAS offers a faster, cheaper alternative to SANs. However, for other environments, SANs may be the only option. Just make sure to test your system before buying it.
Filers are fast enough for many applications
Many would argue that SANs are simply more powerful than NAS. Some would argue that NFS and CIFS running on top of TCP/IP creates more overhead on the client than SCSI-3 running on top of Fibre Channel. This would mean that a single host could sustain more throughput to a SAN-based disk than a NAS-based disk. While this may be true on very high-end servers, most real world applications require much less throughput than the maximum available throughput of a filer.
NAS offers multi host filesystem access
A downside of SANs is that, while they, do offer multihost access to devices, most applications want multihost access to files. If you want the systems connected to a SAN to read and write to the same file, you need a SAN or cluster based filesystem. Such filesystems are starting to become available, but they are usually expensive and are relatively new technologies. DIlers, on the other hand, offer multihost access to files using technology that has existed since 1984.
NAS is easier to understand
Some people are concerned that they don't understand Fibre Channel and certainly don't understand fabric-based SANs. To these people, SANs represent a significant learning curve, whereas NAS doesn't. With NAS, all that's needed ot implement a filer is to read the manual provided by the NSA vendor, which is usually rather brief; it doesn't need to belonger. With Fibre Channel, you first need to read about and understand it, and then read the HBA manual, the switch manual, and the manuals that come with any SAN management software
Filers are easier to maintain
No one who has managed both a SAN and NAS will argue with this statement. SANs are composed of pieces of hardware from many vendors, including the HBA, the HBA, the switch or hub, and the disk arrays. Each vendor is new to an environment that hasn't previously used a SAN. In comparison, filers allow the use of your existing network infrastructure. The only new vendor you need is the manufacturer of the filer itself. SANs have a larger number of components that can fail, fewer tools to troubleshoot these failures, and more possibilities of finger pointing, All in all, a NSA-based network is easier to maintain.
Filers are much cheaper
Since filers allow you to leverage your existing network ifrastructure, they are usually cheaper to implement than a SAN, A SAN requires the purchse of a Fibre Channel HBA to support each host that;s connected to the SAN, a port on a hub or switch to support each host, one or more disk arrays, and the appropriate cables to connect all this together. Even if you choose to install a separate LAN for your NAS traffic, the required components are still cheaper than their SAN counterparts.
Filers are easy to protect against failure
While not all NAS vendors offers this option, some filers can automatically replicate their filesystems to another filer at another location. This can be done using a very low bandwidth network connection. While this can be accomplished with a SAN by purchasing one of several third-party packages, the functionality os built right into some filers and is therefore less expensive and more reliable.
Filers are here and now
Many people have criticized SANs for being more hype than reality. Too many vendor's systems are incompatible, and too many software pieces are just now being released. Many vendors are still fighting over the Fibre Channel standard. While there are many successfully implemented SANs today, there are many that aren't successful. If you connect equipment from the wrong vendors, things just won't work. In comparison, filers are completely interoperable, and the standards upon which they are based have been around for years.
Fillers aren't without limitations. Here's a list of the limitations that exist as of this writing. Whether or not they still exist is left as an exercise for the readers
Fillers can be difficult to back up to tape
Although the snapshot and off-site replication software offered by some NAS vendors offers some wonderful recovery possibilities that are rather difficult to achieve with a SAN, filers must still be backed up to tape at some point, and backing up a filer to tape can be a challenge. One of the reasons is that performing a full backup to tape will typically task an I/O system much more than any other application This means that backing up a really large filer to tape will create quite a load on the system. Although many filers have significantly improved the backup and recovery speeds, SANs are still faster when it comes to raw throughput to tape.
Filers can't do image-level backup of NAS
To date, all backup and recovery options for fillers are file-based, which means the backup and recovery software is traversing the filesystem just as you do. There are a few applications that create millions of small files. Restoring millions of small files is perhaps the most difficult task a backup and recovery system will perform. More time is spent creating the inode than actually restoring the data, which is why most major backup/recovery software vendors have created software that can back up filesystems via the raw device - while maintaining file-level recoverability. Unfortunately, today's filers don't have a solution for this problem.
The upper limit is lower than a SAN
Although it's arguable that most applications will never task a filer beyond its ability to transfer data, it's important to mention that theoretically a SAN should be able to transfer more data than NAS. If your application requires incredible amounts, NAS offers a faster, cheaper alternative to SANs. However, for other environments, SANs may be the only option. Just make sure to test your system before buying it.
Friday, January 15, 2010
Enter the SAN
Some backup software vendors attempted to solve the cost problem by allowing a single library to connect to multiple hosts. If you purchased a large library with multiple SCSI connections, you could connect each one to a different host. This allowed you to share the tape library but not the drives. While this ability helped reduce the cost by sharing the robotics, it didn't completely remove the inefficiencies discussed earlier.
What was really needed was a way to share the drives. And as long as the tape drives were shared, disk drives could be shared too. What if:
A large database server could back up to a locally attached tape drive, but that tape drive could also be seen and used by another large server when it needed to back up to a locally attached tape drive?
The large database server's disk could be seen by another server that backed up its disks without sending the data through the CPU of the server that's using the database?
The disks and tape drives were connected in such a way that allowed the data to be sent directly from disk to tape without going through any server's CPU?
Fibre Channel and SANs have made all of these "what ifs" possible, including many others. SANs are making backups more manageable than ever - regardless of the size of the servers being backed up, In many cases, SANs are making things possible that weren't conceivable with conventional parallel SCSI or LAN-based backups.
What was really needed was a way to share the drives. And as long as the tape drives were shared, disk drives could be shared too. What if:
A large database server could back up to a locally attached tape drive, but that tape drive could also be seen and used by another large server when it needed to back up to a locally attached tape drive?
The large database server's disk could be seen by another server that backed up its disks without sending the data through the CPU of the server that's using the database?
The disks and tape drives were connected in such a way that allowed the data to be sent directly from disk to tape without going through any server's CPU?
Fibre Channel and SANs have made all of these "what ifs" possible, including many others. SANs are making backups more manageable than ever - regardless of the size of the servers being backed up, In many cases, SANs are making things possible that weren't conceivable with conventional parallel SCSI or LAN-based backups.
Subscribe to:
Posts (Atom)
