ハイパーバイザー関連
●KVM
Agentのインストールが必要。（たいした事ないが）
CPU
SpeedStepが作動する
リソース変更はlibvirtがcgroupを使って制御している。
KSMが使える。動作させるイメージの数を制限すれば、オーバーコミットも可能？
I/O
仕様的に期待できない。（えっというほどではないが。)
ボリュームのイメージフォーマットはqcow2なので、I/Oは期待できない。
さらにvhost-netは、DHCPのアドレス取得などに問題があるため利用できない。
●XenServer
Agentのインストールが不要。
CPU
SpeedStepが作動しない。これは大変まずい。
リソース変更は、xeコマンドのVCPUs-paramsを使って制御している。
稼働中のインスタンスのSteal値の監視が必要となる。
Paravirtual kernelが廃れてしまったので面倒だなぁ。。。
I/O
イメージフォーマットがLVMダイレクトなので、ディスクパフォーマンスは速い。
ネットワークも普通にパフォーマンスは出るはず。
ハイパーバイザー関連コメント
KVMは、データセンターでホスティングするような事業者向き。少ないハードウェアリソースで沢山のサービスを行う。ある程度OSのイメージが限定されているケースでは、KSMでパワーを発するかと思う。
XenServerは、ハードウェアの販売や、リソースで価格付けをするようなSIの業者に向いている。オーバーコミットが出来ない分、ハードが販売できるし、各インスタンスのリソース制御もKVMようにトリックを使っていないからリソースのパワーが正しく保証できる。
さらに、CloudStackのサブスクリプションを購入すると、XenServerのサブスクリプションも付いてくる。これ注目！
普通に利用するならば、どちらでも構わないが、私はKVM推し。Xenのテクノロジーは、XenSourceが買収されてからパッとしないし、KVMやVMwareで普通に実装されている機能が未だ実装されていない。（気分の問題と捉えるならばそれでも構わないが。）あと、SpeedStepが利用できなく、ParaVirtual Kernelを今更使うというのはちょっと。。。
●構成全般
・計算機サーバにある程度ローカルディスクの容量があると、インスタンスのイメージをNFSではなく、ローカルに置ける。
・利用するテンプレートタイプの数を少なくし、１インスタンス以上動作していると起動が速い。（気がする。）
・CPUの総クロック周波数がインスタンスで利用できる最大リソース。
例えば、Xeon 2GHz (6core/12thread)のCPUの場合、2GHzx12=24GHzのリソースが利用できる。
AMDのCPUは安いが、HTが使えないため思った以上にインスタンスの稼働はできないかもしれない。結局台数が増えるだけ。（Atomで大量のサーバをさばくよりもCore i7で集約したほうがユニット数、オーバーヘッド数、電源容量の現象につながる。）
ただ、AMDでそろえたほうが、全部物理CPUなのでパフォーマンスはいいかもしれない。
（AMD推しの気持ちもわかる。）
・オーバーヘッド計算
ハイパーバイザーのオーバーヘッド以外に、system vmのリソースが必要なのに注意
sec strg/console/routerで CPU 1.5GHz/Mem 1.5GB。
ちなみに、Eucalyptusとの比較
Amazon AWSとかなり互換をもっているが、CloudStackと大きな違いがあった。
それは、インスタンスが物理CPUに依存してしまう。
例えば、ハイパーバイザーが載っているハードウェアが4coreの場合、そのハイパーバイザーが稼働できる1 vcpuのインスタンスは４インスタンスまで。クロック周波数の総和が効かない。よって、CloudStackと比較すると、膨大な量の計算機ノードが必要となる。構築費用もかさみ、コスト高。動かすだけなら構わないが、サービスとなると採算がかなり厳しい。（ならばAmazon AWSを使うほうがいい。絶対。）
0 件のコメント:
コメントを投稿