Fedora Users — Re: Fedora Makes a Terrible Server?

Les Mikesell wrote:

Roger Heflin wrote:
Yes, and typically to support anything recent you have too manyadd-ons on the enterprise OSes, if you are in a fast moving enterpriseenvironment RHEL won't work.
Fast moving and enterprise are words you don't usually see together.Don't you have to keep decades-old processes running?
RHEL is probably quite good for any of the nice simple staticenterprise environments, but most would argue there you shouldprobably lock everything down so tight that few kernelupdates/userspace are even required for anything, the problem is in anenvironment were you are constantly having to bring in new hardwarethat does not work on the older release, where you cannot wait 6months for RHEL to catch up.
I can't recall ever being in a position of "having to bring in newhardware". What scenario forces this issue on you? I haven't noticed ashortage of vendors who will sell RHEL supported boxes. But it soundslike you have an interesting job...

More cpu power needed to do the job. And the new boxes aren't officially RHELsupported (and sometimes won't even boot with the latest update-but will workwith the latest fedora/kernel.org). You typically bring in around a largeenough set of new machines at a time (usually this was 100-200 machines) anyonly update the pieces required to support that new machine, and then you runsome test to validate that it gives the correct answers for various jobs. Itis really a money issue, the new machine is 2x the speed but not yet supportedby RHEL, so you would need 2x the number of old supported machines for 2x thecost or more. Reliability was required (50 or so disk servers any one of whichwould cause at least partial loss of access to data).

The problem is validating that the new hardware/OS (or old hardware/just an hugeupdate) is the same process, so you change only what you need to, and you arebetter off starting with as new as possible and going from there. We weretypically only updating the kernel, change userspace was even more dangerous asa bad library update could change answers, so unless we found a library bug thatcould not be easily worked around, we did not update it.

Some of the compute customers don't apply updates, it is too risky to causedowntime/wrong answers, they fix the issues that they find, and then every 1-2years they update the older stuff to what is currently being used/proven on thenewest machines, the situation you have is you have sets of machines withslightly different OS loads (which is kind of nasty), but the other choice isthat you update everything all of the time (and that is even worse-as too manydifferent types of HW must be revalidated to still give the correct answer).You end up with old servers that may be running what was originally determinedto be stable by testing and they aren't touched. In this environment thetesting is just as bad with any OS as any other, you start with something likeF8 and then update/downgrade any parts that fail you to something that works,and they you don't touch it for several years. I had a subset of machines(about 250 machines) all of which had reached about 500+ days of uptime (theuptime counter rolled over), the 20 or so machines out of that set that failedto reach that uptime were all HW issues (usually disk failures), but some morelethal failures that required the retiring of the specific machine, it was nottypically worth paying for fixing the nastier issues (usually MB failures) sothey were retired, it was often cheap to just buy a something new that wasvalidated and much faster. The issue with all OSes is that no one testsenough to catch these high MTBF issues, and in a big environment a machinecrashing 1x per every 1000 days of uptime, comes to 1 machine a day crashingbecause of software, and typically the enterprise OSes aren't even close to thatlevel, and while fedora is worse, it is just not that much worse.


                           Roger