Yes, I realize there are tremendous hurdles. It will also take a vendor who builds their own solution ala Network Appliance, or even Sun. They would have to marry it to specific OS/hardware (Sun could "easily" do this, while Netapp would have to sell the internal fibre or SCSI card to go in the server as well as the disk arrays). All that aside, there would be no point if the current network technologies make it unnecessary to separate the two very different traffic requirements. I believe, though, that such an offering would hold tremendous value to large sites, particularly as virtual sites on the internet increase (many servers/services appearing as one).
-----Original Message----- From: tkaczma@gryf.net [mailto:tkaczma@gryf.net] Sent: Monday, March 29, 1999 5:55 PM To: 'toasters@mathworks.com' Subject: RE: NAC SAN
On Mon, 29 Mar 1999, Sam Schorr wrote:
Why not a box with a special OS (ala WAFL) that runs on what servers recognize as a fibre hub, intercepts the SCSI calls from all attached servers, and does all the nifty stuff needed to make the SAN(?) look like locally attached storage? Advantage? Separate file I/O from TCP session traffic but still allow file sharing in some form or another.
I thought about this, but if you really want to take it to the extreme, then the switch has to know exactly how it is used. Imagine any "erver" box that uses mirroring or striping. Unless you know exactly how data is placed you won't be able to recognize how the filesystem looks. Then there is caching. Usually systems don't worry about cache coherency on locally attached storage. The assume (fairly correctly too) that they are the only ones using the storage.
Tom
I think the simple litmus test of SAN vs. NAS is "who's allowed to touch the disks." In a NAS setting, as we have with our filers, all disk access is proxied by the filer.. Even if there were a way to open up the disk directly to the client, we probably wouldn't because they're generally considerd untrusted (in terms of making sure they don't hork things up).
From my perspective of a SAN, is that you trust all the attached hosts not to do 'bad' things to the disk; we can be safe to presume they'll behave in a prescribed manner and therfore have a 'network' of sorts that allows native disk access. All of a sudden, we have something that isn't bound by bottlenecks in the filer at all, can be built up to be reliable in whatever fashion suits us, etc.
One problem. It doesn't work.
Somewhere in there, we still need a means to handle locks, as well as regular filesystem maintenance (managing inode allocation and free blocks comes to mind offhand). There's a couple ways that I can think of doing this, one of which is to have your netapp san device acting as storage management. It takes care of these things, and hosts are responsible for negotiating locks and such through it, but when it comes down to getting data, hosts can act entirely independently.
there's a million other issues to be worked out in the process, namely this bizzare hybrid filesystem driver. Would it be worth it? I'm not really sure, but atleast intuitively, it would seem to move the storage bottleneck back down to the disk.
enough for now.
..kg..
On Tue, 30 Mar 1999, Sam Schorr wrote:
Yes, I realize there are tremendous hurdles. It will also take a vendor who builds their own solution ala Network Appliance, or even Sun. They would have to marry it to specific OS/hardware (Sun could "easily" do this, while Netapp would have to sell the internal fibre or SCSI card to go in the server as well as the disk arrays). All that aside, there would be no point if the current network technologies make it unnecessary to separate the two very different traffic requirements. I believe, though, that such an offering would hold tremendous value to large sites, particularly as virtual sites on the internet increase (many servers/services appearing as one).