powered by PmWiki |
SANNASDifferenceNAS vs SAN – What are they and How are they different?In times gone by the choice between NAS (network attached storage) and SAN (storage area network) was fairly straightforward – cost. Yes there were still plenty of issues regarding performance, functionality and implementation, but SAN was only based around the fibre-channel protocol. Talk fibre channel and think cost. While FC is a tremendously stable, high-performance product, the cost of hardware (disks, jbods, switches etc) are still extremely high today, and the technical difficulties involved in integrating and maintaining such a system kept fibre channel (and therefore pretty much SAN) in the realms of big business. Just finding a technician who integrates fibre channel seamlessly into an existing organisation is a challenge. Then along came iSCSI. iSCSIiSCSI is not in itself a SAN – it is a transport protocol that competes against fibre-channel in that it transports block data (disk data) across an Ethernet network in the same way that FC does across fibre-channel. While it's not as fast as fibre-channel it is more than fast enough for most applications and is considerably cheaper and easier to implement. Storage companies have looked at iSCSI as a way to (a) compete against FC and (b) extend the SAN marketplace into mid-sized businesses which make up the bulk of the marketplace across the world. iSCSI has been with us for over 5 years. It's no new-kid-on-the-block untested technology. It is stable, fast and fully sorted. The real reason it has not taken off over the last five years is that storage companies have been looking for a good use for it. IPSANEnter IPSANs. All the functionality of a FC SAN using iSCSI as the transport instead of fibre-channel. Why is this good for business? Cost, ease of implementation and flexibility. The article will examine the use of IPSAN vs NAS storage – when it's best to use which option and advantages/disadvantages of each. So how does NAS work?Network attached storage (NAS) has been around for many years now. It is an excellent way to add storage to a network and has a lot of other uses which makes it an excellent option for small to large businesses alike. The fundamental principle behind NAS is that the data transferred across the network from a user to the NAS box is done at file level. Basically speaking, a user on a workstation saves a file to the NAS box. The file transfers across the network to the NAS box, whose disk controller converts the file to block data and writes that data to disk. Over a gigabit Ethernet connection you can reasonably expect up to 70mb per second transfer speeds on a well-specified NAS box. The user (workstation or server) connects to the NAS box via a URL (ie \\server\data ). This works very well for files, but can't be utilised by a database. Programs such as SQL, Exchange, Oracle need to address a locally-installed hard drive in the server … they can't utilise a URL for storage. This means that the NAS box can do a lot of storage work for an organisation, but it can't do database storage work. NAS. What's the difference?Conversely to NAS, a SAN storage box creates it's own disks (via raid controllers etc) and presents those disks as “luns” to the network. This network can be on the same network as an organisations workstations and servers, but general good practice dictates that it's a separate physical or virtual network. Since this network will only consist of servers and the IPSAN storage devices, there are generally less than 24 ports involved over a short distance. With the price of good-quality network switches being what they are today, it makes both practical and economic sense to create a separate network for your SAN. A server connects to a SAN disk via an iSCSI connection. This can be done via a dedicated iSCSI HBA, or can be done using free software provided by most operating system vendors. Don't be fooled into thinking that software is second-rate to hardware … it's performance and functionality are every bit as good as hardware which is why you don't see many hardware adapters on the market these days. The iSCSI “initiator” (hardware or software) makes a connection the SAN disk on the external storage device. This is fairly straightforward to implement, but it's at this point that iSCSI kicks in and does some fancy tricks with your data. Remember that on a NAS box data travels across the user network as files to the NAS box, then is converted to block data and written to disk. In an iSCSI SAN the iSCSI initiator takes the file data, converts to block data, packages into Ethernet packets and sends across the SAN network as block data directly to the SAN storage device. Why all this mucking around? iSCSI tricks the server into thinking that the storage disk in the SAN box is in fact a directly-attached disk within the server. It just sees another disk in it's disk management application (totally unaware that the disk resides in a box well-away from the actual server). What does this do for you? Remember that database applications can't use the URL connection of a NAS box, but need a directly-connected disk. Well an IPSAN provides what appear to be directly-attached disks to the application server, allowing database programs to store their data on those disks. The added advantage is speed. Packing block data into Ethernet packets is a lot more efficient than putting files in, so the speed is increased across the same network. While a NAS box may see 70mb per second speeds across a network, the SAN box will reach speeds of 110mb per second per pipe. Add multiple network ports and you have some real speed on your hands. Where does this all fit in and how are these technologies used it in the real world?NAS is good for files and SAN is good for database – right? Yes and No! A NAS box can only accept files via a URL, but it still has a lot of strong points:
SAN on the other hand has strong points when it comes to flexibility and performance. Let's look at how the end user gets their data onto the SAN. A user saves his files from his workstation to a Windows server. Windows takes the files (at file level) and prepares to write the data to disk. The iSCSI initiator kicks in, converts the data to block data, wraps it in Ethernet and sends to the SAN box where it is written to disk. At the same time, applications running on the server are storing their data on the SAN box in the same manner. This makes SAN much more flexible than NAS. SAN external storage boxes “own” the data that resides on them. They present that data to servers, but they can still control that data and do some fancy stuff:
How do I use all this?Now that you hopefully understand the differences between NAS and SAN, let's look at some real-world scenarios where a customer is faced with the decision of what sort of storage to purchase. Fred has two servers … one for Windows file server and one for SQL/Exchange. He was smart enough to purchase powerful servers, but he saved some money by buying 1U server which don't have a lot of storage capacity. As the business has grown he needs storage but doesn't need to purchase new servers. Now he could add JBODs to each server and increase storage that way, but then he needs two backup devices, two processes, and has two management situations. So … does he need a NAS or a SAN. NAS will handle his extra capacity for file-serving, but it won't do much for his SQL and Exchange problems. So Fred puts in a SAN box. Both servers store their data on the SAN box which can grow as capacity needs increase. Further down the track when Fred gets really paranoid about his data he can add a second SAN box and mirror his really important data. So Fred needs SAN. Frank is system admin in a company that has most things under control. He has SQL and Exchange working the way he wants them. His real problem is that his file server has just run out of space. Now he can add capacity to the box, but he decides it's smarter to split his processing and storage. He wants additional storage that is file-based, and won't cost him an arm and leg in Windows licences. So Frank chooses NAS. George is in a different position. He runs a medium-sized landscape architect firm that is up for a new computer system. He is going to have massive file storage, exchange and SQL. He could just purchase one large server, or he could purchase two separate servers, or he could do a server for SQL and Exchange and a NAS box for the massive file storage. Instead George gets smart. He purchases two separate 1U servers that have the performance requirements he needs for file-server and Exchange/SQL. He purchases an IPSAN storage unit that can utilise both SAS (high-speed) and SATA (high-capacity) drives. He runs his SQL and Exchange on the SAS-drive volume in the IPSAN, and his file storage on the SATA-drive massive volume. For backups he attaches a scsi tape drive to the file server and backs up the data from both volumes during the night when no-one is using file-storage (though there are still night-owls using exchange). This was a smart choice. George has the processing power he needs for both servers, he has only one copy of backup software, one tape drive (library) and storage that will grow with his needs. Even if he decides he needs another server later he can add it without worrying about his storage needs. Putting it all together… One of the fundamental principles you can see running through this article is that it's important to separate your storage from your processing. The needs for these two components will change separately over the years, and you don't want to be stuck with having to throw out a perfectly good server simply because it doesn't have enough storage. Another basic principle is flexibility. Combining the power of SAS drives, the size and price of SATA drives, the capability of mirroring, snapshots, backup routines, file and or block storage gives a system admin endless flexibility in designing a storage system that will both meet today's needs (and get the boss off his back), and be flexible enough to grow in the way he requires in the future … whatever growth that may be. So is SAN better than NAS? No, they are just different and need to be placed into their correct environment to give the best benefits to the customer. ReferencesNeil Cameron, Field Application Engineer - Asia Pacific, Adaptec SAN or NAS - Retrieved on date 13 March 2008 All text is available under the terms of the GNU Free Documentation License |