The ABCs of virtual private servers, Part 1: Why go virtual? | Hacker News Reader

The ABCs of virtual private servers, Part 1: Why go virtual?

arstechnica.com

51 pointsevo_933 comments

A hypervisor is just an operating system (arbiter of resource use) relying on legacy operating systems as compatibility shims, because it has a native API nobody wants to deal with. It seems strange that we see resource contention problems when applications try to coexist on an operating system, and our response is to give each app its own guest O/S and then try to make those coexist. Why do we expect an improvement? I can't believe the existing O/S schedulers and paging policies were so poor that anything similar written from scratch for a hypervisor will automatically make better decisions despite less visibility into what's going on.

That said, I can certainly see a win in virtualization for testing. If your production system will have a large set of discrete machines communicating, you can simulate that with a much smaller pool of QA machines (maybe just one).

I could be wrong, but I don't think the argument for virtualisation was that it would fix resource contention, except possibly under some fairly rarefied conditions.

Downsides to VPS

  1. You pay stupidly high *monthly* costs based on RAM.
     This makes little sense, as RAM is ridiculously cheap.
  2. You pay masses for bandwidth if you go over.

1. You'll always pay more renting than buying in the long run. The difference is a factor of how efficient the market is, I guess. A high memory quad XL instance on Amazon has near enough 64GB of RAM, which you can have for $2.00 per hour, or $5300 for a reserved instance for a year. If you wanted to buy that much outright, you'd be paying a couple of thousand just for the DIMMs. Then you've got to buy and maintain the box to put them in, knowing that it'll have depreciated significantly over the year. I guess it depends on what you're actually planning to do with the RAM once you've got it, but it doesn't look like too bad a deal to me.

2. That depends on your VPS host, really.

2. Show me a VPS host that has cheap bandwidth.

For example, lets say we need 10TB of transfer.

  Slicehost: $3,000 (0.30/GB !!! WTF are they smoking)
  Amazon: $1,250 (Assume 5TB in, 5TB out, in US)
  Linode: $1,000 (0.10/GB Good for VPS, but still crazy)

  Typical dedicated server: $99 with 10TB included.

Amazon is ridiculously expensive. I know it's really "hip" to use it, but it's throwing money away. I guess if it's VC's money then who cares if you get to say "We're cloud hosted!!!".

Bandwidth pricing on VPS hosts is just crazily expensive.

I'm somwhat suspicious, but there's this: http://www.hostv.com/linux-vps.shtml; OVH have similar deals.

10TB/month averages out to 32Mbps. From what I've heard, try using anywhere near that on your typical "all you can eat" provider and you'll either be QoS'd enough to never achieve it or you'll suddenly be in violation of some finely printed Terms of Service.

I do around 5mpbs on dedicated servers without issue, I've peaked at 100mps without too much fuss.

I just bought 128GiB of unbuffered ecc ddr3 last week. 4GiB sticks which would be fine in a dual-socket board with 16 ram slots; (pretty typical, at least on the amd side of things. I see a lot of dual qpi xeons with only 6 ram slots between them, though.) I paid $1800 or so for the lot. That would give me two dual-socket 64GiB ram boxes.

Hell, even if you need 8GiB registered ecc ddr3 modules, that's only around $130 per module[1], or $1040 for 64GiB.

(both the qpi xeons by intel and the new G34 and C32 opterons support both reg. ecc and unbuffered ecc, but you generally can't get unbuffered ecc in densities higher than 4GiB per stick)

My standard server has 8 cores (2.0Ghz opterons) 32GiB ram, and 4 500gb "enterprise" sata disks. total cost? under $1800. AMD is interesting in this regard because I can get a dual-socket or even quad-socket board (the above system is single socket) and not pay any extra... I just get more cpu sockets and more ram sockets. (on G34 boards you usually get 8 ram slots per CPU socket.)

Now, the price of ram varies a lot. I think we're at a low point, but there was a period a year or two back where prices on reg. ecc ddr2 were almost as low as ddr3 is now, and there was a period between then and now where I was paying well over 2x what I'm paying now. But in general, the stuff is pretty cheap.

Seriously, we (the VPS providers) are making money on renting you hardware. I am making money, and I'm the opposite of "at scale" (to be clear, I'm paying for my hardware, and paying myself a rather below-market wage. I'm not making a /lot/ of money, but I'm profitable, and by enough of a margin that my rent gets paid on time every month.)

As a rule of thumb, I generally make my money back on a new bit of hardware within four months.

[1]http://www.provantage.com/kingston-technology-kvr1066d3q8r7s... (I used the same vendor for my unbuffered ecc, but I'm too lazy to look up the part number right now. )

In terms of expense to my business, the hardware isn't the only number I'm focused on. By using a VPS hosting provider that I know and trust, I don't have to worry about contracts with colocation facilities, secure access auditing, host hardware failure, image-level backups, console access (in case of network issues [DDoS]), host system updates and upgrades, and a host of other things that I probably don't even know about.

Although, I probably stated that incorrectly when I said I don't have to worry about these things. I do worry about them, but I have delegated them to someone I trust and has served me well for years. That's worth at least a full time salary + hardware, which is more than I pay for a few VPSs. Of course, that equation changes as my hardware requirements increase. At some point, economies of scale shift in favor of running my own gear, but that's a long ways off for most small to medium sized businesses.

right. I'm just correcting this idea that hardware is that expensive.

To be fair, those are both downsides to the current VPS providors business models, rather than flaws in virtual private servers themselves.

And if the traditional leased-machine colocation businesses I've used in the past are anything to judge by, much of the hardware in commercial use today is probably old enough that todays ram prices are not even close to indicative of the actual ram costs when the hardware was purchased... (Not that that should really matter, if the 3 or 4 year old machines my hosting company are currently offering as low or medium end colos aren't fully paid off several times over by now, they're definitely "doin it wrong"!)

"RAM" is generally used as a proxy for "what percentage of a machine you're getting", since most of the resources that aren't cheap, like CPU & bandwidth are shared. PRGMR states this explicitly: http://book.xen.prgmr.com/mediawiki/index.php/Scheduling#Sch... If you rent 1/8th of the RAM, you're guaranteed a minimum of 1/8th of the CPU, although you usually get more because most slices idle along most of the time.

Though a bit dated, I wrote a performance comparison of some of the providers mentioned in this article: http://journal.uggedal.com/vps-performance-comparison

Wrote an introduction to hosting a while ago if anyone's interested: http://openmymind.net/2010/10/26/An-Introduction-To-Hosting

Goes beyond VPSs and tries to look at the different options, plus the options typically available.

VPSs are great if you need less than the resources of one server, need a number of machines for a short period of time or your tasks are not disk IO intensive.

All that work you did to make your IO sequential goes to waste as soon as you put it on a VPS. It will be interesting to see if SSDs overcome the typical VPS limitations.

As you say disk IO is a sore point with VPSes but it's something that in many cases isn't an issue or at worst can be worked around.

Many websites have production rigs involving DB machines with a lot of memory, web workers that rarely do IO and files stored in CDNs or S3 so the disk problems are less of an issue.

As you point out though when your dataset fiscally or practically won't fit in RAM then disk IO catches up to you and I'd certainly appreciate an SSD's random seek time.

It's also important to remember development becomes an entirely different beast with cloud infrastructure though. Even the best tested and reviewed code can't approximate all the variables in production so being able to launch an exact mirror of your production rig and throw recorded traffic at it becomes an amazing test. This is something not feasible in the past.

I'd say VPSs are great if you're CPU bound, okay if you're memory bound, and terrible if you're disk IO bound.

Basically, CPU time is an abundant resource that's easily partitioned, but can be shared. So, you're guaranteed your share, but you often actually get more than your share.

Memory is strictly partitioned. You always get your share, no more, no less.

Disk is almost impossible to partition fairly (performance, not space). Furthermore, the more active disk users there are the worse the total performance is, so if you're unlucky enough to have a neighbor that uses a lot of disk IO than you effectively get double screwed.

What would be interesting is if someone came up with a VPS with dedicated disk resources, but as far as I know no one has done that.

For your better quality VPS providers, memory isn't really an issue because memory is dedicated. For your old time OpenVZ/Virtuozzo low-end box, that's not the case. You can oversell every resource on an OpenVZ box... Back in the day SW-Soft was claiming you could provision hundreds of VPSs on a 32 bit server. I never saw anything close to that, but I've seen some amazingly oversold servers trying to keep up with disk I/O.

One of the nice things about Xen is that disk I/O can be controlled somewhat because each domU has a specific process in dom0 for disk access. So you can ionice things & provide a somewhat more controlled access to the disk.

Memory capacity is typically dedicated (e.g., Linode), but memory bandwidth is difficult to allocate statically, and can be a huge problem even if you're fine on capacity. For example, a simulator I like to run has a 50-60MB working set, much larger than on-chip cache but well under my allocated 512MB of RAM. However, other concurrent users can disproportionately use up DRAM bandwidth, depending on their access pattern and the OS scheduler.

I've never seen a hardware node get anywhere near saturating the bus before disk I/O became an issue. So yes, there is a potential for saturation; however, I'd be really happy if that were my capacity bottleneck.

Again this is a platform specific complaint, back in the day IRIX solved this with GRIO on their Xbow active backplane. This technology will make it into Linux PCs eventually I expect.

>One of the nice things about Xen is that disk I/O can be controlled somewhat because each domU has a specific process in dom0 for disk access. So you can ionice things & provide a somewhat more controlled access to the disk.

My experience? it's easy to make one customers's I/O suck with such tools, but they work for shit when it comes to fairly balancing everyone's I/O.

As far as I can tell, the best practice is to monitor everyone's usage, and if someone goes above some pre-set threshold, to make their I/O suck using ionice or what have you.

But that's a long way from solving the problem.

Yeah, for certain. I guess I just really, really like the ability to have some control. Even if it isn't solving the problem. Back when I was working for a shop doing OpenVZ, all we could do is shrug our shoulders & make our best guess as to what was causing the problems.

Yeah, I know what you are saying. I started on FreeBSD Jails; and god damn, that was /hard/ - the heavy disk users would wipe out everyone else's cache, and so for the light users, when they logged in? the system would behave as if it did not have any pagecache. Moving to Xen, even without doing any I/O limiting, was world changing, simply because heavy users could not overwrite the pagecache used by light users.

Recently added to Microsoft's virtualisation solution is dynamic memory allocation. You give each virtual machine an amount of memory for startup and a maximum value and a priority, and now you can over-allocate resources quite nicely. It does however require the guests to have Enterprise level licenses (for no other reason than to encourage you to upgrade)

Disk is almost impossible to partition fairly (performance, not space)

I strongly suspect this is a platform-specific complaint. As in, if you are running your Linux VMs on a z-Series from IBM this is manageable. It's just a question of what your customers are willing to pay for...

All that work you did to make your IO sequential goes to waste as soon as you put it on a VPS

Why? You can run only one VM inside each hyprervisor. Or you can run only one IO intensive guest.

I hardly see any reasons to run my servers on hardvare instead of VMs in 2011.

Have you benchmarked your bare-metal vs. VM systems? I think you may be surprised how much performance you're losing. If you're not losing any performance I'd be interested as to your setup.

Also, the article discusses VPS systems which are generally much different than installing a VM on hardware you own.

I'll admit that the last time I tried to run an IO intensive task on a VM it was about a year and a half ago. (VMWare ESXi)

I think the processors installed in that box didn't support IO virtualization.

I've benchmarked filesystem with iozone tool and got more or less similar results for guest and host except "Pread" test where host is 20x times better then guest (my assumtion that this is a bug of virtualization software or misconfiguation from my side). I've performed test few times with same results.

My be I'm wrong but I don't understand where I could loose performance.

i use vps for development and beta environments. anything production quality needs to go on physical hardware.

needs? is there some type of law for this where you live?

Have you seen the list of production sites running on EC2? (http://aws.amazon.com/solutions/case-studies/) Linode also has some pretty impressive sites...linode.com probably being the most obvious one.

This really has nothing to do with the content of the article, but it's one of the reasons I respect Ars so much. There is not one mention of "cloud" outside the vendor's specific product names in the entire article. In other words, Ars' authors and editors don't play the buzzword bingo game.

Reply on news.ycombinator.com