Surviving the Sprawl: LXC vs. OpenVZ vs. KVM High-Availability Architectures

It is 3:00 AM. Your pager is screaming because a single tenant on your shared kernel node decided to run a fork bomb, or perhaps a poorly optimized Magento cron job ate all the inodes. If you are running OpenVZ, your entire node is dead. All 40 clients are down. You are SSH-ing into a responsive machine, praying the reboot command works.

I have been there. We have all been there. In the rush to squeeze density out of bare metal, providers have been overselling resources using container-based virtualization like it is free real estate. But in 2013, with the explosion of data-heavy applications, the "shared kernel" model is becoming a liability for serious infrastructure.

Today, we are cutting through the marketing fluff. We are looking at the raw technical reality of scaling infrastructure in Norway: the choice between Linux Containers (LXC/OpenVZ) and Kernel-based Virtual Machine (KVM), and how to orchestrate them without losing your mind.

The Container Trap: OpenVZ and LXC

Containers are lightweight. They are fast. They boot in milliseconds because they aren't booting a kernel; they are just isolating a namespace. I love LXC (Linux Containers) for development environments. It utilizes kernel cgroups (control groups) to limit resources. It is brilliant technology.

However, in a production hosting environment, shared kernel virtualization (like OpenVZ) has a fatal flaw: Noisy Neighbors.

If you are hosting mission-critical data, you cannot afford to have your disk I/O choked because the guy next door is compiling a massive C++ project. Furthermore, kernel modules. Need a specific version of iptables or want to load a custom FUSE module for encryption? On OpenVZ, you are at the mercy of the host node's kernel configuration.

Checking LXC Capability

If you are experimenting with LXC on your local Debian Wheezy or Ubuntu 12.04 LTS box, you can check your kernel's readiness:

$ lxc-checkconfig
Kernel configuration not found at /proc/config.gz; searching...
Kernel configuration found at /boot/config-3.2.0-37-generic

--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled
Multiple /dev/pts instances: enabled

--- Control groups ---
Cgroup: enabled
Cgroup clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled

While the output looks green, the isolation is not absolute. Security exploits targeting the kernel can theoretically bleed through. For a dev team in Oslo, this risk is manageable. For a bank or a healthcare provider dealing with sensitive data under Personopplysningsloven, it is a non-starter.

The Heavy Artillery: KVM (Kernel-based Virtual Machine)

This is where the adults play. KVM turns the Linux kernel into a hypervisor. Each guest has its own kernel, its own memory space, and its own interrupts. If a guest crashes, it crashes alone.

At CoolVDS, we standardized on KVM years ago. Why? Because when we promise you 2GB of RAM, that RAM is allocated to you. It is not "burstable" RAM that disappears when the host gets busy. It allows us to run different operating systems (FreeBSD, CentOS 6, Debian) side-by-side without conflict.

Managing KVM with Libvirt

Managing KVM manually with QEMU commands is madness. We use libvirt. Here is how you can check your VDS status from the host node command line, a command I type fifty times a day:

# virsh list --all
 Id    Name                           State
----------------------------------------------------
 2     production-db-01               running
 3     production-web-01              running
 -     staging-web-01                 shut off

And to examine the XML definition of a node to ensure the network interface is bridged correctly for our Norwegian datacenter VLANs:

# virsh dumpxml production-web-01 | grep "interface type" -A 5
    <interface type='bridge'>
      <mac address='52:54:00:a1:b2:c3'/>
      <source bridge='br0'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

Note the virtio model. Always use VirtIO drivers. They bypass the emulation layer for direct communication with the hypervisor, drastically reducing I/O overhead. If your VPS provider isn't using VirtIO, you are driving a Ferrari with the handbrake on.

Orchestration: Puppet vs. Shell Scripts

So you have 50 KVM instances. How do you manage them? If you say "SSH loops and shell scripts," please stop. In 2013, we treat infrastructure as code.

We rely heavily on Puppet. By defining the state of our servers in manifests, we ensure consistency. If a Junior SysAdmin accidentally changes the MySQL configuration, Puppet reverts it automatically on the next run (usually every 30 minutes).

Here is a snippet of a Puppet manifest we use to ensure our standard system tuning is applied to every CoolVDS node:

class system_optimization {

  sysctl { 'vm.swappiness': 
    ensure => present,
    value  => '10',
  }

  sysctl { 'net.ipv4.tcp_window_scaling':
    ensure => present,
    value  => '1',
  }
  
  # Increase backlog for high connection rates
  sysctl { 'net.core.netdev_max_backlog':
    ensure => present,
    value  => '2000',
  }
}

This level of automation creates stability. Stability breeds trust.

The SSD Revolution and Database Performance

The biggest bottleneck in virtualization has always been Disk I/O. Traditional spinning rust (HDDs) cannot handle the random read/write patterns of fifty concurrent VMs. This is where the "Performance Obsessive" in me comes out.

We recently migrated a high-load e-commerce client from a standard HDD RAID array to our new Enterprise SSD tier. Their database wait times dropped by 90% instantly. However, hardware is only half the battle. You must tune the software.

For MySQL on SSDs, you must change the I/O scheduler. The default CFQ (Completely Fair Queuing) scheduler is optimized for spinning platters. On SSDs, it just adds latency. We configure our CoolVDS templates to use the noop or deadline scheduler.

Pro Tip: Check your current scheduler with cat /sys/block/sda/queue/scheduler. If you see [cfq] selected on an SSD VPS, change it immediately.

Also, update your my.cnf to handle the speed:

[mysqld]
# Use O_DIRECT to bypass OS cache, let InnoDB handle it
innodb_flush_method = O_DIRECT
innodb_io_capacity = 2000
innodb_read_io_threads = 8
innodb_write_io_threads = 8

Data Sovereignty and The "Patriot Act" Fear

We cannot ignore the legal landscape. Many Norwegian companies are realizing that hosting with US-based giants puts their data under the jurisdiction of the US PATRIOT Act. Even if the server is physically in Dublin or Amsterdam, the parent company is American.

This is a compliance nightmare waiting to happen for anyone dealing with sensitive Norwegian user data. Using a local provider like CoolVDS means your data stays in Oslo, protected by Norwegian law and Datatilsynet regulations. We own our hardware. We don't resell Amazon EC2 instances. Your data sits on drives we can physically touch (though we won't, because fingerprints are messy).

Conclusion: Deterministic Performance

The debate between Containers and Hypervisors boils down to this: Do you want maximum density, or do you want guaranteed performance? Containers are great for PaaS (Platform as a Service), but for infrastructure that acts as the backbone of your business, KVM is the standard.

Don't let your database choke on a noisy neighbor's I/O. Don't let your data traverse the Atlantic unnecessarily.

If you are ready to stop fighting with resource contention and start deploying on a stack built for engineers, by engineers, fire up a KVM instance with us. Our network latency to NIX is practically zero.

Deploy your high-performance SSD KVM instance on CoolVDS today.