私の会社は、いくつかの別個の、しかし関連性のある、中程度のヒットのWebサイトをホストしています。したがって、本番データベースサーバー、ステージングデータベースサーバー、本番Webサーバー、ステージングWebサーバーなどが必要です。私の質問は、ニーズごとに物理的に別々のサーバーに投資するべきか、それともそのお金をまとめてはるかにハイエンドのサーバーに投資し、前述のすべてのサーバーを仮想化するべきかということです。皆さんはどのルートを決めますか、そしてその理由は何ですか?
3 に答える
それは多くのことに依存します。主な考慮事項は次のとおりです。
使用率が低から中程度のサーバーが多数ある場合、通常、仮想化により、ハードウェア、電力、および床面積のコストを節約できます。ただし、VM レイヤー自体のオーバーヘッドに基づく転換点があります。正直なところ、これについて適切なコスト/パフォーマンスのバランスを見つけるには、実験する必要があります. VM ベンダーは喜んで計算を手伝ってくれるはずです。
欠点は、仮想化によって単一障害点が生じることです。そのボックスが失敗すると、すべてのサーバーでダウンタイムが発生します。それらを別々にすると、すべてが一度にダイビングする可能性がはるかに低くなります。
確かに、開発サーバーと本番サーバーを物理的に分離する必要があります。開発で何かを行うと、本番環境がホストされているマシンがダウンする可能性があることを心配する必要はありません。また、開発には、物理マシンのハードリセットまたはハードリセットを回避するためのばかげた回避策のいずれかを実際に必要とするいくつかの問題があります。
本番Webサーバーと本番データベースに関しては、同じマシン上で仮想化することによって新しい障害点を実際に導入することはありません。特に、静的バージョンのサイトを別のサーバーに同じ場所に配置できる場合はそうです。中程度の複雑さの最新のWebサイトの場合、データベースの障害はとにかくWebサイトの障害です。
私の経験から、使用量が少ないか中程度の場合は、VM が最適です。いくつかの適度に強力なサーバーではなく、非常に強力なサーバーを 1 つだけ使用すると、お金、電力、スペースを節約でき、同時に実行中のアプリケーションを高速化できます。より高速なハードウェアで。
VM にも同様の別の利点があります。サーバー ハードウェアに障害が発生した場合、同じ VM を別の物理ハードウェアにロードして、何事もなかったかのように実行し続けることができます (完全なバックアップがありますよね?)。実際の運用サーバーを開発マシンで分離して実行し、運用環境でのみ発生する厄介なバグをデバッグします。
しかし、私は開発 (およびおそらくテスト) サーバーを本番とは別の物理マシンに配置します。開発中にどんな愚かな間違いを犯したとしても、本番サーバーがダウンしないようにする必要があります。