maxgarrick.com » openvz

How to create a minimal LAMP stack in OpenVZ

max — Sun, 30 Nov 2008 00:01:38 +0000

Creating a minimal LAMP stack in OpenVZ:

Start with a pre-created centos-5 OpenVZ template & install required packages:


# Create centos-5 OpenVZ container:
vzctl create 1056 --ostemplate centos-5-x86_64-minimal
vzctl set 1056 --ipadd 192.168.0.56 --nameserver 123.123.123.123 --save
vzctl start 1056

# Update software & install packages:
vzctl 1056 install yum
vzctl enter 1056
yum upgrade

# Install packages -- the ".x86_64" tells yum to only
# install the 64-bit packages and not the i386 packages.
yum install vim-enhanced.x86_64 mysql.x86_64 mysql-server.x86_64 \
httpd.x86_64 httpd-devel.x86_64 wget.x86_64 which.x86_64 \
php.x86_64 make.x86_64 gcc.x86_64 gcc-c++.x86_64

# Clean up leftover files from yum:
yum clean all

Next, tune Apache to fit our development 256MB OpenVZ container. If you have more memory dedicated to your container, consider increasing these settings. Edit the prefork MPM section of /etc/httpd/conf/httpd.conf:

<IfModule prefork.c>
StartServers       2
MinSpareServers    1
MaxSpareServers   8
ServerLimit      8
MaxClients       8
MaxRequestsPerChild  4000
</IfModule>

Let’s lock down the MySQL root user before starting up services:

mysql -u root mysql
mysql> update user set password=password('mynewsecurepassword') \
where user='root';
mysql> flush privileges;
mysql> exit

Start services and ensure that services start when the machine boots up:

chkconfig --levels 345 httpd
chkconfig --levels 345 mysqld
service httpd start
service mysqld start

Finally: test!

This will give you a slimmed down LAMP stack, suitable for running small web applications on top.

Understanding OpenVZ resource limits

max — Sun, 12 Oct 2008 04:14:51 +0000

OpenVZ resource limits can be a little tricky, even after reading through the documentation on the OpenVZ website. With this post, I hope to explain the /proc/user_beancounters file as well as provide an illustration of memory guarantees/limits in an example 256mb container.

Before attempting to understand OpenVZ’s memory limits, let’s recap Linux’s memory setup. This background information is important to firmly grasp OpenVZ’s behavior. You can safely skip this section if you already understand Linux’s memory overcommit accounting.

Linux Overcommit Accounting

Memory in Linux refers to the combined RAM + swap values. Memory is allocated from this pool using one of the *alloc() functions. If malloc() is used to allocate memory, the pages are not zeroed out. malloc() is unique in one regard: the kernel can malloc() more memory than what is available in RAM + swap. This behavior of allocating more than the total available memory is called overcommitting memory.

Seems like a recipe for disaster, huh? Imagine… processes are humming along allocating memory and BAM! some process wants to use the n’th + 1 byte of memory and an out of memory (OOM) condition provokes the kernel to start killing processes.

Why does the kernel allow memory to be overcommitted? Because most applications do not actually consume all of the malloc()’d memory. If an app doesn’t use a memory location, it does not really need to subtract from your total available memory.

Consider a typical Apache process. A full 20-30% of an Apache processes malloc()’d memory may not be consumed. With memory overcommit, this slice of memory can be used by other applications. Java applications also allocate much more than they use, as do many scientific applications.

At the system-wide level, these “malloc’d(), but not consumed” slices of memory begin to add up. By overcommitting memory, these slices don’t take up physical memory locations — resulting in more efficient use of memory resources.

OpenVZ and memory overcommit

OpenVZ also has the ability to overcommit memory. When creating an OpenVZ container, we specify the vmguarpages and oomguarpages resource guarantees. vmguarpages represents the maximum guaranteed amount of malloc()’d memory a container may have, while oomguarpages represents the maximum consumed memory. These are called guarantees because (If your server has enough RAM + swap) container processes will never be killed due to OOM if they are within these limits.

What if your container exceeds the vmguarpages or oomguarpages value? This is where a new limit comes in: privvmpages. privvmpages represents the absolute upper limit on container memory. When you run free or `cat /proc/meminfo` in a container, you see this privvmpages value take form as “Total memory”.

The memory gap between privvmpages and the two resource guarantees (vmguarpages and oomguarpages) is not safe to use in an ongoing basis if the sum of all container privvmpages exceeds RAM + swap of the hardware node. This is because if the hardware node runs out of memory, it begins looking for containers using more than their guaranteed memory. The kernel kills a process from the container who’s physpages exceeds oomguarpages the most.

I’ve created a diagram that hopefully illustrates the relationship between these three key memory limits/guarantees. Also included in the diagram is kmemsize, which is used for non-swappable kernel memory–not very important as long as it scales with privvmpages.

Get your dev server, $0.10 a pop

max — Tue, 22 Apr 2008 02:50:55 +0000

One of the best uses of virtualization technology is for creating development environments. Virtual private servers (VPS) are ideal if you need a sandbox to create a new application stack, develop a new web app, or test out the app under a variety of Q/A scenarios.

How can we offer dev environments with low provisioning cost? This is one way:

Set up OpenVZ on a RHEL5 server.
Set up a web template (Apache, PHP5).
Set up a MySQL template
For each dev environment, deploy a web and MySQL container.

This 4 step process glosses over many important challenges. For instance:

How do you access these machines over the network?
How to get the latest code into each deployed web container?
How to get the latest MySQL schema & associated dev data into the MySQL container?
How to get code and schema changes out of the container and into another environment (e.g.: deploying to production)?
How to upgrade/restart the VPS without having to coordinate with each developer?

I’m thinking we can overcome these challenges with some crafty configuration & scripts.

Network access

NAT all VPS servers for more fluid provisioning, less DNS updates. Web nodes occupy one network subnet, DB nodes occupy another. Use a database to track all VPS and build a simple webapp on top that provides bookmarks to each VPS along with CRUD ops.

Getting code into the VPS

Using our git repo, check out a working copy with the latest dev branch. Alternatively, NFS mount staff home directories in each VPS and work off that. I’d prefer the NFS approach, as it makes the VPS more transient: we can destroy and re-create the server using an upgraded template if desired without loosing code.

Getting DB schema into the VPS

Database migrations, similar to Rails (we use PHP for most apps). Moodle CMS also has a form of database migrations which happen via the web, which is a tad simpler. Doctrine ORM supports database migrations, although we use it only for new development and it won’t help our existing code. For older/legacy webapps, we’ll have to maintain a per-tool schema file to bootstrap our webapps.

Getting code and schema updates out of the VPS

Pull code changes using git into a central repo. Put all database migrations in the code, using Doctrine as described above, or schema bootstrap file.

Painless VPS reboots

If all database changes exist in code, and all code exists on the shared NFS server, then destroying & deploying a new VPS from an updated template should not impact a developer. Test data may disappear, which may cause concern. Ideally, all important data would be saved in-code and easily imported into MySQL, through migrations or bootstrap SQL files. Alternatively, we could place the MySQL data files on an iSCSI lun, at an additional provisioning cost.

Once we are able to quickly provision new dev environments, why not do the same for production apps? I think we could use the same code bootstrap & database migration code to deploy new application stacks on demand.