views:

235

answers:

1

The file system part of our asp.net application framework requires updating to fall inline with our SaaS / Multi-Tenancy approach and in particular with regards scaling up.

Our current file system stores files on disk in separate folders for each tenant.

ie: X:\FilesFolder\ApplicationInstance\TenantA etc where the Tenant names and file names are Guids. We have an HttpHandler that retrieves files and resolves all the paths and names and returns the original file names etc. We store the root path for each Tenant, ie : X:\FilesFolder\ApplicationInstance\ on the basis we can move them at some point and to different locations if required.

With regards concerns for scaling this system up, I have some questions... (please excuse my ignorance to the hardware/ windows infrastructure side of things, and my questions are more about implementing the update to our filesystem code)

1) It seems obvious that the files should all be stored on a NAS device?

2) If we add a NAS device and build a server farm, do we need to start running domain controllers? and how does this effect references to paths?

Edit: Found out that Domains are not required for server farms, which is great, still not sure how this effects usable paths etc

3) Should we be using drive letter paths (mapped drives) or UNC paths?

4) Is there any performance hit in referencing UNC instead of names drive letters (even in the same machine)

5) What permissions issues can we expect and how does this effect running on a domain or not?

Edit: Having a domain would make permissions easier, but still still dont know what the differences are.

Any comments on this approach, best practices or a better approach appreciated.

Thanks

+2  A: 

What you should do is abstract your storage code so that the path is only an implementation detail. This way, you can change the path architecture completely, as may be required by your storage technology.

John Saunders
I guess we have done this having the HttpHandler and would just need to enabling the actual reading/streaming of the file from disk by absolute path or UNC by configuration.
Mark Redman
Well, no, that's not what I said. I said abstract away the file access.
John Saunders
ok, then not sure what you're saying?
Mark Redman
Take everything that has to do with file access, and encapsulate it into a small set of public classes. Refactor the classes so that they are not specific to file access, but more generally, to storage. In this way, you will later be able to have one set of classes that are about storage on a file system, another about storage on a NAS, etc.
John Saunders
Thanks, do you know of any information that can give me some ideas/concepts for implementation this?
Mark Redman