Thoughts on a File Server

[Jamo]

What are all your thoughts on the below:

We are looking at provisioning a new file server. We currently have shares scattered among different servers making management more difficult. Bearing in mind we run a VMware system with ESXi servers, would it be better to:

• Create 1 server, with loads of RAM and multiple processors to house all Staff, Student, SharedStaff, SharedStu, 6thForm shares
• Create multiple servers which are less powerful and spread the shares between them

Are there any recommendations as to how much RAM to dedicate to such a server given that we have 700 client PCs with the shares listed above, so it is likely that many open connections will exist at the same time to the different shares for each user.

Either way we will be running Server 2008r2

Thanks,
James

[pete]

What does perfmon suggest?
What does the ESXi performance counters suggest?

Are you attaching storage to a VM or are you putting the storage in with the VM?

[Jamo]

What does perfmon suggest?
What does the ESXi performance counters suggest?

Are you attaching storage to a VM or are you putting the storage in with the VM?

Difficult to suggest what the performance counters suggest as some currently are not just sharing files, one is a DC, one has a lot of web sites attached is a IAS server and runs 2003. So performance is going to be different which ever way we look at it.

We are not getting bad performance, rather just looking for what best practice dictates as one or more servers is going to be created next week!

I don't see what difference you are suggesting by the storage location of the VM disks? They will all be running off one of the 3 SANS we have here.

[dhicks]

Create 1 server, with loads of RAM and multiple processors to house all Staff, Student, SharedStaff, SharedStu, 6thForm shares

I'd go for this option - with all files on one server, deduplication will work better. I seem to remember Windows Server does deduplication at the block level in batch mode, so you write your files to the filesystem and at some point in the future they get deduplicated. That probably takes less RAM than ZFS, which seems to require at least 8GB of RAM before it will do any deduplication.

[SYNACK]

I'd go for this option - with all files on one server, deduplication will work better. I seem to remember Windows Server does deduplication at the block level in batch mode, so you write your files to the filesystem and at some point in the future they get deduplicated. That probably takes less RAM than ZFS, which seems to require at least 8GB of RAM before it will do any deduplication.

I think only 2012 has dedupe built in, before that it was a component of WSS not the base Server OS.

[ChrisMiles]

What are all your thoughts on the below:

We are looking at provisioning a new file server. We currently have shares scattered among different servers making management more difficult. Bearing in mind we run a VMware system with ESXi servers, would it be better to:

• Create 1 server, with loads of RAM and multiple processors to house all Staff, Student, SharedStaff, SharedStu, 6thForm shares
• Create multiple servers which are less powerful and spread the shares between them

Are there any recommendations as to how much RAM to dedicate to such a server given that we have 700 client PCs with the shares listed above, so it is likely that many open connections will exist at the same time to the different shares for each user.

Either way we will be running Server 2008r2

Thanks,
James

Really its probably better to use a single server. File Services are not going to max out on memory or CPU power, its going to only be limited by your storage. I'd say divide the shares up on different servers only if the data is held on different arrays and it's likely that one or more arrays could be maxed out during peak usage.

[zag]

Ram is pretty much irrelevant for a file server. We run our main one on 4gb but it never goes about 1gb in normal day to day usage. Its a hyper-v machine.

I would have 2 file servers mirroring each other personally.

Check my recent thread in the hardware forum

Building a new SSD based file server

[MicrosoftTechy]

Multiple because you then have the option if needed to only bring 'staff' fileserver down or 'students' not everyone

[Jamo]

Multiple because you then have the option if needed to only bring 'staff' fileserver down or 'students' not everyone

Thanks everyone

I did think of doing multiple purely for the reason above, however we are trying to condense similar functions together, all file services together in this case, so if we have to reboot or take down the server with all those shares on it, its going to be something rather bad, which will have probably already impacted the network radically anyway.


From what people are saying here then, single server it is! Going to put each share on a separate VMDK we think, that way we can migrate between datastores quicker per disk so lower downtime per share. Also lets us adjust quotas a little easier.

[oxide54]

Thanks everyone

I did think of doing multiple purely for the reason above, however we are trying to condense similar functions together, all file services together in this case, so if we have to reboot or take down the server with all those shares on it, its going to be something rather bad, which will have probably already impacted the network radically anyway.


From what people are saying here then, single server it is! Going to put each share on a separate VMDK we think, that way we can migrate between datastores quicker per disk so lower downtime per share. Also lets us adjust quotas a little easier.

multiple servers (spread over hosts) will also spread the load across the HBA's and NIC's.

[psydii]

Based on my experience of piling it all into one 2008R2 VM (vSphere 4.1)....


Spread the FileServer load across across your physical boxes and SAN links.
Spread your students evenly (e.i. 1/3 yr7 on srv1, 1/3 on srv2, 1/3 on srv3)
Same for the staff.

WHY? For the reasons stated by @oxide54 and the Indexer Service, which is critical to much useful functionality in W7 has a limit of about 2M files, and IMHO appears to suffer from some sort of leak. Also latency - I'm not sure quite what happens but some client activities overwhelm the single vm, and latency goes sky high, causing clients to behave erratically.

We also see a sustained throughut of about 40Mbps during each period, with spikes at the beginning and end as roaming profiles load and sync's complete.

My hosts are a little tight on RAM, but the FS VM has 8GB allocated and it gives mostly reasonable performance, improved(*) from when it had only 4GB. vSphere reports only 40% utilisation. To my shame I can't report on cache hits/misses, because i haven't been monitoring them.

* With only 4GB we would see dramatic slow-downs quite frequently. With 8 allocated these have dropped right off.