おそらく、単一のホストを使用し、それらすべての間でリソースを共有することによって多くのインスタンスを「エミュレート」できる仮想化に精通しているでしょう。おそらくXENについて聞いたことがあるでしょう。
XEN の「反対」を想像するのは完全に正気ではありませんか?単一の実行中のインスタンスで複数のホストを抽象化するレイヤーです。これにより、「クラスタリング」レイヤー自体をあまり気にする必要のないアプリを構築できると思います。
一部の人々がすでにどこかでそれに取り組んでいると確信しているので、これに対する技術的な制限は何だろうと思います:)
目標は、いかなる種類の障害回復も達成することではありません。これはより高いレベルで処理できる (そして処理すべきか?) と思います。たとえば、MySQL サーバーを巨大なインスタンス (たとえば 50 台のホストで構成) で実行できる場合、MySQL のレプリケーション機能を使用して、同様の仮想インスタンスにデータベースを簡単に複製できます。
良い質問。Microsoft Azure は、アプリケーションを「クラウドに」配置できるようにすることで、この問題に対処しようとしています。これにより、スケーラビリティのアップ/ダウン、冗長性、データ ストレージなどを気にする必要がなくなります。しかし、これはハイパーバイザー レベルでは実現されません。
http://www.microsoft.com/windowsazure/
ハードウェア的には、すべてを多数の小さな VM ではなく 1 つの大きな VM にすることには、いくつかの欠点があります。1 つには、ソフトウェアはすべてのリソースの処理方法を常に理解しているわけではありません。たとえば、一部のアプリケーションはまだ複数のプロセッサ コアを処理できません。私は、IIS が同じリソースを 1 つの巨大なインスタンスよりも複数のインスタンスに分散する方が優れていることを示す非公式のベンチマークを見てきました。
管理の観点からは、場合によっては複数の VM を使用する方がよい場合があります。不適切な展開によってノードが破損することを想像してください。それが唯一の (巨大ではありますが) ノードだった場合、アプリケーション全体がダウンしています。
おそらく、コンセプトSingle System Imageについて話しているでしょう。
以前は Linux の実装であるopenMosixがありましたが、その後閉鎖されました。代替品は知りません。openMosixにより、標準の Linux カーネルで SSI を作成して使用することが非常に簡単になりました。残念なことに、イベントに追い越されました。
私は Xen について十分に知りませんが、それが可能かどうかはわかりませんが、VMware を使用すると、多くの物理ホストからリソースのプールを作成できます。その後、VM にリソースを割り当てることができます。これは、多数の VM の場合もあれば、1 つの VM の場合もあります。 集約: 分離されたリソースを共有プールに変換
複数の物理コアで単一のコアをシミュレートするのは非常に非効率的です。できますが、クラスターよりも遅くなります。2 つの物理コアは、ほぼリアルタイムで相互に通信できます。これらの 2 つの物理コア (および RAM) が別々のマシン上にある場合は、マザーボードの速度を 10 倍以上下げるなどのことを行っています。光ファイバーネットワークでも通信しています。
デュアル コアは、同じマザーボード上の 2 つの個別の CPU よりも高速に通信できます。それらが別々のマシン上にある場合はさらに遅くなり、複数のマシンがある場合はさらに遅くなります。
基本的には可能ですが、達成したい正味のパフォーマンスの向上と比較して、正味のパフォーマンスの低下があります。
実際の例では、デュアル クアッド コア サーバー (コアあたり約 2.5 GHz) で多数の VM を実行していましたが、本来のパフォーマンスをはるかに下回っていました。詳しく調べてみると、個々の VM の負荷が 2.5Ghz を超えると、ハイパーバイザーは単一の 3.5 ～ 4Ghz コアをエミュレートしていたことが判明しました。各 VM を 2.5Ghz に制限した後、パフォーマンスは期待どおりに戻りました。
私はsaidimuに同意します.Single System Imageのコンセプトについて話している. OpenMosix プロジェクトに加えて、同じアイデアの商用実装がいくつかあります (最新の例の 1 つは ScaleMP です)。それは新しい考えではありません。
ここでは、SSI の技術的なポイントについて詳しく説明したいと思います。
基本的に、それが行われていない理由は、パフォーマンスが一般的に絶対に予測できないかひどいものだからです。[NUMA][3] として知られるコンピュータ システムの概念があります。これは基本的に、メモリのさまざまな部分にアクセスするコストが均一ではないことを意味します。これは、CPU がいくつかのメモリ アクセスを別のチップにルーティングする可能性がある巨大なシステム、またはメモリがネットワーク経由でリモート アクセスされる場合 (SSI など) に適用できます。通常、オペレーティング システムは、プログラムができるだけ速く実行できるようにプログラムとデータをメモリに配置することで、これを補おうとします。つまり、コードとデータはすべて同じ NUMA「リージョン」に配置され、可能な限り最も近い CPU でスケジュールされます。
ただし、大規模なアプリケーションを実行している ( SSI 内のすべてのメモリを使用しようとしている) 場合、リモート メモリ フェッチの影響を軽減するためにオペレーティング システムができることはほとんどありません。MySQL は、ページ 0x1f3c にアクセスすると 8 ナノ秒かかることを認識していませんが、ページ 0x7f46 にアクセスすると、ネットワーク経由でメモリがフェッチされる間、数百マイクロ秒、場合によってはミリ秒の間停止します。これは、この種の環境では、NUMA に対応していないアプリケーションががらくた (真剣に、非常に悪い) のように動作することを意味します。私の知る限り、ほとんどの最新の SSI 製品は、マシン間の最速の相互接続 (Infiniband など) に依存して、まずまずのパフォーマンスを達成しています。
これは、データにアクセスする真のコストをプログラマーに公開するフレームワーク (MPI: メッセージ パッシング インターフェイスなど) が、SSI や DSM (分散共有メモリ) アプローチよりも多くの牽引力を達成した理由でもあります。実際、プログラマーがアプリケーションを SSI 環境で実行するように最適化する方法は基本的にありません。