On Sun, 4 Apr 1999, Chen, Ray wrote:
(Actually, I'm lying here. There are two ways of enabling this. One is to use a really simple protocol like SCSI. The other is to implement an industry-standard clustered filesystem with the disk drives/storage devices as an intelligent component of said filesystem. A very complex protocol whose viability and practicality is an issue in its own right. The rest of this mail assumes a block-level SAN protocol.)
Actually the two aren't exclusive of each other. The standard protocol/filesystem could be implemented on the drives or the clients, or a little of both. If it is implemented on the drives then it doesn't need to be so standard, i.e. different OSes could use different protocols. Hey, that's what NAC is doing right now. Perhaps they should change their slogan to "Putting intelligence in the drives" [ Copyright 1999, Tom Kaczmarski along with other look and feel derrivatives ;) unless of course previously copyrighted by someone else. Call me a slogan squatter. ;) ].
As folks have pointed out, SAN has its advantages and disadvantages. It eliminates the backplane of server (unless you have a RAID controller in front of the drives :-) from the I/O path, eliminating a possible I/O bottleneck. But there is no server to protect the integrity of the data and even if there is, the protocol is so low-level in a SAN, the server has no effective way of detecting when a client has gone insane (maliciously or not) and is scribbling gibberish on the drives. So trust becomes a definite issue.
You are a bit confusing here, in the first sentence server means the computer attached to the storage, in the second you mean the drive or storage itself, and the client is the computer attached to the storage. I'm just including this note to clarify, I understand what you mean, I think. You're really not eliminating anything, you're just sharing it. The server backplane (system bus) is unaffected, the I/O "backplane"/bus becomes the I/O backbone. However, perhaps we should come up with a more unified bus and add MP to SAN. I think eventually, this will happen, as drives become really slow with respect to computers (aren't they already), and faster and cheaper semi-permanent and almost-permanent storage appears. "The network is the computer" -- Sun Microsystems.
Personally, I see data sharing using SANS as making sense in small workgroup environments and what I call "machine room clusters" -- a SAN in a machine room supporting a dedicated cluster.
I think SANS will at least initially be used exactly how NAC uses the technology in their clusters, i.e. hot backups. Eventually a standard will be developed to allow "synchronous" device sharing between computers. It's pushing NFS down to the drive, while adding block/drive locking (the latter already present in FC-AL) and synchronisation messaging.
Typically you'd do the latter because scaling via a cluster is cheaper (and more available) than scaling via MP.
I don't agree with this statement fully. Scaling via MP should be cheaper, but probably not more available. Scaling via MP saves on hardware costs, of course this MAY be offset by the additional expense for more complex MP hardware (this MAY be especially true for MP systems with large CPU numbers).
But both are situations where you are willing to trust all the machines in the cluster because they are all firmly controlled by the group whose storage/data is being shared.
With proper measures in the SAN implementation you can extend that trust to all machines, even those you don't trust. You simply don't allow them access to your disks, or cerain portions of those disks. A question of DOS attacks still remains in this scenario, whereas it is limited to the cluster in yours. I think that will be a tougher nut to crack. On one hand, it would be nice to have access to all the storage from one place for backup purposes with as little duplication as possible and maximize your SAN utilization, on the other, you don't want one agent to influence another too much.
Tom