I/O があれば、同じマシンに 3 つの異なるデータベース エンジンをロードしても問題はありません。 それらを処理するためのプロセッサ帯域幅 - 何を投げても、Unix がほぼその仕事を実行することを信頼できます。 それ。
Windows 2000 カーネルは、複数のアプリケーションを同時に処理する能力を十分に備えていますが、Windows レジストリにも同様の処理が必要です。 Microsoft が Small Business Server などの統合製品に導入している編集 -- 1 つあたり 1 つの NIC を使用しない限り、Microsoft のネットワーク スタックも同様です 応用。 その結果、Windows 仮想化は、使用頻度の低い複数のアプリケーションを、互いに干渉することなく同じボックス上で実行および保守できるようにする、完全に合理的な方法を提供します。
Unix 側では、それが BSD、Linux、Solaris のいずれを意味するかは関係ありませんが、現在の Microsoft の問題も、当時の IBM の問題も存在しません。 回避策は存在しますが、それはそれらが必要だからではなく、メインフレームと Windows 環境の人々が回避策を持たなければならないと主張しているからです。
Unix を使用すると、同じマシン上で複数のアプリケーションを安全に実行できます。遭遇する技術的な問題はほとんど、またはまったくありません。 システムリソースの相互作用を最小限に抑えることに関係し、フェイルオーバー管理やネットワークなどの外部との関係も多くあります。 接続性。 ただし、最も重要な違いはテクノロジーではなく、それを使って何をしようとしているかにあります。 リソースはユーザー時間よりも安価であり、価値はユーザーの向上にあるため、使用率は重要ではなくなります。 サービス。
一般に、統合は使用率とサービスの向上の両方につながりますが、重要なのは使用率ではなく、より良いサービスです。 それはうまく図示されていました Sun と Manugistics が発行したプレスリリース 昨日。 その中で、36 個の USIV CPU を搭載した Sun 20K マシンを使用して、Manugistics Fulfillment v7.1 ベンチマークで新しい世界記録を樹立したと報告しています。
これは Sun にとって前向きな結果ですが、ここで重要なのは彼らのやり方です。 以前の記録保持者 (IBM P5-590) と比べて 23% の速度の利点と 45% の価格/パフォーマンスの利点の両方を得るために、データベースとアプリケーション セットの両方を同じマシン上に配置しました。 Unix はクライアントサーバーではないことを思い出してください。SMP と高速バックプレーンがあるのに、なぜ比較的遅いネットワークを使用するのでしょうか?
Unix 統合におけるマシンの考慮事項には、通常、メモリ、ネットワーク、プロセッサ管理におけるオペレーティング システムの制限ではなく、適切なスケーリングが含まれます。 I/O があれば、同じマシンに 3 つの異なるデータベース エンジンをロードしても問題はありません。 それらを処理するためのプロセッサ帯域幅 - 何を投げても、Unix がほぼその仕事を行うと信頼できます。 それ。
一方で、一般的な企業の PC ネットワークを同程度に信頼することはできません。 統合を機能させるための重要な要素は、ユーザーのデスクトップではなく、ユーザーのデスクトップでの応答を測定することです。 サーバ。 サーバーの負荷が軽いにもかかわらず、ネットワークがユーザーを待たせていることがよくありますが、そのような状況では、 サーバーを統合し、サービスを提供するユーザーに電気的に隣接してサーバーを配置し、サーバーをクリーンアップするための資金を予算委員会に戻します。 通信網。
実際のところ、統合能力を制限するのは Unix テクノロジではないため、パーティショニングや仮想化などの回避策は必要ありません。 必要なのは、使用需要パターンをよく理解すること (そして、どこが間違っていたかを発見したら、喜んで変更すること) です。 あなたの成功は、ユーザーのニーズを満たすことにかかっており、毎月何百人ものユーザーを待たせてハードウェアに数千ドルを節約できるかどうかではありません。 日。 これが統合の本当の結論です。ユーザー時間を最小限に抑えることがキャパシティをアイドル状態にしておくということであれば、そうして笑ってください。キャパシティは安くても、ユーザー時間はそうではないからです。