VPS.NET Tokyo cloud launched

Our Tokyo cloud is launched! Its free! http://t.co/ET2a2zf ^RF
@vpsnet
VPS.NET

We are pleased to announce the new beta of our Japan cloud (Tokyo). We are offering old and new customers up to 9 beta nodes for free to test out the location.

Highlights include:
- The fastest, most technically advanced enterprise class SAN within all of our clouds
- Full support for Windows and Linux
- Full OnApp 2.2 support will be enabled during the beta
- Its Free!

VPS.NET just launched their Tokyo cloud today in beta. According to them, this new cloud features an all-new SAN deployment which will resolve issues like their recent (and not only) 50h downtime + customer data loss. SAN failures have been a major issue at VPS.NET during the last year and many customers who didn’t had their own backup strategy lost all their data because of file corruption after a SAN crash (hint: don’t rely on VPS.NET backups -unless R1Soft- and always have your own backup strategy!)

I just ordered a 6-node VPS with Debian 6.0 x64 to test things out. After removing grub-legacy and grub-common I did an apt-get update && apt-get upgrade to get my VPS up to date. The default /etc/apt/sources.list file contains links to mirrors.kernel.org which is currently down, so change it to something to this:

deb http://ftp.dti.ad.jp/pub/Linux/debian/ squeeze main contrib
deb-src http://ftp.dti.ad.jp/pub/Linux/debian/ squeeze main contrib

(How did I come up with ftp.dti.ad.jp? Read: Using netselect-apt to find the fastest Debian mirror)

During apt-get upgrade I was getting all those nasty

locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

kind of errors, which can be easily fixed by issuing a

root@dev:~# locale-gen en_US.UTF-8
Generating locales (this might take a while)...
  en_US.UTF-8... done
Generation complete.

and adding

LANG="en_US.UTF-8"
LC_ALL="en_US.UTF-8"

to your /etc/default/locale file.

Time for a reboot and some testing! My 6-node VPS has 3 CPU cores assigned (I’m pasting only the output of the first one)

root@dev:~# cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 44
model name	: Intel(R) Xeon(R) CPU           E5620  @ 2.40GHz
stepping	: 2
cpu MHz		: 2400.084
cache size	: 12288 KB
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nonstop_tsc pni ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm
bogomips	: 4800.16
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management:

Then I used hdparm -tT to test cache/memory throughput (3 times in a row)

root@dev:~# for i in 1 2 3; do hdparm -tT /dev/xvda1; done

/dev/xvda1:
 Timing cached reads:   15204 MB in  1.99 seconds = 7646.24 MB/sec
 Timing buffered disk reads:  60 MB in  3.66 seconds =  16.41 MB/sec

/dev/xvda1:
 Timing cached reads:   15172 MB in  1.99 seconds = 7630.04 MB/sec
 Timing buffered disk reads:  42 MB in  3.00 seconds =  13.98 MB/sec

/dev/xvda1:
 Timing cached reads:   15196 MB in  1.99 seconds = 7641.91 MB/sec
 Timing buffered disk reads:  52 MB in  3.12 seconds =  16.68 MB/sec

And finally a typical hard disk bench (also ran 3 times in a row)

root@dev:~# dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 18.6979 s, 57.4 MB/s
root@dev:~# dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 11.5814 s, 92.7 MB/s
root@dev:~# dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 12.4096 s, 86.5 MB/s

Hard disk speed test results are not what I expected from the “The fastest, most technically advanced enterprise class SAN” to be honest, but I have to give them credit that today is launch day (+ it’s free for a month!) and maybe the HVs & SANs are overloaded creating new VPSs all the time (although iostat -d -x doesn’t thinks so…)

I will be monitoring the VPS with sar for a few days and will update this post in case things change.

Although disk I/O performance IS important (you want your website to load fast in order for Google to rank you higher) the main issue with VPS.NET was downtime & data loss because of SAN failures. If the new SANs turn out stable and manage to retain data integrity even in a case of failure, then I’m sure that VPS.NET will catch up with the competition again.

Update 19 Sep. 2011:
Five days after posting my initial measurements, I retested everything to see if things got better or worse now that the cloud is sold out and no more activations are being performed.

Here are my today’s results:

root@dev:~# for i in 1 2 3; do hdparm -tT /dev/xvda1; done

/dev/xvda1:
 Timing cached reads:   14980 MB in  1.99 seconds = 7533.07 MB/sec
 Timing buffered disk reads:  44 MB in  3.13 seconds =  14.07 MB/sec

/dev/xvda1:
 Timing cached reads:   14944 MB in  1.99 seconds = 7514.73 MB/sec
 Timing buffered disk reads:  56 MB in  3.23 seconds =  17.32 MB/sec

/dev/xvda1:
 Timing cached reads:   14962 MB in  1.99 seconds = 7523.54 MB/sec
 Timing buffered disk reads:  56 MB in  3.22 seconds =  17.37 MB/sec
root@dev:~# dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 13.4729 s, 79.7 MB/s
root@dev:~# dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 12.2284 s, 87.8 MB/s
root@dev:~# dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 12.7171 s, 84.4 MB/s
root@dev:~# sar
Linux 2.6.32-5-xen-amd64 (dev2) 	09/19/2011 	_x86_64_	(3 CPU)

12:00:01 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
12:05:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
12:15:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
12:25:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
12:35:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
12:45:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
12:55:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
01:05:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
01:15:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
01:25:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
01:35:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
01:45:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
01:55:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
02:05:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
02:15:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
02:25:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
02:35:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
02:45:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
02:55:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
03:05:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
03:15:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
03:25:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
03:35:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
03:45:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
03:55:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
04:05:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
04:15:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
04:25:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
04:35:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00

04:35:01 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
04:45:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
04:55:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
05:05:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
05:15:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
05:25:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
05:35:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
05:45:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
05:55:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
06:05:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
06:15:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
06:25:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
06:35:01 AM     all      0.01      0.00      0.01      0.00      0.00     99.98
06:45:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
06:55:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
07:05:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
07:15:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
07:25:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
07:35:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
07:45:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
07:55:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
08:05:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
08:15:01 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
08:25:01 AM     all      0.01      0.00      0.24      1.55      0.00     98.19
Average:        all      0.00      0.00      0.01      0.03      0.00     99.96

Disk I/O speed seems to be stable at around 80MB/s which is considered slightly above average based on the stats found at the VPS Disk I/O test thread on WebHostingTalk, but certainly not something to brag about. To compare, the VPS this blog is hosted on is always giving me >300MB/sec:

root@hydrogen [~]# dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 3.50145 seconds, 307 MB/s

Again, I can’t stress out enough that VPS.NET ultimately needs to find a stable and reliable storage solution with which they will deploy the rest of their clouds with. Disk I/O speed is of secondary importance. It’s about one year ago since the new SAN 2.0 which would resolve all storage issues was introduced, but again the issues remain and a new SAN vendor had to be found. Lets hope that Nexenta will do the trick this time because this distributed, amazing, multi-path, enterprise, redundant, super-fast (…you get my point) SAN technology VPS.NET is counting on, has screwed their profile and potential many times. VPS.NET should be the leader of VPS providers with their innovative product, ease of use and technology behind it, instead they have to hear their clients losing their data again and again because some SAN crashed.

2 thoughts on “VPS.NET Tokyo cloud launched

  1. Terry Myers

    George,

    I wanted to get in touch with you and thank you for writing a review. How are things going so far? Are you seeing any kind of speed increase/decrease now that the cloud is closed for new VMs?

    Reply
    1. George Tasioulis Post author

      Hello Terry,

      Disk I/O speed today and yesterday seems to be the same (~80MB/sec) like on launch day, no matter what time of the day I’m measuring. I’m going to update the post tomorrow with my newest measurements and will let you know via twitter.

      Reply

Leave a Reply