Samba Success in the Enterprise? 149
gunnk asks: "We've deployed a Samba server here to replace some aging Novell Netware boxes. It works great: fast, secure, stable. However, we have one VIP that feels that Samba is 'amateur' software and that we should be buying Windows servers. I've been searching with little success for large Samba deployments in Enterprise environments. Anyone out there care to share stories of places that are happily running large Samba installations for their file servers? Or not so happy, for that matter — better to be informed!"
samba for the corporation (Score:3, Interesting)
it usually was that I did not upgrade the software often enough because *it just works*.
That in my eyes is the best feature any software package can have, that it is so reliable
you forget you have it.
As for it being 'amateur' software, amateur to me spells motivation and the quality level
of the samba software reflects that dedication quite well.
Better than the 9-5 code monkeys products by a long shot most of the time.
OSS is the future, better believe it.
I work for a Fortune 500... we use Samba (Score:3, Interesting)
Loving it over here (Score:3, Interesting)
The only downside is that until v4 hits the streets, we can't do full AD. We could of course get around this by dropping in a single 2k3 box to be the DC, but we'd like to avoid that if possible. I'm really looking forward to v4, as AD is one of the good things MS has done, imo (standards adherence aside)!
-Ben
Can't be an amature if you're getting paid (Score:3, Interesting)
http://us1.samba.org/samba/support/us.html [samba.org]
Personal experience (Score:3, Interesting)
1) Changing hardware (including replacing drives with bigger drives).
2) Changing entire server (replacing with faster box and previous drives).
3) Power failure & UPS battery had died.
Right now it's serving files to four Windows boxes including storing video for a PVR.
Not that a home installation will mean anything to your VP.
Samba is cool, but a NetApp is better... (Score:2, Interesting)
We support about 6500 engineers here at the rocket ranch. Back at the turn of the century, we wanted to migrate everybody from expensive-to-maintain *nix workstations to vastly cheaper Windows PCs, but we had a problem: all our data was on several dozen HP N-class data servers. We do serious 3D CAD and FEA, with engineering data sets measured in dozens of terabytes. We wanted to leverage the performance and economy of fast, cheap X86 boxen while not losing our investment in our storage management infrastructure. My IT masters had never heard of samba, and were amazed when I demonstrated how easy it was to serve out a Pro/E drawing to an engineer working at one of our brand new 1 GHz NT4 PCs (I told you it was at the turn of the century.) We deployed it sitewide in 2000, and even now, seven years later, my users still thank me for making it possible for them to use fast PCs to access their Unix-based data sets. We ran samba on SunOS boxes, because we never could get it to play nice with HPUX. Samba is ridiculously easy to install, manage, and maintain, especially with one of the GUI frontends that are readily available. We used SWAT, and it rocked. Samba was a great intermediate enabler, allowing us to continue to use our N class servers while we were moving our user base to PCs.
In 2003, however, we acquired a bunch of Network Appliance servers, and migrated off our HPUX and Sun data servers. NetApp filers are platform agnostic; if the client is a *nix box, the filer presents the data as an NFS mount. If the client is Windows, it looks like NTFS. NetApps aren't cheap, but they were worth the major investment. If your company doesn't want to shell out for a filer, then samba is very viable and I recommend it highly.
your "VIP" is a clueless n00b (Score:5, Interesting)
I've implemented it at a number of Fortune 100 companies. I cannot name names due to NDA but you would recognize the names. I am contracting at one of them right now.
For enterprise scale use, I would even contend that Samba makes a better file server to large numbers of Windows clients than running Windows on the server. Can you run Windows on an IBM pSeries 570 (16 POWER5+ processors, 128GB RAM) to serve files to ~20,000 users? I can tell you that RHEL 4 does that just fine.
We just did a similar thing (Score:2, Interesting)
I've just finished deploying a brand new CentOS/Samba solution to replace some ageing NT4 servers.
We got a shiny new Dell Poweredge 2900 with 16GB Memory, twin quad-core Xeons and 8x300GB hot-swap SAS drives.
I configured up CentOS 4.4, using Samba/OpenLDAP/Postfix/Dovecot and MySQL to provide domain, database, roaming profile and file sharing services to a workgroup of around 100 workstations running XP.
Now we have ironed out the smaller issues with the deployment, it's absolutely rock-solid. Current uptime is 18 days, without a glitch at all. Utilisation hasn't peaked over about 20%, giving us plenty of spare capacity for expansion.
We did consider deploying Windows Server 2003, but were put off by the price tag of the cluster of machines that was recommended to provide us with the capacity to service 100 workstations. Suffice to say that the £6k we paid was a mere fraction of the Windows alternative.
Re:Another big company... (Score:3, Interesting)
Re:We serve about 1000 computers with it (Score:3, Interesting)
Yeah, yeah, not exactly "Enterprise" activity, but still...
Re:SAMBA + Windows 2003 Server is shit (Score:5, Interesting)
the POSIX ACL code in Samba.
I understand your problem, but you've got to realize there's
nowhere on a UNIX filesystem to store that meta-data and have
the kernel understand it.
Sure, we can push the NT ACLs into an EA, but nothing in
the kernel will look at that EA or even be able to make sense
of the SIDs stored within it.
We can do the interpretation inside Samba but this doesn't
prevent other POSIX processes from completely ignoring
whatever ACLs you thought you'd securely set on that file.
NetApp can do this as they have their own kernel (based
on FreeBSD originally) which they've hacked to understand
these ACLs. Samba isn't a kernel, and so can't do this
NFSv4 ACLs, whilst having their own problems, are much closer
to what we need to store full NT ACLs. Unfortunately they (a)
break POSIX, (b) aren't yet finished on the most popular
platorm (Linux) and (c) have no userspace API standard for
getting to them.
This is one of the reasons my world sucks (Microsoft DFS is
another at the moment
Your complaint is like a child screaming "I want a pony,
I want a pony...". We *all* want a pony. Where is it going
to live.....
Jeremy.
Other considerations (Score:4, Interesting)
Something else you might want to consider are the things Windows will do that Samba does not (or, at least, does not do without lots of hacking around).
Two of these are DFS Replication (DFSR) and Volume SnapShots (VSS).
We are currently in the process of evaluation a replacement for our aging fileserver plus some sort of centralised, SAN-like storage. Two of the leading candidates are Sun's 5320 and IBM's N5200 which offer access for clients via both network (CIFS, NFS, etc) and block-level (iSCSI, FC). Several branch offices are also in the same situation, although they lack the need for block-level, centralised disk.
However, neither of them support DFSR (nor does any other non-Windows based NAS device from what I can gather). They do both have replication technologies of their own, but those are just as expensive (additional US$8k-ish) - if not more so - than just buying a dedicated Windows fileserver to connect to the SAN/NAS device via iSCSI.
Then there's the snapshotting, which Samba doesn't do on its own (but you can hack together something, depending on the host OS). VSS in Windows is trivial to enable, very simple to use and works quite well. It's primary benefit is to reduce the overheads on support staff from users "accidentally" deleting things and needing them restored - something they are now able to do themselves, rather than weighing down support staff with those requests. It can also be used for simplifying backup procedures. (Any decent NAS device will also have some sort of snapshotting functionality).
With regards to Samba in general, we use it fairly extensively on a per-host basis to allow easy access to certain parts of the filesystem for certain staff. I've experimented with it in the past on an AD level and successfully gotten it working, but the overhead for setup is non-trivial, especially if you want things like UIDs to match up across different machines.
Simple setups in Samba and Windows are simple. More complex (Active Directory integration, especially with multiple servers) are also fairly simple in Windows, but relatively much more difficult with Samba. If you're looking at the latter - *especially if you're not already an expert* - you'll probably need almost a complete person full-time to work with it during the implementation phase.
The simple version is this: software and hardware are cheap, people-time is expensive (this is a concept a *lot* of technically oriented people - myself included - have significant difficulty a) grasping and b) remembering). In all likelihood, you will use substantially more people-time - especially in the earlier phases - with Samba than you will with Windows. That's where the "value" of Windows (or NAS appliances) comes in - saving people-time $$$. If you're already a Samba expert, OTOH, the people-time aspect of the equation will be substantially different and you can compare largely on features. However, banging out a good, manageable, sustainable, reliable AD-integrated Samba infrastructure is something that will take on the order of weeks unless you already know what you're doing and have done it before. Your boss has a very poor argument against Samba, but do not kid yourself that good arguments against Samba do not exist.