Got an email from David Ulevitch on 12 Jan to all the current EveryDNS subscribers that Dyn Inc has acquired EveryDNS. In the acquisition FAQ,
3) Will the service remain free?
While we don’t 100% have the answer to that yet, we will not be making any changes to the service you are currently receiving for the foreseeable future. We will be discontinuing signups in the near future but existing accounts will remain active and fully functional.
Looks like the reality is slightly different. Just got another email from Dyn Inc with regarding to the transition.
First off, anyone who has donated to David and EveryDNS since 2001 will be grandfathered into free Custom DNS hosting with DynDNS.com…
So not everyone will be migrated but those who donated. Well I did donate and got unlimited domains + unlimited records from EveryDNS (although I only have ~10 domains there). The Custom DNS hosting offer is valued at $30/year so that’s the saving a previous donator. However that’s only for 1 zone.
I have to say that DynDNS has pretty good reputation in hosted DNS space, and having 100% DNS availability is arguable even more important than your having your web servers online all the time. Still a hefty price to pay though. With EditDNS going to pay model, EveryDNS migrating to DynDNS and lots of issues with ZoneEdit. Which other free DNS provider would you put your trust on?
If you have been hunting for a virtual private server for a while, you should know all the metrics that service providers use in their advertisement and package/plan pages. You have your monthly data transfer amount (which sometimes are confused with “bandwidth”). There is a disk storage space for your operating system and data files. For OpenVZ based VPS hosting, there is also “guaranteed memory” and “burstable memory”, which I think are probably one of the most-misunderstood concept on forums such as Web Hosting Talk. This post is a reflection of what I commented on WHT last week, in a thread that discusses Xen vs. OpenVZ (which I also wrote about 2 years ago).
Basically, my conclusion about looking at an OpenVZ hosting plan is — just look at the burstable memory and (most of the time) you don’t have to worry about the guaranteed memory.
(Read More…)
December 12, 2009 @ 8:19 pm
Interesting story that got picked up on Hacker News and Proggit this morning — Jeff Atwood’s blog, Coding Horror, lost 100% of its data. Jeff puts 50% of the blame on the service provider of its VPS, CrystalTech, as they failed to back up the server as they were paid to do, and 50% on himself for putting full trust on the service provider, and keep only backups on the same server, i.e. not real back up at all.
And as it was recorded on the Hosting Gospel,
1There were some present at that very time who told him about Coding Horror and Blog.StackOverflow’s 100% data lost. 2And he answered them, “Do you think that Jeff Atwood was a worse sinner than all the bloggers and web masters, because his blogs suffered in this way? 3 No, I tell you; but unless you implement a real backup strategy and verify it regularly, your websites will all likewise perish.
Yup. Sorry for mis-quoting Luke 13, but whenever I read about this kind of disasters, let it be a reminder that I should also make sure my back up works.
It all started when Eivind Uggedal posted his performance comparison of various Xen VPS providers — Linode, SliceHost/Rackspace, Prgmr and Amazon EC2. Here’s the summary:
Summarizing the benchmarks gives us one clear winner: Linode. 32-bit gave the best results on the Unixbench runs while 64-bit was fastest on the Django and database tests. Since Linode also has the highest included bandwidth I have a hard time recommending any of the other providers if performance and price is most important for you.
It has been posted on various startup/programming community sites (Hacker News, Reddit, etc) and got a mention on Linode’s blog. A small thread has been started on Linode Forums on migrating from SliceHost to Linode, when SliceHost, Linode’s direct competitor, appears to perform worse and costs more in the performance comparison.
(Read More…)
Saw the announcement this morning on the bus — Google Public DNS. My immediate reaction (as recorded on twitter) is — I’ll hate to be OpenDNS right now. David U. at OpenDNS quickly responded saying basically “ARGH! OpenDNS is better! Google could be EVIL! But it’s all good for the DNS space”.
Well. Let’s compare them side by side, from my perspective:
| |
OpenDNS |
Google Public DNS |
| IP Address |
208.67.222.222
208.67.220.220
(Anycast) |
8.8.8.8
8.8.4.4
(Anycast) |
| Cache Size |
BIG |
Gonna be MASSIVE |
| Latency to Australia |
Sucks (170ms) |
Sucks Less (150ms) |
| Handling Non-Existing Domain |
Resolve to OpenDNS
(Configurable) |
NXDOMAIN |
| Configuration Options |
Lots! |
None |
Well. Please Google put a resolver somewhere in Sydney! Otherwise a local cache + forward is still preferred. But for now running a cheap virtual server with a badly configured resolver from the provider, I am more likely to jump on Google Public DNS because
- It’s just much easier to remember 8.8.8.8 than 208.what?.
- NXDOMAIN works by default — there is no need for me to log into OpenDNS to set up subnet rules under my account.
OpenDNS does have one advantage for developers though — CacheCheck, which allows you to request the cache to be flushed. Very useful when you have just changed some records, and would like to see that applied to the whole OpenDNS cluster. Google on the other hand gives NIL functionality except something listening on port 53.
For enterprise users it could be a different story though. Having ability to fine tune the behavuour of NXDOMAIN handling, blocking certain domains, phishing/malware/botnet protection, etc — these would be much more useful for an organisation. Will Google gradually roll out similar tools? No idea — just like we have no idea that Google is entering into the public resolver market.
Let’s wait & see.
This is a quick review on the KVM virtual server provided by GeoVPS. Howard from Layerboom first contacted me back in May 2008 through this blog and LinkedIn, and that was before Layerboom was even started. We clicked as both of us had our origins in Taiwan, and Howard mentioned that he has assembled a team to start up a developer-focused virtual server/cloud server company similar to SliceHost and Linode. Over a year later it is finally launched in October this year (as posted on Peer1’s blog). It is called GeoVPS — and it is no ordinary VPS provider.
(Read More…)
It could be the hosting gods punishing me for migrating from SliceHost to VPSLink. Just a week after I wrote that blog post, there is a big outage at VPSLink today.
It started at around 1:40pm AEST (Sydney time). Both of my VPS with VPSLink went offline. One of them, an OpenVZ Link-3, came back 90 minutes later. The other one, a Xen Link-4 hosting this very website, did not come back online until around 6:30pm in the evening. Pretty bad day for HostingFu and around 15 other websites hosted on this VPS.
(Read More…)
Sorry about lack of updates here. A lot of happening in life and it has been quite a hectic year. I have also made some significant changes under the skin here at HostingFu. I said “under the skin” because I have actually kept the old theme and look & feel of the site, but…
From SliceHost to VPSLink
I have migrated from SliceHost, i.e. the RackspaceCloud, to VPSLink for hosting this blog. See my previous VPSLink review here.
SliceHost has served me very well for the last 3 years. In fact at one stage I had > 450 days of uptime, before one of my Python script crashed the slice by using up too much memory. Performance has been great. Absolutely tops in stability. Highly recommended if you are looking for the “Rackspace of Xen VPS host” (which it literally is).
(Read More…)
Tried to set up a new VPS last night — a Xen VPS with stock kernel 2.6.18. Picked Debian 5 Lenny as operating system, and then upgrade to Squeeze using apt-get dist-upgrade. Smooth sailing so far. Until I tried to pull some of the toolchains I was trying to build from a remote subversion repository.
For example to pull the latest WordPress.
$ svn co http://core.svn.wordpress.org/trunk/
svn: OPTIONS of 'http://core.svn.wordpress.org/trunk': could not connect to server (http://core.svn.wordpress.org)
Definitely not a network issue as every single Subversion repository over HTTP is returning the same problem. A bit of gooling seems to suggest that neon is to blame (neon is the HTTP/WebDAV client library used by Subversion). Doing strace shows that:
...
close(4) = 0
socket(PF_INET, 0x80001 /* SOCK_??? */, IPPROTO_TCP) = -1 EINVAL (Invalid argument)
write(2, "svn: OPTIONS of 'http://core.svn."..., 115svn: OPTIONS of 'http://core.svn.wordpress.org/trunk': could not connect to server (http://core.svn.wordpress.org)
) = 115
exit_group(1) = ?
Well. According to /usr/include/bits/socket.h, 0×80000 is SOCK_CLOEXEC (Atomically set close-on-exec flag for the new descriptor(s).), which is not supported on Linux kernel older than 2.6.27. Here comes the problem of para-virtualisation and operating system jails — you are still running the virtualised kernel supplied by your vendor. Almost all of my VPS — Xen or OpenVZ — runs on Linux kernel 2.6.18 as it’s the kernel of choice for RHEL 5 where many virtualisation vendors want to support.
D’oh.
Well. Instead of rebuilding subversion with an older neon library, here is a much simpler work-around posted on Debian’s mailing list.
$ echo 'http-library=self' >> ~/.subversion/servers
Done! Subversion should now be working on the older kernels.
Did the following command on one of my Australian VPS this morning.
$ mtr -n --report www.aussiehq.com.au
HOST: my-vps-in-bne Loss% Snt Last Avg Best Wrst StDev
1. 202.60.89.xx 0.0% 10 0.0 0.0 0.0 0.1 0.0
2. 118.127.9.xx 0.0% 10 267.6 262.3 256.3 267.6 4.3
3. 202.60.84.78 0.0% 10 270.8 265.5 258.5 275.2 5.4
4. 203.88.112.4 0.0% 10 274.9 268.7 262.4 274.9 4.1
5. 203.88.112.153 10.0% 10 271.8 268.0 262.8 271.8 3.1
My VPS is hosted with someone who has servers with DedicatedServers.com.au in Brisbane, doing a traceroute to the home page of AussieHQ in Canberra, one of the largest hosting companies in Australia. I believe the first hop is the host node for thise OpenVZ VE, and the second hop would be the router at DedicatedServers.
It’s interesting to observe the fluctuation of latency between the host node and the router throughout the day. It’s usually pretty bad in the morning — all the way up to 300ms, and then the round-trip latency drops to a few milliseconds in the evenings. Massively oversold bandwidth I guess (won’t name the names yet). Even my sites hosted in California feels faster in Australia.
21
1