<br><br><div class="gmail_quote">On Fri, May 11, 2012 at 11:51 AM, Raymond Wagner <span dir="ltr"><<a href="mailto:raymond@wagnerrp.com" target="_blank">raymond@wagnerrp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 5/9/2012 21:22, Nathan Hawkins wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is ‘Anyone’ virtualizing their backend?! I cant believe I’m the only<br>
person out there who wants to do this…<br>
</blockquote>
<br></div>
I've stated my views on virtualization on this mailing list multiple times in the past, but new people keep joining and asking, so here goes...<br>
<br>
Why do you want to want to virtualize your backend? "Because I think it would be interesting" is a perfectly valid reason here. "Because the industry uses it and VM vendors tell me it magically makes everything better" is not. So why does industry use it?<br>
<br>
The first reason would be security. There are many mechanisms to isolate different processes on a single system, but none of them can be as complete or absolute as full system virtualization. You can run different application servers, or servers for multiple departments with different user access rights on one physical system, and if one gets compromised, there is (almost) no risk to the rest. It can be flushed and restored from a clean copy with no harm to the other services. If you are looking to virtualize MythTV for security purposes, your journey ends here. If you are not running MythTV on a safe, trusted network, you either shouldn't be running MythTV, or you should be looking into adding cryptographic authentication into all the various communication interfaces MythTV uses.<br>
<br>
The second reason is high availability. The virtual machine allows you to save the state of the machine, and in the event of a failure, resume that state on another piece of hardware. This is really only a crude route to high availability, as such capability is much more effectively and efficiently performed by the application itself, such as MySQL clustering and replication servers. It becomes a question of how valuable is the application to your needs, and is it valuable enough to warrant the time and expense developing native support in the application. If your interest is in HA, you've already thrown far more money at virtual machines than someone who would be asking a basic question such as this on an open source mailing list.<br>
<br>
And that's it. Those are the two good reasons to run virtual machines in a production environment.<br>
<br>
<br>
-- Counter Argument 1 --<br>
What about the need to run on a different hardware architecture or operating system? Don't. Find software that suits your needs that can all run on one OS. If it's something critical that you cannot do without, perhaps that makes it worth dedicating another machine to.<br>
<br>
<br>
-- Counter Argument 2 --<br>
What about software that refuses to run on anything outside a pre-defined hardware set, so you define it against a virtual machine to allow the VM to be mobile? Shame on the company for putting such restrictive licensing measures on their software. Double shame for botching it in such a manner that it could be bypassed by simply using a VM. From an idealist standpoint, shame on the customer for patronizing such an abusive developer.<br>
<br>
<br>
-- Counter Argument 3 --<br>
What about software that could crash and take out a system? If you're doing development, this is a great thing. Any application that you expect to crash with destructive results should not be used in a production environment.<br>
<br>
<br>
-- Counter Argument 4 --<br>
What about ease of management? When trying to run multiple applications and servers on a single system, you may run into dependency conflicts. You may update one library for one application, only to find it has broken another application. Virtual machines let you run multiple independent installs, with independent dependency sets, to avoid these issues. This is the big one, and I believe the reason most people improperly use virtual machines.<br>
<br>
This has NOTHING TO DO with virtualization. Virtual machines require this behavior, but this behavior does not require virtual machines. You can do the SAME EXACT THING with a simple chroot, without all the unnecessary complexity and overhead of running a fully virtualized hardware instance. All your required libraries would be in the self-contained chroot. The only thing you would have to match for binary compatibility moving from one machine to the next to the next is the kernel interfaces, and those interfaces retain backwards compatibility for a long time. If you really wanted, you could even implement these on opaque disk images, that would get loopback mounted where ever you wanted to run them, just like virtual machines.<div class="HOEnZb">
<div class="h5"><br>
______________________________<u></u>_________________<br>
<br></div></div></blockquote><div><br>I like to think I have a valid reason, and mine is this: Consolidation. I have a server rack in my basement, and prior to my current VM server, I had several boxes in that rack: 1) Domain controller / DHCP / DNS / file server. 2) OpenFiler NAS / SAN device. 3) MythTV Backend. 4) ESXi 3.5 server with ~5 VMs on it, doing all sorts of magical things. <br>
<br>One of the problems I had was that my storage was all over the place. I pointed some of the boxes to my OpenFiler appliance but the storage was scattered all over the place. Much of this was due to the fact that I'm a WIndows admin and I really suck at Linux storage administration. At any rate, I'd have x free terabytes here, y free terabytes there, and it was just one big disaster.<br>
<br>My server rack now has exactly two "boxes" in it: A PowerEdge 2 x quad-core Xeon I bought on ebay for $300, and an Apple Xserve RAID (two RAID 5 arrays), connected via fiber. Everything that was physical has been either replaced or virtualized, and I couldn't be happier with my setup. Having a VM infrastructure actually enables me to spread roles out to more "servers" and lessen the chance of an application taking down six others, which I believe is something Raymond touched on in his post. <br>
<br>Virtualization brings a lot of challenges and is definitely a paradigm shift. It's not something I'd recommend to use "in production" to anybody not familiar with the technologies and the layers of abstraction it brings. But for me the benefits far outweigh the time and effort spent building out the infrastructure, and I'd do it again in a second.<br>
</div></div><br>