Thursday, June 27, 2013

Virtualization

I am surprised to learn there are other good virtualization geeks out there. I have only worked with two really good virtualization guys in the last ten years. I don't know why its so hard to convince other old school people that more processors != more performance, most of the time. Here is another site confirming much of what I have posted previously about virtualization. Requires login with email address. http://searchservervirtualization.techtarget.com/tip/Sizing-server-hardware-for-virtual-machines I disagree with sizing the same as you would physical. Do not do that. http://blogs.softchoice.com/advisor/ssn/4-principles-for-right-sizing-physical-servers-in-your-virtual-environment-intel/ pretty good post by a geek. http://www.datacenterpost.com/2012/03/vcpu-sizing-considerations.html

Wednesday, June 26, 2013

Virtual machine sizing

Unfortunately lately I have been pushed to make bad decisions when it comes to VM sizing. A few reasons have been, "We are not utilizing all of our hardware, all that extra processing power and memory should be allocated, or it just goes to waste", "Each additional VM costs upwards of $30K to support, so we should build fewer larger VMs", "X company won't certify or support their products unless you match their minimum specs".
     While these are valid business concerns and should be factored in when creating a VM infrastructure, they should not be the deciding factor. An older rule of thumb when creating virtual machines was to always start with a single vcpu and 4 gigs of memory. Times have changed and the rules of thumb need to be updated.
     Sizing is highly dependent on what applications you run and how you plan to utilize the machine. I will delve into Apache Httpd, because I most frequently worked tuning them.
     For instance if you have a virtual machine hosting the Apache httpd front end to a wiki server, you want to run for a perceived user load of 1000 concurrent users. I have tested these sizes and they give the best default performance. Apache HTTPD virtual, 1 Vcpu, 4 gigs of memory and two Gig Ethernet interfaces for production traffic . Of course httpd needs to be setup correctly. Fresh out of the box httpd will use about 250mb per thread.
Tuning similar to http://chrisgilligan.com/consulting/tuning-apache-and-mysql-for-best-performance-in-a-shared-virtual-hosting-environment/ and http://oxpedia.org/wiki/index.php?title=Tune_apache2_for_more_concurrent_connections Apache HTTPD can be tuned to use about 15mb a thread while servicing SSL/TLS. For 225 concurrent user connections on a reasonable well tuned system you will use 3.5 gig of memory the OS will use the other 500MB. If you have a requirement for large amounts concurrent users, for example 1000 which is the perceived max per system based on httperf testing results. Apache httpd server should never be allocated with more than 2 cores and 16 gig of memory. If you have a 10,000 concurrent user requirement, you should not build an eight core box with 160 gig of memory. Scaling horizontally and spreading load out to 10 machines with 2 cores and 16 will provide much better response times. Even on the same virtual host. Depending on load while doing a production replay through httperf while testing processor count may need to be moved up to 4 cores. This is a test, you should split the load across more virtuals. Don't take this at face value. You should test 2 / 4 four proc Apache httpd setups vs. 4 / 8 two proc Apache setups. The Performance metrics don't lie.