Mongrel users - Dec 2006 - Using a network drive to share files between Mongrel/Rails instances...?

I have a Apache proxying to a number of Mongrel''s on different physical
machines.

What I need to do next is share files between the Rails instances. I am 
creating dynamic files which will be created by Rails and stored on 
disk. The file is then recovered and served at a later date by an ajax 
request.

But because of the proxying the ajax call my be routed to a different 
machine. Therefore I am considering setting up a shared drive to which 
all Rails instances will save the files. At the moment I am working on 
Windows but this will be Linux or FreeBSD in the end... I''m guessing 
shared drives are simply paths in both cases.

Is there anything I need to consider with this method?


Many thanks, K.



PS. I am aware of other methods for doing this eg. sticky sessions and 
some kind of message que, and I am open to suggestions :)

Kris,

I assume you mean network shared drive (as in NFS)?

While I think that NFS is the simplest solution - where you have one  
file server that exports a share, and your web servers mount the  
share, there are plenty of operational issues with NFS, enough that I  
would strongly consider any other options before deciding to make NFS  
share part of your production system.

There are a couple of problems with NFS that one should consider.   
First of all it''s rather slow, but that does not have to be a huge  
problem (plus file system caching may alleviate this somewhat).   The  
bigger problem is the hanging mounts, which may happen if your server  
goes away temporarily from the network (either crashes, or network  
failure, or network overload).  In my experience hosts that mount NFS  
shares from a server which disappears may become frozen /  
unresponsive / impossible to fix without a hard reboot.  This comes  
from  observing a particular production system running Linux /  
Solaris machines and using NFS for exactly the described purpose.

If you are creating these files, but not really deleting them by the  
application in real time, you may consider writing them locally on  
each server to a given directory, and serving them from another local  
directory, which is populated by a periodic script. The script would  
run on each participating machine and would clone a batch of newly  
created files to each participating server.  More management  
overhead, but if you are running a mission critical and performance  
hungry application with lots of components, that would be my first  
choice.

For non-mission critical apps, or where performance is not a huge  
deal the NFS approach is by far the simplest.

Hope this helps,
Konstantin


On Dec 18, 2006, at 2:30 AM, Kris Leech wrote:
> I have a Apache proxying to a number of Mongrel''s on different  
> physical
> machines.
>
> What I need to do next is share files between the Rails instances.  
> I am
> creating dynamic files which will be created by Rails and stored on
> disk. The file is then recovered and served at a later date by an ajax
> request.
>
> But because of the proxying the ajax call my be routed to a different
> machine. Therefore I am considering setting up a shared drive to which
> all Rails instances will save the files. At the moment I am working on
> Windows but this will be Linux or FreeBSD in the end... I''m
guessing
> shared drives are simply paths in both cases.
>
> Is there anything I need to consider with this method?
>
>
> Many thanks, K.
>
>
>
> PS. I am aware of other methods for doing this eg. sticky sessions and
> some kind of message que, and I am open to suggestions :)
>
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

Kris,

Another option, depending on the size of the files of course, is to  
create a secondary database for the application and store the files  
within that database.

I am not claiming that this is optimal for your instance, just that  
it is a very effective option and should be at least thought about.

If the files are smaller and you increase your database caching  
"sufficiently" then this can prove to be a very viable option and  
quite simple to implement.

   ~Wayne

On 12/18/06, kigsteronline at mac.com <kigsteronline at mac.com>
wrote:
>
> If you are creating these files, but not really deleting them by the
> application in real time, you may consider writing them locally on
> each server to a given directory, and serving them from another local
> directory, which is populated by a periodic script. The script would
> run on each participating machine and would clone a batch of newly
> created files to each participating server.  More management
> overhead, but if you are running a mission critical and performance
> hungry application with lots of components, that would be my first
> choice.


For this, I''d reccomend rdist [1]. With a little bit of work, you could
produce the files on one of the machines and easily distribute them to other
machines.

-ryan

1. http://www.magnicomp.com/rdist/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20061224/bc66bc0c/attachment.html