[Samba] UNIX with samba .vs. native Windows Server , how to compare thei r performance for Windows-biased management

Wieprecht, Karen M. Karen.Wieprecht at jhuapl.edu
Fri Dec 13 20:24:01 GMT 2002


I had samba working on an old Sun Enterprise server using a JBOD that was
managed with veritas volume manager (legacy stuff that had long outlived
it's usefulness).  Management  arbitrarily decided to replace the aging
Solaris server with a native Windows server without talking to me. I instead
tried to persuade them to use an SGI cluster I had been putting together and
use newer features of samba (winbind, domain authentication) for hosting
this data,  but they weren't interested.  

When that old Solaris system started having problems,  and the new windows
server wasn't online yet,  I had to temporarily host the data on my SGI
cluster,  a duo of servers that was running  samba with winbind and domain
authentication.  It was a very nice setup, either server in the pair could
serve the files,  and we made user login scripts mount the shares from
whichever server reponded first.  When we had to take the primary server
down for maintenance,  we switched the login script to point them to the
secondary server's shares,  had them log out and back in. While they worked
happily off of the secondary server,  we did a half day's worth of
maintenance on the primary server without affecting the users.  When we were
done,  we put the login script back the way it was before,  and the next
time they logged out  and back in,  they were again pointed to the primary
server with the secondary as a backup.

Even after demonstrating how nice my configuration was and how seemlessly we
were able to do maintenance without affecting users,  management  and the
two NT guys I work with were still sold on using the Windows native server.
They claimed that it was cheaper to buy the hardware and easier to manage
permissions and file access rights with the native equipment (of course,
they are PC guys).  My argument was that we could probably achieve the same
file access flexibility with UNIX ACLs (which previous staff had not enabled
on the UNIX side),  and that the UNIX machines use RISC-based processors,  a
completely different animal than the GHZ pentium processors,  so they would
really have to come up with some benchmarks to compare the two systems.
They also weren't originally going to accommodate any easy file
interoperability with the UNIX users,  they were going to make them use FTP
to move files between the UNIX machine and the windows server, and I argued
that this was removing capability that users were accustomed to having,  not
a real crowd pleasing decision.  

Now they are experimenting with Microsoft SFU to make the Windows box allow
the UNIX machine to NFS mount its shares,  and I have to say it does seem to
work pretty well.  It tied right into NIS nicely, automatically mapped
matching usernames on either side, allows me to define mappings with
usernames that do not match, etc.  But it still digs in my crawl though that
I never even got a chance to show what my cluster could do for them until
after management had already decided to buy the windows server, and even
after a nice demonstration of the UNIX cluster's capabilities,  they are
still sold (arbitrarily) on using the native Windows box.     

How can I compare the performance of the two servers?  Many of you started
out with Windows servers and migrated to samba to get better performance,
but  my collegues have done the opposite.  Am I blindly biased that UNIX is
better or is there a way I can get some real numbers to prove that te
windows server  is a slower file server?

The guys are always weighing the cost and ease of management against the
difference in performance (if there isn't much difference in performance,
go with what is cheaper and simpler to manage),  and for them that is the
PC-native stuff.  I feel like my UNIX skills are slowly getting pushed aside
and I'm not sure how to get real performance metrics.

Help, feedback,  condolences are all welcome.  

	karen



More information about the samba mailing list