samba - Dec 2002 - UNIX with samba .vs. native Windows Server , how to compare thei r performance for Windows-biased management

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

I feel your pain Karen.

I'd tried briefly (before I figured that it wasn't worth my breath
because they wouldn't listen at all) to convince my superiors to clean
up a HD problem through Samba and one of the two Solaris boxes we have.
We have this nice brand new storage array, and it probably isn't getting
used for a whole lot, yet our domain controller (primary) is constantly
running with less than 1 GB available free space.  I have even suggest
as well just setting up a small PC with Linux just for users storing
their large files (read: images), but have had no such luck.

So, after months of dealing with this, I feel your pain.  Funny thing
is, they just ordered another Windows-based server machine for some
un-(insert appropriate religious deity here) purpose.

As far as benchmarking goes, I'm afraid I can't help much, as I'm
limited to the use of PCs at the moment.  But you've got me into the
idea of setting up a small Linux cluster for the sake of learning how to
do it and stuff.

Regards,

Scott Wrosch
desk 248.333.7700 x227
email swrosch@marketingassociates.com 

-----Original Message-----
From: Wieprecht, Karen M. [mailto:Karen.Wieprecht@jhuapl.edu] 
Sent: Friday, December 13, 2002 3:24 PM
To: 'samba@lists.samba.org'
Subject: [Samba] UNIX with samba .vs. native Windows Server , how to
compare thei r performance for Windows-biased management


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
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  http://lists.samba.org/mailman/listinfo/samba

Go with a GNU/Linux system and get the best of the two worlds:
Unix power
and
cheap hardware

btw, I cannot believe they say managing a windows box is more
comfortable, have you ever showed your boss how much time his NT admins
need to spend to "easily" click trough endless number of windows?

I always found Unix machine much faster to administer,
and it can be done easily also remotely (and _securely_) through SSH.

Let's not talk of automation through scripts, Windows simply does not
exist in that field.

Simo.

On Fri, 2002-12-13 at 21:23, Wieprecht, Karen M. wrote:
> 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
-- 
Simo Sorce - simo.sorce@xsec.it
Xsec s.r.l.
via Durando 10 Ed. G - 20158 - Milano
tel. +39 02 2399 7130 - fax: +39 02 700 442 399
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part
Url :
http://lists.samba.org/archive/samba/attachments/20021213/b3f51707/attachment.bin