読者です 読者をやめる 読者になる 読者になる

電子計算記

個人的な検証を

Alibaba Cloud の Aliyun Linux

jp.aliyun.com
昨年後半、Alibaba Cloudの日本リージョンがリリースされ、中の人からの紹介だったり、2万円クーポンキャンペーンをしてたりするので、今触っていたりします。

すると、インスタンスの作成時のOSに、Aliyun Linuxというのが選べました。
f:id:fujish:20170416224419p:plain

Aliyunとは、Alibabaのクラウドコンピューティングサービス名称の阿里雲のアルファベット表記。
AWSで言う、Amazon Linuxみたいなものですかね。自社で開発した自社で使ってるLinuxみたいな。
ググッてもあまり情報がなかったので中見てみました。どこのディストロベースかなー。

上記画像のとおり、選べるバージョンは15.1のみ。64bitと32bitが選べます。以下、64bitで作成しました。

OS上でのディストリビューション名を確認します。

[root@<UUID> ~]# ls -al /etc/*release
-rw-r--r--. 1 root root   28 Jan  6  2015 /etc/alios-release
lrwxrwxrwx. 1 root root   13 Mar 25  2015 /etc/system-release -> alios-release

/etc/system-releaseは用意されてるんですね。でも/etc/lsb-releaseは無しと。
ちょっと古そうな印象。

[root@<UUID> ~]# cat /etc/alios-release
Aliyun Linux release6 15.01

なるほど、release6の15.01と。

次にカーネルを見てみると。

[root@<UUID> ~]# uname -a
Linux <ホスト名:UUID> 2.6.32-220.23.2.al.ali1.1.alios6.x86_64 #1 SMP Sun Jan 4 15:01:53 CST 2015 x86_64 x86_64 x86_64 GNU/Linux

2.6.32-220か、となるとRHEL6.2と同じ。

パッケージ管理は、YUMRPM
リポジトリは自分とこ向いてる。

[root@<UUID> ~]# cat /etc/yum.repos.d/aliyunlinux-Base-Aliyun.repo
[base]
name=aliyunlinux-$releasever
enabled=1
failovermethod=priority
baseurl=http://jp.mirrors.cloud.aliyuncs.com/aliyunlinux/$releasever/os/$basearch/
(以下略)

その他、バージョンを見ていくと、

[root@<UUID> ~]# bash --version
GNU bash, version 4.1.2(1)-release (x86_64-koji-linux-gnu)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
[root@<UUID> ~]# gcc -v
Using built-in specs.
Target: x86_64-alios-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bbs.aliyun.com --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-alios-linux
Thread model: posix
gcc version 4.4.6 20110731 (AliCloud Linux 4.4.6-3) (GCC)
[root@<UUID> ~]# httpd -v
Server version: Apache/2.2.15 (Unix)
Server built:   Jul 26 2014 06:52:25
[root@<UUID> ~]# mysql --version
mysql  Ver 14.14 Distrib 5.1.73, for koji-linux-gnu (x86_64) using readline 5.1
[root@<UUID> ~]# php -v
PHP 5.3.3 (cli) (built: Jul 28 2014 21:21:24)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies

といったところで、bashは4.1.2、gccは4.4.6、httpdは2.2.15、MySQLは5.1.73、PHPは5.3.3。
これはもうRHEL6系ベースですね。て言うかバージョン古い。

ここまでこれといった、独自の拡張みたいなのがなく、NICとかストレージコントローラとかのデバイスが特殊かなと思ってても、いずれもKVMのvirtioで普通。

となると、カーネルかなと。CentOS6.2とカーネルビルドオプションを比較してみると、以下がAlibaba Linuxに追加されてました。

< CONFIG_IKCONFIG=y
< CONFIG_IKCONFIG_PROC=y
< CONFIG_HOOKERS=m
< CONFIG_MODULE_SIG_FORCE=y
< CONFIG_TOA=m
< CONFIG_RT_STAT=m
< CONFIG_IP_VS_TAB_BITS=20
< CONFIG_BLK_DEV_DRBD=m
< CONFIG_DRBD_TRACE=m
< CONFIG_TLOCK=m
< CONFIG_BLK_DEV_SD=y
< CONFIG_DM_FLASHCACHE=m
< CONFIG_NETOOPS=y
< CONFIG_NETPOLL_TARGETS=y
< CONFIG_NETPOLL_TARGETS_DYNAMIC=y
< CONFIG_EXT3_FS_SUBTREE=y
< CONFIG_SUBTREE=y
< CONFIG_OVERLAYFS_FS=m
< CONFIG_CONFIGFS_FS=y
< CONFIG_ACRIDAFS=m
< CONFIG_PRINTK_TIME=y
< CONFIG_UNUSED_SYMBOLS=y
< CONFIG_GTP=m
< CONFIG_PAGE_CACHE_ACCT=y
< CONFIG_DETECT_KERNEL_VUL=y
< CONFIG_CRC_T10DIF=y

これを見ていくと、Alibabaが作ったパッチが適用されていて、そこを追ってたらそのまんま核心を見つけた。

github.com

All features of RHEL6U2 kernel, source code version is 2.6.32-220.23.1.

やはり、RHEL6.2ベースでした。Alibabaが自分たちで使っているようです。
安定がウリのようですが、とは言え、バージョンも古いですしね。
次回は性能面を見ていきましょう。

NUROが開通したのでベンチマークしてみた話

これまで自宅のインターネット回線は、フレッツ 光ネクスト ギガマンション・スマートタイプという1Gbpsの回線にISPは、Yahoo!BBIPv6 IPoE+IPv4 で繋いでいましたが、ウチのマンションにもNUROが来たので、フレッツに加え追加契約しました。
NURO光 for マンションという2Gbpsの回線です。


ということで、速度を見ていきましょう。まずは簡単に以下のベンチマークサイト
fast.com
で見てみます。3回実行しました。

# フレッツ NURO
1 450 Mbps 720 Mbps
2 350 Mbps 740 Mbps
3 400 Mbps 740 Mbps

やはりNUROで速くなりました。倍近く違います。調子がいいと800Mbps以上でることもあります。


次に、もう少し大きいデータのダウンロードで試してみます。
IDCFクラウド上でnginxのサーバーをたて(Standard.L16)、CentOS-6.7のisoファイル(3.6GByte)を置きます。ここに対してクライアントからはpgetを使ってダウンロードします。ディスクI/Oがボトルネックにならないよう、ファイルはメモリ上に読み書きしてます。

ちなみに、wgetだと帯域を使いきれないので、pgetを4並列で使っています。
qiita.com
具体的には、

user@localhost:/dev/shm/tmp$ pget -p 4 http://<IPアドレス>/CentOS-6.7-x86_64-bin-DVD1.iso
Checking now http://<IPアドレス>/CentOS-6.7-x86_64-bin-DVD1.iso
Download start from http://<IPアドレス>/CentOS-6.7-x86_64-bin-DVD1.iso
 3895459840 / 3895459840 [=========================================] 100.00% 34s

binding with files...
 3895459840 / 3895459840 [==========================================] 100.00% 1s
Complete

ここでは、Downloadにかかった時間(34s)で比べたいと思います。

# フレッツ NURO
1 123 sec 36 sec
2 137 sec 37 sec
3 130 sec 34 sec

4倍近い差がでました。900Mbps以上出ている計算ですね。クライアントのPCもその上のNUROのルータも1Gbpsのポートなので、このあたりでボトルネックになっていると思われます。


定評のとおり、NUROでは良い結果が出ましたので、メインの回線はNUROに切り替えました。
NURO 10Gのマンションタイプが待ち遠しい。

IDCFクラウドの仮想マシンでMACアドレスを変えたいときに

IDCF Cloud Advent Calendar 2016 の12/14が埋まってないので個人的に責任(疲)をとって埋めておきますね。

突然ですが、サーバーのMACアドレスを変えたいときってありますよね!?

ないかもしれませんが、例えば、
IDCFの旧セルフクラウドからIDCFクラウドに移行するときにMACアドレスを変えたくない(ライセンス的に)とか・・・。

ちゃんとした話するなら、IDCFクラウドの特徴として、VRRPを使ったVirtual IP (VIP)が使えるので、VIPと合わせてMACアドレスも変えるとか。

Linuxなら簡単にできるので紹介します。

例えば、こんなNICがあったとします。

[root@test ~]# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 02:00:4e:43:00:46 brd ff:ff:ff:ff:ff:ff
    inet 10.21.0.84/21 brd 10.21.7.255 scope global eth0
    inet6 fe80::4eff:fe43:46/64 scope link 
       valid_lft forever preferred_lft forever

この時点でeth0のMACアドレスは 02:00:4e:43:00:46 ですね。
これを aa:bb:cc:dd:ee:ff に変えます。

[root@test ~]# ip link set eth0 address aa:bb:cc:dd:ee:ff
[root@test ~]# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
    inet 10.21.0.84/21 brd 10.21.7.255 scope global eth0
    inet6 fe80::4eff:fe43:46/64 scope link 
       valid_lft forever preferred_lft forever

この通り、eth0のMACアドレスが aa:bb:cc:dd:ee:ff に変わりました。

念の為、別のサーバーから疎通を確認しましょう。

[root@test2 ~]# ping 10.21.0.84
PING 10.21.0.84 (10.21.0.84) 56(84) bytes of data.
64 bytes from 10.21.0.84: icmp_seq=1 ttl=64 time=2.00 ms
64 bytes from 10.21.0.84: icmp_seq=2 ttl=64 time=0.249 ms
64 bytes from 10.21.0.84: icmp_seq=3 ttl=64 time=0.224 ms
〜略〜
[root@test2 ~]# arp -an
? (10.21.0.84) at aa:bb:cc:dd:ee:ff [ether] on eth0

pingが通ること、ARPテーブル上も書き換えたMACアドレスになっていることが確認できます。

以上のとおり、MACアドレス書き換えはOS上でさらりと設定できました。
ただ、クラウドの基盤側のセキュリティポリシーにも依存しそうな話なので、利用する前にしっかり事前試験はしてください。
もしクリティカルな場面で使用したいのであれば、サポートに聞いてみることをおすすめします。

IDCFクラウドでポートミラーリングしたいときに

IDCF Cloud Advent Calendar 2016 の12/12が埋まってないので個人的に責任(w)をとって埋めておきますね。

突然ですが、ポートミラーリングが必要になるケースってありますよね。
例えば、通信の中身をチェックしなければならないときとか。
もっと具体的に言うと、IDS/IPSで入口対策するときや、振る舞い検知などの出口対策のときです。

このようなセキュリティ用途の機械やサーバーをインライン型で入れると、ここがボトルネックになりかねないので、ポートミラーリング型で入れる。
でも、クラウドだとポートミラーリングってどうやってやるのでしょうか。
オンプレだとL2スイッチなどのネットワーク機器の方でミラーリングできますけど。

と、言うことで、ここではIDCFクラウドでポートミラーリングする際の構成方法を紹介します。

今回想定する、ネットワーク構成は以下です。

f:id:fujish:20161224221405p:plain

追加ネットワーク(192.168.0.0/21)を作成し、そこにwebサーバーが接続されてます。
同じネットワークに、ポートミラーリング型のIDS/IPS(192.168.5.254)を設置します。
そして、標準ネットワーク(10.11.0.0/21)と追加ネットワークに両方接続するかたちで、ロードバランサーやルータ(またはプロキシ)のような仮想マシンを設置します。この仮想マシンの追加ネットワーク側のNIC(192.168.1.1)からIDS/IPSにポートミラーリングするとします。

前置きが長くなりましたが、今時のLinuxであればiptablesで一発です。
構成図のLB/Routerのマシンにて、以下のコマンドを入れます。

iptables -t mangle -A PREROUTING -i eno33557248 -j TEE --gateway 192.168.5.254

ここで、
i eno33557248 はNICのインターフェース名です。eth0的なもの等環境に合わせてください。
gateway 192.168.5.254 はミラーリング先のIPアドレスになります。

一つ補足すると、IDS/IPS等のミラーリング先で、IPアドレスを持たないマシンというケースもままあると思います。この時は、IDS/IPSの該当のNICMACアドレスを調べ、そのMACアドレスに対して無理やりIPアドレスを指定してしまいましょう。今回のケース(192.168.5.254にミラーリングしたい)だとLB/Routerのマシンにて、以下のコマンドを入れます。

arp -s 192.168.5.254 00:AA:BB:CC:DD:EE

00:AA:BB:CC:DD:EEの部分は、ミラーリング先のMACアドレスを入れます。
ARPテーブルを静的に入れてるだけです。

このように、iptabelsのTEEとARPを組み合わせると、簡単にポートミラーリングが実現できます。

是非お試しください。
ニーズはかなり少なさそうですが。

gpu.7XLM40でChainer

IDCF Cloud Advent Calendar 2016 の12/11が中々埋まらないので個人的に責任(ぇ)をとって埋めておきますね。

IDCFクラウドGPUインスタンスgpu.7XLM40が搭載しているTesla M40はディープラーニング用とのことなので、前回のエントリに続き、手元にあるJetson TK1と比較してみます。
今回は国産のフレームワークであるChainerを試してみましょう。

前回のエントリの通り、CUDAまで入っている前提で進めます。

まずは、NVIDIA謹製のDeepLearning高速化ライブラリ cuDNN を入れます。
以下からダウンロードします。

developer.nvidia.com

以下のようにダウンロードしたファイルをCUDAインストールディレクトリに展開します。

# tar zxf cudnn-8.0-linux-x64-v5.1.tgz -C /usr/local/

次にChainerをpipでインストールします。

# apt install python-dev python-pip -y
# pip install chainer

以下のようにMNISTサンプルを動かして時間を比較しましょう。

# wget https://github.com/pfnet/chainer/archive/v1.19.0.tar.gz
# tar xzf v1.19.0.tar.gz
# python chainer-1.19.0/examples/mnist/train_mnist.py

Jetson TK1の場合、

# python train_mnist.py -g 0
GPU: 0
# unit: 1000
# Minibatch-size: 100
# epoch: 20

epoch       main/loss   validation/main/loss  main/accuracy  validation/main/accuracy  elapsed_time
1           0.191052    0.0946279             0.942567       0.9685                    15.3752       
2           0.0759313   0.079524              0.975899       0.974                     27.6975       
3           0.0477192   0.0753355             0.984999       0.9782                    39.9687       
4           0.036118    0.0776683             0.988181       0.98                      52.2688       
5           0.0288793   0.0803554             0.990682       0.9784                    64.564        
6           0.0237394   0.0802068             0.992365       0.9808                    76.8615       
7           0.0206044   0.0778168             0.993249       0.9809                    89.1331       
8           0.0188643   0.0854813             0.993732       0.9793                    101.466       
9           0.0161048   0.0746344             0.994749       0.9832                    113.725       
10          0.0121589   0.0872302             0.996382       0.9827                    125.995       
11          0.0171261   0.0819404             0.994816       0.9819                    138.278       
12          0.012826    0.109307              0.996232       0.9796                    150.613       
13          0.00925115  0.107072              0.997199       0.9793                    162.971       
14          0.0152739   0.0923335             0.995265       0.9823                    175.281       
15          0.013186    0.106915              0.995599       0.9815                    187.636       
16          0.00774953  0.0932978             0.997649       0.9833                    199.973       
17          0.00556501  0.095636              0.998332       0.983                     212.293       
18          0.0136293   0.102989              0.996166       0.9824                    224.661       
19          0.0108599   0.0967607             0.997266       0.9819                    236.958       
20          0.00808728  0.108585              0.997465       0.9811                    249.314

gpu.7XLM40の場合、

# python train_mnist.py -g 0
GPU: 0
# unit: 1000
# Minibatch-size: 100
# epoch: 20

epoch       main/loss   validation/main/loss  main/accuracy  validation/main/accuracy  elapsed_time
1           0.192398    0.103778              0.941517       0.9661                    3.31695       
2           0.0745933   0.0841857             0.977366       0.9727                    6.05998       
3           0.0486797   0.074385              0.983998       0.9786                    8.80333       
4           0.0367712   0.0739067             0.987615       0.978                     11.5473       
5           0.027089    0.0893926             0.991115       0.9742                    14.2486       
6           0.0233483   0.0714004             0.992715       0.9805                    16.9643       
7           0.0221298   0.0675429             0.993066       0.9814                    19.6585       
8           0.0181648   0.0812684             0.994115       0.9812                    22.3716       
9           0.0163283   0.108464              0.994815       0.9746                    25.0874       
10          0.0138237   0.0710016             0.995482       0.9848                    27.7974       
11          0.0133834   0.0990396             0.995915       0.9791                    30.5191       
12          0.013658    0.0909462             0.995599       0.9812                    33.2338       
13          0.0133063   0.0876385             0.995949       0.9827                    35.9592       
14          0.0093469   0.0917807             0.997065       0.9817                    38.6743       
15          0.0119297   0.0796671             0.996416       0.9853                    41.3877       
16          0.0118582   0.10504               0.996482       0.9808                    44.1021       
17          0.00992382  0.0811633             0.997066       0.9837                    46.817        
18          0.00825741  0.102598              0.997582       0.9821                    49.5329       
19          0.00609279  0.0972261             0.998366       0.9819                    52.2437       
20          0.0118044   0.105861              0.996865       0.9804                    54.9529

20epoch回すのに、
Jetson TK1は、249.314sec、
gpu.7XLM40は、54.9529sec、
5倍くらいの差がでました。さすがM40速いといいたいところですが
もっと差が出ても良さそうですが、層が浅いせいかな。

次回は別のDeepLearningのフレームワークで試してみる。

IDCFクラウドのGPUインスタンス

IDCF Cloud Advent Calendar 2016 の12/10が空いていたので個人的に責任(ぉ)をとって埋めておきますね。

新リージョンこと東日本リージョン2と併せて、GPUインスタンスであるgpu.7XLM40がリリースされてます。
56vCPUなので7XL(XL=8vCPU)、NVIDIAGPU TeslaのモデルからM40となってます。

このあたりのGPUなんちゃらの話は、12/8のアドカレの通りオフィシャルのテックブログに書かれてます。

blog.idcf.jp

手元にあるGPUとしてJetson TK1があったので、gpu.7XLM40と比べてみます。


本題の前に、上記テックブログのエントリーでは、CentOSにCUDA入れてますが、以降ではUbuntu14.04を使ってるので、インストールコマンドだけ書いておきます。

# apt update && apt upgrade -y && reboot

# wget http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1404/x86_64/cuda-repo-ubuntu1404_8.0.44-1_amd64.deb
# dpkg -i cuda-repo-ubuntu1404_8.0.44-1_amd64.deb
# apt update
# apt install cuda -y
# reboot

# export PATH=/usr/local/cuda-8.0/bin${PATH:+:${PATH}}
# export LD_LIBRARY_PATH=/usr/local/cuda-8.0/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}

ここでwgetしてるリポジトリファイルの最新は以下から入手してください。

developer.nvidia.com


昔と違ってCUDA入れるのも楽になりましたよねー、動作確認としてはCUDAと一緒に入る以下のコマンドで。

# nvidia-smi
Fri Nov 25 21:36:06 2016
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 361.93.02              Driver Version: 361.93.02                 |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Tesla M40 24GB      On   | 0000:03:00.0     Off |                    0 |
| N/A   38C    P8    17W / 250W |      0MiB / 22944MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+


+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID  Type  Process name                               Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+


では、Jetson TK1とgpu.7XLM40比べていきましょう。
前提として、Jetson TK1はCUDA6.5、gpu.7XLM40は上記のとおりCUDA8.0です。

Jetson TK1は、Keplerが 192 CUDA Core。
gpu.7XLM40は、Maxwellが 3072 CUDA Core。

では、CUDAのsmplesを動かして比較してみましょう。

まずはbandwidthTestでデータ転送速度を見ます。

$ ./bandwidthTest 
Jetson TK1 gpu.7XLM40
Host to Device(MB/s) 998.2 7907.7
Device to Host(MB/s) 5464.7 8288.7
Device to Device(MB/s) 11901.5 211407.8

わかってましたが桁違いの差ですね。
次にnbodyでFLOPSを見ます。

$ ./nbody -benchmark -numbodies=16384
$ ./nbody -benchmark -numbodies=16384 -fp64
$ ./nbody -benchmark 
Jetson TK1 gpu.7XLM40
-numbodies=16384(GFLOP/s) 13.356 3216.793
-numbodies=16384 -fp64(GFLOP/s) 0.865 142.198
-numbodies=131072(GFLOP/s) 13.393 4003.906

こちらも圧倒的な差ですね。Maxwell倍精度遅いと言っても、Jetson TK1と比べると圧倒的な差ですね。
今日はここまで、次回はTesla M40の用途に合わせてDeep Learningの性能を見ていきましょう。

IDCFクラウドのHighio.5XL128.g2について

IDCF Cloud Advent Calendar 2016 の12/7がキャンセルされたので個人的に責任(謎)をとって埋めておきますね。

今日はIDCFクラウドの2つのVMタイプ、Highio.5XL128とHighio.5XL128.g2について。

そもそも、Highio.5XL128.g2の存在にお気づきでしょうか。
西日本リージョンだとg2が利用できます。
このg2、仮想化アーキテクチャを一新し、ディスクI/Oへの仮想化のオーバーヘッドを大幅に低減しベアメタルに近い性能を体験できます、といってもダイレクトパススルーではないですが。

では、tpcc-mysqlの性能を見ていきましょう。
赤がHighio.5XL128、青がHighio.5XL128.g2、緑がHighio.3XL128です。

f:id:fujish:20161212234352p:plain

ついでに、Highio.3XL128も一緒にやりましたが、もともと3XL128よりもだいぶ速かった5XL128がg2になりより高速な結果となっています。

計測内容としては次の通り。

MySQLバージョン
MySQL Server Community Edition 5.6.30
公式RPMバイナリ使用

MySQLコンフィグ

skip-name-resolve
max_connections = 1000
thread_cache_size = 1000
innodb_buffer_pool_size = 90G
innodb_log_file_size = 2G
innodb_flush_method=O_DIRECT
innodb_write_io_threads=16
innodb_read_io_threads=8
innodb_io_capacity=10000
innodb_max_dirty_pages_pct=60
innodb_adaptive_flushing=1
innodb_log_files_in_group=2
innodb_thread_concurrency=0
innodb_purge_threads=1

ベンチマークツール
tpcc-mysql

./tpcc_start -d tpcc -u root -w 1500 -c 30 -l 3600 -i 60 -r 0

MySQLサーバーのローカルで実行
初回1回実行した結果

■OS
CentOS 7.2

■datadir
仮想マシンのdatadirは追加ディスク(DATAディスク)をゼロ埋めした後に、データを入れている。


以上、g2の速さがお分かりいただけたと思いますが、g2になっても価格は同じ。
でも西日本リージョンでのみ利用可能となっています。
東日本リージョンの場合で5XL128で性能が足りない場合はベアメタルサーバーもあります。
このあたりはIDCFクラウド本の6.3章に私が書いています(宣伝)。
www.idcf.jp