I maintain the servers for a big webproject (java + postgres + some tools around) which is currently hosted on three machines:
- Machine: Mailserver (postfix), Ad-Server (lighttpd + php + openx)
- Machine: Tomcat + Servlet
- Machine: PostgreSQL-Server, static content (via lighttpd)
All machines run Debian Stable and are connected via a VPN (openvpn). As the hardware is very old (AMD Athlon 3000+ and 2GB RAM on each) its time for a change.
These servers should now be replaced by one big machine (16GB Ram, big Intel CPU's supporting VT, 5 IP's).
The question now is: Should I still seperate the differents tasks using Virtual Machines or should I simply put everything on the machine as usual. Where are the pros and cons?
I thought of the following:
Pro Virtualization:
- Security: As the vm's are seperated you cant take the whole machine (hopefully)
Con Virtualization:
- Performance: There is a performance loss
- Work: Every maintaince-work has to be done several times for every vm
- Communication: Communcation of the different vm (Servlet do Database) gets more complicated.
- Hard Memory Limits: I have to assign static resources (like Memory) to each machine. This can be a con if say my db-server needs more ram for 30 seconds (than it got assigned) and there would be more ram available on other machines. With no virtualization this wouldn't be a problem.
Thanks for any hints.
Virtualization is nice, as many people mentioned, for the fact that you can easily make/restore a snapshot.
I'd like to address some things. Someone mentioned the need to maintain multiple machines versus one. It is possible to reduce a lot of that maintenance by net booting the vm's, and mounting the partitions of all software from a central point. This way, software updates/installs automatically migrate to the other machines, eliminating most of the additional maintenance time.
There's also a 3rd option: FreeBSD jails. - These let you create separate environments without the overhead of virtualization. - Separation is much higher than common GNU/Linux chroot ( everything, even the network layer, is separated at the kernel level) - each jail can have it's own IP, and these are actually NOT virtualized, rather just isolated environments in the kernel+filesystem. http://en.wikipedia.org/wiki/FreeBSD_jail
I wouldn't dismiss the security gain as a pro. It is true that it is possible to break out of virtual machines under certain conditions (bugs in vm software - though these get patched; keep up with updates, as with anything else) - Security is about layers, not one layer is failsafe. While simplicity tends to benefit security, there are some things that just give you too much benefit, and as I mentioned, things can be simplified by mounting the base system from a central location (could even be a read-only mount) -
Here's a real-world example:
Say a php application has a mysql injection vulnerability in it, an attacker could exploit this to write files to your server. (eg: via the INTO OUTFILE sql syntax) - A common approach is to write a php file containing more exploit code, further breaching the server; after all a php script is almost equivalent to a shell account running as the user executing it (the user executing the apache process) - From there an attacker is only a local exploit away from full root access. If mysql is in an isolated environment, say a virtual machine, a bsd jail, or a chroot environment, the attacker would be able to write his php code to a file, but he'd never be able to execute the file by visiting a url, since the mysql service would not have access to any files hosted by apache.
I would prefer the virtualization because,
a.) You can do server backups on a very easy way
b.) You can create a second instance of a running server to test something without touching the production server
c.) You can perfectly handle the resources to give one server more priority then the others.
cheers
plucked
virtualization is the way.
this way, you can easily backup/restore or even move your vm from one server to another with minimal downtime.
with good hardware, software and good setup, the performance loss is minimal. just use ssh for all communication and use separated local IPs that's inaccessible from internet. simple and secure.
in the long run, you will find the maintenance is actually easier. openvz even let you easily take snapshot of any running vm.
and it scale! it's much easier to add more vm than to add more hardware.
also, any one vm crash/down will not affect other vm.
Performance loss - Yes, technically there is one. Is it something you or your users will notice? Unless it's some crazy high-end workload, or you horribly over-provision VM's* (or are trying to squeeze 5 VM's with a "normal" RAM allocation onto an old, existing server, I seriously doubt it. Remember to actually check your RAM usage - if you're splitting everything up, you don't need, say, 512megs for an NTP server that defaults to runlevel 3. (Splitting off JUST an NTP server is excessive, it was merely an example.)
Work - This is true. If it's only going from, say, one to three servers, probably not that big a deal - do your change, copy/paste your commands from one terminal session to the other. Past that though, you want some kind of management tool, I'm currently looking at Puppet.
*Memory Limits - Depends on the virt. solution you use. Some environments, like ESX/vSphere allow you to allocate more RAM to VM's than physically is available. If you pay for the feature, ESX let's you set up resource pools, and will automatically adjust resources as needed, with the ability to set priorities. Like everything, you have to know how it works and the tradeoffs in a particular environment.
That security part is pretty relative, as you will have to secure three environments instead of just one, and separation alone isn't exactly going to offer much security.
You are correct that there is a performance loss, not to mention the fact that any bug in your virtualization software may crash the entire machine.