Storage Area Networks never really realized the promise of providing a shared pool of storage. IBM’s Storage Tank delivers on that promise - and more. Here’s an exclusive, in-depth look at how Storage Tank works
By now, most of you are probably familiar with the promise of storage area networks (SANs): put all your storage in a heap in the center of the room and all your servers around the edges. In this configuration, the storage heap looks like the physically-attached disks the servers are used to, but all of the servers see all of the same disks all the time. According to the ideal, SAN is supposed to cheaper and simpler, too. With SAN, storage doesn’t have to be divided up among the servers, and shadowing and workload partitioning are unnecessary. And, of course, the SAN ideal provides the speed of conventional, locally-attached disks.
Indeed, sites are using SANs today to get these benefits. You can move storage space from one server to another, or from your reserve pool, without leaving your desk and without powering down. You can have a multitude of servers use a single copy of some data.
But the reality stops far short of what you might envision as a shared pool of storage. Though you can move storage around just by updating configuration files, you still have to manage the space.
You still have to figure out how many blocks of what kind of space each server needs, and you must constantly move it around to stay on top of changing business needs. You’re still required to keep track of what’s mounted where, must enlarge and reduce filesystems, must move files from one filesystem to…
Please log in to view this content.
Not Yet a Member?
Register with LinuxMagazine.com and get free access to the entire archive, including:
