Hi, guys!
I'm Rebuilding all the servers in the company I work for. I read anything I found about best practices in virtualizing, but I didn't find anything about virtualizing Apache. As MySQl is not considered to be virtualized as a best practice but to be on a separate machine - my question is "Do I virtualize an Apache server or put it on another real machine?". And also I'm going to put the server on Ubuntu!
Thank you!

... depends on the traffic ...

Instead of Apache I suggest to build NGINX... its perfect Webserver for virtualization

Thanks, man! Then I'm virtualizing it! If it doesn't work well I'll use a separate machine, but I think it WILL!

What are the fundamental principles that determine whether an application is best virtualised or native?

Mostly traffic. That's because database servers have a great traffic they are preferred to be native. At least I've read so...
Here's what I've read
http://www.google.bg/url?sa=t&source...RAt0Rg&cad=rja

Although network traffic is a possible issue, you usually want to use physical machine for heavy I/O operations. Virtualized machines are in general not really suited for this kind of work. That's the reason why it is not advised in general to virtualize a database server.

Isn't traffic a heavy IO operation!? Isn't it what someone means by saying "heavy IO operation"?

Disk I/O... Disks are often the slowest part in a server. Especially when shared with different VPS's. Actually optic fibre channels are so fast that a HD cannot keep up.

Apache virtualizes very well, especially if you use PHP or Python scripts and are not constrained by storage I/O.

I recommend trimming the Apache modules, though, to a set that fulfills your needs, but does not include unused ones. Also, limit the maximum run time and memory each script interpreter instance is allowed to use, for both security and stability. That way a runaway script won't be able to consume all available memory and crash Apache.

A typical web site has a lot of small files used on most pages -- CSS stylesheets, user interface images, and so on. These are typically cached in memory (automatically by the kernel, because they're so often accessed) and do not incur physical storage I/O. These are rarely any kind of a bottleneck, since even a low-power virtual processor can fill a 1Gbit/s pipe from memory-cached files. The CPU needed by script pages is usually offset by their lower storage I/O requirements.

The next typical bottleneck is the database server the scripts get their contents from (or, more accurately, the limited number of connections allowed to the database server). Please make sure you have enough connections available to service each script instance Apache is allowed to have, so that users don't get those annoying "Database unavailable" error messages. If using the prefork model, it's perfectly reasonable to reduce the maximum number of children to the number of database connections available.

Nominal Animal

The general consensus of where I work, one of the car companies, is that anything that is PRODUCTION will NOT be virtualized. Virtualization is best left for development environments due to the ease of staging a new VM for testing.

So anyway, we ignore that and virtualize all kinds of production stuff.

We sometimes run benchmarks of an application on bare-metal, then compare them with benchmarks of the same application virtualized, using LoadRunner to engage the traffic. If it is comparable, within 10%, we will roll with it. If not, we will put it on iron.

In my opinion, Java runs like crap in virtualized environments. Big Mysql db's bottlenecks in virtualized environments. Anything with lots of Disk I/O really suffers, such as FreeNAS and such.

Vmware will stomp their feet and tell you all the great things about virtualization and how it can save you money on hardware, and speed isn't an issue, and blah blah blah. But remember, they are trying to sell you a product, by any means necessary. Virtualization will always cause a hit in performance. It just depends on how much performance you are willing to lose.

IMHO

1 members found this post helpful.

Thanks szboardstretcher and Nominal Animal. That was a great explanation and I'm gonna put it in use!

+1 to that