At a Hamish Macarthur symposium on managing and securing data I realised something afresh. It starts from that well known storage point that SANs serve blocks to server applications and NAS serve files. Okay. Now put a NAS head on the SAN. There is no change. The SAN access route delivers blocks; the NAS one provides files. But the data in the blocks comes from different storage locations than the data in the files.

You don't have a single logical pool of storage holding blocks of data. It is not the case that the SAN access method gets raw blocks delivered and the NAS route gets the blocks combined into files which are then delivered. Or, rather, yes the SAN applications get raw blocks and the NAS applications get blocks combined into files, but they are different blocks.

The SAN blocks are stored in one place - the SAN of course - and the NAS blocks are 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. You simply cannot combine NAS-type block storage and SAN-type block storage. You simply can't combine non-shared SAN blocks with shared NAS blocks (in files).

Having NAS and SAN inevitably means having two separate pools of storage, even behind a NAS head on a SAN. The NAS head gives you file-level access to a lump of file blocks tacked onto the side of the SAN but not logically part of it.

This means that a lump of virtualised SAN storage cannot be used to hold NAS files. A lump of virtualised NAS storage cannot be used to hold SAN blocks.

NAS and SAN are separate and divisible and cannot be virtualised into one single pool of storage.

Find your next job with techworld jobs