Server Consolidation Guide via Virtualization
sunshineluv7 writes to tell us TechTarget is running a good overview of 'why, when, and how to use virtualization technologies to consolidate server workloads.' The summary provides links to several podcasts and other articles relating real world experience with how to utilize virtualization to best meet your needs. From the summary: "Advances in 64-bit computing are just one reason that IT managers are taking a hard look at virtualization technologies outside the confines of the traditional data center, says Jan Stafford, senior editor of SearchServerVirtualization.com."
They make sense.
aaaand...whee!
Except when your virtual server gets hit with a slashdotting and goes up in smoke. Taking out even more domains than usual.
That submission is what constitutes a "good overview" these days? Maybe it is, if you are the person trying to drive traffic to TechTarget.com sites....
What does 64bit have to do with driving virtualization? Are people really that ignorant about 64 bit processors and what the mean and don't mean? Seriously, how are these two technologies correlated?
Disaster Recovery and test environments are the two biggest reason's I can see for using virtualization. Having the ability to pick up your system and plop it on any old box makes things so much easier. In theory HAL's should have made this possible years ago but they never really lived up to their promise. As to virtualization making management easier, bullocks. Some of the tools bundled with good virtualization products like ESX might make management somewhat easier, but you still need additional good tools to make management bareable for large numbers of server/virtual servers.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
When they talk "virtualization", do they mean running virtual domain service or virtual ips, allowing one computer to handle multiple web services, or do they mean running multiple virtual machines on one box?
I'm not too sanguine about the virtual machine approach. I suppose the only reason they'd be doing it that way is so that one server could seem like it's being multiple computers, so later the tasks can be split up if loads become high, or so that it looks absolutely identical to a two-machine setup that's being replaced. But while running virtual machines on x86-descended hardware has become much easier compared with only a few years ago, it still exacts a price in resources and performance, and may complicate administration. I'd strongly recommend using other techniques to load two tasks onto one machine.
For instance, let's say you want to run two SQL databases on one machine. The easiest solution is to partition the table namespace and run a single server. If the namespaces collide and there's no easy fix for it, you can run them on different ports and let iptables direct communications to one or the other based on ip.
I suppose there's one more reason for virtualization, and that's if you need to run multiple operating systems; but still IMO for future administration you're best off standardizing on one OS rather than trying to run two or more on the same box.
If you use VMWare heavily, I'm sure you're running ESX, but I'll ask you anyway:
Can you (or anyone else) tell me the recommended way to back up your virtual machines with VMWare Server? All of the documentation I've found talks about ESX Server. They give you 2 choices: 1) Run backup software *inside* of the VM and back it up like any other machine, or 2) Back up the VM files directly. In the case of ESX, you use the Perl API to set up a redo log, but AFAIK that's not possible with Server. Without that, how would I be sure that the image is intact, and not in an unsuable state, especially when backing up multi-gigabyte files will take a while, all the while the VM might be making changes?
I know VMWare needs a carrot to get people to spend the big bucks, but it seems to me there should be *some* way of being able to back up VM images under Server without worrying about them changing while you're backing them up... Does anyone have any suggestions?
Linux IT Consulting and Domino Development in Michigan
In a Unix environment, you can argue about whether the basic multi-user permissions environment and extra tricks like jails are enough to provide security in a multi-user multi-application market or whether it's helpful to use virtual machines as well. In a Windows environment, there's really not much question, even with XP-Pro and server versions - there's just not enough help from the OS. But even in a Unix environment, there are applications that want to use specific directories, or specific TCP and UDP port numbers, and virtualization lets you run multiple instances at the same time managed by different people. It also provides you some Least-Privilege-Principle separation of powers between your administrators - you can have one person who needs root to manage the firewall, but doesn't need to muck with the database, and somebody else who needs to control the database but doesn't need to touch the web servers.
For some applications, like virtual colo, virtualization environments really do rock, whether they're VMWare, UML, Xen, or whatever. I've seen people renting out virtual machines for ~$20/month or less, when physical colo costs would be $100, and it works fine (if there's enough cheap RAM) because usually you don't really need a big CPU full-time just to run an email server and web server or whatever.
Running multiple OS's at once is mainly useful in a desktop environment, or for specialized tasks like running an OpenBSD firewall, a Windows domain administration system, and a Linux general-purpose environment including web server and database all on the same box. I agree that it's usually cleaner to run everything in a single environment, even if it's multiple VMs - but there are times that the tools you want to use won't all run on the same OS.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks