Archive for August, 2008


Managed VPS Hosting vs In-House Servers

Friday, August 15th, 2008

We’ve been doing some research lately in order to determine the relative costs that a client or potential client might incur if they utilize other hosting methods.

The results have been interesting to say the least. For instance, let’s look at the rough costs of having your own internal server for one year:

  • Hardware: $1500 Server, upgraded/replaced every 3 years = $500/yr
  • Electricity: 165 watts continuous @ .14 per kWh = $202.50/yr
  • Daily off site backups stored a minimum of 30 days: $800/yr

So, at this point we’re looking at approximately $1400 per year without even factoring in costs for:

  • Administration
  • T1 or better connection
  • Infrastructure – cooling, battery backup, firewall, and physical space to house the equipment

For argument’s sake, we’ll say that you already have a T1 connection ($450+/month), but even if so, we still need to add on the costs of an administrator. Even if we factor in very affordable system administration services ($35/hr) and estimate only 2 hours of SysAdmin time per week, we’re looking at another $3640 per year, bringing our total costs to over $5000. These estimations are on the very low-end and in reality will usually cost much more.

Considering that HostCube VPS configurations start at $960/year and top out at $2400/year for the XL plan, we’re thinking you’d need an interesting set of requirements before it would make sense to seriously consider in-house hosting over a VPS. This is especially true as the VPS configuration would significantly outperform the in-house hosting configuration noted above.

In the weeks to come we’ll be comparing VPS to dedicated hosted servers as well as trying to peer through some of the fog surrounding “the cloud.”

BTW If you’re interested in the differences between managed VPS and shared hosting, check out Shared hosting vs. managed VPS. When to upgrade?

Security For Your Managed Virtual Server

Thursday, August 14th, 2008

Lions, tigers and hackers… oh my! Hackers and script kiddies are unfortunately constantly searching the Internet for insecure sites. If you have insecure or mis-configured software, it’s not “if” but “when” you will be compromised.

I’m not using this as scare tactic or as a reason to use our proactively managed virtual private servers, but as a fact from what we see every day. Unfortunately, the number of compromised servers we see hitting our network every day is staggering. For example, it’s not uncommon for us to block 50-100 new unique IP addresses daily for SSH or FTP brute force attempts. That’s just on a slow day. These are not Windows based desktops mind you, but Unix, Linux, or Windows based servers. You know, the servers that you would think are managed by system administration professionals.

Unfortunately it’s all too common for a web developer or designer think that buying a $99/month unmanaged dedicated server is all that is needed. Set it and forget it! Security is a continuous and never-ending process. Also many system administrators do not configure a server properly or too overtaxed putting out other fires. Even if you are not a HostCube customer, I strongly recommend hiring a qualified person or company to keep your server secure.

According to a Verizon Business study, the most common notification method of a security compromise is by a third party. So not only is the server software kept out of date, the software configuration is probably kept to defaults, but no monitoring exists when a comprise occurs. In this all too common case you might as well give away the keys and let the hacker do what they want with your setup!

Server security is about deploying layers; many different methods of proactive, reactive and defensive measures to protect from getting compromised. To give a high level view, here are the precautions we employ with managed virtual servers and managed servers:

  • Remove unneeded services
  • Employ best practices with software configuration (server hardening)
  • Automatic deployment of software updates
  • Hardware and local firewalls
  • Remote log storage
  • Backups (we can be used a method to audit a server)
  • Scanning for common Rootkits
  • Host Integrity Monitoring (HIM) to detect changes in operating system files
  • Unusual port and services detection
  • Monitoring services for availability and trends
  • Autoblock SSH/FTP attacks
  • Proper file and service permissions (sandboxing)

Monitoring log files and detecting server changes are some of the additional security measures we employ. We’ve just recently added Rootkit Hunter and Osiris host integrity monitoring to our list. Both tools monitor and detect attempted rootkits and any modifications to server setup. This additional monitoring makes our services fully PCI DSS compliant and just some of the features we perform to make sure a customer’s account is secure. You can rest assured knowing we are monitoring your managed virtual server very closely.

I won’t go into all of our security measures, nor details, but I will say the above list should be at least your security baseline. When choosing a provider, ask if they are really ‘managed’ and are performing these tasks for you. If not, you’ll definitely want to make sure you are addressing all these areas on your own.

VPS space in Data center #2

Tuesday, August 12th, 2008

We now have room in data center #2.  Customers, who want a their VPS located in a specific data center, please add this to the order comments.

Virtuozzo vs. Xen

Thursday, August 7th, 2008

We currently use Xen as our virtualization technology. To put it simply, Virtuozzo (or the open source version OpenVZ) is one level above chrooting or BSD jail. Yes, Virtuozzo has much less overhead per VPS instance and has some performance advantages, but at a cost of isolation and reliability. Virtuozzo uses OS level virtualization, while Xen uses paravirtualization.

When evaluating the different virtualization technologies we had very specific requirements. We wanted virtualization technology that allowed for:

  • dedicated server like isolation.
  • customizations to the installed operating system (i.e. kernel, iptables, etc.) just like a dedicated server.
  • proven deployment.
  • cannot oversell services (ensuring a specific level of quality of service).
  • complete separation of each operating system installation.

The differences with Virtuozzo and Xen are:

  • fixed memory and disk definitions.
  • custom kernels.
  • firewall configuration.
  • isolation.

For our purposes Xen acts, breaths, and looks like a dedicated server.

Fixed Memory and Disk Definitions

In Xen’s current form, memory cannot be oversold. If the node only has 16 GB of ram, it means only 16 GB of ram can be allocated to all VPS instances. Virtuozzo offers bustable memory, whereas Xen has hard, fixed caps. Burstable memory is great if you have control over all of the VPSes (everyone is friendly), but when you have a diverse environment, we prefer hard memory caps (you’re guaranteed by the technology that you actually get what you pay for).

With Xen, like a real server, you get a specific amount of memory and swap space. This allows the operating system handle memory and swap to disk as needed. Memory on Virtuozzo is a much muddled situation. To the VPS instance, it all appears to be memory, when in fact it’s not. With Virtuozzo, It’s not uncommon for services to just die because no memory is available. Depending upon the provider, memory can be oversold and performance is then no better than shared hosting setups. Currently with Xen there is no way for us to do this and therefore you know that what you pay for is exactly what you are getting.

Firewall Configuration

Firewall configuration with Virtuozzo is very limited and you do not have access to the full iptables setup. This means there are many hoops you must go through to firewall your VPS instance. Most Virtuozzo providers configure their setup to have the node control the firewall configuration.

Custom Kernel

Xen allows for custom kernels. Each VPS instance can be unique. Need a special module, or custom kernel? With Virtuozzo, since the virtualization uses the same kernel for all VPS instances, you can’t do this. With Xen, each virtual server has a separate kernel and allows for increased security.

Isolation

This is an area that is typically more anecdotal than “hard facts,” and is always up for debate by both sides. While the Virtuozzo crowd states their virtualization technology performs better, the tests I’ve seen are not real world situations. The simple fact is that I’ve never heard of a Xen node getting overwhelmed and bringing down the other instances. With Virtuozzo we’ve seen this happen a lot and it is primarily because of two factors:

  • Oversold memory and bustable memory.
  • Hypervisor scheduler. While Xen’s scheduler options are much more limited, it works and works well.

In our case we’ve had many times where we’ve seen a specific VPS instance running at 100% CPU usage and high disk IO without the other VPS instances even missing a beat. With Virtuozzo it is assumed each VPS will play well with others and this simply is not always the case. The biggest limitation with Xen is it’s disk IO scheduler. The IO scheduler is somewhat simplistic, but does have the benefit that you can control unruly virtual servers and prevent them from affecting the other servers.

Summary

If you are looking for “dedicated-like” performance, customization, isolation and security, Xen is a perfect fit. With our managed virtual servers, it’s like getting a dedicated server for a fraction of the cost!

Also keep in mind that while we currently use Xen we are not married to it. We are always looking at the other virtualization technologies. With the recent announcement from Red Hat, KVM definitely has a chance. The way our cloud infrastructure is designed, the VM manager really doesn’t matter. In the end, what matters to us and our customers is running what works and is stable, secure and provides the best isolation. For now, Xen is that perfect fit, while Virtuozzo is simply not as robust.