New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
VPS SHOWDOWN: Waveride vs VPS Database vs Iniz vs Prometeus vs domVPS
I've collected uptime statistics from the five above-mentioned (and LEB featured) VPS providers over the past 2 weeks and put them head to head. I think I've produced something which prospective buyers will appreciate - unbiased and relatively scientific.
Please follow the link to read my article:
I hope you find it useful!
Comments
I would hate on more if they had performed as poorly or had staff which responded in the same way.
You may be right about enabling a setting or two. I don't know OpenVZ like the back of my hand, I'm a Xen admin. But I do know running the same kernel for every "machine" invites huge privilege escalation risks.
I can't take a furfag's opinions seriously, sorry.
Oh god you're one of those ping retards who file support tickets versus sending a traceroute because of your "100% network uptime" dedicated server
-> Trash
I recorded 2 weeks of data in the mere course of doing DNS failover. I mentioned that I also monitor these machines with Icinga from a second location.
I brought the outages to the attention of the providers because that's what you do when you're paying for a service and not getting it. It was also a good way to get a feel for the technical support staff at each provider. The level of service you can expect from an ISP is an important factor in deciding on whether to stick with them or not.
@foxpaws contacting the provider if you experience connectivity problems is the right thing to do. But not including a traceroute is not so good - without this information it is hard to diagnose what the problem was, especially if it is something transient that already went away.
I would say 99.5% of the "VPS DOWN!!!!" ticket I see are people running ping for like 500 - 1000 pings.
When I request a traceroute / MTR, I've seen some with clear packet loss and some of these folks, not saying you fall into the category, cannot even read a traceroute / MTR properly until I explain "your packet loss is like you driving on a flat tire. The further you go, the tire is not going to get better"
That is fair. I have experienced my share of apparent outages due to peering issues somewhere down the chain that had nothing to do with the provider.
I will bear that in mind in the future.
I understand, and this is definitely not me. The script the data comes from pings only four times, once every five minutes. I think my host monitor is configured the same. I never contacted a provider until I was sure the problem was persistent.
I think, despite all the problems with a straight-up ping monitor that COULD crop up at any one time or another, the length of time the data was recorded for and the patterns which appear speak volumes.
Taking your valid criticism into account, and seeing how the major DNS failover providers ping from more than one location, I could monitor all VPSes from each other. Taking a traceroute snapshot every five minutes is not reasonable but would it bear the burden of proof if four VPSes all over Europe agree one is down?
multiple +1's :OpenVZ can be stable and reliable if the provider knows what they're doing and proactively monitors their system for abuse.
This isn't limited to low cost OpenVZ VPS's. It also occurs with low cost KVM and Xen. Some low cost providers do a great job of limiting abuse and act immediately when an attack occurs. On the other hand there are many providers who don't even know the difference between DDoS and DoS (and there are also a few providers who will call any outage a "DDoS attack" when the real reason for the outage was they don't know what the f**ck they're doing).
True in many cases. Some dude or some child with limited technical skills who would be lost if they didn't have the turnkey software holding their hands, and who is "CEO" of a "company" that isn't a legal entity (and when asked why their business isn't incorporated will usually answer "it costs too much in my state to incorporate a business", "I don't want to deal with all the paperwork involved in operating an incorporated business", "I'm not old enough to form an LLC yet" , "I'm a moron and the thought of limiting my liability if my business is sued never entered my mind", etc)
...or using a service like Pingdom as their only source of information when they scream "MY SERVER WAS DOWN!!!"
Absolutely, low cost anything. Throw in anonymous PayPal payments and it's a playground.
It still doesn't help diagnose the problem. But you can modify your monitoring script to do and record a traceroute only if the monitored target appears to be down, i.e. if there was no reply to ping.
That's true, and I think that's where some of the confusion is coming from.
Beyond using the outages as a valid reason to get to know their technical support I don't plan on helping them solve any problems in the future.
My interest is in having disposable VPSes that can go down and back up without my intervention. The objective of my monitoring is to determine the least reliable providers and drop them in favour of more reliable providers to get the most bang for my buck and the least dropped connections.
If a provider is down as often as the worst offender on my list it's not worth my time to contact their support vs. migrate to a new provider and begin to feel them out.
Why not just use nodeping with 1 min delays?
It's Nodeping, like any other of those unreliable providers that LEB folks use to go at the end of the month and file SLA claims complaining about "losing money"
Why pay for something you can do yourself for free?
I'm already more than half done:
http://foxpa.ws/2013/05/28/crossfire-ping-monitoring-part-1-the-setup/
http://foxpa.ws/2013/05/28/crossfire-ping-monitoring-part-2-collecting-the-data/
This is a fun project and you'll get to watch my stats in more-or-less real time once I'm done the front-end.
HAHA! If you're "losing money" on a $10 VPS you're not losing enough.
How is it not reliable? If it's not reliable then which monitoring service is reliable?
You should do this every minute and with double checks.
They can't read a SLA properly, get pissed when its like less than $2 SLA credit then off to the WHT turbo posting they go!
http://foxpa.ws/crossfire/
Pretty nifty visualization, huh? Right now you can see what appears to be a problem between Iniz and Prometeus (I don't know, I haven't tracerouted yet).
And VPS Database is dropping packets from every VPS like a leaky colostomy bag.
Vindication, perhaps?
I'm going to add the ability to search a date range then publish the source.
It would be better if you compared to other well known brand as well (like linode, knownhost, etc) and see if its really bad or normal. my guess is uptime will be similar
I'm about to publish the source for crossfire ping monitoring so anyone can run their own, no reason not to monitor other hosts with it.
It might even be fun if we got a bunch of VPS owners together and added them to the pool, we could gain great insight into routing issues around the world by looking through the eyes of each.
Every location is always testing every other location, all the time. That's the beauty.
That's the issue I've had with "uptime monitoring" services: if they host on crap and check from crap, why do you expect otherwise crap results? Uptime Robot is one of the worst.
That's a good question, and there's no reason NOT to run crossfire from not-crap. But I was doing monitoring on two very not-crap locations and look at the flack I got
The point of crossfire is you're getting a second, third, fourth and fifth opinion. You're right, it would be a great idea to extend the pool to trustworthy, reliable servers. However, if two or three of five crap servers are reporting host XYZ is up then I think it's safe to say there's a routing issue - likewise if four or five crap servers are reporting host XYZ is down (excluding itself) then I think it's safe to say the farthest the problem could be from the provider is their DC.
Additionally, if you look at the current data in my little crossfire frontend we can see that not only is VPS Database having trouble getting to the other VPSes, the other VPSes are having trouble getting to them - but not a lot of red. This means that their connection is probably crappy/their server is oversold/they are under attack no matter how you slice it. Or they have the slowest-replaced flaky switch in the world. It also explains why - when I was only testing from one of my regular servers - so many 0-out-of-4 entries for VPS Database were made. If it's dropping 3 packets to a European VPS it is likely going to drop all 4 on the way to North America.
Did the vps turned off / down? Or is it just the network?
It looks like you're from Prometeus? From the way crossfire sees things only Iniz is having trouble talking to Prometeus, and vice versa. The VPS is fine, I can ping it from everywhere except Iniz just fine - and vice versa.
Here is a traceroute from Iniz to Prometeus:
2 as198203.dataplace.nl.proserve.nl (83.96.226.101) 0.338 ms 0.385 ms 0.266 ms
3 te1-2-vl7.cr1.nkf.nl.proserve.nl (80.84.254.73) 1.526 ms 1.598 ms 1.592 ms
4 213.19.192.5 (213.19.192.5) 1.559 ms 1.553 ms 1.546 ms
5 ae-51-51.csw1.Amsterdam1.Level3.net (4.69.139.153) 16.701 ms 16.746 ms 16.659 ms
6 ae-57-112.ebr1.Amsterdam1.Level3.net (4.69.153.189) 16.659 ms ae-58-113.ebr1.Amsterdam1.Level3.net (4.69.153.193) 16.667 ms ae-59-114.ebr1.Amsterdam1.Level3.net (4.69.153.197) 16.627 ms
7 ae-48-48.ebr2.Dusseldorf1.Level3.net (4.69.143.210) 16.653 ms ae-46-46.ebr2.Dusseldorf1.Level3.net (4.69.143.202) 16.615 ms 16.599 ms
8 ae-23-23.ebr1.Dusseldorf1.Level3.net (4.69.143.189) 16.581 ms ae-24-24.ebr1.Dusseldorf1.Level3.net (4.69.143.193) 16.734 ms ae-23-23.ebr1.Dusseldorf1.Level3.net (4.69.143.189) 16.589 ms
9 ae-48-48.ebr3.Frankfurt1.Level3.net (4.69.143.178) 16.682 ms ae-45-45.ebr3.Frankfurt1.Level3.net (4.69.143.166) 16.566 ms ae-48-48.ebr3.Frankfurt1.Level3.net (4.69.143.178) 16.665 ms
10 ae-93-93.csw4.Frankfurt1.Level3.net (4.69.163.14) 17.032 ms 16.626 ms ae-83-83.csw3.Frankfurt1.Level3.net (4.69.163.10) 16.625 ms
11 ae-81-81.ebr1.Frankfurt1.Level3.net (4.69.140.9) 16.589 ms ae-61-61.ebr1.Frankfurt1.Level3.net (4.69.140.1) 16.576 ms ae-91-91.ebr1.Frankfurt1.Level3.net (4.69.140.13) 16.632 ms
12 ae-1-14.bar2.Milan1.Level3.net (4.69.142.193) 16.624 ms 16.617 ms 16.615 ms
13 212.73.241.130 (212.73.241.130) 17.706 ms 17.473 ms 17.579 ms
Here is a traceroute from Prometeus to Iniz:
2 gw-cdlan-2.prometeus.cdlan.net (217.171.46.253) 0.447 ms 0.560 ms 0.642 ms
3 212.73.241.129 (212.73.241.129) 1.363 ms 1.332 ms 1.328 ms
4 ae-14-14.ebr1.Frankfurt1.Level3.net (4.69.142.194) 15.224 ms 15.261 ms 15.254 ms
5 ae-71-71.csw2.Frankfurt1.Level3.net (4.69.140.6) 15.246 ms * *
6 ae-93-93.ebr3.Frankfurt1.Level3.net (4.69.163.13) 18.955 ms ae-83-83.ebr3.Frankfurt1.Level3.net (4.69.163.9) 16.381 ms ae-63-63.ebr3.Frankfurt1.Level3.net (4.69.163.1) 15.304 ms
7 ae-45-45.ebr1.Dusseldorf1.Level3.net (4.69.143.165) 24.091 ms 15.251 ms 21.438 ms
8 ae-21-21.ebr2.Dusseldorf1.Level3.net (4.69.143.182) 15.243 ms ae-24-24.ebr2.Dusseldorf1.Level3.net (4.69.143.194) 15.298 ms 15.239 ms
9 ae-48-48.ebr1.Amsterdam1.Level3.net (4.69.143.209) 15.263 ms ae-47-47.ebr1.Amsterdam1.Level3.net (4.69.143.205) 15.285 ms ae-48-48.ebr1.Amsterdam1.Level3.net (4.69.143.209) 15.280 ms
10 ae-59-114.csw1.Amsterdam1.Level3.net (4.69.153.198) 15.284 ms 15.306 ms ae-57-112.csw1.Amsterdam1.Level3.net (4.69.153.190) 15.248 ms
11 ae-1-51.edge3.Amsterdam1.Level3.net (4.69.139.137) 15.246 ms 15.231 ms 15.225 ms
12 213.19.192.6 (213.19.192.6) 15.623 ms 15.646 ms 15.588 ms
13 te5-5-vl7.cr1.dp.nl.proserve.nl (80.84.254.74) 16.848 ms 16.783 ms 16.867 ms
14 proserve.dataplace.nl.as198203.net (83.96.226.98) 20.390 ms 20.418 ms 20.310 ms
15 nl-3.routingdns.net (176.56.227.148) 16.651 ms 16.627 ms 16.631 ms
Also tried HTTP, nada.
I've published the source for the front-end at http://foxpa.ws/2013/05/28/crossfire-ping-monitoring-part-3-the-presentation/
You can find my post on that at http://lowendtalk.com/discussion/10806/crossfire-ping-monitoring
I hope this allays any fears that I'm just some prick with a ping problem.
I know I was stinging in my review but I think now that the data is in my claims have been vindicated, moreover I hope that Crossfire can benefit others.
Agree with one fact, completely, OVZ is not stable enough.
We have about 30 OVZ servers, in total used to have 1-2 reboot a month (server lock-up, reset needed), after the last patch for the escalation vulnerability, we have 2 a week.
Still some servers never go down, so I believe it is the processes combination that triggers a lock-up, probably some race conditions.
Had 300+ days uptime on some before the patch, now I doubt any of the servers will reach that.
There is also the weird loopback problem when some services fail to connect to loopback if the ip for localhost is 127.0.0.1 but work for 127.0.0.2. This was also introduced with the last patch.
OVZ is great in many aspects, however, it is the inherent design flaws that will make it unstable, no matter the effort put into is.
Simply put: need stable ovz ? Go with .18 kernel. Less features and low compatibility with some software (especially java). Need more features ? Go with .32, but it will die on you a few times.
Need stability and compatibility ? Go with Xen-PV. Very low overhead, own kernel, proven and reliable technology.
KVM comes later because of a bigger overhead, even with Virtio, but can run almost any os.