Linode Simplifies Plans, Reveals CPU Priority
linode.com
linode.com
http://web.archive.org/web/20110713211922/http://www.linode....
It appears Linode removed the 768 and 1536 plans, renamed the 1024/2048/4096 plans to 1GB/2GB/4GB, and added an 8GB plan. They also added a row in the table showing CPU priority. The 512 plan is unchanged, as are specs and prices for the other three remaining plans.
Linode's "priority" seems like ex-Slicehost's way of saying "hey bigger machines get a higher proportion"... nothing really useful for figuring out exactly what you're buying.
And you can't ever really figure out what you have: things could be severely over-committed, and you'll never know until you get starved. So you can't just benchmark your way out of it.
There's probably no reference hardware beyond `cat /proc/cpuinfo`.
On a nearly-identical XenServer instance, it shows the same info, showing 2 CPUs but identifying the CPU as a 6-core Opteron.
From this, however, you cannot infer what percentage of those 2 virtual CPUs that you are going to get.
http://ark.intel.com/products/40201/Intel-Xeon-Processor-L55...
Amazon's CPU commitments are just as reliable as Linode's, but they seem to be less for the same dollar.
As for actual hardware, to go based on `/proc/cpuinfo`, some of the older instances I manage show up as Xeon L5420 CPUs at 2.5GHz, and the newer ones tend to be L5520 at 2.27GHz for what that's worth. They seem fairly consistent, and if you don't like what you get, just like AWS you can delete the instance and get a new one. You get refunded for your unused time.
Please notice that the minimum time block is a day. If you spin an instance, you pay for the whole day.
The real issue is hardware skew. We like to buy/sell and build on cloud as if it is a pure utility where every unit is equivalent, but every year processors change, go EOL, etc. As a provider you have to make a call about how much of that complexity you expose to the end customer. Some customers want complete transparency, which I understand, but the downside of that is hundreds of variations of pricing options and complications around managing heterogeneity (e.g. how do you represent simply how much available capacity there is when you effectively have 300 variations of the same 'size' instance).
Of all the component parts of compute, CPU is the one that changes the quickest. Disk capacity is easy to model, disk throughput has changed much at all (minus the introduction of SSD), memory is pretty stable (minus some increases in databus rates). All in for the typical instance in a multi-tenant virtual environment, the same today as in 2006, the two most vaguely defined attributes are cpu and i/o. With the increasing use of 10gigE as well as SSD, hopefully we finally push through the i/o piece. Not sure what it will take to get us there for a clean way to model and describe 'standard cpu' as a provider.
Also, if anyone has specific questions about Slicehost cpu priority handling circa 2006-2008 or Rackspace Cloud Servers cpu pre OpenStack, just ask and I'll be happy to answer.
The other issue, which I don't see Rackspace (or Slicehost or many others) addressing is the actual commit. It's fine to say "you get 2 cores", but then not tell me if those are reserved or if they might be sometimes overcommitted. This is a larger issue, because it means things might work fine... until they don't.
(I tried one provider out, and things worked swell in all our tests, but rarely in production, the entire VM would get paused for a few hundred ms ore more; something that wouldn't happen if there was a non-over-commitment guarantee. Right?)
1: "One EC2 Compute Unit provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor."
Regarding the guaranteed capacity, this is another one we spent a lot of time thinking about. At the time EC2 made the call of guaranteeing CPU share by hard-limiting the ceiling of performance by any VM. We (slicehost and RAX) took the opposite approach of weighting CPU by vm size when under contention, but allowing for burst-ability to full core power when the box was idle. That meant that in the case of low-ish utilization customers Slice/RAX VMs had a higher higher average performance but EC2 had more predictable performance.
It's a super interesting tradeoff. People would benchmark us and we'd come out way better one day but not so hot the next and that was the reason why. The flip side of that was that EC2 is stranding CPU capacity on physical hosts that are full of underutilized VMs. Even without us describing this well to the market, customers and workloads adjusted and customers and use cases migrated to each provider according to better fit (higher 'average' performance with tolerance of variability go to RAX, hardline predictable guarantees go to EC2). We had some video transcoding services that could not deal with the volatility and preferred lower performance that was predictable (and therefore kept a lot of workload on AWS).
A similar tradeoff where AWS did it one way and we did it the other is around the expectation for persistence on local disk versus ephemeral VMs. Persistence (what we did) was more like what people were used to. ephemeral is more 'cloudy'. EBS as well as hosted datastore services mitigated the difference, but the AWS approach required legacy customers and applications to re-architect for cloud and ours was more friendly to the transitional customers or people that just wanted classic feeling hosting on demand. The AWS bet was right in the sense that more of the usage of cloud (and everything actually) is in the future and not the past, and the choices we were making were more as a gap solution (but with eyes wide open about that).
The problem is how to make money at it.
Please don't take that as confrontational, I would just like to hear your opinion since you really are the authority here.
For us at Slicehost, we had an amazingly fortuitous start, due in equal parts to strategy and luck. We saw pretty clearly that rails was picking up steam really quickly and the hosting options were pretty shitty (shared hosting at the time didn't support the versions of ruby and rails people needed not to mention the memory hungriness of the framework and dedicated was still fairly pricey with 100-200/month being dirt cheap).
So we picked a really ripe initial niche market to spend time making ourselves visible in, which we did in forums, chat rooms, etc. The luck came in that we got some pretty vocal early customers who all had a great experience and evangelized us. That was lucky because either of those factors could have easily gone the other way. They could have been quiet customers or we could have had early blips in service (we had plenty of later blips, we just had a nice patch of initial smooth sailing).
You could test (or run in production) for a month, and every day things work fine. Then for whatever reason (extra sales, internal policy changing, other customers' work profiles increase) you end up CPU starved.
Without a commit/guarantee, "Past performance is not an indication of future results."
Shouldn't it be four variations? (Or maybe only two if you count a tick and a tock as the same.) Would it really kill providers to offer something like Nehalem-1C-4GB and SNB-1C-8GB?
Making major purchases once a year and always getting the new stuff, you get 4 processors over the life of the hardware warranty (4 years, which I also believe is the timeframe for capital depreciation).
Purchasing 2x a year, you'll end up with 8 CPUs in the environment unless you opt for the 2H purchase to be the same as the 1H purchase.
If you're buying new hardware every quarter, those agreements become more important if you want to keep your environment homogenous.
If you're running thousands of servers, is it better to pay a premium on your hardware to be able to get the same machines for the entire year, or do you want to incremental improvements and environment fragmentation resulting from updating? Different models sometimes have different utilities to manage them, and now you're writing abstraction layers to handle mass updates.
I agree that predictability of performance requires dedicated hardware. I'm just going from the IT perspective.
Any interest on your part in starting another VPS hosting company? I figure if you did it right once, you can do it again. You'd likely have a customer in me.
Not in the cards for me. Technically still under non-compete, but even if that weren't the case at this point I am connected to so many other hosting providers that I'd rather just support them in doing the right things and work on other stuff. Right now I run a startup accelerator and am spending my time as a full time seed stage investor.
What's your beef with the Rackspace service right now? As far as 'big' providers, besides the obvious AWS and Rackpsace, you should also consider SoftLayer and Joyent, and depending on what you are doing the PaaS providers are all getting pretty solid now - Heroku, AppFog, DotCloud, GAE even Azure (node is a first class citizen on Azure now).
If you want something that feels really VPS-y that is run by a Slicehost-style team, Linode is a definitely a solid option (mentioning them first since this is their thread). I also am a fan of DigitalOcean (they went through our accelerator and I've spent a lot of time with them), and 6sync is run by Mario Danic who was a super active early Slicehost community member.
Unless that's changed, that would mean that all instances running on a given machine share the same CPU Priority, there will just be fewer instances demanding service from the CPU(s) the larger the plan you have.
...so wondering if that's what CPU Priority means, or if Linode is about to mix instance sizes on same hardware?
And maybe I'm just ignorant on the topic, but what exactly does CPU priority do here? I understand basic linux process priority (like the 'nice' command), but how exactly does CPU priority behave on linode. Searching through their docs, I couldn't find anything.
EDIT: to maybe answer my own question, maybe this is the Xen credit schedule? http://wiki.xen.org/wiki/Credit_Scheduler
I'm assuming that meant access to part of a processor, but how does that work with 4 CPU and 16x priority? (I'm working on the assumption that 1x priority ~= 1 core.) Of course, my assumption is probably wrong - just curious how this affects the load on a given server and how the VPS interacts with other VPS's on that node.
It's quite easy to get a decent micro HP server (even with SSD storage) within $1000, which would cost $150.00 - $300.00 a month for a equivalent plan on Linode. Suppose you upgrade your server every two years, the monthly cost of the server is less than $50. You get dedicated CPU time and I/O, permissions to managing everything.
Internet bandwidth might be a problem. But let's put ourselves in the 2 or 3 years future. What if you already have Gigabit Internet like Google Fiber for $70/mo?
And you get other benefits for owning a server in your house. Since it's connected to your home LAN, it can be used to help build a smart home, control smart sensors/cameras, or serve as a media server.
Am I missing something here?
You are missing a lot of things.
1. Linode et al buy top-end hardware. It is, generally, going to be more reliable.
2. Linode et al have redundancy in multiple parts of their system. Redundant power, redundant networking, redundant disks, redundancy all over the damn place. A server sitting in a hallway closet does not have these advantages.
3. Finally, you assume that your time is worthless; as in having a $0/hr value.
I charge a lot more than $0/hr for my time. If, in actual fact, I could successfully farm out my little Wordpress blog network to a reliable host who charged a lot more than Linode, I would do so in a heartbeat because it makes financial and hair-pulling sense.
I farm out the management of physical servers to Linode for the same reason. I am nearly 32, my time is expensive, my patience is short and my interest in hardware has long since abated because I have other shit to do. Linode is a bargain from my POV.
Let's start with point #1. You're paying $1000 upfront. With a VPS, you can pay a few bucks per month to get very decent performance (assuming you go with a LEB instead of a overpriced Linode). You assume that you could use your home internet, but the reality of that is that almost every consumer ISP on the face of the earth won't allow customers to run servers. Can you get away with it? Usually, yes. Is it a good idea? Not at all.
Why spend the equivalent of $50/mo? You can get budget dedicated servers for that price range, with a heck of a lot better network resources, and no need to maintain your own hardware.
Really, there's a ridiculously long list of reasons that running any public-facing server from your home is a horrible idea. Take the game server I used to run as an example — I'd be completely and utterly screwed if my home connection was getting 4Gbps DDoS attacks, yet with it being on a remote server, I have options to mitigate it or even ignore it (nullroute, yay).
Edit: There's a ridiculously long list of reasons why home-hosting is bad.
The last mile is a huge problem. If we all get gigabit fibre to the home in a few years? everything will change, and of course, you will be right.
But, here in reality, if you want a network connection with a decent upload speed and decent reliability, you are paying a kilobuck or more a month. 'round here, it's usually $3-$5K/month for 100 to 1000Mbps (Up; you can get 100M down from comcast for like $400, but that's only 10M up.) and this is silicon valley. the place is lousy with dark fiber.
(It's better if you live in Santa Clara or Palo Alto; both places have municipal fiber. But you are still talking tens of kilobucks to get the fiber from the street to your house, and that's if you are very close to the city fiber, and then you've gotta buy bandwidth at a datacenter.)
But yeah, all that said, there are some places with decent last-mile internet; sacramento has had surewest FTTH for far longer than google has. Some areas, Verizon does it. Maybe we will all have it in a few years? It sure would be nice. But I ain't holdin' my breath.
\* I moved to gmail, not because of cost, but because I got tired of managing the spam filter.
For my needs, $30/mo was about as much as I'd spend on a server to host mine and a few friend's blogs, some photos, and some remote services. $40 is too much for me and the lower plan just doesn't have enough RAM to be interesting.
So now my options are 1) find somewhere else, or 2) backup my data and rebuild the box in place.
0 - I manage a few Linode 768s including my own. 768 was a great size for a few small blogs and a low traffic Rails site, or a larger traffic blog.
Additionally, I've always found the Linode support folks to be fairly accommodating, so maybe it's worth asking if they can still provision 768s.
EC2 is good but their spin-up time is crap.
Though same-kernel is obviously a security reduction, the speed is far better: I for one can't wait to see more LXC and other lightweight virt stuff being made available with real cgroup-level guarantees.
Was that PV vs. HVM by any chance?
(We setup a few vps's with rackspace and have been happy so far.)
Prgmr you buy a machine send an ssh key they set it up and send you the bill. Then you get a login console at xxxxxx.prgmr.com and login and setup a user or deploy your own OS using centos recovery. But you can't create and destroy servers like linode or aws or rackspace.
I'm switching to Azure because their prices are reasonable and you get the full management experience.
Here's some data comparing the 1GB plans:
Linode 1GB: http://serverbear.com/13-linode-1024-linode
Prgmr 1GB: http://serverbear.com/1709-1024mib-prgmr-com
I am very happy at the moment managing two Linode accounts, one for personal use and another for an organization I am the IT guy for.
I'm not surprised that a Pi is similar in overall performance (I have a Pi as well).
https://www.edis.at/en/server/colocation/austria/raspberrypi...
I've got two Raspberry Pis coming to me in the mail, so I'm thinking I might do it.
http://serverbear.com/benchmark/2012/09/11/ENc5kl1X2ZciF0LZ
http://serverbear.com/benchmark/2012/09/08/gcMHO1PDOY6Crq2W
Compare with the Micro performance:
I've had fewer issues with my Linode hosts than with EC2. Granted, the services offered by EC2 are much more advanced -- VPC, routing, firewalls, NAT, etc.. so perhaps this is to be expected.
The best thing about Linode is the support: if an issue happens they open a ticket with me and if I reply with questions / clarifications I'm replied to within a couple of minutes. Their pricing is a bit higher than elsewhere but after having shitty experiences with another company (vps.net) I decided to bite the bullet and switch and haven't regretted it since.
The billing isn't as flexible as EC2 (but then I guess they're different markets) however you get pro-rated payments to the day. So a server up for 10 days will cost 33% of the monthly cost and they refund the amount to you in account credit when you remove the server. Flexible enough that it can be helpful when you just need a server for a couple of days. Oh and their nodebalancer product is great.
I have seen complaints about one of their datacentres having some issues (Newark) but I can't comment on that as I use their London datacentre almost exclusively.
I am currently hosting one major site running Wordpress on my Linode box which gets roughly 17,000 uniques per month coupled with a plethora of other domain names and blogs (about 10 other sites) they don't get as nearly as much traffic though I have running on their 512mb plan and I haven't hit any kind of resource limit in terms of CPU, space, memory or bandwidth just yet. I am pretty amazed a small 512mb configured correctly can handle what I've thrown at it.
If you're new to managing your own server, get their $5 per month backup service (trust me, you'll need it). Because as you're learning, you're going to potentially destroy and break your site a lot and it's easier to revert to a backup than it is to decipher and fix Linux configuration issues when you have no idea where to start or even search on Google. Restoring from a backup is pretty quick as well.
My limited experience with VPS hosting (I've dabbled with Rackspace before and a Mediatemple Dedicated Virtual server as well) is pretty limited, but I have yet to see an affordable host allow you to destroy, create and rebuild instances so quickly like Linode allows you too.
About CPU priority, Linode never kept it a secret. For the small VPS (512MB RAM), you get a guaranteed 1/20 of a 4 core XEON processor and it scales linearly with each plan's RAM.
As explained on their FAQ, their machines have 8 cores each and house 40 512MB VPS.
I was hoping this change would rectify that, wishful thinking I suppose.
For the longest time I lived on a single 512 linode, and ran 6 mid sized Django sites, all with postgres and redis on the same machine. I knew how to keep lean (taking advantage of varnish, nginx, uwsgi) and even used that linode for a ongoing mumble server and irc. I've since got more Linodes (grew with more sites) and split up the responsibilities, but I still remember getting a lot of performance out of that one little instance.
Also, Linode brings other features to the table, like a great API, easy to use dashboard, free nameserver, and availability in various geographic locations. Granted, my opinion is biased - I'm a really happy customer there. But I have had experience managing other machines on Slicehost (horrible experience) and EC2 (decent enough, but doesn't make me smile).
An API sounds cool, but I have no use for that. The control panel is excellent, I have no reason to use Linode instead. BuyVM has free DNS (and 5GB of free backup space), so no reason to use Linode over them. BuyVM has SJC and Buffalo locations, sure, they could use more, but I don't need multiple servers. I've stuffed quite a bit of stuff onto my VPS, and performance has been amazing. They've even absorbed large DRDoS attacks for me with the filtered IPs, and were willing to accommodate my unusual situation (the DRDoS source slaves didn't realize the source IP was spoofed, and sent abuse reports to my provider, which were useless as they were the ones attacking me) — after explaining the situation to them, they agreed to ignore any further reports from said network. I currently have three low end virtual servers for (a lot) of things, and my favorite out of all of them is the BuyVM VPS. So, at least in my case, I can see no possible reason I'd want to go with a provider that is 2x the cost, has historic security issues, has been reported to be unwilling to deal with any sort of DDoS attack whatsoever beyond a nullroute, and offers inferior performance and resources.
I actually don't like the idea of getting a OVH budget dedi over a VPS for any type of production site, it's just not as stable.
My ideal VPS provider would be somewhere between Heroku and Linode, offering self-managed hosting when you want it, and fully-managed hosting where you need it.
So what is the appeal of Linode? That you can upgrade to a faster server quickly?
- If you hardware says goodbye, your server says goodbye as well. It needs to be physically rebuilt. With Linode, maintenance time means your server shuts down here and reboots somewhere else.
- Can you reinstall your server, pick a new distro automatically?
- Can you add more memory or more storage to your server with a click?
Presumably as long as the server your VM sits on has more memory than your VM, you can increase memory easily. But the maximum might only be what a dedicated server would have given you from the start?
Edit: I just checked, seems Hetzner has a server with 16GB RAM for 49€/month (64$). The maximum Linode VM with 8GB sets you back 320€/month.
It seems the 49€ is the cheapest standard Hetzner server atm, but you can get cheaper ones via their auctions. Of course then if you need more memory you have to move server, not sure how complicated that really is...
Edit: overuse of the word "host"
For those that don't remember hackers managed to get root access to several VPS via some Linode vulnerability. Didn't bother to let customers know. Didn't bother to update their status/website. Didn't bother to tell anyone what they've done to fix it. Compare that with CloudFlare: http://blog.cloudflare.com/post-mortem-todays-attack-apparen...
Linode continues to be a recurring example of how not to behave as a vendor.
Aside from the issue you mention, what else have they been doing wrong?
And the fact is that every single day that passes without them updating their security/disclosure policies and showing some commitment to transparency is another day they will be classed as "untrustworthy".
http://status.linode.com/2012/03/manager-security-incident.h...
You were very active in the very forum thread wherein the announcement was posted by another customer, not half a dozen posts above you, so I find it hard to believe this falsehood is not intentional:
http://forum.linode.com/viewtopic.php?f=20&t=8509
Considering the grandstanding you did in that forum thread and are continuing to do here with your overly aggressive (and false) commentary, I question whether you have some kind of overt agenda against Linode that is clouding any message you might have. Every company makes mistakes, and Linode, in my opinion, handled this one as appropriately as they could have; were it Amazon, who are far more secretive (particularly with outages), we might have never known.
I don't think that's an unreasonable complaint. I'm still a pretty enthusiastic Linode customer, but that incident bothers me a little bit too. I have to wonder if they would have addressed the problem publicly at all if the story hadn't made the rounds on the social news sites.
You shouldn't question his motives unless you have something more solid to go on than, "unhappy former customer".
Usually, I side with "better eventually than never".
I agree on the root complaint, and it is valid, but OP did pretty directly say that Linode did not notify customers about the issue, implying to this day. That's demonstrably false, and I don't like to see Hacker News threads turn in to a whirlwind of fairy tales.
My conclusion regarding OP is based largely upon his behavior in the forum thread I linked. I actually remembered him by name when I saw his comment, which should say something.
You linked to the email exchange between Linode support and one of the affected customers. You know that Linode already had an idea that they had a problem before the rest of their customers found it. Do you think it would have been so unreasonable for Linode to at least put up a message on status.linode.com, "We are investigating an incident of unauthorized access to one of our customer Linodes, we will update this as we investigate it"?
And I don't read that implication from taligent's comment here. I think it's obvious that he's saying that they didn't bother to let their customers know when the incident occurred.
Basically: he thinks they didn't handle the disclosure on that matter in a way befitting its seriousness, and he thinks that they've done nothing to show that they'll handle it differently in the future. I agree on both counts. As he said in the forum thread, what makes this so frustrating is that Linode has been so spectacular in every other regard.
He's right also to point to the CloudFlare post-mortem as an example of Doing It Right. Surely you see the stark difference between CloudFlare's handling of their incident and Linode's? We still don't know the exact nature of the compromise (former employee? Did Linode have an externally-accessible customer service interface? What happened), nor do we have any idea what they did about it, other than that they say they "will be reviewing our policies and procedures to prevent this from ever recurring" -- an extremely wormy statement that will still be true even if they choose to change nothing at all.
I don't like to see HN threads turn in to a whirlwind of pointless personal attacks. Let's just discuss the facts, OK?
What you're interpreting from his statements certainly isn't obvious, as it's just the way that you interpreted it. I interpreted it differently, using only the words that he typed and not filling in any of my own as you have -- I think you realize that, too, since you italicized your additions.
> (I wonder now which one of the users you were in that forum thread. sednet?)
I do not post on the Linode forums.
Fine, you're right; I might have been a little harsh on taligent, but I'm perpetually annoyed by crusaders who latch on to one mistake so strongly that the surrounding facts of the mistake begin to distort in their memory. If you're going to have a problem with Linode, back it up with the truth -- we get enough of alternate reality with politics.
I think it should go without saying that we should read other users' comments as charitably as possible. You say that my reading of his comment is "just the way that [I] interpreted it", but then you bless your interpretation of his comment as being "the black and white facts".
But English is messy. It carries nuances and context and hidden clues. Worse still, everyone has the attention span of a coked-out gnat now. Brevity is supposed to be the most important property of a statement, so we don't go around explicitly writing in all of the nuances and blanks and context. Thus it's natural to omit something like, "when the incident occurred" from the end of every statement. (Which, by the way, I italicized as emphasis; even a cursory glance at my comments page would have clued you in that I do that habitually.)
Your interpretation assumes (emphasis again) that he was deliberately lying.
You called someone a liar.
Publicly.
Based on your interpretation of what they said.
Whereas I assume that it's more likely that he was simply being brief.
Maybe you're right and I'm wrong. But, I'm unwilling to assume that someone else is a liar when there is clearly room for misinterpretation of what they said, just as I'm unwilling to assume that anyone that I'm talking with here is an idiot. (Although, I'm becoming more willing to assume deliberate obtuseness and argumentativeness ... not apropos of anything in this thread.)
I don't want to brow-beat you for your reply to him, but you're still thinking of him as a "crusader", and you're still assuming that the facts are "distorted" in his memory. When I asked to stick to the facts, I meant that it would have been sufficient to say simply that Linode notified the 8 affected customers and posted a statement to their site about the incident.
That would have left room for both you and him to be right, instead of accusing him of grandstanding and being a liar and a crusader and so on and so forth.
And most importantly: whether or not we agree on his characterization of what happened, he does still have a legitimate point. Linode did not handle that incident admirably, it can be contrasted starkly with the way that CloudFlare handled their incident, and Linode is still compounding their initial error by not taking steps to correct their handling of future incidents -- all points from my previous comment which you completely ignored, in favor of continuing to attack another user here.
HN needs to calm down just a tiny little bit.
Sorry for picking on you today.