Despite the similar acronym soup (or soupa, as a colleague says) and similar objectives, the characteristics are quite different. I would even say that the application of one and the other is found in very distinct places. However, the most striking similarity between SAN and NAS is that both are network-attached storage devices.
In a very simplistic way, it’s a way to store information for multiple purposes, in an organized and centralized manner. Since it is a device, it’s not possible to consider a NAS or SAN as the local disks of a database server, for example.
Normally, a NAS or SAN are specialized devices that provide better read/write performance, better security, and, obviously, interconnectivity.
NAS – Network Attached Storage
A typical architecture with NAS can be seen in the figure “NAS Topology”, where we have several servers connecting to a Disk Array (set of disks) via LAN through TCP/IP. It is possible to set up a NAS infrastructure via WI-FI, too. Cool examples of NAS usage: collaborative file sharing (excel, word, ppt, etc.); repository of images for e-commerce; multimedia sharing (photos, movies, music); email inboxes for mail servers; in short, the utilities are diverse, but note that I did not include the use with databases here. However, NAS appliances have increasingly found their niche: Backup. In my humble opinion, I believe this is undoubtedly the unbeatable area of NAS appliances.
NAS architectures can also be used to increase storage capacity, since being a specialized device dedicated to storing and distributing data, its growth capacity is much superior to that of servers. Additionally, it is much simpler to create high scalability and redundancy environments. For example, replicated environments can be created. In this way, in the event of the loss of one device, another NAS device would have all the updated information and could take over the task of continuing to deliver service.
A NAS can be an off-the-shelf device, or it can be assembled from common servers with NAS software installed.
Certainly, the best bet is “off-the-shelf devices”, the so-called “appliances”. The cost of a NAS can vary as much as a ticket to a classic football match. There are “appliances” for home use (very popular these days), others for the SOHO, SMB market, and for more demanding applications.
For example, D-Link has a great line of NAS appliances: D-Link ShareCenter. It’s a product range that goes from home-use to more high-end ones. Apple’s great Time Capsule also falls into this category.
There is a wide range of manufacturers offering NAS appliances in all sizes, colors, shapes, and, of course, prices. In Brazil, appliances range from R$ 499 to R$ 20,000.
Here are some tips for choosing your NAS appliance, and of course, these tips may vary depending on the purpose of your appliance, but always keep in mind:
– MTBF: Mean Time Between Failure. This is the average time between failures recognized by the manufacturer. I’ve been emphasizing this point more and more. When it comes to storage media, for me, it is the most important item.
– Network Interface: Remember you’ll be communicating over the network. A good interface is a preliminary condition. Of course, if your network is all 100MBits/s, it doesn’t make sense to think about having a NAS with 1GBit/s or even 10GBit/s. However, if you decide to have a NAS in your infrastructure, make sure the servers that will access it, and the network devices (switches, for example) support the same speed.
– Scalability: Maximum disk capacity and consequently the maximum volume of data supported.
– Disk Interface: What types of disks will be accepted – SATA/SAS/SCSI/SSD? Is there Cache? What is the Cache size? “SATA” disks, for example, work well for basic applications and backups. For applications that require higher performance, only SAS with a good cache is acceptable. Be very, very careful about this.
– Disk Management: A good appliance should offer flexibility in the use, management, and maintenance of disks. Supporting RAID 0, 1, 5, and JBOD is fundamental. The ability to create volumes should be part of the package: imagine a NAS with a capacity for 4 disks of 2TB. If the appliance allows volume creation, the combined capacity would be 8TB. Defining user permissions, disk quotas, energy management, internal monitoring, and alert systems should also be considered.
And there are also software-based NAS. This is nothing more than servers (mostly Linux) with software that will transform the computer into a NAS. I’m not a fan of this option because the price of appliances and the resources offered don’t excite me, and I’m not keen on installing a computer for this purpose. However, there are great options (if you want to test and even risk it): FreeNAS, Gluster, and other projects.
SAN – Storage Area Network
Normally, SAN is a completely different world. Although it’s also used as a large data repository. Typically, SAN equipment is much more specialized, faster, with higher availability and resilience, and above all, more expensive.
Unlike NAS devices, which operate basically at the file level, SANs operate with data blocks (chunks), which by itself already changes performance. While NAS devices are available on the network via TCP, SAN equipment is mostly connected directly to a specific server, usually via fiber (fibre channel), which is another point that differentiates the bandwidth and traffic speed.
SAN devices are usually also accessible via TCP. Although they work with blocks, it is possible to create layers of file system abstraction.
The use cases for SANs are, in a way, similar to those of NAS. However, here, I include their use for databases. Generally, SAN appliances have greater I/O (read/write) capacity than local disks, feature better cache systems, translating into an excellent solution for databases that require high performance (provided the application has the budget).
In the MySQL world, up until mid-2005/2006, it was unthinkable to have a SAN (or even a NAS) as a data storage repository.
With the constant maturation of MySQL, and its increasing use in highly performant applications, mission-critical applications, and large-scale projects, MySQL-based applications have reached a new and higher level. Since 2007, I’ve seen companies increasingly looking for faster, more reliable, and secure storage solutions for their MySQL-based applications.
To give you an idea, in 2007 I participated in a single MySQL project that adopted the use of a SAN. By 2012, 25% of projects used SAN as a viable solution within the proposed budget.
Uncle’s Impressions
NAS and SAN are not for all MySQL applications. As a database that lives in an OpenSource world, firmly part of the LAMPP platform, and therefore surrounded by smart solutions, and, if not free, at least low-cost options, it’s necessary to exhaust all possible alternatives before adopting the use of NAS/SAN.
I’m not against it. I really like NAS for file-sharing/server-type applications. I don’t approve its use for databases. I love SANs, in fact, this week I’m working on a large-scale project that uses two wonderful SANs, acquired for the mere sum of R$ 250,000 each.
I approve SAN. But it has to make sense, and you must have the budget for it.
Visit our Blog
Learn more about databases
Learn about monitoring with advanced tools
Have questions about our services? Visit our FAQ
Want to see how we’ve helped other companies? Check out what our clients say in these testimonials!
Discover the History of HTI Tecnologia
