Image Server for WebApp... questions about how to serve images

[TechBoyJK]

I'm building an app, and I'm trying to decide on the best way to manage hosting photos that would be uploaded.

The app is hosted on a CentOS vm named WWW01.

My current plan is to have a standalone CentOS box called 'IMAGES01' on the same private network with a folder /images shared via NFS and mounted as /images01 on the webserver (WWW01). With that, any uploads through the webapp will end up on the image server.

In order to serve the images, I'm trying to decide between hosting them back through the webserver, or hosting them directly from the imageserver. It seems like it would be more efficient to use apache to host the images directly off the image server.

Thoughts?

 

[debian0001]

Wouldn't it be better to have it hosted on the same server? Seems overkill to have 2.

 

[TechBoyJK]

Wouldn't it be better to have it hosted on the same server? Seems overkill to have 2.

Good question. Let me explain why I'm planning things this way.

It's for growth. There will be multiple web servers for load and redundancy.

The app is coded to allow for multiple image servers as well. By keeping the images on a separate server, images uploaded through the app don't need to be reconciled among the different web servers. They will all hit a single, central image repository. And I can also have multiple repositories by just setting up a new image server (IMAGES02, IMAGES03). My app will keep track of which imageserver an image is on, and include that info when retrieving and publishing the image.

aka. I could have 20 different instances of the webapp running on the cloud, and if I hosted directly, they'd all need to have copies of the images and keep it in sync. That's 20 copies of each image. That'd actually be overkill.

Make sense?

 

[Ken g6]

Serving files off NFS doesn't seem like a good idea to me. That just means both servers have to do work. I'd think you'd want to serve the files directly off separate servers. At some point, you might want to move the files to a Content Delivery Network, or CDN, and then you'd definitely want the files on separate servers.

 

[MrColin]

Serving files off NFS doesn't seem like a good idea to me. That just means both servers have to do work. I'd think you'd want to serve the files directly off separate servers. At some point, you might want to move the files to a Content Delivery Network, or CDN, and then you'd definitely want the files on separate servers.

I have to agree with this. You are only introducing more load on the app server by making it serve both the http request and mounting/using the NFS share. I guess the work of integrating whatever access control between the app server and the content server could be avoided with the NFS approach though.

 

[Aluvus]

Wouldn't it be better to have it hosted on the same server? Seems overkill to have 2.

There are real advantages (and disadvantages) to hosting images (and other static content) from a separate subdomain.

 

[hooflung]

If they are on the same physical machine serving over a share folder adds protocol overhead that just isn't needed. For instance if a VM vendor, or a personal cloud stack, might run virtual images off of iSCSI then there is no reason you 'd want to NFS between your vm's which are already running on top of another filesystem (hopefully zfs) which might already be implementing NFS.

HTTP static content is probably the best bet. Nginx it out.