The article is not well written.
One of the biggest problems is that there are multiple layers of abstraction built into the full stack of storage, and "virtualization" is a fuzzy enough word as to be hard to definitively assign a place to put it. For a good look at the many layers of abstraction in storage, I'll point you at a blog piece I did last year (read it here for the gory details).
In marketing-speak, "Storage Virtualization" is just introducing abstraction where there previously hasn't been any. That can happen at many points depending on the market segment. But that's just marketing. Time for technical.
The storage stack (somewhat simplified):
- Disk
- RAID controller
- Software RAID
- Volume manager
- Filesystem
- Network filesystem
- Network filesystem client
Disk, even old school spinning magnetic disks, do a level of virtualization. They present a logical view of the actual blocks on the platters (or storage cells for an SSD), and this has been this way since the mid 80's or so. Magnetic drives reserve a certain number of blocks for reassigning blocks that go bad, and the logical view is how this is abstracted away from the disk controller. Technologies like SMART can catch this in the act and report that the drive is "pre-fail" so you can plan your transition accordingly. This has been in place in some form since the 80's.
RAID cards provide another abstraction layer, hiding the true shape of storage from an operating system. This has been in place since the first RAID cards came out in the late 80's, and they've only gotten more complex since then. Cards with write-caches on them provide still another abstraction layer, as writes can be reported as committed before they're actually on a disk somewhere. The really fancy ones (such as those in Storage Area Network arrays) can even write to two separate disk arrays for realtime replication, and the OS is none the wiser.
Once you get into the operating system things get a lot more murky, as each does their own thing. Software RAID (md in Linux) is typically implemented as a low level storage driver that presents the logically combined storage to higher storage layers. As with the RAID cards, you can do all sorts of interesting things here. Some of the "Storage Virtualization" products you see out there are implemented at this stage.
Going higher you get to the volume managers (LVM) can provide for some seriously complex configurations. Where the next layer down aggregates disks into a single virtual volume, the volume managers can combine multiple volumes into a single bigger volume... or split a pool of volumes into an arbitrary number of volumes. Again, some of the Storage Virtualization products you see have a presence in this layer as well.
The next step up is the filesystem. This is the layer where the well known abstractions of "file" and "directory" come into existence. Some filesystems (btrfs, zfs) have volume-manager like features built into them which allows things like snapshotting, deduplication, replication to other devices, and even migration of files between storage tiers. That last bit is not in many filesystems yet, but is definitely a target for Storage Virtualization vendors.
The next step up is the network filesystem. This is things like Samba/CIFS, NetATalk/Appletalk, NFS, and others. If written the right way, these network filesystems can further abstract storage. One product I'm thinking of, Novell's Open Enterprise Server and their ShadowVolumes, takes multiple volumes on different storage (presumably differing speeds/cost) and presents them as a single volume to the network user, and then migrates files between the volumes based on usage statistics. Some of the "Storage Virtualization" appliances you can buy actually do their heavy lifting at this layer.
The last stop on our trip up the storage stack is the network filesystem client in the client machine. It is at this level that the Distributed File System (DFS) exists, which allows a single logical presentation of a filesystem to exist on multiple network filesystems. The client knows that this is a DFS share, and that specific object is a DFS link, and when following it present the specified network-share as a sub-directory of the parent directory. There have been other examples of abstraction at this level, but DFS is perhaps the most common.
One thing to keep in mind is that through all of this, each layer of the storage stack is independent of those above it. Many layers are already doing block-level abstraction, so adding one more doesn't change a whole lot. File-level abstraction has to happen near the top of the stack (for that's where the file-systems live) and the impacts lower down are highly decoupled to the point that it may not even be noticed.
At it's core "Storage Virtualization" is still mostly a marketing term for something that has been happening since the dawn of the PC era (if not earlier), only this time the new abstraction layers are happening when virtualization is the buzzword of the moment.
The one new abstraction layer I know of is something called a "Storage Router", which you'll only ever see on large Storage Area Networks. This device has several different storage arrays behind it, and presents those separate arrays as single array with multiple LUNs. The fancier ones can do interesting block-level abstractions like moving rarely used blocks to slower/cheaper storage and moving the highly used blocks to SSD layers, or handle realtime replication between storage arrays that normally wouldn't allow that kind of thing.
P.S.: RAID is not just device-level virtualization. I'm working with a storage array right now that takes slices of disks and assigns them to different RAID groups. It is working just fine (I'm doing it right now), and I have both RAID1 and RAID5 volumes on the same disk device. Lose two drives and the RAID5 volumes are toast, but the RAID1 volumes on the same disks are just fine.