I've been thinking about this for a while but this blog post by Pascal Meunier pretty much sums up my feelings about Virtualisation.
Back in the 90s when the Internet was new-ish and just becoming important all the machines running it were Unix boxes. (Maybe not all, but most). And a 386 would typically run DNS, sendmail, telnet (shell accounts), ftp and apache. All on the same box.
Security wasn't so tight in those days but it was usually good enough and the box could happily do what it needed to do.
Along came Microsoft and produced the idea of "one box - one service". You can't seriously consider running your domain controller as a file server. What are you thinking? And to put mail on the same box? No way. In fact, your SQL server is running under significant load, chain a few together.
And companies would buy into this concept. Microsoft were happy - more licenses. All the PC guys were happy too - more money. More complexity - more jobs.
Essentially what has happened now is that Moores Law has kicked in and has caught up with the complexity of Microsoft's software to the point where one server box can run multiple applications on it. Imagine that. But Microsoft has planted the one-service-one-box concept so well that it is now part of IT law. File server and mail server on one box? But wait...whats this button over here....? Vir-vir-virtualisation.
And now we have the tools to allow us to once again run multiple applications on one server without having to admit that one-application-one-server never made sense.
To be fair - Virtualisation does have other advantages - running multiple Operating Systems for example, being able to easily move a virtual machine from one box to another (without configuration issues), being able to make a snapshot backup of a system.
But running multiple applications on one box is not a huge win.
2 comments:
I've seen servers (Unix and Windows) where 'all apps in one' was the sysadmins preferred mode. They are not pretty. And not all of the reasons for one app per server are due to the poor design of modern operating systems (Unix and Windows).
Library conflicts. Yes, on all platforms, conflicting libraries make a mess out of the all-in-one strategy. Running with multiple glib/gtk/perl installations on unix is as much of a headache as it is impossible to do on Windows. Ever descend into CPAN hell on a perl instance that is shared by more than one application? How about trying to figure out if an old library can be uninstalled. Those are platform neutral problems that have been around for a couple decades.
Availability, SLA's and change windows. Different apps have different requirements, and because one cannot be assured that app changes, application performance issues, and/or app security issues will not affect other apps on the server, O/S level separation is necessary. If not, the entire server is forced to the SLA/change window/security profile of the most restricted application. That means that fast moving/changing applications are held back by apps that can only be re-started twice per year because of SLA requirements.
Security, installation, uninstallation, upgrades. No, I don't trust any operating system to maintain application compartmentalization. Applications still insist on spewing themselves all over the file systems, they still insist on forcing user rights and permissions to directories all over the file system, and they still insist on binding themselves to all IP addresses. They still leave random crud behind after upgrades and uninstalls on all platforms. And - try to do an O/S upgrade/patch on an all-in-one server. Application 'A' requires Patch 16, and Application 'B' croaks on Patch 16. Good luck resolving that one.
Auditing. When the scope of the audit is the financial system, do you really want 5000 users to have file share accounts on the finance database server that is also the users file server? Guess what - you just scoped userland crud into your finance audit. Good luck passing that one.
There are plenty of reasons to run one service per server (either virtual, real or my preference - a Solaris Zone/Container). Virtualization is not panacea, and shouldn't be necessary if O/S design were fundamentally re-thought. But with current O/S designs, virtualization seems to be a good solution to a bunch of operational an security problems on both Unix and Windows.
Michael,
Thank you so much for your comment.
It is very well thought out.
However, your first 3 points are issues with Server OS design which are being worked out. You won't get library conflicts on stable versions of Debian or Ubuntu. Perl libraries can be put into different directories so you can have multiple copies of a Perl library on a server. Point taken though.
Services should be able to be stopped and started independantly. The unix saying of "reboot for kernel changes only" should take care of SLAs.
Security issues have not come up with Virtualisation yet but that doesn't mean that there are none. I think that this is a valid point but more work should be done to sort this issue out than moving the issue to another layer.
Your point about Auditing makes sense but technically if you run a file server virtual machine and your accounting virtual machine on the same hardware then the Auditors should audit both systems and you have achieved nothing by virtualising.
If a junior Sys Admin runs something bad on a minor security machine and it compromises the whole virtual machine's base operating system and hence all the virtual machines then you are in trouble anyhow.
Having written this comment - I agree with you more than disagree. I am looking at this from a "this is how things should be" point of view and you are obviously someone who works with this stuff and sees how things are.
I don't think that OS design needs to be radically rethought - just fixed up.
Post a Comment