実際にオーダするにあたりどの程度のスペックを選択すればよいか悩むことが有ります。代表的なクラウドサービスのAmazon Web ServicesのEC2などではCPUとメモリサイズは固定されてメニューとして提供される方式ですがSoftLayerの仮想サーバは、CPU、メモリおよびストレージが自由に選択できます。
今回は東京データセンター上の仮想サーバでUnixbenchとfioを使ったパフォーマンス比較を実施しました。
リソースのコスト
リソース | 単位 | コスト($/Mo) | 選択可能数 |
---|---|---|---|
CPU | 1core(2.0GHz) | $15/Mo | 1〜16Core |
Memory | 1GByte | $12.60/Mo | 1〜64GByte |
- ストレージの単価は、こちらの記事を参照して下さい。
[仮想サーバのストレージ費用比較] (http://niccloud.niandc.ne.jp/?p=1210)
ストレージについて
仮想サーバのストレージの種類には「Local」ディスクと「SAN」ディスクの2種類が選択できます。これは一般的な仮想化の構成と同じに考えていただくのと同じで、「Local」の場合はハイパーバイザーが稼働するハードウェアの「内蔵」ストレージです。「SAN」はハイパーバイザーに接続されているネットワークストレージを意味します。
東京データセンターでは、この「Local」ストレージがSSDで構成されているということなので実測としてどの程度の速度が出るのかをFioで計測してみたいと思います。また同様の構成で「SAN」ディスクを選択した場合を比較します。
測定の結果は、実測であり性能を保証するものではありません
パフォーマンス測定
測定に際してOSは Ubuntu14.04を利用しています。またFIOをストレージについては全て ext4 でフォーマットされている状態としています。その他のチューニング等は実施してない状態です。
Unixbenchの測定結果
東京データセンターでの仮想サーバのCPUスペックは以下の様になっていました。
System: testfio: GNU/Linux
OS: GNU/Linux -- 3.13.0-48-generic -- #80-Ubuntu SMP Thu Mar 12 11:16:15 UTC 2015
Machine: x86_64 (x86_64)
Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
CPU 0: Intel(R) Xeon(R) CPU E5-2683 v3 @ 2.00GHz (4000.1 bogomips)
Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET
06:46:57 up 2:19, 1 user, load average: 0.13, 0.14, 0.26; runlevel 2
CPU Core数 | UnixBenchスコア |
---|---|
1 | 505 |
2 | 865.5 |
16 | 2665.8 |
fioの測定結果
SANタイプのストレージの場合には、仮想サーバのネットワークインターフェースの帯域の影響を見るために100Mbps/1Gbpsの2タイプを測定しています。
測定指標 | Local | SAN(NW Link:100Mbps) | SAN(NW Link:1Gbps) |
---|---|---|---|
ランダムリード(4K) | 29394 | 17409 | 21503 |
ランダムライト(4k) | 25758 | 21808 | 25869 |
シーケンシャルリード(4k) | 41079 | 23695 | 25454 |
シーケンシャルライト(4k) | 39854 | 26472 | 25527 |
リード(帯域) | 586MByte/s | 204MByte/s | 209MByte/s |
ライト(帯域) | 641MByte/s | 400MByte/s | 434MByte/s |
「Local」タイプは、もっと低レイテンシであることを期待していましたが実際には「SAN」タイプと比べてシーケンシャルアクセスでは差がでていますがランダムアクセスでは差が出ていません。
帯域についてははやりローカル接続されているストレージであるということで2倍以上の帯域が有ることが確認できました。
おまけ
補足としてよくあるパターンでRAID-0構成を組んでみました。SANタイプのストレージは合計4本を追加出来きます。
root@splunk:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 25G 0 disk
├─xvda1 202:1 0 243M 0 part /boot
└─xvda2 202:2 0 24.8G 0 part /
xvdb 202:16 0 2G 0 disk
└─xvdb1 202:17 0 2G 0 part [SWAP]
xvdc 202:32 0 10G 0 disk
xvde 202:64 0 10G 0 disk
xvdf 202:80 0 10G 0 disk
xvdg 202:96 0 10G 0 disk
root@splunk:~# /sbin/mdadm --create /dev/md0 --chunk=256 --level=0 --raid-devices=4 /dev/xvdc /dev/xvde /dev/xvdf /dev/xvdg
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
今回はこのようにして出来た/dev/md0を同様にフォーマットして計測してみました。
測定指標 | SAN(1本) | SAN(4本RAID0) | SAN(4本RAID0)/Link:1G) |
---|---|---|---|
ランダムリード(4K) | 17409 | 28322 | 29293 |
ランダムライト(4k) | 21808 | 33048 | 31906 |
シーケンシャルリード(4k) | 23695 | 28965 | 30131 |
シーケンシャルライト(4k) | 26472 | 30659 | 32620 |
リード(帯域) | 204MByte/s | 258MByte/s | 308MByte/s |
ライト(帯域) | 400MByte/s | 664MByte/s | 697MByte/s |
ネットワークのリンク速度を1Gにした状態で 30K IOPS程度となりました。
まとめ
CPUについてはUnixbenchの結果的にはリニアに性能が向上して行くのがわかりました。ディスクに関しては「Local」がもう少しIOPSが高いと思っていましたが現状では、帯域が必要なアプリケーションでない場合には「Local」を選択するよりは耐障害性がある程度ある「SAN」ストレージを選択するのが良いことがわかりました。
仮想サーバは、CPU、メモリそしてストレージが自由に選択できますので今回のパフォーマンス結果を参考にモデルを選択していただければと思います。また実際に利用開始後もリソースは、「Upgrade/Downgrade」することが出来るのも魅力なのでぜひご活用下さい。
SoftLayerの場合には仮想サーバも中規模になると、物理サーバ(ベアメタルサーバ)の一番下のレベルのサーバがオーダできる費用になるため今度はベアメタルサーバとの比較も実施して行きます。