forward looking statements

| | Comments (14)
so I've decided what I'm going to do about the larger domains. 

The problem is that people get a 4GiB domain and then are all disappointed, because I/O sucks.  The thing is, Virtualization sucks for storage.  If I have a mirror, and I run 8 4GiB guests on it, when there is contention for disk, each domain gets a lot less than 1/8th the disk performance they would get if they had a disk to themselves;  you see, SATA disk is pretty good for sequential transfers, but it sucks for random access.  If you have 8 guys trying to sequentially access the disk, guess what?  all that sequential access is now random, in an attempt to service each request in a reasonable amount of time. 

(now, I/O also sucks for smaller domains, but people don't complain as much there.   I mean,  you are paying $8 a month, what do you want?  If you get enough ram, the thing ends up being reasonably usable once you warm up the cache.)

So, my plan for the 4GiB domains is to jack up the prices (I plan on staying well below slicehost and linode prices, still)  and giving you your own mirror.  Current pricing plan is something like the current price ($68/month)  plus $0.10 per gigabyte of disk (so around $100 for a 1TB disk)  with the caveat that you must buy the entire disk.   (you would get a mirror, not an individual disk, so I think $.10 per gigabyte month is a reasonably good deal.)   

So, I have a bunch of disk laying about on many of my servers, sitting idle;  it is possible I  will use some of them as 4TiB or 8TiB guests.  It is also possible I'll just start buying servers with 16 drive bays and going at it that way.  (maybe with the 500GB 2.5" disks?  500GB is a nicer disk size and disk cost than making people buy a whole TB and a half, which are what the disks I have now are.)  

note, as the title implies, these are 'forward looking statements'  - I have not tested this out;  I have not shaken out the bugs.  It's possible I'll never get around to doing this.  It's even more likely that I'll run out of free disks in short order and it will be a while before I accept new larger orders. 


Hey Luke,

Not sure how much it will help, but have you looked into tweaking the IO scheduler?

yeah, we use CFQ in the dom0 and it should be noop on the DomU (though I can't stop the user from changing that) the thing is, you want all your request cohelesing and stuff to happen on the Dom0 (as the domUs only have part of a spindel)

the thing is, when a DomU trys to 'sync' Xen tries to push that through to the disk before returning, so stuff like database servers that try to flush stuff to disk are a really bad fit for virtualization, as they force out-of-order (elevator wise) writes.

If you compromise consistency, (which is to say, you cache up more writes before writing) you can make your access patterns much more sequential, and thus much more performant... but the problem is that you sacrifice consistency. if I crash or lose power, and I've been lying to you about committing your writes, your data is going to be messed up pretty bad (as both ext3 and many database systems make strong assumptions about the order in which data is committed to disk)

So, just to confirm what you're saying is that the monthly pricing will stay about the same with a setup cost of the price of $100/TB for disks?

I was thinking the disk fee would be a monthly fee, as it'd be quite a bit more value than what the competition offers, and organizing the disks would be a bit of a pain.

Obviously, it would be something of a premium service. (and right now I've still got more customers than I can handle, so while I still want to be careful to not jack up prices on existing customers or for existing services, I have no reason to lower prices on new features just yet.)

Perhaps I'm an unusual case. I don't actually care so much about disk I/O, but do want 1GB of memory.

Why? Java. If you're doing anything significant with Java, you will need to have quite a bit of memory available even if you're not doing a lot with I/O.

When you start to need 4GiB, then, yes, disk I/O will be a bottleneck, but you can quite easily have one low I/O app running on 1GiB and be quite happy with your service.

I know that I am.

Perhaps you should consider disk I/O and pricing separate from memory?

I suspect the first VPS hosting company that is brave enough to try Intel SSDs as storage will be a huge win. They are so much better on random access (reads are unbelievable, writes will still be much better than spinning disks). And you can charge more for it.

The Intel X25-E SSDs are pretty awesome. (many of the cheaper SSDs are, ah, less so.)

The problem is that they are, ah, rather small and expensive. I've been talking about giving everyone a small slice of a shared SSD (like, say, as much ssd as you buy ram) with the idea being that people can either put performance critical stuff on them, or move the ext3 journal on to them to boost performance.

But the thing is, especially if you mirror them, you are talking about a cost that is almost as high as the cost of ram, and ram is already my biggest expense, so I'd have to charge quite a bit more.

I think that the reason others don't do it is not so much that they aren't brave enough, but that the whole reason for using a VPS is cost. 'premium' customers really are better off with dedicated servers.

For a build server, which builds my code base to confirm it complies with standards, Disk IO is supreme.

With the cost being around $68 + 50 (for 500 meg disk) the cost is still in cheaper then me rushing out and buying a rack server or blade server or something.

Anything over that price I can essentially go out and buy a refurbished blade server from HP (and still get all the warranties) cost effectively.

Perhaps you can offer a premium service with SSD at 0.20 a gigabyte or something. With the similar disk size associated with SSD this might be cost effective.

That is a really good point. physical co-location seems to start in the $50-$100/month range, so really, if I can't keep my offerings much below that, I'm not providing much value to the customer, as older computers with 4GiB ram can be had for next to nothing. (catch me at the right time and I might give you one. Anyone need a bunch of 2GiB FBDIMMs?) There is some value to taking care of the hardware for people, but really, people who place a high value on that are usually less technically oriented, and thus are support liabilities.

Maybe if you try to keep your pricing pretty similar (at $1/64MB) plus whatever margin it costs you to go to a 24 drive server chassis (and the extra 1RU) - lets say an extra $0.20/64MB.

Split these into 2.5GB (min) per drive-pair servers (although this is getting complicated). Approx. $50/month (with the $4 admin fee).

Then, let people pay for the drives they want. My suggestion, a setup fee equal to the price you pay for the drive (e.g. $280 for a RAID1 160GB, $720 for a RAID1 500GB) plus an ongoing fee equal to replacing these every 3 years ($7.80/month for the 160GB and $20/month for the 500GB).

You could also offer SSDs (in potentially single drives if you're happy not having RAID for SSDs).

hm. the problem with that is that non-standard-ness means more work (I've gotta keep different size spares, etc) - I guess I could build out standard systems with standard disk sizes; that might be the best idea. If I'm going with the high setup fee/low monthlies, that might even be a cheap way to get people 2TB disks.

But there are other problems with the high setup/low monthlies model. it's essentially a moral hazard for me; meaning, if most of what you pay is setup, I have incentive to encourage you to leave and then sell it to someone else. Now, I don't think I'd do that (Hell, I think I errored on the other side when I had a customer who paid a high setup and low monthly on a dedicated server... I ended up refunding part of the setup when I asked him to leave; he was getting more abuse complaints than the rest of combined) but it's always bad when my interests don't mesh with yours.

On the other hand, that pricing model does closely match my own costs, which I think is good.

Heh. I guess I could have you mail me your own disk and use that, but I'd have to charge more for that, as it'd be more work for me.

Happy to have a monthly fee as well, it's just your $0.10 per GB fee (for HDD only) is roughly 2 months to pay off a raw TB.

I'm happy for you to make a profit, but I would not consider paying for this in a bare-metal VPS environment - not unless I got unlimited scalability, no minimum storage commitments and redundant geographically dispersed backups (re: Amazon S3).

Ok, well, that's a good data point... Note, it would be 2 raw 1tb disks, as it's gotta be mirrored, not 1 raw 1tb disk to offer 1TB to a customer. (I tried offering unmirrored space a long time ago, and people get /really mad/ when the disk fails; and disk does fail.)

But yeah, I guess if you want to pay a lot extra you get your own dedicated server, right? so maybe I should just stick with what I've got until I figure a way to deal with disk in a way that doesn't add a lot of complexity for me.

And yeah, it sounds like I need to 'fly under' amazon by more than 20%. I should be aiming for more like 50% or less of what they charge.

maybe I should charge less because you are buying the whole disk at once even if you only use some? but on the other hand, that's more value for you, too; you know that you get the full performance available from that disk; none of it would go to anyone else.

hm. I think you are right that $0.10 per gigabyte is unreasonably high for. so I do have a server with 12 drive bays. I could sell 6x4GiB ram servers, each with 2x2TB drives. figuring $340 for a pair of 2tb 7200rpm hitachi drives purchase, and maybe $6/month for the .1 amp each they'd probably draw,

hm. so if I were to pay it off in four months, (which is about how long it takes me to pay off a server, not counting pre-paid plans or labor costs) I'd be charging $91/month for the disk, or around $0.045 per gigabyte, well under half what s3 charges.

I suppose I could also offer the disks raw (unmirrored) which would double the space (and potentially, performance) at the same cost, but that's probably a bad idea, at least until I get some sort of fast provisioning thing going, like amazon has (see, on amazon, when your ephemeral storage dies, you lose the data on it, but you can immediately re-provision another server, restore from backup, and continue your work. provisioning is anything but immediate.)

Leave a comment