Ok – certain people do certain things well.
I’m a storage administrator/architect. If you present me a problem I will *ALWAYS* look at it from a storage standpoint. If you present me with a non-storage problem, I’ll try and make it fit.
I’ve identified four types of systems engineer-type-people:
I think that just about anyone in IT either fits into one of those four roles or supports one of those roles.
Now when you are looking to solve a problem, the solution you get depends on who you go to. If you ask a desktop person to solve a network problem for instance, they will probably come up with something under the desk. (IE throwing a linksys router under a desk.)
If you try and throw a server person a storage role, you’re going to get a server solution to that role.
Enter IBM GPFS.
GPFS is a server solution to a storage problem. It’s obvious that the person who came up with the idea of solving a storage problem by loading software on a server is not a storage person.
POSIT: Mutliple hosts in a web-farm need access to data. Filesystems need to be R/W to an ingest server and R/O to the web-content servers.
Storage Solution: NAS/NFS – Trunked connection to a real backbone and multiple Apache webserver front-ends running at 1G to play out data. (Fastest data transfer is going to be the 45MB/Sec backbone coming into the building, so a single Gigabit connection can handle it. F5 Round-robin load-balancer to distribute the front-end load. (might also be proposed by Savvy network people, who tend to understand NAS)
Server Solution: IBM GPFS solution. Over a million dollars in net-new server hardware + software licensing (not including storage). Each host accessing storage requires HBA’s, Drivers, fast RELIABLE network. and a level of complexity unheard of even in government.
From what I can tell, and maybe someone can give me a little more insight, works very much like Sun’s Shared QFS. A metadata server acts as a gatekeeper telling which member servers can access which blocks on which disks. There is still no simultaneous disk access because a SCSI lock is a SCSI lock.
Now from a storage standpoint, this is rife with problems.
First off, it would seem that if network access was compromised during a write data integrity could easily be compromised.
Secondly, Other than block-level mirroring of the underlying disks, I can’t see a good way to replicate this. And block-level mirroring of the underlying disks would require an identical infrastructure at the remote/DR site wouldn’t it? That is of course assuming that the metadata can be mirrored.
Now in database uses or other types of distributed computing I can see it being VERY valuable. But for flat file storage and web retrieval I can’t think of a single good reason to use something so obnoxiously complicated. Especially when EMC Celerra, NetApp, or just about any of the other higher-end NAS appliances would cost *SO MUCH* less and be *SO MUCH* more reliable.