2013年 07月 07日
SUSE+XEN で作るプライベートクラウドのハードウェア選びのポイント
この６、７年、SUSE+XEN という仮想化システムに携わり、かつLANの黎明期から従事してきた経験から、プライベートクラウドに必要なハードウェアや問題点をまとめてみました。突っ込みどころ満載なので、コメントいただけると幸いです。
-ディスクはケチるな-
まず、HDDの速度はケチってはいけません。# sar 1 -p コマンドで見ている限り、「遅い」と感じるのはほとんどディスクのIOです。できれば 15,000 rpm の 3.5inch SAS HDD の一番大きなサイズのものをRAID1 （二重）構成したものをお勧めします。安くても 7,200 rpm の SATA ディスクを使うとひどい目に逢います。できればRAID コントローラもお金を掛けたいところです。
もちろんサービスレベルと予算、規模、利用量の問題もあるので、必ずそうだとは言い切れないことは承知しています。
問題は SATA も SSD も、ハードウェアベンダーとしては「消耗品」扱いしている点です。
HP の場合はSSDの最大保障期間３年＋アクセスバイト数によって保障期間が決まっています。
HP ProLiant用SSD、PCIe IOアクセラレータ製品の標準保証期間
特に MLC タイプの保障期間は短いようです。一般的には MLC より一桁値段が違う SLC タイプの方が長期利用できそうです。固定データのインフラ系サーバや、開発用で保存容量が必要なければ、DRAM をたっぷり乗せて RAMディスクを使った方が安そうですね。
Dell のストレージシステムも SATA ディスクは１年保障です。
壊れた時点でアウトだし、延長保障もなければ５年で償却したいサーバ向けのディスクではありません。
SSD の歴史はまだ短くサーバーでの実績もありません。「壊れることが前提」で構築すべきです。
一般的な（古い言い方で）「SCSI」 はタグ・キューイングの機能を持っており、SCSI をシリアル化した、SAS にもそのその機能は継続されています。
タグキューイングというのは、昔 NetWare 時代に有名になったエレベーターシーキングのようなものですね。とても長い歴史があります。エレベータは「行き先階を押したものの早いもの勝ち」ではなく、みんなが１階で「押された順番に関わらずランプのついた階には順番で止まる」というHDDシークを効率化するマルチタスクには必須の機能です。ヘッダの動きと円盤の動きを見て、リクエスト順ではなく、もっとも短い経路で拾ってくるセクタを優先する方法です。ランダムアクセスには絶大な威力を発揮します。
この機能は圧倒的にディスクそのもののマルチタスク性能に影響します。
ところがシングルタスクを基本とした ATA を基にした SATA にも Native Command Cueing という機能が実装されていますが、DMA コントローラの制御にいちいちＣＰＵが関与しなければならないようで、「負荷が高くなりがち」になるようです。
Tagged Command Queuing英語版 Wikipedia
よく、SOHO や コンスーマ向けのNAS を真面目に「ファイルサーバー」と称しているお客様を見ますが、どこか勘違いしているようです。コストを掛けられないなら、バックアップを毎日取るなりの「人的コスト」をかけて欲しいものです。
本来は SSD を使ってみたいものですが、読み出し性能は良いとしても、書き込み性能に問題があればお勧めできないし、通常書き込み量に応じて保障期間が決まっているので、SSDは消耗品として割り切って仮想化システムのブートシステムとして構築すべきです。「いつ壊れても困らない」仮想イメージを保存して、定期的にHDDにバックアップするのが良いでしょう。どうせ３年しか使えない記憶装置です。
Linux システムなら６～１０Gほどで十分ですから、停止から再起動までの時間も数分で済みます。困るのは Windows 7/2008 系です。システムだけで３０G程度用意しないといけないので、バックアップ時間も停止時間も、用意するSSDの容量も考慮しなければなりません。もっとも Windows サーバーはパフォーマンスがよくないので、無理してSSDを使う必要はないというご意見もあります。どうせアイドリングしていても頻繁に細かな書き込みがあるのでSSD化はちょっと問題ありですね。
どっちにしても、同じ円盤の中にファイルコピーするより違うデバイスにコピーしたほうが性能がきっちり出ます。
SATAディスクはシーケンシャル書き込みには強いのですが、読み出し性能に問題がありそうなので、単純な「バックアップ用ファイルサーバー」として考えて良いでしょう。一日１回しか動かないシステムだとすれば、発熱もパフォーマンスもそれほど要求しません。
-意外と使わないCPU性能-
sar 1 -p コマンドを実行して観察していると、ほとんどのお客さんの仮想サーバーのＣＰＵの利用率は 1% 以下です。つまりほとんど働いていない。情報系のシステムとはそんなものですね。タマに90% を割り込むことがありますが、ほとんど %iowait の時間です。つまり、どれだけ i//o が重要かがよくわかります。コア数が少ないと、コアを奪い合う %steal の量が増えます。安い SATA ディスクと貧弱なCPUを使った当所のテスト環境では如実に出てきます。
そもそもインフラ系のサーバーは、IO 性能より「あればいい」程度のサーバなのであまりリッチな環境は必要としません。DNS や ドメインコントローラがどれほど重要かと言っても、冗長性が重要で、性能ではありません。
ただし、コア数が多いとそれなりに「サーバを詰め込む」ことができるので、低電圧、低電源、多コアのハードウェアをお勧めしています。所詮ファイルサーバのＩＯはメモリの多寡に左右されますし、マザーボードを始めとしたＩＯのＤＭＡクロック転送速度が問題となるので、同じマザーボードなら制御のためのＣＰＵ性能はあまり重要視されるものではありません。同じマザーボードなら「そこそこ早くて安くて電源食わない低クロック低発熱ＣＰＵ」をお勧めしています。
-一番難しいクライアント仮想化-
クライアント仮想化、いわゆるシン･クライアントは、BYODのニーズともマッチし、ホットで一番悩む問題です。何しろ小さいファイルアクセスがガリガリとあり、ＧＰＵ性能も必要で、軽い動作ならまだしも、ディープなバッチ処理もこなさなければなりません。
しかし非力なマシンやタブレットからも、強大なマシンパワーを使えるというメリットが出てきます。特にメディア系の時間がかかるエンコード処理だとか高度な画像処理なんかですね。もっとも最終的な処理は手元のハイエンドマシンで行う必要はあるでしょう。高解像度の処理をどうするかが今後の問題です。こうなるとやはりCP性能とディスク性能がモノを言うわけです。
大事なのは、ユーザのグルーピングです。ヘビーユーザなのかライトユーザなのかで構成を考えてみることです。レスポンスを重要視するか、バッチ処理を優先するかです。混在すると、色々問題が出てきそうです。
Windows7 sp1 では remoteFX の機能が搭載されました。これはサーバー側のGPUの機能で３Dグラフィックスを利用できる機能ですが、一般的な「サーバーハードウェア」はCUIや「映ればいい」程度のグラフィックス性能しか持ち合わせていません。逆にコンスーマ向けグリグリゲームマシンであれば高価なグラフィックスカードがモノを言います。私の手元の機材では XEN+Windows 2008 R2 環境でも Google Earth の 3D 描画がうまく動きました。これは AMD のCPUに内蔵されたGPUの性能のおかげです。
サーバにそこそこのGPUを追加して乗せた場合、ノマドワークやシンクライアントでのリモート３D機能も試してみたいところです。
-意外と進まないクライアントの 1Gbe 化-
かつて１時間にパッチケーブルを１００本終端加工する職人の凄技というのを見たことがありますが、ケーブルのフロア敷設というのは結構面倒なものです。パイプに通線する際は裸線を配線してから終端をモジュラなりローゼット加工しなければなりません。モジュラーをつけた状態では床下やパイプ配線は不可能です。通線してから終端加工をします。
１００Mbeの時代なら、まだ終端加工もマージンがありましたが、１Gbeの時代では、なかなか職人技を必要とします。ＣＡＴ６以上のクラスになると単線の「撚り」をほどいて圧着するには素人ではまず無理です。シールドもぎりぎりまで残さなければなりません。何しろ数ミリ単位で加工が必要です。
私は壊れたＣＡＴ６のモジュラを自分で圧着して１００Ｍしか出なかった時はショックでした。そのあたりのＰＣショップで売っているプラグや圧着工具では、まず1Gbeの速度は出ません。秋葉原の「愛三電気」の親父に「工具が違うんだよ」って怒られそうですね。「アカアオオレシロミドアオ...」とついに覚えられなかった素人配線ですが。ケーブルは導線の性能だけではありません。ローゼットやプラグのカシメのテクニックがモノを言います。職人技ですから工賃が高価になります。よく素人ブログで「自作ケーブル」の記事を見ますが、「繋がった」とヨロコンでいるだけで、性能までは評価されていないようです。
ということでデスクトップマシンもＨＵＢも Gbe 化しているにも関わらず、床下配線はＣＡＴ５というところはまだ意外と多いようです。それほど高度な「職人さん」がいないということですね。引っ越したばかりのオフィスであればCAT6配線も発注できますが、１０年前に引っ越したオフィスビルでは未だにCAT5クラスでしょう。
こういったところでサーバルーム内でファイルサーバと、工場加工出荷されたケーブルで直接配線されているシン･クライアントは威力を発揮します。
ということで、ほとんどの場合フル1Geという恵まれた状況はなかなかなく、途中に遅いケーブルやHUBが介在するわけですね。
ただし、画面転送の速度が遅いと利用者側はいらつくでえしょう。目の前のマシンならリブートしてしまえば良い話なのですが、リモートマシンは簡単にリブートというわけにはいかないのですね。Windows を使う以上、「使っていると重くなる」のは必然的なことで、定期的なバックアップや再起動といった処理が必要となるか、管理者がクレームを把握して再起動するなどの処理が重要になります。
今はBYODの世の中ですから、タブレットからちょっとこの処理がをしたいとかと言ったニーズが増えることも考慮しなければなりません。
ということでSSD は仮想環境で実力を出すか SUSE+XEN で検証してみました。
islandcenter.jp
-ディスクはケチるな-
まず、HDDの速度はケチってはいけません。# sar 1 -p コマンドで見ている限り、「遅い」と感じるのはほとんどディスクのIOです。できれば 15,000 rpm の 3.5inch SAS HDD の一番大きなサイズのものをRAID1 （二重）構成したものをお勧めします。安くても 7,200 rpm の SATA ディスクを使うとひどい目に逢います。できればRAID コントローラもお金を掛けたいところです。
もちろんサービスレベルと予算、規模、利用量の問題もあるので、必ずそうだとは言い切れないことは承知しています。
問題は SATA も SSD も、ハードウェアベンダーとしては「消耗品」扱いしている点です。
HP の場合はSSDの最大保障期間３年＋アクセスバイト数によって保障期間が決まっています。
HP ProLiant用SSD、PCIe IOアクセラレータ製品の標準保証期間
特に MLC タイプの保障期間は短いようです。一般的には MLC より一桁値段が違う SLC タイプの方が長期利用できそうです。固定データのインフラ系サーバや、開発用で保存容量が必要なければ、DRAM をたっぷり乗せて RAMディスクを使った方が安そうですね。
Dell のストレージシステムも SATA ディスクは１年保障です。
壊れた時点でアウトだし、延長保障もなければ５年で償却したいサーバ向けのディスクではありません。
SSD の歴史はまだ短くサーバーでの実績もありません。「壊れることが前提」で構築すべきです。
一般的な（古い言い方で）「SCSI」 はタグ・キューイングの機能を持っており、SCSI をシリアル化した、SAS にもそのその機能は継続されています。
タグキューイングというのは、昔 NetWare 時代に有名になったエレベーターシーキングのようなものですね。とても長い歴史があります。エレベータは「行き先階を押したものの早いもの勝ち」ではなく、みんなが１階で「押された順番に関わらずランプのついた階には順番で止まる」というHDDシークを効率化するマルチタスクには必須の機能です。ヘッダの動きと円盤の動きを見て、リクエスト順ではなく、もっとも短い経路で拾ってくるセクタを優先する方法です。ランダムアクセスには絶大な威力を発揮します。
この機能は圧倒的にディスクそのもののマルチタスク性能に影響します。
ところがシングルタスクを基本とした ATA を基にした SATA にも Native Command Cueing という機能が実装されていますが、DMA コントローラの制御にいちいちＣＰＵが関与しなければならないようで、「負荷が高くなりがち」になるようです。
Tagged Command Queuing英語版 Wikipedia
よく、SOHO や コンスーマ向けのNAS を真面目に「ファイルサーバー」と称しているお客様を見ますが、どこか勘違いしているようです。コストを掛けられないなら、バックアップを毎日取るなりの「人的コスト」をかけて欲しいものです。
本来は SSD を使ってみたいものですが、読み出し性能は良いとしても、書き込み性能に問題があればお勧めできないし、通常書き込み量に応じて保障期間が決まっているので、SSDは消耗品として割り切って仮想化システムのブートシステムとして構築すべきです。「いつ壊れても困らない」仮想イメージを保存して、定期的にHDDにバックアップするのが良いでしょう。どうせ３年しか使えない記憶装置です。
Linux システムなら６～１０Gほどで十分ですから、停止から再起動までの時間も数分で済みます。困るのは Windows 7/2008 系です。システムだけで３０G程度用意しないといけないので、バックアップ時間も停止時間も、用意するSSDの容量も考慮しなければなりません。もっとも Windows サーバーはパフォーマンスがよくないので、無理してSSDを使う必要はないというご意見もあります。どうせアイドリングしていても頻繁に細かな書き込みがあるのでSSD化はちょっと問題ありですね。
どっちにしても、同じ円盤の中にファイルコピーするより違うデバイスにコピーしたほうが性能がきっちり出ます。
SATAディスクはシーケンシャル書き込みには強いのですが、読み出し性能に問題がありそうなので、単純な「バックアップ用ファイルサーバー」として考えて良いでしょう。一日１回しか動かないシステムだとすれば、発熱もパフォーマンスもそれほど要求しません。
-意外と使わないCPU性能-
sar 1 -p コマンドを実行して観察していると、ほとんどのお客さんの仮想サーバーのＣＰＵの利用率は 1% 以下です。つまりほとんど働いていない。情報系のシステムとはそんなものですね。タマに90% を割り込むことがありますが、ほとんど %iowait の時間です。つまり、どれだけ i//o が重要かがよくわかります。コア数が少ないと、コアを奪い合う %steal の量が増えます。安い SATA ディスクと貧弱なCPUを使った当所のテスト環境では如実に出てきます。
そもそもインフラ系のサーバーは、IO 性能より「あればいい」程度のサーバなのであまりリッチな環境は必要としません。DNS や ドメインコントローラがどれほど重要かと言っても、冗長性が重要で、性能ではありません。
ただし、コア数が多いとそれなりに「サーバを詰め込む」ことができるので、低電圧、低電源、多コアのハードウェアをお勧めしています。所詮ファイルサーバのＩＯはメモリの多寡に左右されますし、マザーボードを始めとしたＩＯのＤＭＡクロック転送速度が問題となるので、同じマザーボードなら制御のためのＣＰＵ性能はあまり重要視されるものではありません。同じマザーボードなら「そこそこ早くて安くて電源食わない低クロック低発熱ＣＰＵ」をお勧めしています。
-一番難しいクライアント仮想化-
クライアント仮想化、いわゆるシン･クライアントは、BYODのニーズともマッチし、ホットで一番悩む問題です。何しろ小さいファイルアクセスがガリガリとあり、ＧＰＵ性能も必要で、軽い動作ならまだしも、ディープなバッチ処理もこなさなければなりません。
しかし非力なマシンやタブレットからも、強大なマシンパワーを使えるというメリットが出てきます。特にメディア系の時間がかかるエンコード処理だとか高度な画像処理なんかですね。もっとも最終的な処理は手元のハイエンドマシンで行う必要はあるでしょう。高解像度の処理をどうするかが今後の問題です。こうなるとやはりCP性能とディスク性能がモノを言うわけです。
大事なのは、ユーザのグルーピングです。ヘビーユーザなのかライトユーザなのかで構成を考えてみることです。レスポンスを重要視するか、バッチ処理を優先するかです。混在すると、色々問題が出てきそうです。
Windows7 sp1 では remoteFX の機能が搭載されました。これはサーバー側のGPUの機能で３Dグラフィックスを利用できる機能ですが、一般的な「サーバーハードウェア」はCUIや「映ればいい」程度のグラフィックス性能しか持ち合わせていません。逆にコンスーマ向けグリグリゲームマシンであれば高価なグラフィックスカードがモノを言います。私の手元の機材では XEN+Windows 2008 R2 環境でも Google Earth の 3D 描画がうまく動きました。これは AMD のCPUに内蔵されたGPUの性能のおかげです。
サーバにそこそこのGPUを追加して乗せた場合、ノマドワークやシンクライアントでのリモート３D機能も試してみたいところです。
-意外と進まないクライアントの 1Gbe 化-
かつて１時間にパッチケーブルを１００本終端加工する職人の凄技というのを見たことがありますが、ケーブルのフロア敷設というのは結構面倒なものです。パイプに通線する際は裸線を配線してから終端をモジュラなりローゼット加工しなければなりません。モジュラーをつけた状態では床下やパイプ配線は不可能です。通線してから終端加工をします。
１００Mbeの時代なら、まだ終端加工もマージンがありましたが、１Gbeの時代では、なかなか職人技を必要とします。ＣＡＴ６以上のクラスになると単線の「撚り」をほどいて圧着するには素人ではまず無理です。シールドもぎりぎりまで残さなければなりません。何しろ数ミリ単位で加工が必要です。
私は壊れたＣＡＴ６のモジュラを自分で圧着して１００Ｍしか出なかった時はショックでした。そのあたりのＰＣショップで売っているプラグや圧着工具では、まず1Gbeの速度は出ません。秋葉原の「愛三電気」の親父に「工具が違うんだよ」って怒られそうですね。「アカアオオレシロミドアオ...」とついに覚えられなかった素人配線ですが。ケーブルは導線の性能だけではありません。ローゼットやプラグのカシメのテクニックがモノを言います。職人技ですから工賃が高価になります。よく素人ブログで「自作ケーブル」の記事を見ますが、「繋がった」とヨロコンでいるだけで、性能までは評価されていないようです。
ということでデスクトップマシンもＨＵＢも Gbe 化しているにも関わらず、床下配線はＣＡＴ５というところはまだ意外と多いようです。それほど高度な「職人さん」がいないということですね。引っ越したばかりのオフィスであればCAT6配線も発注できますが、１０年前に引っ越したオフィスビルでは未だにCAT5クラスでしょう。
こういったところでサーバルーム内でファイルサーバと、工場加工出荷されたケーブルで直接配線されているシン･クライアントは威力を発揮します。
ということで、ほとんどの場合フル1Geという恵まれた状況はなかなかなく、途中に遅いケーブルやHUBが介在するわけですね。
ただし、画面転送の速度が遅いと利用者側はいらつくでえしょう。目の前のマシンならリブートしてしまえば良い話なのですが、リモートマシンは簡単にリブートというわけにはいかないのですね。Windows を使う以上、「使っていると重くなる」のは必然的なことで、定期的なバックアップや再起動といった処理が必要となるか、管理者がクレームを把握して再起動するなどの処理が重要になります。
今はBYODの世の中ですから、タブレットからちょっとこの処理がをしたいとかと言ったニーズが増えることも考慮しなければなりません。
ということでSSD は仮想環境で実力を出すか SUSE+XEN で検証してみました。
islandcenter.jp
by islandcenter
| 2013-07-07 16:00
| プライベートクラウド
|
Comments(0)
