Cloud Storage Strategies for 2010: Why Your SAN is Obsolete

Let’s be honest: buying hardware in 2009 is a losing game. I recently sat down with a CFO who was hyperventilating over a quote for a new EMC SAN implementation. The capital expenditure (CAPEX) was astronomical, and the lead time was six weeks. In an era where Amazon S3 and virtualization are rewriting the rules, sinking $50,000 into spinning rust that sits idle 80% of the time is negligent.

The conversation around storage is shifting. It's no longer just about capacity; it's about IOPS, latency, and where that data physically sits—especially here in Norway with the Datatilsynet watching closely.

The Bottleneck is No Longer CPU

We used to worry about CPU cycles. Today, with quad-core Xeons becoming standard, the bottleneck has firmly moved to I/O. I saw this firsthand last month while migrating a high-traffic Joomla news portal in Oslo. The CPU load was under 1.0, but the site was crawling. Why? I/O Wait.

The shared hosting provider they were on was running standard 7.2k SATA drives in a RAID 5 array. One noisy neighbor started a backup job, and the disk heads started thrashing. The site went dark.

This is where the architecture of your Virtual Dedicated Server (VDS) provider becomes critical. You cannot rely on generic hosting for database-heavy applications.

Optimizing Linux for Disk I/O

Before you blame the hardware, ensure your OS isn't the problem. In RHEL 5 or Debian Lenny, the default filesystem mount options are rarely optimized for performance. By default, Linux updates the access time (atime) every time a file is read. For a busy web server, this is thousands of unnecessary write operations.

Here is the standard optimization we deploy on all CoolVDS instances to reduce disk thrashing:

# /etc/fstab optimization
# Change defaults to noatime,nodiratime to stop writing access times
/dev/sda1   /   ext3    defaults,noatime,nodiratime,errors=remount-ro 0 1

Furthermore, if you are running MySQL 5.0 or 5.1, the key is ensuring you are utilizing RAM to avoid hitting the disk. The innodb_buffer_pool_size should typically be set to 70-80% of your available RAM on a dedicated database server.

The Rise of SSD in the Datacenter

While still expensive, Enterprise Solid State Drives (SSDs) like the Intel X25-E are beginning to appear in high-end hosting environments. The difference is staggering. A standard 15k RPM SAS drive might give you 180 IOPS. An SSD can push thousands.

For 2010, my strategy is hybrid: use cheap mass storage for backups and static assets, but demand SSD or high-performance SAS RAID-10 for your database and OS roots. This is why we treat CoolVDS as our reference implementation for high-load projects—they don't oversell their I/O capacity.

Pro Tip: Use the iostat command (part of the sysstat package) to diagnose bottlenecks. If your %iowait is consistently above 10%, you need faster storage, not more CPU.

Data Sovereignty: The Norwegian Context

With the rise of US-based cloud giants, a new risk has emerged: the USA PATRIOT Act. Legal counsel is increasingly advising against hosting sensitive Norwegian customer data on US-owned servers, even if they have a datacenter in Europe (like Dublin).

The Norwegian Personal Data Act (Personopplysningsloven) places strict requirements on data controllers. Latency is another factor. Physics is undefeated; light takes time to travel.

For a Norwegian business, hosting locally isn't just about patriotism; it's about latency and compliance. Connecting to the Norwegian Internet Exchange (NIX) ensures your traffic stays within the country, improving speed and security.

Conclusion: Prepare for the Virtual Decade

As we head into 2010, the days of buying physical servers for every project are ending. It is inefficient and inflexible. However, not all "clouds" are created equal. You need a partner that understands the I/O requirements of modern databases and the legal landscape of Norway.

Don't let your database choke on slow disks. Evaluate your current I/O wait times today. If you are seeing lag, it’s time to migrate. Deploy a high-performance instance on CoolVDS and see what sub-millisecond local latency does for your application response times.