2012年 06月 29日
SSD は仮想環境で実力を出すか SUSE+XEN で検証してみた
SUSE+XEN で作るプライベートクラウドのハードウェア選びのポイントという無責任な記事を書いたので、SSD が仮想サーバーの性能にどう影響するかをテストしてみました。
物理サーバー
CPU: 2/4 スレッド i5-3570T CPU @ 2.30GHz 2/4 スレッドTDP 45W
HDD: Hitachi製 7,200rpm Cache 16M
Memory: 8Gb
OS: SLES11sp2 Linux +XEN (Kernel 3.13 XEN 4.1.2)
低予算、低カロリー、低姿勢の「水曜どうでしょう」的なマシンです。
比較のため利用したSSD
SSD:ADATA SP900 ASP900 シリーズ SATA3 R:550MB/s, W:520MB/s をマウントしました。
仮想サーバー１
SLES11sp1 ベースの Novell OES11 (Novell Openenterprise Server)を +addon し 4vcpu 3G memory で準仮想化し、HDDに作成したボリュームとSSDにNSSボリュームを作成しNCPプロトコルを使います。
仮想サーバー２
今回は Windows 2003 に HDD と SSD で作った仮想ディスクイメージをドライブとして作成しました。
条件を同じくするため 4vcpu 3G メモリです。Novell のWindows 用、準仮想化ドライバ Virtual Machine Driver (VMDP1.7) をインストールしています。プロトコルはCIFSです。
クライアント環境
CPU:Core i3 2330M 2.2Ghz 2/2 スレッド
memory: 8Gb
一般的なノートブックです。
これらを CAT6と7 のケーブルで メタル筐体の 1Gb HUB に接続しました。
テストデータ
テストに利用したデータは Windows 7-32 の iso イメージ、約 2.3Gb です。
-実マシンの場合-
SLES+Samba にクライアントから直接 CIFS コピー
SSD >
Write - 21.3 sec
Read - 24.0 sec
HDD>
Write - 33.5 sec
Read - 27.0 sec
見た目ではHDDの書き込み以外、それほど大きな差はありませんでした。ネットワークの負荷は常時 80% 前後を示しています。帯域を「使い切っている」感がありました。ネットワークの負荷は若干、山と谷が HDD では出ています。HDDかSSDかの違いよりも、どれだけキャッシュができるかの違いがあります。
OES11 Linux の場合
仮想化された Novell OES11 Linux のボリュームをSSDに作りローカルから SSDとHDD 上の NSS ボリュームへの NCP プロトコルアクセス
SSD>
Write - 49.2 sec
Read - 51.1 sec
HDD>
write - 45.5 sec
read - - 1,05.0 sec
Novell OES 11 の場合、あまり読み書きに極端な差は出ませんでした。
ただし、ネットワークI/Oの状態を見ると、HDD では、山と谷ができていて、iowait が出ていることがわかります。ネットワークの負荷状態はどちらも 50% 前後です。
Windows の場合
3-1) 仮想化された Windows の SDD 上の NFFS ボリュームに CIFS アクセス
>SSD
Write - 2,00.4 sec
Read - 28.4
>HDD
Write 3,45.1 sec
Read 33,2.0 sec
書き込み速度は圧倒的に明らかに遅く、読み出し速度は逆に驚くほど早くそれほど変化はありません。
書き込みは 1Gbe でネットワーク I/O はどちらもギザギザの山が多く、かなり効率が悪いことがわかりますが、どちらも読み出しにはほとんど山がなく、安定して高速です。
書き込み操作は常時 12.5% 前後で推移しています。
参考値として Windows 同志の場合
Core2 Duo 4G メモリWindows 8 PR 版マシンから Core i3 2core 8G マシンの「共有」フォルダへのアクセスです。SSD 未装着の 2'5inch HDD 同志のアクセスです。
Write - 43.0 sec
Read - 1,24.0 sec
書き込みはなぜか仮想マシンより、早く、読み出しは逆に遅くなっています。これは「ユーザから見た」Windows が 8G のメモリを用意しており、十分なキャッシュ速度を出しており、逆に「こちら側」の性能が低く、読みだした後の書き込みが遅いことが原因なのでしょうか。コピー速度とネットワークのトラフィックが両方見れるため非常によくわかるのですが、初速が速く、あとはノンビリしています。後半ほとんど 12.5% 程度のトラフィックで遷移しています。
仮想マシンの作成
SLES11sp2 の仮想マシンイメージの作成を行う場合、仮想ディスクとインストール用 iso ファイル(約 3.3Gb)をSSD に置いた場合と、HDD で普通に作った場合です。インストールを開始し、特にオプションを選ばず、インストール開始ボタンを押してフォーマットを始めるタイミングからリブートの確認ボタンが出てくるまでの時間です。
>SSD 6,41.0 sec
>HDD 23,36.0 sec
これだけの作業になると本当に大きな差が出ました。仮想マシンのインストールだからと言ってノンビリとコーヒータイムも取れない時間です。
また、SSDを使うとリブート後の最終設定、SUSEconfig の書き込みなども非常に軽快でした。
仮想サーバの納期を短くするには SSD は良い選択です。
--
シーケンシャルアクセスばかりのテストですが、「サーバーの性能」はキャッシュとして使える OS メモリの多寡に左右されることがよくわかります。それほど HDD なのか SSD なのかの差は出ませんでした。もっともクライアントが１台しかない環境なのでこれが全てではありません。
明らかに HDD より SSD の方が速いケースが多いわけですが、2.3Gb という巨大なファイルアクセスですから、ディスクの性能よりも OS のメモリの方が有効だと言えそうです。
今回はコンスーマ向けの「安い省電力マシン」を使ったわけですが、サーバ向けの XEON + SAS 15,000 rpm Raid1ミラー構成のハードウェアであれば、SSD との差はどれほど出たでしょうか。顧客先で使うシステムはほとんどサーバー向け XEON+SATA の DAS 構成なので、運用面で問題を聞いたこともないですし、メンテナンスもそれほど「遅い」と感じたことはありません。
ただ、SATA-HDD も SATA-SSD もアクセス中の iowait は大きく、単に「円盤ではない」以外の I/F の規格の限界を感じました。
iSCSI は SUSE 仮想環境でファイルサーバとして使い物になるか
というテスト記事を２年半前に書きました。この時は iSCSI は Windows では使い物にならないと結論づけましたが、仮想マシン上にDAS接続されているディスクであれば、十分に高速であること。と言えます。逆に Windows に iSCSI は向かない事を感じます。実際この数年間 Windows + iSCSI での運用でトラブルやデータの損失何度も経験しているので、お勧めはできません。 Windows の iSCSI イニシエータの出来の悪さを感じます。
また、Windows 共有ではやっぱり初速は出るが、結局 12.5% の壁は破れないこと。これは特に低スペックのマシンでは日頃感じることで、「お遊び用」の AMD E-450 軽量マシンではファイルの CIFS コピーを行うと必ず CPU の負荷は 100% になります。
原因はなぜなのでしょうかね。NTFS の性能なのか CIFS の性能なのかは不明です。ただ条件が良い場合であれば Samba への書き込みが速いことを考えると一辺に CIFS は遅いとは言い切れないような気がします。
OES Linux ではあまりそのような事故は経験しませんでした。（オペミスを除く）
これがクローズドソースの Windows 製品と「他人からいつも見られている」オープンソースの製品の出来の違いなのでしょうか。
--
もっとも SSD の効果を「実感」できたのは、仮想マシンの作成作業です。シーケンシャルアクセスとランダムアクセスの多いこの作業が実質 1/3 から 1/4 でできたことは大変評価しています。特に YaST でのGUIインストール/設定のレスポンスの良さは非常に好感がありました。
一般的な「シンクライアント」環境を構築する場合、SSDは仮想環境で有効である、と思います。システムのインストールは、ユーザさんの操作そのものです。ただし、書き込み回数の制限からどれだけ耐久性があるか不安要素は沢山あるため、業務終了後に 「SSD から HDD に仮想マシンイメージをバックアップしておく体制」は考えておきたいところです。
HP ProLiant用SSD、PCIe IOアクセラレータ製品の標準保証期間
サーバーハードウェアにSSDを搭載して、ブートドライブとしても、Power On から Bios のシーケンスに時間がかかり、そのあとカーネルを読み込み、周辺機器を検出する部分で、CPUやDMAチップの性能を使うわけで、カーネル（といってもわずか数十メガバイト）といくつかのサービスプログラムを読み込むためだけに SSD を使っても、起動時間全体のわずか１０数パーセントしか向上できないだろうと予測しています。
またデータドライブとした場合も信頼性と耐久性の問題で「検討すべきではない」と考えています。パフォーマンスの向上のためであれば、サーバーRAMを大目に、仮想マシンもメモリは大目にがポイントだと思います。
それよりも、サーバハードウェアにSSDを効果的に使うのならSSDキャッシュでしょう。これなら特定のファイルアクセスのキャッシュ効果を望む以上の効果が期待できそうです。もっとも「消耗品」であり、故障したときの信頼性、継続性に難はありそうですが、全体的なパフォーマンスの向上には期待できそうです。
SSDについては Windows で「これだけ起動が速くなった」とか「単体ベンチマークでこれだけの速度が出た」という記事か、ハードウェアベンダーのよいしょ記事しか見ないので、システム管理者ではな「エンドユーザがどれだけ「快適に使えるか」ということを目的に検証してみたつもりです。「使える」ことと「快適で使いやすい」は別な意味です。「使えても快適ではない」システムは敬遠され、いずれ高価な投資が無駄になる危険があります。
今後は Web サイトの構築もクラウドを意識した「仮想マシン全体」を納品するケースが増えるでしょう。単なる「Webデザイナー」では成立しにくくなっています。Web サイトのデザイン、連携、構築といった作業も SSD を使えばかなり納期の短縮に役立つでしょう。
-Keyword-
SUSE SLES Linux XEN OES Openenterprise Server 11 仮想化 SSD SSHキャッシュ HDD 効果 違い シンクライアント Novell VMDP
islandcenter.jp
物理サーバー
CPU: 2/4 スレッド i5-3570T CPU @ 2.30GHz 2/4 スレッドTDP 45W
HDD: Hitachi製 7,200rpm Cache 16M
Memory: 8Gb
OS: SLES11sp2 Linux +XEN (Kernel 3.13 XEN 4.1.2)
低予算、低カロリー、低姿勢の「水曜どうでしょう」的なマシンです。
比較のため利用したSSD
SSD:ADATA SP900 ASP900 シリーズ SATA3 R:550MB/s, W:520MB/s をマウントしました。
仮想サーバー１
SLES11sp1 ベースの Novell OES11 (Novell Openenterprise Server)を +addon し 4vcpu 3G memory で準仮想化し、HDDに作成したボリュームとSSDにNSSボリュームを作成しNCPプロトコルを使います。
仮想サーバー２
今回は Windows 2003 に HDD と SSD で作った仮想ディスクイメージをドライブとして作成しました。
条件を同じくするため 4vcpu 3G メモリです。Novell のWindows 用、準仮想化ドライバ Virtual Machine Driver (VMDP1.7) をインストールしています。プロトコルはCIFSです。
クライアント環境
CPU:Core i3 2330M 2.2Ghz 2/2 スレッド
memory: 8Gb
一般的なノートブックです。
これらを CAT6と7 のケーブルで メタル筐体の 1Gb HUB に接続しました。
テストデータ
テストに利用したデータは Windows 7-32 の iso イメージ、約 2.3Gb です。
-実マシンの場合-
SLES+Samba にクライアントから直接 CIFS コピー
SSD >
Write - 21.3 sec
Read - 24.0 sec
HDD>
Write - 33.5 sec
Read - 27.0 sec
見た目ではHDDの書き込み以外、それほど大きな差はありませんでした。ネットワークの負荷は常時 80% 前後を示しています。帯域を「使い切っている」感がありました。ネットワークの負荷は若干、山と谷が HDD では出ています。HDDかSSDかの違いよりも、どれだけキャッシュができるかの違いがあります。
OES11 Linux の場合
仮想化された Novell OES11 Linux のボリュームをSSDに作りローカルから SSDとHDD 上の NSS ボリュームへの NCP プロトコルアクセス
SSD>
Write - 49.2 sec
Read - 51.1 sec
HDD>
write - 45.5 sec
read - - 1,05.0 sec
Novell OES 11 の場合、あまり読み書きに極端な差は出ませんでした。
ただし、ネットワークI/Oの状態を見ると、HDD では、山と谷ができていて、iowait が出ていることがわかります。ネットワークの負荷状態はどちらも 50% 前後です。
Windows の場合
3-1) 仮想化された Windows の SDD 上の NFFS ボリュームに CIFS アクセス
>SSD
Write - 2,00.4 sec
Read - 28.4
>HDD
Write 3,45.1 sec
Read 33,2.0 sec
書き込み速度は圧倒的に明らかに遅く、読み出し速度は逆に驚くほど早くそれほど変化はありません。
書き込みは 1Gbe でネットワーク I/O はどちらもギザギザの山が多く、かなり効率が悪いことがわかりますが、どちらも読み出しにはほとんど山がなく、安定して高速です。
書き込み操作は常時 12.5% 前後で推移しています。
参考値として Windows 同志の場合
Core2 Duo 4G メモリWindows 8 PR 版マシンから Core i3 2core 8G マシンの「共有」フォルダへのアクセスです。SSD 未装着の 2'5inch HDD 同志のアクセスです。
Write - 43.0 sec
Read - 1,24.0 sec
書き込みはなぜか仮想マシンより、早く、読み出しは逆に遅くなっています。これは「ユーザから見た」Windows が 8G のメモリを用意しており、十分なキャッシュ速度を出しており、逆に「こちら側」の性能が低く、読みだした後の書き込みが遅いことが原因なのでしょうか。コピー速度とネットワークのトラフィックが両方見れるため非常によくわかるのですが、初速が速く、あとはノンビリしています。後半ほとんど 12.5% 程度のトラフィックで遷移しています。
仮想マシンの作成
SLES11sp2 の仮想マシンイメージの作成を行う場合、仮想ディスクとインストール用 iso ファイル(約 3.3Gb)をSSD に置いた場合と、HDD で普通に作った場合です。インストールを開始し、特にオプションを選ばず、インストール開始ボタンを押してフォーマットを始めるタイミングからリブートの確認ボタンが出てくるまでの時間です。
>SSD 6,41.0 sec
>HDD 23,36.0 sec
これだけの作業になると本当に大きな差が出ました。仮想マシンのインストールだからと言ってノンビリとコーヒータイムも取れない時間です。
また、SSDを使うとリブート後の最終設定、SUSEconfig の書き込みなども非常に軽快でした。
仮想サーバの納期を短くするには SSD は良い選択です。
--
シーケンシャルアクセスばかりのテストですが、「サーバーの性能」はキャッシュとして使える OS メモリの多寡に左右されることがよくわかります。それほど HDD なのか SSD なのかの差は出ませんでした。もっともクライアントが１台しかない環境なのでこれが全てではありません。
明らかに HDD より SSD の方が速いケースが多いわけですが、2.3Gb という巨大なファイルアクセスですから、ディスクの性能よりも OS のメモリの方が有効だと言えそうです。
今回はコンスーマ向けの「安い省電力マシン」を使ったわけですが、サーバ向けの XEON + SAS 15,000 rpm Raid1ミラー構成のハードウェアであれば、SSD との差はどれほど出たでしょうか。顧客先で使うシステムはほとんどサーバー向け XEON+SATA の DAS 構成なので、運用面で問題を聞いたこともないですし、メンテナンスもそれほど「遅い」と感じたことはありません。
ただ、SATA-HDD も SATA-SSD もアクセス中の iowait は大きく、単に「円盤ではない」以外の I/F の規格の限界を感じました。
iSCSI は SUSE 仮想環境でファイルサーバとして使い物になるか
というテスト記事を２年半前に書きました。この時は iSCSI は Windows では使い物にならないと結論づけましたが、仮想マシン上にDAS接続されているディスクであれば、十分に高速であること。と言えます。逆に Windows に iSCSI は向かない事を感じます。実際この数年間 Windows + iSCSI での運用でトラブルやデータの損失何度も経験しているので、お勧めはできません。 Windows の iSCSI イニシエータの出来の悪さを感じます。
また、Windows 共有ではやっぱり初速は出るが、結局 12.5% の壁は破れないこと。これは特に低スペックのマシンでは日頃感じることで、「お遊び用」の AMD E-450 軽量マシンではファイルの CIFS コピーを行うと必ず CPU の負荷は 100% になります。
原因はなぜなのでしょうかね。NTFS の性能なのか CIFS の性能なのかは不明です。ただ条件が良い場合であれば Samba への書き込みが速いことを考えると一辺に CIFS は遅いとは言い切れないような気がします。
OES Linux ではあまりそのような事故は経験しませんでした。（オペミスを除く）
これがクローズドソースの Windows 製品と「他人からいつも見られている」オープンソースの製品の出来の違いなのでしょうか。
--
もっとも SSD の効果を「実感」できたのは、仮想マシンの作成作業です。シーケンシャルアクセスとランダムアクセスの多いこの作業が実質 1/3 から 1/4 でできたことは大変評価しています。特に YaST でのGUIインストール/設定のレスポンスの良さは非常に好感がありました。
一般的な「シンクライアント」環境を構築する場合、SSDは仮想環境で有効である、と思います。システムのインストールは、ユーザさんの操作そのものです。ただし、書き込み回数の制限からどれだけ耐久性があるか不安要素は沢山あるため、業務終了後に 「SSD から HDD に仮想マシンイメージをバックアップしておく体制」は考えておきたいところです。
HP ProLiant用SSD、PCIe IOアクセラレータ製品の標準保証期間
サーバーハードウェアにSSDを搭載して、ブートドライブとしても、Power On から Bios のシーケンスに時間がかかり、そのあとカーネルを読み込み、周辺機器を検出する部分で、CPUやDMAチップの性能を使うわけで、カーネル（といってもわずか数十メガバイト）といくつかのサービスプログラムを読み込むためだけに SSD を使っても、起動時間全体のわずか１０数パーセントしか向上できないだろうと予測しています。
またデータドライブとした場合も信頼性と耐久性の問題で「検討すべきではない」と考えています。パフォーマンスの向上のためであれば、サーバーRAMを大目に、仮想マシンもメモリは大目にがポイントだと思います。
それよりも、サーバハードウェアにSSDを効果的に使うのならSSDキャッシュでしょう。これなら特定のファイルアクセスのキャッシュ効果を望む以上の効果が期待できそうです。もっとも「消耗品」であり、故障したときの信頼性、継続性に難はありそうですが、全体的なパフォーマンスの向上には期待できそうです。
SSDについては Windows で「これだけ起動が速くなった」とか「単体ベンチマークでこれだけの速度が出た」という記事か、ハードウェアベンダーのよいしょ記事しか見ないので、システム管理者ではな「エンドユーザがどれだけ「快適に使えるか」ということを目的に検証してみたつもりです。「使える」ことと「快適で使いやすい」は別な意味です。「使えても快適ではない」システムは敬遠され、いずれ高価な投資が無駄になる危険があります。
今後は Web サイトの構築もクラウドを意識した「仮想マシン全体」を納品するケースが増えるでしょう。単なる「Webデザイナー」では成立しにくくなっています。Web サイトのデザイン、連携、構築といった作業も SSD を使えばかなり納期の短縮に役立つでしょう。
-Keyword-
SUSE SLES Linux XEN OES Openenterprise Server 11 仮想化 SSD SSHキャッシュ HDD 効果 違い シンクライアント Novell VMDP
islandcenter.jp
by islandcenter
| 2012-06-29 15:01
| SUSE
|
Comments(0)
