How Hard is it to Manage Different Unices?

vrmlguy asks: "Where I work has several Unix-based servers, all running the same vendor's OS. We are getting ready to buy another big server, and management wants to get bids from other vendors. However, our staff is only familar with our current vendor's OS. Yes, I know that any two flavors of Unix are more alike than not, and yes, I know about the Rosetta Stone for Unix that makes it easy to transfer skills. I want to know about the down-side: What's the difference in the cost of operations between a mono-culture and a shop running two or more vendors' OSs?"

Comments

Re:Only 2 Versions Of Unix

[anonymous_wombat]

Also, running your software on these different flavors of UNIX will shake out some bugs that you might not find on just one or two platforms.

Software costs

[Krieger]

Are what's going to kill you. Having to support software and software interoperability between different platforms can be a serious pain. A mono-culture is easier when dealing with software. However if you are presented with a significant enough savings from another platform, consider it.

Your admins, if they're any good, should be able to adapt to a different UNIX easily. Yes there are differences, but not ones that should trouble an experienced admin any longer then it takes him to read a couple man pages.

OS hardware knowledge

[cprice]

I've found that operationally, my ability to move between Tru64, Soalris, AIX, HP-UX is relatively seamless. My biggest hurdles have come when doing hardware troubleshooting, upgrades and maintenance. Each vendor has their own unique approach to device names, hardware settings and architectures, which I've found to be the most difficult to master when moving between unixes.

Complexity is the answer

[.@.]

The reason homogenous environments are easier to manage than heterogenous environments is due to complexity.

Simply put, if every server and workstation is identical, interoperability is not an issue, and the work associated with tracking, testing, and applying changes to that one, homogenous OS image is minimal.

The moment you branch out into different configuations of the same OS version, different OS versions, or different OS platforms, you've increased the complexity of the system, and thus increased your workload. Suddenly, interoperability is a factor in every decision, and issues with multiple versions and/or vendors must be tracked.

I've been meaning to write a short paper on this for some time, and attempt to relate it to Christopher Langton's Lamba parameter for the measurement of complexity (in the 3rd Annual Proceedings of the Artificial Life Conference). I've studied the identification of single points of failure for some time, as well as the question of "how many sysadmins do I need?". Both answers are directly related to the complexity of the system being managed (here, defining "system" as the collection of applications, OSes, hardware, and networks that comprise the scope of a sysadmin's responsibility). There are indeed identifiable factors that define the heterogeneity of an environment, and the ways in which these dimensions impact such things as the number of SA's required to manage them can be defined.

Stay away from closed source, especially HP-UX

[Anonymous Coward]

Let's say you want to install the GNU version of some standard system utility, because the HP version has not advanced noticeably in 22 years. Not an uncommon scenario - compare HP awk to GNU awk, or note that Perl 4 ships with HP-UX 11.00.

So, you get the good stuff, compile it (Oh, crap, you didn't buy the AN$I C Compiler for a bajillion dollars? You've got the "brain-dead" K&R compiler? You poor sap. Have fun getting gcc installed, you're going to really, really need it.) and decide where to put it. Your best bet is to follow the HP-UX Porting and Archiving Centre's guidelines (DON'T try to use HP's; they don't even try to conform to their own published standards so it's a lost cause).

Now, you've got the new version ready. You need to disable the old version. Wait, have I mentioned the dreaded HP "Depot system?" It works like this: HP gives you a bunch of patches that you desparately need because of numerous remote rootable kernel bugs. Boo-rah. That'd be great if they weren't six months later than every other unix vendor's patches, never mind that. Anyway, you will have to use the "Depot system" to install them.

The software to manage depots is called SD. But wait! Don't type sd, that is for ubergurus, and consequently if you have problems nobody at HP will be able to help you! Use swlist, swinstall, etc. instead - these are aliases that let the system know you are a (l)user not a god.

So, use swinstall to install your patches. But, you didn't do anything that screwed up the K&R compiler did you? Whew, that's lucky. The kernel rebuild and reboot process is not too forgiving when you are forced to use the depot interface.

Anyway, back to our GNU software. We need to disable HP's compress and link back to gzip instead, for legal reasons. But, that breaks SAM!
Did I mention sam? Oh, sam is wonderful. On my $500,000 N-class machine, if I try to modify one of my three ethernet interfaces using HP's sam utility, it shuts down and deletes two of them. What fun! Guess I better get a depot patch set for that, maybe it'll fix the bug where sam eats your entire password database if there is a blank line in the /etc/groups file! Or maybe not.

SO, anyway, we can't remove compress. Let's install something else. Hey, we did it, it works, and the users have been prevented from using the broken antique HP version by the simple expedient of chmod -x. But I still have to install those kernel patches... hey, the depot system has run rampant through my system and replaced the executable bit I just stripped off!

Luckily the depot packaging system is unbelievably fat and redundant (without the reliability redundancy usually implies, though, so be sure to check those checksums) so you can just plunge into the tar-ry mess and find out in advance how it's going to screw you. That won't prevent it from happening, it'll just let you know how to fix it afterwards.

Or, use Linux or BSD on an Alpha box and get superior performance and reliability for a quarter million dollars less. But that's not the Merkin way!

--sd uberguru

been there, some advice . . .

[Satanboy]

we had multiple OSes to support.

We didn't have the luxury of 2, no . . . we had somewhere between 10 and 20 different versions of operating systems, that is if you include different revisions, etc.

we had everything from SCO to Solaris, to NT 4 to 2k, it was nasty.

The company had bought out a bunch of little ISPs and just threw all their boxes in the racks and made us try and get em all on the network.

Many of these were bought out ISPs and the admins were fired, so of course half of em had no passwords, and a bunch had all kinds of nasty little quirks.

I would say stick with no more than 2 versions at a time, maybe 3.

Different distros have their strong points and weak points, so balance it that way. There is not much of a learning curve unless you have like Solaris and Redhat and BSD in the same building.

Then you start forgetting which system commands work where because you log into em so frequently to do different things.

Its really not an issue of learning curve, its more an issue of annoyance.

the best recommendation I have is to make scripts to do the simplest tasks, that made things so much easier for us in our situation.

UNIX geeks perspective

[jregel]

I've no idea about the cost issue, but as a UNIX geek, the more versions of UNIX the better. I like the subtle differences and would hate it if there were only a single version.

Knowing that (as an example) AIX has a pretty self tuning kernel, that Solaris has a modular kernel, and that UnixWare needs a recompile (relink) for any minor changes forces the admin to think about the operating system instead of just drooling on the keyboard.

The biggest differences are still SysV vs BSD. Understanding those is vital in a mixed OS environment. Beyond that, there are usually differences in disk layout (and filesystems), but they just add to the rich diversity that is my favourite OS.

At my work, we are big users of Solaris, but because we develop software for multiple platforms, I've also had exposure to AIX, UnixWare, Sequent Dynix/PTS, HP-UX and DRS/NX. These days we've dropped Dynix/PTS (EOL anyway I think), HP-UX (too expensive for our customers), and DRS/NX (dead?) but we're looking to port to OpenUnix 8 and Red Hat Linux, so things are still pretty mixed. I just think it's a shame that I don't get to work with HP-UX and that Unixware is dying (yes - I like it!).

We also port to NT/2000, which is good to compare - it's a nightmare to work with when used to UNIX.

Re:I see it like this...

[Zeinfeld]

My experience is that in the 1990s when we ran an all DEC shop we got our DEC prices on hardware down by 10% when we bought a sun box. At another institute we saw a similar effect with SGI.

The price advantage you see is likely to depend very much on the type of computing you do and the volume. If you only buy 5 machines a year I doubt that the price break you get by going to a multivendor environment is going to be worth loosing binary compatibility for, let alone the admin hassle. If on the other hand you buy 100 machines a year you should definitely get a second vendor in place.

The other issue is that the price gap from Sun to Intel is huge. Comparing machines of like performance Intel boxes can be up to a third of the cost. Unless you have a real definite need for the features of a non-Intel platform (and I can't think of many offhand) the cost saving of Linux or BSD can be great.

I can't think offhand of any reason to have six vareties of Linux arround unless you are a masochist of some sort.