Ads by Google
物理サーバと仮想サーバの比較
Physical vs Virtual Servers
元記事：http://etbe.coker.com.au/2008/11/29/physical-vs-vi... (2008/11/29)
SlicehostとLinodeの比較とサーバのスケールアップの記事[1]についたコメントで、物理サーバを占有するのと、仮想化されたサーバを全て利用するのとでは違いが無いのではないか？という指摘を受けた。
In a comment on my post about Slicehost, Linode, and scaling up servers [1] it was suggested that there is no real difference between a physical server and a set of slices of a virtual server that takes up all the resources of the machine.
コメントにはさらに仮想化されたマシンのほうが管理が楽だとも指摘されていた。プロバイダーのサーバルームに物理マシンを置いた場合にはいろいろと監視しないといけないことがある。各部の温度だとか、各パーツの稼動状況だとかだ。物理サーバを自前で管理する場合には、ＯＳのメンテナンスだってしなくてはならない。プロバイダがサーバを持っているなら、プロバイダーのスタッフが管理することになる。そういう各所の温度などの管理データとサーバを管理するのはシステム管理者の仕事だが、あるサーバが死にそうだということが管理データからわかるなら、ユーザが全部を掌握していたほうがいい。
The commentator notes that it’s easier to manage a virtual machine. When you have a physical machine running at an ISP server room there are many things that need to be monitored, this includes the temperature at various points inside the case and the operation of various parts (fans and hard disks being two obvious ones). When you run the physical server you have to keep such software running (you maintain the base OS). If the ISP owns the server (which is what you need if the server is in another country) then the ISP staff are the main people to review the output. Having to maintain software that provides data for other people is a standard part of a sys-admin’s job, but when that data determines whether the server will die it is easier if one person manages it all.
もし、あるマシンの全ての資源(Dom-0が消費するわずかな分を除いて)を使うようなXenのDom-Uのインスタンスを利用しているなら、もしあるディスクが死にそうなら、プロバイダーのスタッフがRAIDの再構築の期間（その間、サーバのパフォーマンスは低下するだろう）を知らせてくれれば、いつでもディスクを交換してもらっていい。もっと深刻なサーバの障害が認められた場合には、サーバのインスタンスを別のマシンに移動(live migration)してもいい。このlive migrationがスムーズにできるのなら、仮想化の大きなメリットと言っていいだろう。
If you have a Xen DomU that uses all the resources of the machine (well all but the small portion used by the Dom0 and the hypervisor) then a failing hard disk could simply be replaced by the ISP staff who would notify you of the expected duration of the RAID rebuild (which would degrade performance). For more serious failures the data could be migrated to another machine, in the case of predicted failures (such as unexpected temperature increases or the failure of a cooling fan) it is possible to migrate a running Xen DomU to another server. If the server migration is handled well then this can be a significant benefit of virtualisation for an ISP customer.
他に、Xenでは起動時に設定された以上のメモリを使うようにメモリ領域を拡大できるが、まだ自分は試したことはないので、どれくらいうまく動くのかは知らない。
もしこれが有効ならば、メモリの少ないサーバで起動して、本当にメモリが必要になった時点で、十分なメモリを持ったサーバにmigrationする、という手も使えるだろう。
Also Xen apparently supports having RAM for a DomU balloon out to a larger size than was used on boot, I haven’t tested this feature and don’t know how well it works. If it supports ballooning to something larger than the physical size in the original server then it would be possible to migrate a running instance to a machine with more RAM to upgrade it.
問題は、仮想化利便性は、パフォーマンスダウンのコスト見合うのか？ということだ。
アプリケーションの負荷が、ちょうど1台の物理サーバにフィットするケースというのは稀だと思う。大抵は、サーバの性能のごく一部しか使わないようなアプリケーションがほとんどだ。そして、複数のサーバのパワーを必要とするようなアプリケーション（そんなアプリを作ってみたいものだ）もそれほど多くない。（そこは自明だろう）
The question is whether it’s worth the cost. Applications which need exactly the resources of one physical server seem pretty rare to me. Applications which need resources that are considerably smaller than a single modern server are very common, and applications which have to be distributed among multiple servers are not that common (although many of us hope that our projects will become so successful ;).
したがって、ポイントは、仮想化によるオーバーヘッドのコストが、複数のサーバの資源をあわせて1台の仮想サーバを作り上げるメリットに見合うかということだ。１ＣＰＵで動くプログラムを並列処理に書き換えるのは開発コストがかかるし、１台のサーバのパワーを向上させるには、指数的にコストがかさんでしまうから、この方面では仮想化は大きなメリットがあるだろう。
他に、遅延の問題がある。IOには多少時間がかかるようになるのは避けがたい。CPUの負荷が10％にすぎなくても、メモリがいくら余っていても、レスポンスは多少悪化するだろう。でも、それはネットの遅延に比べれば微小だろう。
So the question of whether it’s worth the cost is often really whether the overhead of virtualisation will make a single large machine image take more resources than a single server can provide (moving from a single server to multiple servers costs a lot of developer time, and moving to a larger single server exponentially increases the price). There is also an issue of latency, all IO operations can be expected to take slightly longer so even if the CPU is at 10% load and there is a lot of free RAM some client operations will still take longer, but I hope that it wouldn’t be enough to compete with the latency of the Internet - even a hard drive seek is faster than the round trip times I expect for IP packets from most customer machines.
VMwareはVMwareとXenと素のマシンの性能比較をした興味深いベンチマークの結果を公開している。これは2007年に行われたもので、基本的にXenに対するVMwareの優位性を示そうとしたものだが、結果としてどちらも満足のいく性能を示している。テストの中には32bitのWindowsシステムを動かしたものが含まれているが、サービスプロバイダは少ないメモリで済む32bitのインスタンスを使ってもらいたいだろうから、これは自然なことだろう。
ところで、一つ不満なのは、整数演算の項目では、VMwareが素のマシンの80％の性能なのにXenでは60％にもならない理由が説明されていないことだ。それ以外の項目ではどちらの仮想化Windowsは満足のいく性能が出せている。
VMware has published an interesting benchmark of VMware vs Xen vs native hardware [2]. It appears to have been written in February 2007 and while it’s intent is to show VMware as being better than Xen, in most cases it seems to show them both as being good enough. The tests involved virtualising 32bit Windows systems, this doesn’t seem an unreasonable test as many ISPs are offering 32bit virtual machines as 32bit code tends to use less RAM. One unfortunate thing is that they make no explanation of why “Intger Math” might run at just over 80% native performance on VMware and just under 60% native performance on Xen. The other test results seem to show that for a virtualised Windows OS either VMware or Xen will deliver enough performance (apart from the ones where VMware claims that Xen provides only a tiny fraction of native performance - that’s a misconfiguration that is best ignored). Here is an analysis of the VMware benchmark and the XenSource response (which has disappeared from the net) [3].
CambrigeのXenの開発者は、良く知られたベンチマークテストを使って１つのDom-Uが素のサーバの90％以上の性能を引き出しているという結果を公表している。
The Cambridge Xen people have results showing a single Xen DomU delivering more than 90% native performance on a variety of well known benchmarks [4].
大抵のテストケースで素のマシンの90％以上の性能が引き出せるということは、通常のアプリケーションがマシンの９０％以上の性能を必要としないという事実と考え合わせれば、素のマシンをわざわざ使ってわずかの性能向上を引き出す利点は少ないといえる。
As it seems that in every case we can expect more than 90% native performance from a single DomU and as the case of needing more than 90% native performance is rare it seems that there is no real difference that we should care about when running servers and that the ease of management outweighs the small performance benefit from using native hardware.
今ではSlicehostは、性能を全部引き出す用途に向けたメニューを用意している。仮想サーバのメモリのメニューは256MBが最小でその上は倍々になっていくのだが、15.5GBというメニューがあるのだ。これは、物理サーバの全メモリの１６ＧＢのうち、ハイパーバイザーとDom-0のために必要最低限の512MBを割り当てて、それ以外の全てをXenのDom-Uに割り当てたものだといえる。
このメニューの弱点があるとすれば、サーバのＩＯ性能は全て使いたいが、そんなにメモリは要らないというアプリケーションのユーザにとって無駄があるということだろう。しかし、管理の規格化を考えれば、特定のユーザのためにわざと特注のメモリ半分の８ＧＢのマシンを管理するくらいなら、標準の１６ＧＢのマシンを占有させたほうがプロバイダーは楽だし、コストも下げやすいかもしれない。
Now it appears that Slicehost [5] caters to people who desire this type of management. Their virtual server plans have RAM going in all powers of two from 256M to 8G, and then they have 15.5G - which seems to imply that they are using physical servers with 16G of RAM and that 15.5G is all that is left after the Xen hypervisor and the Dom0 have taken some. One possible disadvantage of this is that if you want all the CPU power of a server but not so much RAM (or the other way around) then the Slicehost 15.5G plan might involve more hardware being assigned to you than you really need. But given the economies of scale involved in purchasing and managing the large number of servers that Slicehost is running it might cost them more to run a machine with 8G of RAM as a special order than to buy their standard 16G machine.
他の仮想サーバのホスティング会社は、サーバの占有を認めていない。最大でもマシンの1/4か1/5の資源しか割り当てられない。インスタンスのサイズを制限するのは、他の物理マシンにmigrateする際に容易だからかもしれない。
Other virtual hosting companies such as Gandi and Linode clearly describe that they don’t support a single instance taking all the resources of the machine (1/4 and 1/5 of a machine respectively are the maximums). I wonder if they are limiting the size of virtual machines to avoid the possibility of needing to shuffle virtual machines when migrating a running virtual machine.
物理マシンを占有するひとつの大きな利点は、そのマシンの上で仮想化ができて、その設定をいじれるということだ。あるDom-Uの負荷が大きくなったら、他のDom-Uの資源(RAM, CPU)を解放して、重いDom-Uに割り振ることができる。こういうサービスをしているところは寡聞にして知らない。Slicehostがそういうサービスをしてくれるなら、私のお客のひとつは確実にSlicehostに乗り換えるだろう。
One significant benefit of having a physical machine over renting a collection of DomUs is the ability to run virtual machines as you desire. I prefer to have a set of DomUs on the same physical server so that if one DomU is running slowly then I have the option to optimise other DomUs to free up some capacity. I can change the amounts of RAM and the number of virtual CPUs allocated to each DomU as needed. I am not aware of anyone giving me the option to rent all the capacity of a single server in the form of managed DomUs and then assign the amounts of RAM, disk, and CPU capacity to them as I wish. If Slicehost offered such a deal then one of my clients would probably rent a Slicehost server for this purpose as soon as their current contract runs out.
仮想サーバのホスティングにはまだまだサービスの開拓の余地があると思う。ここに書いたようなことはすぐに実現するのではないだろうか。私の顧客には、仮想サーバのサービスに関してはあまり長期（１年程度だが）の契約を結ばないように、と、アドバイスしている。
It seems that there is a lot of potential to provide significant new features for virtual hosting. I expect that someone will start offering these things in the near future. I will advise my clients to try and avoid signing any long-term contracts (where long means one year in the context of hosting) so that they keep their options open for future offers.
Physical vs Virtual Servers
元記事：http://etbe.coker.com.au/2008/11/29/physical-vs-vi... (2008/11/29)
SlicehostとLinodeの比較とサーバのスケールアップの記事[1]についたコメントで、物理サーバを占有するのと、仮想化されたサーバを全て利用するのとでは違いが無いのではないか？という指摘を受けた。
In a comment on my post about Slicehost, Linode, and scaling up servers [1] it was suggested that there is no real difference between a physical server and a set of slices of a virtual server that takes up all the resources of the machine.
コメントにはさらに仮想化されたマシンのほうが管理が楽だとも指摘されていた。プロバイダーのサーバルームに物理マシンを置いた場合にはいろいろと監視しないといけないことがある。各部の温度だとか、各パーツの稼動状況だとかだ。物理サーバを自前で管理する場合には、ＯＳのメンテナンスだってしなくてはならない。プロバイダがサーバを持っているなら、プロバイダーのスタッフが管理することになる。そういう各所の温度などの管理データとサーバを管理するのはシステム管理者の仕事だが、あるサーバが死にそうだということが管理データからわかるなら、ユーザが全部を掌握していたほうがいい。
The commentator notes that it’s easier to manage a virtual machine. When you have a physical machine running at an ISP server room there are many things that need to be monitored, this includes the temperature at various points inside the case and the operation of various parts (fans and hard disks being two obvious ones). When you run the physical server you have to keep such software running (you maintain the base OS). If the ISP owns the server (which is what you need if the server is in another country) then the ISP staff are the main people to review the output. Having to maintain software that provides data for other people is a standard part of a sys-admin’s job, but when that data determines whether the server will die it is easier if one person manages it all.
もし、あるマシンの全ての資源(Dom-0が消費するわずかな分を除いて)を使うようなXenのDom-Uのインスタンスを利用しているなら、もしあるディスクが死にそうなら、プロバイダーのスタッフがRAIDの再構築の期間（その間、サーバのパフォーマンスは低下するだろう）を知らせてくれれば、いつでもディスクを交換してもらっていい。もっと深刻なサーバの障害が認められた場合には、サーバのインスタンスを別のマシンに移動(live migration)してもいい。このlive migrationがスムーズにできるのなら、仮想化の大きなメリットと言っていいだろう。
If you have a Xen DomU that uses all the resources of the machine (well all but the small portion used by the Dom0 and the hypervisor) then a failing hard disk could simply be replaced by the ISP staff who would notify you of the expected duration of the RAID rebuild (which would degrade performance). For more serious failures the data could be migrated to another machine, in the case of predicted failures (such as unexpected temperature increases or the failure of a cooling fan) it is possible to migrate a running Xen DomU to another server. If the server migration is handled well then this can be a significant benefit of virtualisation for an ISP customer.
他に、Xenでは起動時に設定された以上のメモリを使うようにメモリ領域を拡大できるが、まだ自分は試したことはないので、どれくらいうまく動くのかは知らない。
もしこれが有効ならば、メモリの少ないサーバで起動して、本当にメモリが必要になった時点で、十分なメモリを持ったサーバにmigrationする、という手も使えるだろう。
Also Xen apparently supports having RAM for a DomU balloon out to a larger size than was used on boot, I haven’t tested this feature and don’t know how well it works. If it supports ballooning to something larger than the physical size in the original server then it would be possible to migrate a running instance to a machine with more RAM to upgrade it.
問題は、仮想化利便性は、パフォーマンスダウンのコスト見合うのか？ということだ。
アプリケーションの負荷が、ちょうど1台の物理サーバにフィットするケースというのは稀だと思う。大抵は、サーバの性能のごく一部しか使わないようなアプリケーションがほとんどだ。そして、複数のサーバのパワーを必要とするようなアプリケーション（そんなアプリを作ってみたいものだ）もそれほど多くない。（そこは自明だろう）
The question is whether it’s worth the cost. Applications which need exactly the resources of one physical server seem pretty rare to me. Applications which need resources that are considerably smaller than a single modern server are very common, and applications which have to be distributed among multiple servers are not that common (although many of us hope that our projects will become so successful ;).
したがって、ポイントは、仮想化によるオーバーヘッドのコストが、複数のサーバの資源をあわせて1台の仮想サーバを作り上げるメリットに見合うかということだ。１ＣＰＵで動くプログラムを並列処理に書き換えるのは開発コストがかかるし、１台のサーバのパワーを向上させるには、指数的にコストがかさんでしまうから、この方面では仮想化は大きなメリットがあるだろう。
他に、遅延の問題がある。IOには多少時間がかかるようになるのは避けがたい。CPUの負荷が10％にすぎなくても、メモリがいくら余っていても、レスポンスは多少悪化するだろう。でも、それはネットの遅延に比べれば微小だろう。
So the question of whether it’s worth the cost is often really whether the overhead of virtualisation will make a single large machine image take more resources than a single server can provide (moving from a single server to multiple servers costs a lot of developer time, and moving to a larger single server exponentially increases the price). There is also an issue of latency, all IO operations can be expected to take slightly longer so even if the CPU is at 10% load and there is a lot of free RAM some client operations will still take longer, but I hope that it wouldn’t be enough to compete with the latency of the Internet - even a hard drive seek is faster than the round trip times I expect for IP packets from most customer machines.
VMwareはVMwareとXenと素のマシンの性能比較をした興味深いベンチマークの結果を公開している。これは2007年に行われたもので、基本的にXenに対するVMwareの優位性を示そうとしたものだが、結果としてどちらも満足のいく性能を示している。テストの中には32bitのWindowsシステムを動かしたものが含まれているが、サービスプロバイダは少ないメモリで済む32bitのインスタンスを使ってもらいたいだろうから、これは自然なことだろう。
ところで、一つ不満なのは、整数演算の項目では、VMwareが素のマシンの80％の性能なのにXenでは60％にもならない理由が説明されていないことだ。それ以外の項目ではどちらの仮想化Windowsは満足のいく性能が出せている。
VMware has published an interesting benchmark of VMware vs Xen vs native hardware [2]. It appears to have been written in February 2007 and while it’s intent is to show VMware as being better than Xen, in most cases it seems to show them both as being good enough. The tests involved virtualising 32bit Windows systems, this doesn’t seem an unreasonable test as many ISPs are offering 32bit virtual machines as 32bit code tends to use less RAM. One unfortunate thing is that they make no explanation of why “Intger Math” might run at just over 80% native performance on VMware and just under 60% native performance on Xen. The other test results seem to show that for a virtualised Windows OS either VMware or Xen will deliver enough performance (apart from the ones where VMware claims that Xen provides only a tiny fraction of native performance - that’s a misconfiguration that is best ignored). Here is an analysis of the VMware benchmark and the XenSource response (which has disappeared from the net) [3].
CambrigeのXenの開発者は、良く知られたベンチマークテストを使って１つのDom-Uが素のサーバの90％以上の性能を引き出しているという結果を公表している。
The Cambridge Xen people have results showing a single Xen DomU delivering more than 90% native performance on a variety of well known benchmarks [4].
大抵のテストケースで素のマシンの90％以上の性能が引き出せるということは、通常のアプリケーションがマシンの９０％以上の性能を必要としないという事実と考え合わせれば、素のマシンをわざわざ使ってわずかの性能向上を引き出す利点は少ないといえる。
As it seems that in every case we can expect more than 90% native performance from a single DomU and as the case of needing more than 90% native performance is rare it seems that there is no real difference that we should care about when running servers and that the ease of management outweighs the small performance benefit from using native hardware.
今ではSlicehostは、性能を全部引き出す用途に向けたメニューを用意している。仮想サーバのメモリのメニューは256MBが最小でその上は倍々になっていくのだが、15.5GBというメニューがあるのだ。これは、物理サーバの全メモリの１６ＧＢのうち、ハイパーバイザーとDom-0のために必要最低限の512MBを割り当てて、それ以外の全てをXenのDom-Uに割り当てたものだといえる。
このメニューの弱点があるとすれば、サーバのＩＯ性能は全て使いたいが、そんなにメモリは要らないというアプリケーションのユーザにとって無駄があるということだろう。しかし、管理の規格化を考えれば、特定のユーザのためにわざと特注のメモリ半分の８ＧＢのマシンを管理するくらいなら、標準の１６ＧＢのマシンを占有させたほうがプロバイダーは楽だし、コストも下げやすいかもしれない。
Now it appears that Slicehost [5] caters to people who desire this type of management. Their virtual server plans have RAM going in all powers of two from 256M to 8G, and then they have 15.5G - which seems to imply that they are using physical servers with 16G of RAM and that 15.5G is all that is left after the Xen hypervisor and the Dom0 have taken some. One possible disadvantage of this is that if you want all the CPU power of a server but not so much RAM (or the other way around) then the Slicehost 15.5G plan might involve more hardware being assigned to you than you really need. But given the economies of scale involved in purchasing and managing the large number of servers that Slicehost is running it might cost them more to run a machine with 8G of RAM as a special order than to buy their standard 16G machine.
他の仮想サーバのホスティング会社は、サーバの占有を認めていない。最大でもマシンの1/4か1/5の資源しか割り当てられない。インスタンスのサイズを制限するのは、他の物理マシンにmigrateする際に容易だからかもしれない。
Other virtual hosting companies such as Gandi and Linode clearly describe that they don’t support a single instance taking all the resources of the machine (1/4 and 1/5 of a machine respectively are the maximums). I wonder if they are limiting the size of virtual machines to avoid the possibility of needing to shuffle virtual machines when migrating a running virtual machine.
物理マシンを占有するひとつの大きな利点は、そのマシンの上で仮想化ができて、その設定をいじれるということだ。あるDom-Uの負荷が大きくなったら、他のDom-Uの資源(RAM, CPU)を解放して、重いDom-Uに割り振ることができる。こういうサービスをしているところは寡聞にして知らない。Slicehostがそういうサービスをしてくれるなら、私のお客のひとつは確実にSlicehostに乗り換えるだろう。
One significant benefit of having a physical machine over renting a collection of DomUs is the ability to run virtual machines as you desire. I prefer to have a set of DomUs on the same physical server so that if one DomU is running slowly then I have the option to optimise other DomUs to free up some capacity. I can change the amounts of RAM and the number of virtual CPUs allocated to each DomU as needed. I am not aware of anyone giving me the option to rent all the capacity of a single server in the form of managed DomUs and then assign the amounts of RAM, disk, and CPU capacity to them as I wish. If Slicehost offered such a deal then one of my clients would probably rent a Slicehost server for this purpose as soon as their current contract runs out.
仮想サーバのホスティングにはまだまだサービスの開拓の余地があると思う。ここに書いたようなことはすぐに実現するのではないだろうか。私の顧客には、仮想サーバのサービスに関してはあまり長期（１年程度だが）の契約を結ばないように、と、アドバイスしている。
It seems that there is a lot of potential to provide significant new features for virtual hosting. I expect that someone will start offering these things in the near future. I will advise my clients to try and avoid signing any long-term contracts (where long means one year in the context of hosting) so that they keep their options open for future offers.
* [1] http://etbe.coker.com.au/2008/11/27/slicehost-vs-l...
* [2] http://www.vmware.com/pdf/hypervisor_performance.p...
* [3] http://www.cmg.org/measureit/issues/mit41/m_41_1.h...
* [4] http://www.cl.cam.ac.uk/research/srg/netos/xen/per...
* [5] http://www.slicehost.com/
Ads by Google
このページへのコメント