Feb 132017
 

Found a good post on how to use the  rescue mode in Hetzner to setup a Logical Volume that spans multiple drives. This plus vsftpd can help setup Terabytes of space for storage as backup. In any case you should not use Hetzner for anything closely resembling a legit online service, website etc. It is only popular as Seedbox for a reason as they are quick to lock your server out.

Speaking of seedboxes, if you want to setup one here is a good script https://github.com/arakasi72/rtinst It can optionally install Webmin.

For file storage, search and download etc I have not yet found a tool. It’s mostly find and scp

If you feel adventurous I found a tricked out Seedbox setup script here https://github.com/dannyti/seedbox-from-scratch. Does everything and makes coffee.

With Bacula running on the local server I can send snapshots over to Hetzner albeit at a slow-as-snail speed. 30 Euros per month for 5.5TB of space is not too bad. I picked up a system from the their auctions and its quite alright but one shouldn’t expect performance or longevity from such systems. You get what you pay for essentially.

 

Feb 022014
 

A lot of providers will sell you 1 Gbps port with oodles of bandwidth. A test file download to boot. For most people that seems to be enough. That is incorrect in most cases. Having good speed and bandwidth is just one piece of the cake you never ate. You can have a lot of bandwidth allocated but if there is bad network connectivity, crappy maintenance, a decade old routers etc you will never be able to reap any of the benefits. Which is why you will see that some dedicated hosts do poorly as opposed to smaller shared hosting served sites when serving end users.

Here’s how to evaluate a new provider where you do not know any existing sites that you can use to test. (And please don’t use the IPs, files as target to test, those are specially setup servers)

First find out the organization name. Here I target “NoUptime“, (fictitious) since they actually have oodles of packet loss for a good example (in a bad way) nothing against them, they are great cheap cost provider.

 

First we need to find an IP that is live with this provider and test against it.

1. Let us go to to RIPE who maintain list of who owns which IPs. it is not always up to date but for our purposes it is quite accurate.

I will visit their Database search

https://apps.db.ripe.net/search/full-text.html

type in NoUptime and you will see some results

on the right side of the page you have “result type” filter. Select “inetnum” i.e. IPv4. You can even try inet6num for IPv6 if thats what you want to test.

The results are updated.

2. Select an IP from the results. You may have to try multiple times to get one which is live. I normally select the first IP in the range given in the results. Try different search result pages, not the first only.

So I get an IP, let’s say 10.2.3.4 (not real IP)

3. Run the MTR

While this is only half the report it is still a good indicator. So let us begin. Get the MTR tool if you haven’t already. Once you get it installed run it on the target IP

 

Example:

#mtr 10.2.3.4 (edited to remove real identification IPs etc)

Host                                    Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.168.0.1                           0.0%   623    0.4   0.5   0.4   1.4   0.1
 2. some.ip.near.you                            0.0%   623    3.7   6.0   3.0 102.9   8.0
 3. some.ip.further                         0.0%   623    4.9   7.7   3.7 210.7  17.8
 4. some.ip.on.isp                          0.0%   623    4.2  10.0   3.9 206.4  24.1
 5. some.ip.isp.isp               0.0%   623   10.2   7.6   4.8  40.6   2.1
 6. init7.net.any2ix.coresite.com         0.0%   623  173.6 171.4 169.6 197.7   1.7
 7. r1nyc1.core.init7.net                 0.0%   623  256.7 255.8 251.4 267.1   3.6
 8. r1lon1.core.init7.net                 0.0%   623  321.7 317.0 312.5 332.3   4.3
 9. r1nue1.core.init7.net                 0.0%   623  335.1 336.0 333.7 347.9   2.6
10. gw-nouptime.init7.net                  0.0%   622  333.5 339.0 332.3 415.5  13.3
11. core12.nouptime.de                    44.4%   622  335.5 335.6 334.2 351.6   1.6
12. core22.nouptime.de                    12.5%   622  336.8 337.3 335.3 360.8   2.9
<span style="color: #ff0000;">13. juniper2.rz13.nouptime.de              10.0%   622  373.3 351.5 328.5 424.0  23.5
14. hos-tr4.ex3k11.rz13.nouptime.de        15.0%   622  331.9 332.4 329.9 343.2   1.6</span>
15. static.4.3.2.10.clients.your-server.de    20.0%   622  337.1 336.9 335.2 346.5   0.9

This above shows the packets sent to the NoUptime IP that hosts a customer’s server and this amount of packet loss is really really bad. The packets lost are retransmitted. If you were on an ip at NoUptime you can even run the same trace from Server to your connection. It is safe to say it will be just as crappy. As per above we observe that almost 50% of the packets are lost in NoUptime at hop # 11. Which means half the data you send will never reach and will have to resent. What’s worse is that at Hop #12 another 25% of the packets that do manage survive Hop # 111 die of unnatural circumstances. so End of the day your 100 MB file will take more than twice as long to upload. Now CAVEAT: Some routers don’t respond to ICMP as claimed by providers, what I do not is why they’d respond to half the packets and not all. In any case what you need to see in the Last hop, in this case #15. Here we see 20% packet loss. This is the REAL loss and that is what matters. Again, the reason I say try with different IPs is because someone may have configured their network wrong like not turning “autoneg on”. Which was my case.

I have observed that on reverse MTR at NoUptime it’s even worse as such Downloads that account for 90% over of all regular website traffic will suffer greatly contributing to End User experience . This provider is consistent enough for me to just decide one day (today) to write about how to test and still get the same sort of lossy MTR. The reason I write this is because packet losses are normal on the internet and do not mean it is same from every location or every day.

To give any provider the benefit of the doubt you need to conduct the test over a couple of days and not continuously. Just get a sample at every few hours and for a few days (2-5 days), try from multiple locations if you have SSh access to remote servers you currently run, try the RIPE for different IP of the provider. Because device or packet loss can be fixed by engineers when detected, normally they fix on their own. If their network maintenance is really crappy and despite customer complaints they do not fix it then now you know. 

they has your packets.

they has your packets.

Do you have any more ideas on how to evaluate a new Hosting Provider? Share in the comments please.

Until next time.

 

EDIT: I have corrected the example. I ran a real traceroute at the time and adjusted the numbers manually for laziness. I have marked the packet loss by hops correctly to explain the scneario. Point is if you see zeroes in between then it is not an issue. It should be loss from one start point to end or -1 hop (in case the destination host is also blocking ICMP)

Also see comments from Chris below