The "Cloud" Buzzword vs. The Reality of I/O

It is 2011, and if I hear one more sales rep tell me to "just put it in the cloud," I might decommission their email account. The explosion of data we saw in 2010 has left many CTOs and Systems Administrators scrambling. We are torn between the infinite scalability promises of object storage like Amazon S3 and the raw, predictable performance of local iron.

I recently oversaw a migration for a media publishing house in Oslo. They wanted to move 4TB of assets to a public cloud provider in the US to save on hardware costs. It looked great on a spreadsheet. In practice? The latency killed the application. Loading a front page took 4 seconds because of the round-trip time (RTT) across the Atlantic. We moved the hot data back to a local VDS (Virtual Dedicated Server) in Norway, and the load time dropped to 300ms.

Here is the reality: For heavy database transactions and Nordic compliance, "The Cloud" isn't always the answer. Sometimes, you just need fast disk access close to your users.

The I/O Bottleneck: Why Your Database Hates Shared Storage

In a virtualized environment—whether it's Xen, KVM, or OpenVZ—disk I/O is the scarcest resource. CPU cycles are easy to schedule; random read/write operations on a spinning disk are not. When you have a noisy neighbor on a host node trashing the disk, your MySQL queries pile up.

Many budget hosting providers oversell their storage backend. They put 50 VMs on a single SATA RAID-5 array. If one user decides to compile a kernel or run a backup, everyone else suffers. This is why at CoolVDS, we emphasize the architecture of the storage backend over raw capacity.

Identifying the Bottleneck

Before you blame the network, check your disk wait time. On your Linux box, run:

Look at the wa (wait) column. If it is consistently over 10-15%, your CPU is sitting idle waiting for data from the disk. That is money being wasted.

Optimizing for Performance on Linux (Kernel 2.6.x)

If you are running RHEL 5, CentOS 5, or the new Debian 6 (Squeeze), there are tweaks you must apply to survive in a virtual environment. The default settings are often tuned for desktop usage, not high-performance servers.

1. The I/O Scheduler

The default cfq (Completely Fair Queuing) scheduler is often inefficient for virtualized guests because the host OS is already handling scheduling. Switch to the deadline scheduler for database servers to prioritize read requests and prevent starvation.

Edit /boot/grub/menu.lst and append elevator=deadline to your kernel line, or change it on the fly:

2. Filesystem Access Times

Every time a file is read, Linux updates its access time metadata. For a high-traffic web server, this causes a massive amount of unnecessary write operations. Mount your filesystems with noatime.

In /etc/fstab:

Pro Tip: Be careful with EXT4. While it is stable in recent kernels, many production environments in 2011 are still safer on EXT3 for critical data integrity until EXT4 matures further. If you use CoolVDS, we provide templates optimized with these flags pre-configured.

The Legal Landscape: Datatilsynet and Sovereignty

Performance is physics, but compliance is law. In Norway, we operate under the Personopplysningsloven (Personal Data Act). While the US-EU Safe Harbor framework theoretically allows data transfer to the US, the legal ground is shaky. Norwegian companies handling sensitive customer data (financial records, health data) face strict scrutiny from Datatilsynet.

Hosting your primary data outside the EEA (European Economic Area) introduces risk. If a US authority issues a subpoena under the Patriot Act, your data host might be forced to comply, bypassing Norwegian privacy protections. This is a massive headache for any pragmatic CTO.

Keeping data in a Norwegian datacenter solves two problems:

1. Latency: NIX (Norwegian Internet Exchange) peering ensures your local users get sub-10ms response times.
2. Sovereignty: Your data stays under Norwegian jurisdiction.

The Hybrid Approach

You don't have to choose between massive storage and speed. The winning architecture for 2011 is hybrid:

• Static Assets (Images, Video, Backups): Offload these to an object storage system or a CDN. It is cheap and latency matters less.
• Transactional Data (MySQL/PostgreSQL, PHP execution): Keep this on a high-performance VDS with RAID-10 storage.

We built the CoolVDS platform specifically for that second tier. We use enterprise-grade SAS drives (15k RPM) and emerging SSD technology for caching layers in RAID-10 configurations. We don't use RAID-5 because the write penalty is too high for databases. The result is a system that behaves like dedicated iron but scales like a VM.

If you are still struggling with high iowait or nervous about where your data actually lives, it is time to rethink your topology. Don't let a slow disk kill your user experience.

Ready to lower your wait times? Spin up a CoolVDS instance in Oslo today and keep your data strictly within Norwegian borders.