Last month, Techworld storage editor, Chris Mellor, posed an interesting storage question in his blog as to whether NAS and SAN can really be served from a single enterprise storage pool, or whether the differences between block and file storage will always lead to a need for separate storage in the subsystem?
NAS and SAN have developed as two different storage architectures, optimised to serve two different purposes. As a result, vendors have created separate products for each market. But behind all storage: disk, tape, Fibre Channel, SATA, NAS and SAN, lies a load of old blocks.
A storage block, is a storage block, is a storage block: 512 bytes of data, they look the same whether they are used for raw block or for file data. There is a possibility of formatting disk devices using exotic sector sizes, such as 520 or 1024 bytes, but this has little to do with the NAS vs. SAN argument. (To be accurate, NetApp does format their disks with 520 byte sectors, and uses the extra 8 bytes for purposes of their WAFL filesystem. However, most other filesystems work perfectly with 512 byte sectors, including such well-known on-disk architectures as NTFS, ext3 and xfs, all of them widely deployed in various NAS appliances).
I recently asked a host of vendors whether it is possible to serve up NAS and SAN from the same physical volume, (Note the careful use of the term physical). Steve Tongish, director of marketing for Plasmon systems, responded with some comment that included the following:
NAS and SAN systems use fundamentally different storage architectures For this reason they can't coexist on the same physical volume.
He then went on to completely contradict this statement, but he is by no means alone in his confusing use of terminology. Chris recently returned from a MacArthur Stroud conference, having been lead to believe (by several vendors who should know better) that NAS and SAN blocks must be stored in separate areas, on separate disks in fact, because blocks in a file structure are laid out on disk in a different way than blocks in a SAN. As a result, he was told, a lump of virtualised SAN storage cannot be used to hold NAS files.
Taking a physical volume to mean a volume of physical storage (as it indeed does), at the most basic level, partition a single disk, and you can serve NAS from one partition and SAN from the other. Ah, I hear you cry, but then you have created two physical volumes. True, but bear with me.
If I virtualise a physical volume on a disk, I can create two logical volumes on one physical volume. From these separate logical volumes I can serve a host what I like: block or file. So with virtualisation in place, I can run NAS and SAN from the same disk, the same array, in short from a single storage pool.
Not so, according to Stephen Watson, HPs UK Enterprise Storage Manager. Watson maintains, quite rightly, that our NAS and SAN argument:
is not dependent on whether the physical volume is in a NAS device or on a SAN. It is dependent on what the physical volume or disk is attached to and controlled by.
However, he then suggests that to serve NAS and SAN from the same disk you somehow need separate controllers:
To be able to attach a physical volume or disk to two different controllers whether it be a SAN, NAS, desktop or single server, you would have to have multiple connections on the disk itself so that it can appear to both controllers. However, I would then ask, how do you control who has access and when to avoid overwriting each others data and so forth?.
Confusingly, Watson then goes on to point out, if I put a NAS head onto an FC SAN, I can serve up file storage from a LUN on the underlying SAN. In any case, according to Roger Turner, director of storage systems EMEA at HDS, with the right FC SAN I can serve up data to 8 completely different host storage domains through a single FC connection connected to a single controller. These can be two hosts with completely different operating systems, and I can then create separate LUNs within these domains from which to feed NAS and SAN.
All very well in the FC world, but with IP SAN and NAS, surely Watsons argument stands? Well no.
As with many vendors of converged NAS/SAN, you can take a NAS filer, and place an iSCSI target within one large file. But then I could take a dustbin lorry, place a blue flashing light on it and use it as an ambulance. It works, but it is not the most elegant solution. You are taking iSCSI block storage - optimised for high I/O, squeezing it through a file system - optimised for sharing files, and then you are converting it back to block storage on the disk.
What makes more sense in the IP world is to simply virtualise storage at the right level, before we even consider what it is to be used for.
A well architected IP storage product should use a logical volume manager to allow virtualisation of all connected physical storage at a level below NAS and SAN. You can then build a NAS head and an iSCSI SAN head in parallel above this, explains Kirill Malkin, CTO of Reldata. Capacity from the virtualised pool can then be shared between IP NAS and IP SAN. On an IP level, the concept of NAS and SAN as separate products almost disappears, you simply serve files to hosts which want files and blocks to hosts which want raw block storage.
Put this way it seems clear that NAS and SAN storage can share a physical volume. But there is a good reason for the confusion .
(Part 2 of this feature will go into these reasons. It will be posted on Techworld in a few days time - Ed.)
Rory MacDonald, Technology Creative
T: +44 (0)23 9281 4259
M: +44 (0)7899 965 232
E: [email protected]
Find your next job with techworld jobs