We are migrating shared files off of a Windows domain controller to a
discrete file server, and I'm thinking through what would be the best design
for that new server.     Given that 64 bit operating systems are now here,
I'm thinking we do not need to spend much on fast drives, but we should
instead invest in the lowest cost 64 bit server (a file server won't
bottleneck on CPU so even a 1 GHz machine would be fast enough) and install
gigabit ethernet and lots of memory.     I'm sure that the most requested
files would fit into a memory cache that is under 10 GB in size.     A
computer with 12 GB of memory, 64 bit Windows 2003 server web edition, and
gigabit ethernet should provide the best possible speed for the case where
there is not much write activity, but lots of read activity on less than 10
GB of data.

Assume less than 20 users, heavy read activity, very low write activity.
Disk with all file shares would be under 100 GB, but under 10 GB of that
represents 95% of the activity.

Is my design correct if I want to maximize performance for this small
network?

--
Will

[ Post a follow-up to this message ]

Will wrote:
> We are migrating shared files off of a Windows domain controller to a
> discrete file server, and I'm thinking through what would be the best desi
gn
> for that new server.     Given that 64 bit operating systems are now here,
> I'm thinking we do not need to spend much on fast drives, but we should
> instead invest in the lowest cost 64 bit server (a file server won't
> bottleneck on CPU so even a 1 GHz machine would be fast enough) and instal
l
> gigabit ethernet and lots of memory.     I'm sure that the most requested
> files would fit into a memory cache that is under 10 GB in size.     A
> computer with 12 GB of memory, 64 bit Windows 2003 server web edition, and
> gigabit ethernet should provide the best possible speed for the case where
> there is not much write activity, but lots of read activity on less than 1
0
> GB of data.
>
> Assume less than 20 users, heavy read activity, very low write activity.
> Disk with all file shares would be under 100 GB, but under 10 GB of that
> represents 95% of the activity.
>
> Is my design correct if I want to maximize performance for this small
> network?


If you've correctly characterized your workload, it's not an
unreasonable plan, except I didn't think MS has done a 64 bit WS2003
Web Server Edition yet, and second, the Web Server Edition is *not*
licensed for local file serving.

64-bit WS2003 Standard Edition is probably what you're looking for.

Nonetheless, reasonably fast drives will help at initial loads and when
hitting files that don't cache.  But I'd probably be more concerned
about drive reliability than performance.  A mirrored pair of server
class SATA drives of the requisite capacity (but not the fastest
available) are probably a much better idea than cheaping out and
putting a couple of desktop drives in there.

Second on a server, and *especially* with that much RAM, I'd
absolutely insist on ECC'd memory.

[ Post a follow-up to this message ]

Will wrote:
> We are migrating shared files off of a Windows domain controller to a
> discrete file server, and I'm thinking through what would be the best desi
gn
> for that new server.     Given that 64 bit operating systems are now here,
> I'm thinking we do not need to spend much on fast drives, but we should
> instead invest in the lowest cost 64 bit server (a file server won't
> bottleneck on CPU so even a 1 GHz machine would be fast enough) and instal
l
> gigabit ethernet and lots of memory.     I'm sure that the most requested
> files would fit into a memory cache that is under 10 GB in size.     A
> computer with 12 GB of memory, 64 bit Windows 2003 server web edition, and
> gigabit ethernet should provide the best possible speed for the case where
> there is not much write activity, but lots of read activity on less than 1
0
> GB of data.
>
> Assume less than 20 users, heavy read activity, very low write activity.
> Disk with all file shares would be under 100 GB, but under 10 GB of that
> represents 95% of the activity.
>
> Is my design correct if I want to maximize performance for this small
> network?
>

10GB of RAM sounds like overkill.  File servers of the size you're
talking about are generally well underutilized.  I've seen VMWare
servers with 4GB of RAM running 10 Windows file servers serving more
users per server than you are looking for.  If money is no object, but
all means go for it.  If you're looking to size your server to your
workload you could probably save yourself several thousand dollars by
going with a lower end box with less RAM.

Also, you don't mention what type of data you'll be working with, but
typically file servers are very tolerant of disk latency.  If an end
user opening a file sees a 50ms delay instead of a 4ms delay, do they
really notice the difference?  If you're working with large sound or
video files and that's a concern, you could go with 15K rpm SCSI disks.
If not, you're probably going to be okay with lower cost and higher
capacity SATA disks.

[ Post a follow-up to this message ]

"Jon Metzger" <blagh@___gmail.com> wrote in message
news:ecut56$6j0$1@lenny.tc.umn.edu...
> 10GB of RAM sounds like overkill.  File servers of the size you're
> talking about are generally well underutilized.  I've seen VMWare
> servers with 4GB of RAM running 10 Windows file servers serving more
> users per server than you are looking for.  If money is no object, but
> all means go for it.  If you're looking to size your server to your
> workload you could probably save yourself several thousand dollars by
> going with a lower end box with less RAM.

Point well taken.   What tools are available for a Windows environment to
help us profile what amount of the file system is actually being read over
the course of a week?

--
Will

[ Post a follow-up to this message ]

<robertwessel2@yahoo.com> wrote in message
news:1156674534.173513.147570@i42g2000cwa.googlegroups.com...
> If you've correctly characterized your workload, it's not an
> unreasonable plan, except I didn't think MS has done a 64 bit WS2003
> Web Server Edition yet, and second, the Web Server Edition is *not*
> licensed for local file serving.

It looks like you are correct.   What a pity.   Not very good marketing on
Microsoft's part.   I would probably try to get more life out of a Windows
2000 box than force an expensive software upgrade.

--
Will

[ Post a follow-up to this message ]

Will wrote:
> "Jon Metzger" <blagh@___gmail.com> wrote in message
> news:ecut56$6j0$1@lenny.tc.umn.edu... 
>
> Point well taken.   What tools are available for a Windows environment to
> help us profile what amount of the file system is actually being read over
> the course of a week?
>

Check out Perfmon, it's built in to Windows.  It may be a little tricky
to set up, but all the information you'll need you should be able to
find there.

[ Post a follow-up to this message ]

"Jon Metzger" <blagh@___gmail.com> wrote in message
news:ed1bl1$lk0$1@lenny.tc.umn.edu...
> Check out Perfmon, it's built in to Windows.  It may be a little tricky
> to set up, but all the information you'll need you should be able to
> find there.

I don't think Perfmon would track anything more than low level performance
characteristics like number of reads and writes on a logical or physical
volume.

How is that going to help me determine that 95% of the reads are on xx GB of
the file system?

--
Will

[ Post a follow-up to this message ]

Will wrote:
> "Jon Metzger" <blagh@___gmail.com> wrote in message
> news:ed1bl1$lk0$1@lenny.tc.umn.edu... 
>
> I don't think Perfmon would track anything more than low level performance
> characteristics like number of reads and writes on a logical or physical
> volume.
>
> How is that going to help me determine that 95% of the reads are on xx GB 
of
> the file system?
>

Sorry, I misread your original question...PerfMon probably won't get you
that level of detail.  I'm guessing you're wanting to know this
statistic in order to size your RAM so that all of this "most read" data
will remain in filesystem cache.  I think you may be over-engineering
your solution.  I've seen people insist upon 15K rpm SCSI disks for
fileservers that have since been migrated to ATA without anyone knowing
the difference.

With that said, having hard data to plan with is always better than
guessing.  I'd watch PerfMon for reads and writes per second and KB
transferred and purchase disks which can handle that load plus some
headroom for growth.  The filesystem cache is all well and good, but
it's a good idea to plan for your disk to handle the load without it.
Then any performance gain you get from cache is a bonus.  I think that's
the safest approach to your problem, and it should be less expensive
than your original plan to boot.

[ Post a follow-up to this message ]

I think you may be focusing on the wrong areas.  DISK performance and NIC
performance should be the priority, less on 64bit.  If you get a NIC that
has it's own TOE, 64 bit and processor become less important.  For the
DISKS, a RAID controller that supports WRITE BACK cache in addition to READ
cache will be optimal.

Da Moojit

"Will" <westes-usc@noemail.nospam> wrote in message
 news:6pKdnWwmUPdKJ23ZnZ2dnUVZ_s6dnZ2d@gi
ganews.com...
> We are migrating shared files off of a Windows domain controller to a
> discrete file server, and I'm thinking through what would be the best
> design
> for that new server.     Given that 64 bit operating systems are now here,
> I'm thinking we do not need to spend much on fast drives, but we should
> instead invest in the lowest cost 64 bit server (a file server won't
> bottleneck on CPU so even a 1 GHz machine would be fast enough) and
> install
> gigabit ethernet and lots of memory.     I'm sure that the most requested
> files would fit into a memory cache that is under 10 GB in size.     A
> computer with 12 GB of memory, 64 bit Windows 2003 server web edition, and
> gigabit ethernet should provide the best possible speed for the case where
> there is not much write activity, but lots of read activity on less than
> 10
> GB of data.
>
> Assume less than 20 users, heavy read activity, very low write activity.
> Disk with all file shares would be under 100 GB, but under 10 GB of that
> represents 95% of the activity.
>
> Is my design correct if I want to maximize performance for this small
> network?
>
> --
> Will
>
>

[ Post a follow-up to this message ]

As long as you're sticking with Windows as your OS, I would definitely agree
with the previous comment about investing in a TCP Offload Engine (TOE)
card.  There are a few of them out there, but the one that's been around the
longest is Alacritech.

I'm not sure I agree with your comment that you can't get CPU bound with
file sharing, since I've seen plenty of really high-end file servers that
cost hundreds of thousands of dollars get CPU-bound.  But if I add "for
twenty users" to the end of your sentence, then I'd agree with it.  I'm
guessing that's what you meant.  Just wanted to clarify the point for anyone
else who might be reading along.

On 8/31/06, Will <westes-usc@noemail.nospam> wrote:
>
> "Bill Todd" <billtodd@metrocast.net> wrote in message
>  news:dvmdnUQAqMVpOWrZnZ2dnUVZ_rGdnZ2d@me
trocastcablevision.com... 
>
> Unfortunately, since it is a Windows based file server, what would matter
> would be the additional limitations of the Microsoft OS and not the
> hardware.   For 32-bit Windows Standard Edition server, the maximum memory
> utilization appears to be 4 GB.   The 64-bit Windows Standard Edition
> jumps
> that to 32 GB.   I need about 12 GB, therefore it's 64 bit or nothing.
>
> 
>
>
> I was planning to use Veritas Storage Foundation which has a feature
> Vcache
> built in that lets you specify exact amounts of cache for each logical
> volume.    I guess I should not take for granted that it will not max out
> before 12 GB.   If I can't cache the file system, then the whole approach
> I'm taking is pointless.
>
> --
> Will
>
>
>

[ Post a follow-up to this message ]