Testing Out Vultr
-
Here is what I have responded to them:
"That's not an encouraging answer. How many other stability issues exist and are ignored because it isn't procedure to fix them? What certain circumstances cause this issue? This is a one day old, vanilla CentOS 7 build. What have I done wrong that Vultr, as provided, is not stable? "
-
And here is the documentation that they pointed me to. Notice that the "why this happens" is just "this shouldn't happen." Um, okay, but it does happen. So let's stop pretending that it doesn't and deal with reality.
https://www.vultr.com/docs/configuring-static-networking-and-ipv6-on-centos-7
-
And here is the final followup. They definitely feel like they are just avoiding giving an answer. Don't know if they just don't know or if they just are refusing to talk about it:
If you are having issues with the DHCP configuration, switching to a static configuration will fix your issue.
IPv6 is one of the features which may interfere with DHCP.
I was using their new IPv6 Beta feature. So maybe it is my fault for testing that. Did not realize that it might break IPv4. Seems like, if they felt that that were true, that they would mention that and not just say that sometimes their platform isn't stable. If they could demonstrate that IPv6 being turned off would fix the issue, I imagine that they would be all over that. This feels like general instability to me.
-
Moved the system to static and the problem has returned!!
-
Definitely some serious instability going on here. How much time is it worth putting into troubleshooting when I've not seen any real advantage to the platform? On its own, it isn't bad, but it is the same pricing as Digital Ocean who has had zero stability problems over months of testing and has every feature the same, except for Windows support, which is dramatically more expensive anyway?
-
Lost our network connection again. This experiment is not turning out well. And apparently their monitoring of the issue failed too since they said that they were watching it and they did not catch it.
-
Now having issues that their console is not working. So that issue is definitely not VM related.
-
What's annoying is that they closed the ticket without fixing anything. Apparently they just accept instability as business as usual. Sound familiar? Not going down that road again. Even for a lab, this is too unstable and way too expensive.
-
I think Vultr has t3h vultures circling
-
@scottalanmiller said:
@JaredBusch said:
@scottalanmiller said:
The support custom ISOs as well, which is a nice feature.
This means things like Elastix should be a snap to setup on their infrastructure.
Absolutely. And CentOS 5 is available too, for things like Elastix 2.
Is Elastix like FreePBX better installed from their own custom ISO?
-
@scottalanmiller said:
What's annoying is that they closed the ticket without fixing anything. Apparently they just accept instability as business as usual. Sound familiar? Not going down that road again. Even for a lab, this is too unstable and way too expensive.
Well, they sound a more and more like the Canadians@Cost.
Their ticketing system doesn't email you when they reply. I didn't know they'd even replied until typing this.
It's still free to send emails internationally, right?
-
@nadnerB said:
@scottalanmiller said:
What's annoying is that they closed the ticket without fixing anything. Apparently they just accept instability as business as usual. Sound familiar? Not going down that road again. Even for a lab, this is too unstable and way too expensive.
Well, they sound a more and more like the Canadians@Cost.
Their ticketing system doesn't email you when they reply. I didn't know they'd even replied until typing this.
It's still free to send emails internationally, right?Ha ha. To be clear, Vultr emails you, CloudatCost does not
In case anyone was reading that and wondering. C@C doesn't normally need to email you as normally they just don't respond. -
@Dashrender said:
Is Elastix like FreePBX better installed from their own custom ISO?
Yes. There is a process to download the RPM and mount it like a repo and then install from there, but I never had that turn out well.
Related: I would never use Elastix in the current form. The only released version is 2.5 and it is ancient, running on CentOS 5 and barely updated freepbx.
-
@JaredBusch said:
@Dashrender said:
Is Elastix like FreePBX better installed from their own custom ISO?
Yes. There is a process to download the RPM and mount it like a repo and then install from there, but I never had that turn out well.
Related: I would never use Elastix in the current form. The only released version is 2.5 and it is ancient, running on CentOS 5 and barely updated freepbx.
So what do you like?
-
@Dashrender said:
So what do you like?
FreePBX or PBX in a Flash.
If you make me pick only one... I would say PBX in a Flash, but only because I have used it more and it is an older distribution that has been very well supported for years. -
We need a new thread about the pros/cons of each distro.
-
We are actually giving Vultr another try. They have exactly a setup that we need for a storage workload, so testing it out now.
-
Interesting to hear about the DHCP issues you had, I have been running about 7 VMs through them over the past few months - 5 CentOS, 2 Debian - and haven't had any issues myself. It sounds like I'm very lucky to not have needed support so far!
One thing to note - they put a hard limit on the number of VMs you can spin up at first... I think it's around 4 or 5 VMs? Once you hit that limit you just need to submit a ticket asking your limit to be raised. Annoying but I suppose I can understand the need for it...
-
For one reason or another, something monumentally stupid happened to one of my clients' Vultr instances yesterday that took it down for far too long. When we went into the clients' Vultr console to check on its status, the VPS was stopped with a message that it was down due to some emergency thing and technicians were working on it to bring it back up ASAP. Okay, cool, but I saw that at 4pm and it stayed down until almost 10pm when I submitted a support ticket through the client's account asking for an update on the outage.
Right after submitting the report, the VPS hosting their webserver went from "stopped" to "running". It started responding to pings but wasn't serving the website yet, so I tried viewing the console and got in at first but then got a connection error that kicked me out and kept coming back when I tried to reconnect. Attempting to restart the server through the console was met with an error message stating the server timed out so it couldn't be restarted. I was about to try an SSH session when the website loaded in my browser and seemed to be working fine again. I was able to log in, make a full backup, and download it. Shortly afterwards the support ticket was updated with a message noting that the instance should be back up and running now. The entire time, all of my own VPS instances on my account were running just fine.
I'm glad the server came back up, of course, but I can't shake the suspicion that human error was ultimately responsible for the length of this particular server's outage. Though possibly a coincidence, it is pretty fishy that the server came back up immediately after submitting a ticket after being down for so long. It makes me wonder if the actual outage wasn't that long but someone forgot to flip a switch somewhere to start the server back up... And of course, their SLA is vaguely mentioned in the TOS but not actually laid out anywhere I have found so far... except that you waive your right to it if you don't mention it to them within three days.
Throughout the outage, spinning up a backup from their automated server backup system didn't work, despite me doing exactly the same thing earlier that day on a test server. The original VPS was in LA, and the backup instance was in Seattle, but neither of them were loading the website. Also, the LA node was listed as green with no issues here the entire time.
I'm just glad I'm on good enough terms with the client, and the website is small enough at this point, that it wasn't the gargantuan issue it could have been. Still, you better believe I now have the motivation to learn EC2 hosting and revamp my site backup system. Vultr just went from "awesome" to "not for production, or maybe anything" within the space of a few ridiculous hours.
-
That's pretty major! I would definitely worry a bit about Vultr for production at this point. We are using it in this one instance for something internal that has a good amount of ability to go offline for a while without it being an issue. Vultr is saving us a fortune in this instance.
Amazon and Azure are really the big players now for production stuff. Rackspace is there but their quality is definitely lagging. We still use them (for ML for example) but are using them less and less. I've run into almost non-stop issues with using them for anything of scale. Their support is just so poor.
