複数のサーバーと1つの大きなサーバーのパフォーマンス
私の開発者チームは、私たちが開発している次のプロジェクトのサーバー構造を提案しました。私たちの構造は「論理的」です。つまり、アプリケーションのさまざまな論理コンポーネント（分散型コンポーネント）は異なるサーバーに依存しています。一部のコンポーネントは他のコンポーネントよりも重要であり、より多くの負荷がかかります。
私たちの提案は、コンポーネントごとに1台のサーバーを用意することでしたが、ハードウェア担当者は、さまざまなマシンを仮想サーバーを備えた単一のより大きなマシンに置き換えることを提案しました。彼らはブレードサーバーを使うつもりです。
さて、私はまったく専門家ではありませんが、みんなへの私の質問は次のとおりでした：たとえば、3つの2GHz CPU/2GB RAMマシンが必要な場合、あなたは私に1台のマシンを与えます3つの2GHzCPUと6GBのRAM同じですか？彼らは私にそう言った。
これは正確ですか？両方のソリューションの長所または短所は何ですか？一般的に受け入れられているベストプラクティスは何ですか？問題を扱っているURLリファレンスを指摘していただけますか？
編集：
いくつかのより多くの情報。 （インターネット/イントラネット）アプリケーションはすでに階層化されています。 DMZにページをインターネットに公開するサーバーがいくつかあり、データベースは独自のマシン上にあります。分割したい（そして参加したい）のは、主に公開するいくつかのWebサーバーです。 1つはデータベースレイヤーと通信するDAL、1つはページごとに1回呼び出されるシングルサインオン/ユーザープロファイルアプリケーション、もう1つはインターネット上で見られるもののクローンであり、LANで使用されます。
それらの要件が少し「ウーリー」に聞こえ、実際にはかなり低いことを考えると、これを仮想化することを強く望んでいます。まず、2つのブレードといくつかの共有ストレージから始めます。その後、必要に応じてVMを作成、変更、削除できます。パフォーマンスが大幅に低下し、柔軟性が大幅に向上します。さらに、直線的にスケールアウトできます。ユーザーへの影響。
重大なボトルネックがどこにあるか、または発生する可能性があるかを特定するのが正しい方法だと思います。 VMは分離に最適であり、使用するハイパーバイザーの種類によっては、実際のパフォーマンスにほとんど影響を与えない場合があります。仮想ネットワークは、おそらく物理ネットワークよりもうまく機能するでしょう。
ただし、冗長性があるため、物理マシンをいくつか用意することをお勧めします。 100万台のVMを搭載した1台の物理サーバーがある場合、その1台の物理サーバーが停止すると（そして停止すると）、100万台のVMが停止します。
すべての卵を1つのバスケットに入れないでください！
彼らはあなたに単一のブレードシャーシを提供することについて話しているのですか？もしそうなら、それはまだ多くの個別のサーバーであり、住宅ユニットに含まれているだけだからです。彼らが文字通り多くを実行するための1つの強力なサーバーについて話している場合、彼らは（おそらく）ブレードについて話していません。
とにかくブレードのことを無視して、これが私の見解です。アプリが複数の小さなサーバー間でうまくスケーリングする場合は、そうしてください。小さいサーバーは購入するのが安く、サーバーを追加することで簡単に横方向に拡張できます。個々のアプリは、サーバーがほとんどある場合、より確実に動作する傾向があります。
ただし、極端な点もあります。アーキテクチャを少なくとも2つのレイヤー（フロントエンドとデータベース）、または3つのレイヤー（フロントエンド、アプリケーション、データベース）に分割することはかなり一般的ですが、システムの絶対的なモンスターを作成しない限り、そうすることはあまりありません。それを超える必要があります。
開発中のシステムについて、さらに情報を提供できますか？使用しているプラットフォームの種類、OS、言語、ユーザーベース、開発ライフサイクル？
EDIT：編集に基づいて、さらに質問があります-現在の構成の制限要因は何ですか？ RAMが不足していませんか、ディスクの読み取り速度が十分でないか、またはDBからレコードを十分に速く引き出すのに問題がありますか？ CPUを使い果たしましたか？あなたが今持っているものの制限要因は、あなたがこれで行く必要がある場所の主な舵取りであるべきです。
3 2GHz CPU/2GB RAMマシンで、3つの2GHzCPUと6GBのRAM同じですか？同じですか？ 。
いいえ同じではありません。仮想化プラットフォームに応じて、ハイパーバイザーレイヤーからのオーバーヘッド（5〜30％のどこか）が発生します。
両方のソリューションの長所または短所は何ですか？
詳細がないと難しいですが、ここにいくつかの一般性があります
利点：
- OSライセンスの方が安くなる可能性があります-ベンダーの多くは、VM OSライセンスの料金を請求しないか料金を下げます
- 移植性-スケーリングの問題やハードウェアの変更が必要な場合はVM）なので、ハードウェアを変更または追加するのは簡単です。
- 効率-すべてのVMが物理ボックスで利用可能なすべてのリソースを利用していない場合、そのCPUとRAMは無駄になります。別のマシンがより多くのリソースを必要とする場合は、新しいシステムを購入する時期です。仮想マシンを使用すると、より多くのリソースを必要とするシステムに、使用可能なリソースのプールからより多くのリソースを割り当てることができます（これもハイパーバイザーによっては自動的に発生する場合があります）
- テスト/開発環境は本番環境とまったく同じです。ほとんどのプラットフォームでは、マシンを新しいネットワークに複製して、本番環境に展開する前に「実際の」環境でパッチなどをテストできます。
短所：
- パフォーマンスのトラブルシューティングはより問題があります-簡単に言えば、相互に影響を与える可動部品が多くあります。ハイパーバイザーに問題がありますか、ホストで問題を引き起こしている他のマシンがありますか？運が良ければ、IOPSがボトルネックになります。つまり、ディスクまたはキャッシュを追加購入する必要があります。
- システム要件は少し高くなります-通常、システムが十分に活用されておらず、電力などでいくらかの現金（長期）を節約したいために仮想化していますが、ハイパーバイザーのオーバーヘッドのため、MHzが必要になる前にMHzが必要になった場合は、ハイパーバイザー
- 追加の管理-仮想化後は、以前と同じ管理負担とハイパーバイザーが発生します。ハイパーバイザーの選択と通行料によっては、これは問題にならない場合があります
- コスト-短期的には、おそらくもっと高くなるでしょう。私は3つのシステムを取り、それらを1つの物理的なボックスに配置しません。なぜなら、その1つのボックスに障害が発生した場合、私のサービスは完全に停止するからです。通常、3つのシステムが必要です（コストの目的で、通常、リソースを2倍にするよりも1/3のオーバーヘッドを追加する方が予算が安くなります）。
特定のケースでは、これらのシステムのいずれかがダウンした場合にサービスが停止する場合は、1つのシステムが問題ない可能性があります。その場合、リスクは追加されていません。また、これらのシステムは6Ghzの処理能力を必要としないようです。この場合、これら3台のマシンだけで6Ghzを購入することはないため、統合によって確実にコストを節約できます。注意する必要があるもう1つのことは、（そして確かに特に考慮に入れて）I/O要件と潜在的なI/O競合です。
別の方法として、これらのWebサービスが同じマシン上で共存できる場合は、同じサービスで2つのVMを作成し、クラスタリングを使用するか、1つを単にスタンバイ状態にしておくことを検討することもできます。
URLについては、をご覧ください
単一サーバーのセットアップは、有益な場合と非常に悪い場合があります。 3台を維持するよりも1台のサーバーを維持する方が簡単で、サーバーがダウンするとすべてがダウンします。
複数のサーバーをセットアップすると、区分化できますが、3つのサーバーのいずれかがダウンし、他の2つが機能するためにサーバーに依存している場合は、同じ場所にいるため、これは役に立たない可能性があります。
以下によっては、間違っている可能性があります。
- 64ビットアプリケーション/ OS /データベースを使用していますか？そうでない場合、32ビットに固執すると、それ以上4GBを使用できなくなり、すべてのアプリケーションがデフォルトで2GBの物理RAMを「共有」します。
- ストレージはどうですか？このサーバーは、より強力なストレージコントローラーとあなたの（x3）と同じ数のディスクを取得する必要があります。ソリューションで多くのストレージを使用していない場合は、おそらくそうではありません
- リスク：この固有のサーバーを緩めたり再起動したりすると、すべてが失われます。 3つのうちの1つがダウンしている場合にも当てはまるかもしれません
建築は数学ほど単純ではありません。しかし、詳細がなければ、これ以上アドバイスすることはできません。
容量要件は、負荷テストと経験的データによって最もよく決定されます。予測やインスピレーションを得た当て推量に頼らないでください。
可用性は別の問題です。確かに、複数のサーバーは1つよりも優れています。アーキテクチャに影響を与える他の要因があるかもしれません。特にこれがオープンソースではなく、サーバーごとのライセンス料がかかる場合、またはロイヤルティの支払いが必要なサードパーティコンポーネントを使用している場合は、主にコストがかかります。