memmott at gmail
May 11, 2012, 9:36 AM
Post #20 of 57
(2065 views)
Permalink
|
On Fri, May 11, 2012 at 11:51 AM, Raymond Wagner <raymond [at] wagnerrp>wrote:
> On 5/9/2012 21:22, Nathan Hawkins wrote:
>
>> Is ‘Anyone’ virtualizing their backend?! I cant believe I’m the only
>> person out there who wants to do this…
>>
>
> 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...
>
> 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?
>
> 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.
>
> 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.
>
> And that's it. Those are the two good reasons to run virtual machines in
> a production environment.
>
>
> -- Counter Argument 1 --
> 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.
>
>
> -- Counter Argument 2 --
> 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.
>
>
> -- Counter Argument 3 --
> 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.
>
>
> -- Counter Argument 4 --
> 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.
>
> 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.
>
> ______________________________**_________________
>
>
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.
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.
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.
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.
|
1
