![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
![[quick]](http://tweakimg.net/g/if/icons/world_link.png){kind=icon}
YALOEP: Yet another Linux on enterprise post
Ok, I know this is a subject that already has a lot of attention in the various media. You will find a lot of opinions, and a lot of distributors that will tell you that Linux is ready for the enterprise.
It's just not true!
Ok, now before you go and start flaming and trolling me with all you have I have to state that I am (among others) a Linux administrator. We have around 4000 systems running on various Linux distributions and versions. Some very big, some quite small, but all have problems when you put them in large environments.
Linux is great when it comes to doing simple things reliably. If you look at a relatively simple webserver, things like serving mail or just plain and simple stuff you will have a great time with Linux and you will actually usually get good uptimes and just enjoy the experience.
Then you will start mulling and thinking, "Hey, we could do this for other purposes". And that's where the trouble usually starts. You probably need some sort of support agreement with the distributor. You are no longer that flexible, because since you want support you need to keep things in mind that could potentially throw you out of the support structures like tainted modules, HCL's and the likes.
Then try to explain that you need expert knowledge in large environments. There is a large community out there, but most of the problems you encounter are pretty unique. Ranging from stuff like modules that are shared by all hardware interfaces using them. Want an example? Try adding new LUN's from a SAN online. If your HBA will actually find them but the SCSI stack of the OS won't detect them you have two options: Reloading some modules or just reboot the server. Neither option will look good when you have to explain that to the customer.
I like Linux. I actually like it a lot and I enjoy the challenges that come with the administration of the servers. And I can tell you that each operating system has it's own problems in various areas, none of them are perfect.
But... Some are better suited for large environments where uptime is critical. Linux is not one of them in my opinion, but I would love to hear your comments on my ideas and any other opinions (that are actually based on something
).
It's just not true!
Ok, now before you go and start flaming and trolling me with all you have I have to state that I am (among others) a Linux administrator. We have around 4000 systems running on various Linux distributions and versions. Some very big, some quite small, but all have problems when you put them in large environments.
Linux is great when it comes to doing simple things reliably. If you look at a relatively simple webserver, things like serving mail or just plain and simple stuff you will have a great time with Linux and you will actually usually get good uptimes and just enjoy the experience.
Then you will start mulling and thinking, "Hey, we could do this for other purposes". And that's where the trouble usually starts. You probably need some sort of support agreement with the distributor. You are no longer that flexible, because since you want support you need to keep things in mind that could potentially throw you out of the support structures like tainted modules, HCL's and the likes.
Then try to explain that you need expert knowledge in large environments. There is a large community out there, but most of the problems you encounter are pretty unique. Ranging from stuff like modules that are shared by all hardware interfaces using them. Want an example? Try adding new LUN's from a SAN online. If your HBA will actually find them but the SCSI stack of the OS won't detect them you have two options: Reloading some modules or just reboot the server. Neither option will look good when you have to explain that to the customer.
I like Linux. I actually like it a lot and I enjoy the challenges that come with the administration of the servers. And I can tell you that each operating system has it's own problems in various areas, none of them are perfect.
But... Some are better suited for large environments where uptime is critical. Linux is not one of them in my opinion, but I would love to hear your comments on my ideas and any other opinions (that are actually based on something
).
 05-'09
|
EMC World 2009: Packing my bags |
 04-'09
|
HA Clustering: KISS (and make up) |
Comments
By
BeachPatroller,
Wednesday 06 May 2009 12:31
I agree,
I work in a multiplatform environment (HP-UX, AIX, Solaris and Red Hat).
Red Hat clustersuite is not as reliable as Sun Cluster, HACMP or HP SG.
Things like managing filesystems online, are not as advanced as on the other Unix stuff.
It has pro's and cons.
Pro's
It's fast
It's cheap
Con's
Certified Linux hardware can be a pain When you run Red Hat on SUN and you face an (hardware/ software) issue, Sun can send you to Red Hat and Red Hat can send you back to SUN.
Third party software can be a pain ( a 64bit OS where the application needs 32 libs.
Clustering is not as sophisticated
Hardware error reporting is not as detailed.
e.g. on real Unix distro's CPU's can be shut off while running, memory banks can be blacklisted etc. In Linux there is no hardware platform which can do that.
I/O throughput for SAN is still better and more reliable on Unix (fibre from SAN to IN the box). In Linux is the speed from SAN to the box is like, redirecting traffic from a highway to an Urban road.
As long as Enterprise Unix has dedicated hardware (made for the OS) it will be more reliable and scalable
Veritas has way more features than LVM(2) on Linux.
I think SUN's ZFS is a big mistake though.
I work in a multiplatform environment (HP-UX, AIX, Solaris and Red Hat).
Red Hat clustersuite is not as reliable as Sun Cluster, HACMP or HP SG.
Things like managing filesystems online, are not as advanced as on the other Unix stuff.
It has pro's and cons.
Pro's
It's fast
It's cheap
Con's
Certified Linux hardware can be a pain When you run Red Hat on SUN and you face an (hardware/ software) issue, Sun can send you to Red Hat and Red Hat can send you back to SUN.
Third party software can be a pain ( a 64bit OS where the application needs 32 libs.
Clustering is not as sophisticated
Hardware error reporting is not as detailed.
e.g. on real Unix distro's CPU's can be shut off while running, memory banks can be blacklisted etc. In Linux there is no hardware platform which can do that.
I/O throughput for SAN is still better and more reliable on Unix (fibre from SAN to IN the box). In Linux is the speed from SAN to the box is like, redirecting traffic from a highway to an Urban road.
As long as Enterprise Unix has dedicated hardware (made for the OS) it will be more reliable and scalable
Veritas has way more features than LVM(2) on Linux.
I think SUN's ZFS is a big mistake though.
By
Renegade,
Wednesday 06 May 2009 12:40
Interesting. I think that ZFS is going along the lines of NetApp's WAFL (NetApp apparently thought the same since they sued Sun. 
) and I don't see that as a bad thing. Care to explain?
) and I don't see that as a bad thing. Care to explain?
By
BeachPatroller,
Wednesday 06 May 2009 12:46
Well, we had a corrupted pool for several times and there is nothing you can do about it when it's broken when the snapshot stuff does not work.
On other fs'es there where always tools to fix or recover things.
ZFS should be that good that you never need to repair it according to sun
On other fs'es there where always tools to fix or recover things.
ZFS should be that good that you never need to repair it according to sun
By
X-DraGoN,
Wednesday 06 May 2009 15:48
I think you are right, but I also think it's not the fault of the Linux creators, it's the fault of the businesses that like to make money and therefore make everything closed source. Since there is 'only' one big OS around for large enterprises, it's obvious and even logical to develop software that works first on the majority of the systems and then focus on the lesser known OS'es. Hell, I'd probably do it myself if I had a big business. The point of all this is simple, Windows has a head start of some years and a billion dollar economy pushing it, Linux started with Linus'es post and still today is kept up-to-date with the leisure time of programmers. That is the difference... In my opinion
X-DraGoN, i think you are simplifying things a little bit too much. Consider this:
1. The post doesnt mention Windows as a more capable enterprise OS, this isn' t about software availability.
2. Linux is by no means a leisure project by developers, there are several commercial Distro's out there.
1. The post doesnt mention Windows as a more capable enterprise OS, this isn' t about software availability.
2. Linux is by no means a leisure project by developers, there are several commercial Distro's out there.
By
BeachPatroller,
Wednesday 06 May 2009 16:24
X-DraGoN,
There is more then Linux and Windows.
I wouldn't call Windows a HA Enterprise solution.
I think the author means Linux vs Unix.
Most big enterprises run some kind of Unix on critical (HA) systems, Windows is out of scope here.
There is more then Linux and Windows.
I wouldn't call Windows a HA Enterprise solution.
I think the author means Linux vs Unix.
Most big enterprises run some kind of Unix on critical (HA) systems, Windows is out of scope here.
By
Renegade,
Wednesday 06 May 2009 17:40
First of all let me state that we use a lot of operating systems here. We've got the range from Microsoft, Linux, the mainstream Unices (HP-UX, Solaris, AIX), older Unices and we use virtualization on various platforms. Tha'ts exacly why I made this post, I worked on a lot of these operating systems, and not one of them is perfect, but on Linux I just see problems in large systems/landscapes that are not that common on the other platforms.
The products created in Redwood are not bad. As long as you stay within the parameters that the OS has set for you, you are generally good to go, be it Windows, Solaris of another OS. Opening the source for others is not generally the solution to this problem. If you take my example of the SAN/SCSI layer you will find that under linux you can use the open source HBA drivers, but that does not resolve the problem mentioned. This is a different level because a lot of developers just don't have hardware like that standing around (active/active arrays are not commodity goods, neither are active/passive), and you are more often then not hooked to developers that are working for one of the major companies anyway.
That is another statement, you say that Linux is kept up-to-date with the leisure time of programmers. I beg to differ. I would suggest that over 70% of the code and programs created that make Linux what is is today, are being created by people who are employed by larger companies that have the "freedom" to work on those things. Classic non-kernel example would be Apache where Microsoft is one of the big sponsors, and Bill Hillf was a big contributor to Apache. He was allowed to work on it during office hours when he still worked for IBM.
The products created in Redwood are not bad. As long as you stay within the parameters that the OS has set for you, you are generally good to go, be it Windows, Solaris of another OS. Opening the source for others is not generally the solution to this problem. If you take my example of the SAN/SCSI layer you will find that under linux you can use the open source HBA drivers, but that does not resolve the problem mentioned. This is a different level because a lot of developers just don't have hardware like that standing around (active/active arrays are not commodity goods, neither are active/passive), and you are more often then not hooked to developers that are working for one of the major companies anyway.
That is another statement, you say that Linux is kept up-to-date with the leisure time of programmers. I beg to differ. I would suggest that over 70% of the code and programs created that make Linux what is is today, are being created by people who are employed by larger companies that have the "freedom" to work on those things. Classic non-kernel example would be Apache where Microsoft is one of the big sponsors, and Bill Hillf was a big contributor to Apache. He was allowed to work on it during office hours when he still worked for IBM.