[Gluster-devel] Re-exporting NFS to vmware

[Christopher Hawkins]

This is not scalable to more than a few servers, but one possibility for this type of setup is to use LVS in conjunction with Gluster storage. 

Say there were 3 gluster storage nodes doing a 3x replicate. One of them (or a small 4th server) could have a virtual IP that accepts inbound NFS requests and then forwards them to one of the 3 "real server" gluster storage nodes. Each would be listening on NFS, would have all the files, and would be able to serve directly and respond with the IP that the packet was originally addressed to. 

While this is not scalable, it would be fast and I assume would allow you to break the 500MB/s barrier by removing the single point of origination / response that was the sole NFS server. If the nodes could each be loaded up with enough storage maybe this works for some people.

Chris  


----- "Gordan Bobic" <gordan at bobich.net> wrote:

> 沈允中 wrote:
> 
> > And now I know that it's impossible for nfsd to re-export a FUSE
> mounted filesystem.
> > But the workflow of the gluster native nfsd is not smart just as the
> white paper mentioned.
> > Gluster will act stupid when not using glusterfs protocol.
> > 1. A client asks server A for a file but server A doesn't have it.
> > 2. Server A finds server B has the file.
> > 3. Server B transfers the file to the server A.
> > 4. Server A transfers the file to the client.
> > 
> > So step 3 is a stupid and time-wasting process.
> > How do you solve this problem when you have to use nfs protocol?
> 
> There is no way to solve this with NFS. The protocol doesn't
> understand 
> the concept of multiple servers.
> 
> Depending on how far you were prepared to go with cheating and forging
> 
> network packets, however, you might be able to do something like
> this:
> 
> 1) Request comes in to server A. Server A doesn't have the file.
> 2) Server A notifies server B, which has the file, that client C wants
> 
> the file.
> 3) Server B hand-crafts network packets to make them look like they
> are 
> coming from server A, and server A continues getting responses, which
> it 
> continues passing to server B. Server B uses this information to 
> continue sending "forged" packets with the file data to client C.
> 
> If you are using UDP for NFS, you could plausibly do something like 
> this. You'd still need server A to pass ACKs to server B. Server B
> would 
> effectively be performing a man-in-the-middle sort of attack to 
> facilitate the bulk of the data going straight from A to C.
> 
> Of course, nothing like this is implemented, so I guess it depends on
> 
> how desperate you are for such a feature.
> 
> Gordan
> 
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/gluster-devel